I won't answer to this closed-minded way of thinking, but to this:

Take a look on the dates of those posts. They're not the same. In 2020, I didn't even know how Bitcoin works technically. I was literally a newbie.

It's clear that we won't ever agree that Lightning does scale. In my opinion, it does as it minimizes the transactions that happen on-chain and therefore, the weight of the chain. In your opinion, it doesn't as ITs' NoT BiTCoIn! But, that's okay. Everything's relative.

Huh?

Alas, they do use it. They use the Bitcoin network to create channels. They couldn't have Lightning if they didn't have the first layer. And the existence of the Lightning contributes to those who want to only use the first layer. The transactions which would occur on-chain by those who use Lightning, did not happen. The chain weights less!

Another misinterpretation? What else have I said? That I want your death, because I requested a ban? That I hate Bitcoin, because LN iS nOt BiTCOiN? That I'm Satoshi, because <irrelevant reasons>? Quote me wherever I cursed Bitcoin principles for one more time and I'll show to everyone you just misunderstood my sayings...

Imagine anyone using '2MB Bitcoin' in a brick-and-mortar store, waiting 10 minutes for confirmation..
Or what about buying $1 coffee with $0.08 (absolute minimum!) fee? Sounds like nothing at first, but it's an 8% fee.
Block size doesn't change confirmation time and transaction cost, no matter if the mempool will always be empty or not. Because 1sat minimum is not negligible, especially in the future!

How about microtransactions at the cent-level to e.g. pay for music or movie streaming by the second? Or low-value digital items? Every time a fee of at least 250 sats? At the moment it's only 8 cents, but if Bitcoin reaches $1 million, that will be ~$2.5 for every transaction at 1 sat/vB MINIMUM FEE!

Much rather opening a channel for 2 bucks instead and use it basically for free afterwards..

Also let's not forget in other countries economies, $0.08 is not 'nothing', like for us. Wages can be >10x lower, so that would be already like $1 for them, at low low Bitcoin prices of $30k. Imagine what happens at $100k or more.

These are not mutually exclusive either. You can be a super hardcore Bitcoin supporter with even multiple full nodes, but prefer to pay through Lightning (from one of those nodes or LN app, whatever), in stores, for micropayments or other stuff, for example.

---

It's just one extra capability of LN. If people want to switch from Bitcoin to another coin, it should be their freedom to do so and it's possible already today through something that we call 'exchange'... Don't you think?

You got it! We scale Bitcoin by taking some weight off its back (the blockchain)... We take actual, real Bitcoin transactions and move them between users without storing every movement on the ledger. This is why we call it 'scalable'.
Any on-chain scaling mechanism is limited to some very hard bounds and thus can't be called 'scalable'.
Like, a 2x throughput increase (2MB blocks) is not 'scaling'. That's a freaking tiny constant factor. It's not nearly enough for global adoption.

I see, you like numbers. Let's go ad absurdum.
Assume every node operator has a 100Mbit internet connection (not all do) and unlimited computing power so a block is completely verified in 1 nanosecond.
This means in 10 minutes (600s) he can transmit 60,000Mbits or 7.5GB. This will be the absolute biggest block size.

The smallest possible Bitcoin transaction is 166 Bytes in size.
A 7.5GB block (biggest 'scaling' you can do on-chain) can thus contain 7,500,000,000/166=45,180,722 transactions, or 75,301 tx/s.
This would suffice for worldwide usage.

Though then we run into a storage issue: 7.5GB/10min is 0.75GB/min or 1080GB/day. After 10 years, the blockchain will have the size of 3,944,700GB or 3,944 Terabytes. This requires over 200 18TB Seagate HDDs, basically buying 20 of them every single year. This is a rate of around 2 Seagate 18TB HDDs per month.

At current MSRP of $600 per drive, that gets rather expensive.
And don't forget about the magical instant-multi-GB-block-verifying CPU and fully saturated 100Mbit/s internet connection (this is the most realistic bit about this whole thought experiment now that I think about it).

Now, you will say, we don't need 75k tx/s. That's true. What if we want to replace VISA and Mastercard (no normal bank transfers)? From what I can gather, together they typically have 5k tx/s.
So if we go from 75k to 5k, that's just a factor of 15. Meaning instead of having 3,944 Terabytes of data after 10 years, we will have only 263TB. That's still 15x $600 drives, driving your node cost upwards of $9000.
If this doesn't drive centralization, I don't know what will.

So you think every Bitcoin user has to 'protect' and 'help' Bitcoin? And that nobody should be allowed to use Bitcoin if they're not running a node at home?

Also, as I said earlier, running a node and using LN is not mutually exclusive.

I'm not shying away! Then we say the blocks stay at 1MB?
Let's say you magically get a transaction down to 10 Bytes each (impossible but let's say it).

That's 100,000 tx/block (maximum 'transaction count increase'). This would yield 166 transactions per second. Clearly not enough.

It's not about how many it does right now, it's more about how many it can do.
Lightning can definitely do that many transactions per second. It would be extremely easy: 160 users send a transaction to their peer at the same time. We have thousands of these channels already.... so if needed, LN can already provide that speed.

As I showed you, Mastercard + VISA perform roughly 5,000tx/s.

I find it a very weak argument that only because very few people use Bitcoin, it doesn't need a way of scaling.
Because that assumes Bitcoin usage will (and should) never change, and at most by a very small constant factor.

To set things clear: you don't want Bitcoin to replace rival existing banking systems? Because to do so, it does need to reach at least VISA + Mastercard speeds. These 2 networks don't even include bank transfers, which can also be replaced by Bitcoin.

Nononono I already showed how much data it will use if we scale block size. Then you said you want to reduce transaction size instead, so I gave you the best chance with my assumption that we can get a transaction down to incredible 10MB (that was in YOUR favour!!) and that it still only would do ~160tx/s.

Okay, so you want to simply incrase block size to 4MB, why did this require 12 pages? Everyone here's trying to figure out what you actually want propose. Just state right away: 'I want Bitcoin to have X block size and reduce transaction size and that's my scaling solution'. Let's say you can then do around 4x the transactions of pre-segwit Bitcoin (7tx/s), that puts you at 28. This works if adoption only slightly rises.

It also doesn't allow for micropayments which happen much more frequently than 'purchasing X things per day'. For example, when listening to a podcast on Breez, I can pay them 10sats/min (so 1tx/min). I would be sending 60 transactions a day if I were to listen for a podcast a day, opposed to the 1-5 transactions you are claiming. Of course you will say that microtransactions are unnecessary and stupid, but the fact is many people would like something like that. I accept your opinion that you don't need or like it though.

Just trying to say that since LN 'truly scales' (not 4x constant factor, that's not really scaling), you can do things that were not possible before.

This all sounds simple and fun, but it's not a real scaling mechanism. It's small improvements here and there, that maybe bring you from 7tx/s to 28, 50 or maybe even 100. In the end, there will be a constant factor formula to get from block size to transactions/s.

However, if you get the load off the blockchain and people send commitments back and forth off-chain, the throughput will be completely independent from block- and transaction sizes. That's the beauty of it. With the same base numbers, you can handle 10, 100 or 1000s of users and transactions, because they're essentially only limited by their internet connection speeds amongst each other.

Wait, who is forcing anyone? Anyone can use whatever they want. In fact, I'm wondering why you're feeling so forced to use stupid Bitcoin with cludgy SegWit, silly LN developers and pruned-node-fanatics. There are Bitcoin forks out there with 4MB blocks, no SegWit and no LN.........

I'm a little bit disappointed you showed no interest in my 7.5GB... numbers, since you like to post so many yourself, but no worries..

The following post is a continuation of the discussion which started here.

---

And that's how you learned that "Routing" type messages do not contain any routing instructions or liquidity information.



Again, just because you can technically fit some data inside ping/pong messages, it doesn't mean that the other node expects it. In fact, you should not send any data using them:



So, as per specifications, the data sent through ping/pong messages is just a bunch of zeros.


Feel free to name those privacy-oriented wallets which do not follow the specifications to improve the privacy of their users.


As Z, you won't learn about the CW channel, but you can still learn about AB, BC, CD, DE from either W, who can learn about them from C, or from some outside node which had received a gossip message about any of those channels. W can safely forward gossip messages from C as those messages are exactly the same for every hop.

All messages are encrypted so it doesn't really matter what you put inside (still, the specs recommend using zeros). The overall size of the message is more important as standardised messages have a fixed size, so a third-party might try to guess what you are talking about with some other node.


I have no idea where you got the "private updates" from. Your quote suggests that you can create synthetic traffic in combination with BOLT04. In other words, for example, you can send ping messages while routing a payment to pretend that the payment was split or forwarded to a different node. You just need to send a ping message with the same size as "update_add_htlc".


Encryption keys are changed every 500 uses. Ping/pong messages count as one use. As ping/pong messages are sent frequently, they are the cause of frequent key rotations. They are not used to exchange new keys. No extra data is sent here.


Let me explain my point again. Here's what you said before:


Yes, technically you can fit this information in there. However, an optional TLV payload was not a part of the initial specs and the Lightning Network works well without depending on it. Here's how I replied to you:


None of the existing wallets or implementations expects information about fees, ctlv timelock or liquidity in the TLV payload. They would ignore it. Sure, you could modify your client to behave this way, but you would still have to comply with the specifications to be able to talk with other nodes without any problems. So, if the TLV payload is not used to exchange this information, what's your next idea?


If we assume that all of the C's channels are private then you are almost correct (you forgot about DE). Although, "DNS network bootstrap map" is not really a suitable name for DNS bootstrapping used by new nodes and a local map of the network maintained by every node. Technically, any Lightning node can be listed in the DNS seeds.


What's the point of discussing what the Lightning Network could look like if we can't come to agreement how pathfinding and payment routing works at the moment in existing implementations and wallets? Other people already have a hard time keeping up with our discussion, especially that we are constantly switching between private, public and disabled channels in examples.

Bumping the topic as I believe we've achieved a breakthrough.  After many years, franky1 has finally managed to articulate their grievances in a manner which can be interpreted:


The stance franky1 takes here is that backwards-compatible non-SegWit nodes are not following consensus.  It's certainly a... unique... interpretation, but that's not the point.

Their issue is that they don't like the consequences of their choice.  It's not enough for them that they can remain part of the network while declining to utilise, or even recognise, SegWit.  They feel diminished in their role, despite that being the path they chose.  Almost as though it's a form of discrimination to them.  It might sound like I'm reaching, but this point will be evidenced again below.



Again, franky1 reiterates his belief that non-SegWit nodes, with the new addition of non-Taproot nodes, are supposedly not following consensus, yet somehow remain part of the Bitcoin network.  And again expresses anthropomorphised feelings that backwards-compatible nodes are being treated unfairly somehow.  Given the choice between being a part of the network and being forked off the network, I'd have thought most people would be happy with being able to remain.  This, however, is not enough for franky1.  If he can't have what he wants, apparently no one can (except we can and do, in fact, have everything we want, he's simply in denial about it).



It's worth pointing out that Bitcoin's network has no concept of "true consensus" as franky1 chooses to define it.  After all, that's a notion which only exists in his imagination.  It's not a genuine thing here in the real world.  Consensus empirically does not function in the way franky1 describes above.  Yet he continues to argue that it "should" because the alternative is that he feels diminished in his role and that his non-SegWit node is treated as "lesser" because he is making the choice not to take part in that aspect of the available features.

I hope this gives people some fresh insights in how to handle this colossal man-baby and his ceaseless tantrums.

if doomad thinks bitcoin didnt have a true consensus.. then he is the idiot that does not understand bitcoin
but it is funny how i had to spend years dumbing things down to the most "explain like your 5yo" before he can understand the objections.... but thats on him. not me


he loves the fact that the consensus mechanism of 2009-2016 has been broken and bypassed. where he now wants to pretend it never existed.
that bitcoin never had a consensus (solution to byzantine generals problem)
but thats just his and his buddies that follow his narratives SHAMEFUL, manipulative, malicious, shenanigans and ignorant mind at play

i cannot believe how malicious doomad (and his chums) rhetoric is by saying that bitcoin doesnt and never had a true consensus. .. i understand why he says it. because his favoured subnetwork doesnt have a consensus system to protect their network value.  so he is selling a narrative that systems dont have nor need consensus and pretend bitcoin never had or needed one.. SHAMEFUL sales pitch

very shameful!!

the thing is

YOU idiots want to say that nodes with:
stripped blocks(non witness) that dont offer IBD seeding to peers.
and/or
pruned chains that dont offer IBD to peers.
nodes that dont verify every rule

you malicious deceitful fools are still deeming those nodes as being full nodes, pretending that they fully secure the network fully and are following consensus fully
BUT THEY ARE NOT

you lot do not care about making users risk aware or understand the variances and their impacts


..
consensus is where nodes need to majority be ready to verify new rules BEFORE a new rule is activated so that the nodes can verify the blockchain fully. and fully agree they have all verified all data and came to the same agreed end state

yet you IDIOTS what to have this stupid diluted insecure mashup of variant nodes of one brand, where people are still reliant on one brand even if they are not fully securing the network.

all so you lot can weaken bitcoins system by subversion so you lot can promote your crappy subnetwork as a 'solution' to limitations and flaws added by the devs that should not be putting these limits in but instead should be expanding and evolving bitcoin

take the new RBF. nodes that have full rbf disabled. when seeing a tx. keep the first seen. and thus are left falsely thinking the tx they see pending in the GUI is the one that will confirm. yet other nodes that use RBF will reject first seen and keep the higher fee spending utxo. thus nodes will have different mempools and different trust of whats pending to be confirmed. and thus ruining the risk based tolerance of acceptance of zero confirmation.

yep you lot wanted to break this zero-confirm tolerance because it impedes users that want to accept zero confirm. thus now they cant risk tolerate low value, are being told to use your stupid broke subnetwork as the replacement/solution to the zero confirm acceptance system

---

consensus is not about changing the rule and then if you dont like it, its too late go fork off to an altcoin

consensus is majority without manipulation(by pre-rejection-pre orphan miscounting). then would only activate a new feature if there is agreement by the masses(get a dictionary and learn consensus)


now go play with your silly subnetwork and stop abusing bitcoin with your charades that are malicious and only end goal is to ruin and stifle bitcoin to make your other silly non blockchain.non consensus network seem more attractive

you malicious manipulative vile people