2

How can bitcoin & lightning support a full planet adoption rate of settlements?

Just trying to understand how this works, and whether or not this might be a problem.

Lets imagine Bitcoin is finally adopted, and most people use it. For 8000M-10.000M inhabitants that means probably between 2000M and 5000M "households" or individual Bitcoin account parties.

Imagine most of those households follow the regular recommendations, they will hold their own coins in their own wallets.

For daily usage, they will have a considerable part of their BTC locked up in the Lightning Network, so they can spend quickly even small amounts of satoshis.

But, also per recommendations (last time I checked) they should want to settle their BTC from time to time to the layer 1 Bitcoin network. Specially if they want to save that money, which is what Bitcoin gives you that fiat took away by design.

So if millions of parties want to settle at a pace of 7 transaction per second we get:

  • 2000M parties would be able to settle every 3306 days, meaning 1 settlement per 9 years!
  • 5000M parties would do 8267 days per settlement, 1 settlement every more than 22 years!

Let's do the it other way around. Imagine we want to know how many tps we need if 2000M-5000M parties want to settle monthly. That means between 800 tps to 2000 tps.

I understand that we want the Bitcoin blockchain to be as lean as possible, so all history fits on a regular computer you can have at home, not a huge expensive cloud instance, which would make the network centralized.

But still, how can bitcoin & lightning cater for a full planet adoption rate of settlements?

Maybe we need to forget about individual holdings as adoption grows?

Maybe people wanting to settle will be a minority? (less than 18Millions parties monthly for instance)

Improve this question

3 Answers 3

Reset to default
1

I think your misunderstanding comes from a few points which I will try to cover as best as I can:

1: The scalability of bitcoin is not meant to rely on the base layer. The base layer of bitcoin is meant to be a completely robust, byzantine fault tolerant, backwards compatible, censorship resistant, and 100% verifiable ledger. To achieve this you need to make certain kinds of trade offs, and you also need to realize the fundamental assumptions of anything you may be changing. For example, if the core software were to "hard fork" in a way that would make old scripts defunct, it would ruin the coins of the original bitcoin supporters which is obviously not in the benefit of the network. Bitcoin was designed in a way that allows us to work with in a relatively modular consensus mechanism, every single upgrade that has been done to Bitcoin is done through SOFT forks which have never rendered old bitcoin scripts defunct. Thus the choice to deal with the limitations has actually lead to our transactions becoming extremely small and succinct over time in order to save block space, and increase transactions per block. We can even include several participants in a single signature which starts to scale down the block size even more. The point is, the base layer of bitcoin is the only example of a completely backwards compatible long-term modular and scaling up each year network that exists. If you compare it to ETH for example( their chain is over 1TB and is newer than bitcoin, that is not scalable at all, i literally have 3$ on my eth address from 2 years ago that is more expensive in fees to move than the eth costs and it has not changed, seems like a ponzi scheme to me honestly) , the bloat of transactions is not even close due to the way they handle memory in the EVM. Bitcoin solves this by not shooting itself in the foot in the first place, and focusing on backward compatible code that fits within soft fork upgrades.

2: The scalability of bitcoin (and any other blockchain) DOES rely on alternative layers built on top of bitcoin. Lightning network is only the FIRST most popular example of a protocol that uses satoshis that already exist in order to produce a network effect of near instant payments. There are many issues with lightning network, but that being said there are more layers being built than just them. There is the liquid "financial" side-chain developed by blockstream, in which you can participate in decentralized swaps which also have faster finality times than the base layer. There is rootstock, a "pow-peg" side chain which uses merge mining to brige people in and out of the system, they allow smart contracts to be built on top of them and have a faster settlement time than the btc base layer. ALL of these extra layers on top of bitcoin enable the scalability, and if you haven't noticed we are literally within the first few years of them even existing.

3: What are the implications? The implications are that max scalability is NOWHERE NEAR complete for bitcoin, and no one has stopped working on it at any point. It is probably true that we could have more people working on the issue, but if you have been paying attention the vast majority of the "crypto" space is not concerned with backwards compatibility, decentralization, soft forking, consensus, decentralized layering, compression, or even scalability. Instead the majority of the space continues to chase the carrot on the stick of flashy ape-like marketing schemes and un-realistic yield farming re-hypothicatoion scenarios. There really is a more positive outlook on the future of bitcoin scalability if you care to dig in to the existing work being done.

Improve this answer
6
  • 1
    Thanks for the very complete answer!
    – user1098300
    Jan 23 at 7:44
  • 1
    I wonder if that multiple parties signature feature can allow for "shared funds": a single transaction output being shared by N participants with constraints such as participant A can spend up to X, participant B up to Y, and so on. In essence a single transaction output can become tenths or hundreds or individual transactions under the hood. I guess not. We probably require another layer o side chain to keep the accounting and some new op codes to allow for checking those constraints in the base layer.
    – user1098300
    Jan 23 at 8:12
  • No problem, it is important to understand how new this all is relative to other fields of study so it is understandable that everyone has questions relating to how it all works. Its better that people ask some questions rather than no one asking anything. To answer the second part, I am not as much of an expert as I would like to be on bitcoin multi-signatures however I am quite optimistic that the scenario you have described is possible to accomplish. I have heard similar descriptions of multi-sig protocols before, but as for the specific one I unfortunately do not know.
    – Poseidon
    Jan 23 at 19:02
  • A 2 of 2 multi-sig format works basically like this: p1 has funds f1 p2 has funds f2 In utxo model chains such as bitcoin these funds (f1, f2) are called outputs or unspent outputs. To lock them together in a multi-signature one of them can fund some kind of script which basically says provide the valid signature for public key p1 AND p2 in order to spend the output within this script. Then when it is funded by the other party it retains the same characteristic, you can also set a timelock on the contract so that the initiator can reclaim their funds if the co-party does not cooperate.
    – Poseidon
    Jan 23 at 19:06
  • The type of signature you describe is basically an any of n so it would allow any parties to sign the script at any time assuming they have some valid output they can spend in this script. I imagine this only takes a bit of extra logic to say something like: it is possible for p1 to spend output f1 without the signature of p2 in this case. But like I said, I am still learning about the technical details. Either way this is a highly important field of research and I encourage you to study it if you are interested in setting it up yourself. I am still getting started with bitcoin scripting
    – Poseidon
    Jan 23 at 19:21
1

But, also per recommendations (last time I checked) they should want to settle their BTC from time to time to the layer 1 Bitcoin network. Specially if they want to save that money, which is what Bitcoin gives you that fiat took away by design.

No, you don't need to close or splice-out from a channel "from time to time". A lightning network channel can be indefinite, though you need your node or watchtowers to be online so they can notice if someone tries to publish an old state on the timechain (blockchain), and if you catch them doing so you can claim the whole channel balance.

I know I'm not answering you question at a whole but just wanted to make this clear. 😉

Improve this answer
1
  • Thanks for your reply! I guess I need to look again into how lighting actually works and specially about the security posture. I guess my worry is if, when there are hundreds of millions of users if we may hit some scalability issue. I am totally fine with people not wanting to settle in layer 1, the problem would be they cannot even if they wanted to.
    – user1098300
    Feb 20, 2022 at 9:27
0

The demand for transactions reflects in the transaction fees.

If they become prohibitively expensive for additional adoption, Bitcoin will either have to adapt or it will tremendously suffer as a payment network (on top of the difficult accounting compliance we already have for individuals).

Two possible solutions I see:

  1. Modify Lightning so that you can expand channels to new addresses without having to publish anything on the blockchain. I don't know how feasible is this.
  2. Increase block size. Hopefully in the future, storage, bandwidth, and processing power will be cheap enough to still have a lot of network nodes in spite of the larger blocks. And hopefully those transaction fees will sustain enough proof-of-work mining to keep the network secure (as of now, including the block reward, we have >$900k/h which I think is plenty). This was the approach taken by Bitcoin Cash and Bitcoin SV, but sadly the market did not reward them with adoption.

Failing to do either of the two will mean Bitcoin will become an asset only for people who can afford to burn a lot on transaction fees. Which means, centralized ownership.

It looks like a proof-of-work cryptocurrency is a trade-off between centralized ownership (high txn fees) and centralized mining (large block size). The ideal point on this spectrum remains to be discovered.

Improve this answer
4
  • you cant commit to things on the blockchain off the blockchain, that makes no sense. I have my issues with lightning, but to imagine that its the only scalability solution for bitcoin represents a lack of willingness to do the research. Lightning is merely the most popular member of the first round of bitcoin scaling layers.
    – Poseidon
    Jan 21 at 7:19
  • There is no reason for the receiving end of a transaction to commit to the blockchain, if the sender does not attack. Ideally the sender could just give them the un-broadcast transaction. In case of an attack by the sender, the recipient could broadcast it.
    – danuker
    Jan 27 at 13:50
  • That is not true, when someone spends coins to you that is the receiving end of the blockchain. If that spend is not registered on chain you can spend it again registering the off-chain spend illegitimate.
    – Poseidon
    Jan 27 at 21:28
  • Just being able to rebroadcast is not enough, you need the sender to send to a multi-signature 2 of 2 with a timelock that the receiver agrees to. The sender needs to send the receiver a hash pre image that they can use to unlock the senders side of the coins. You cannot just rely on rebroadcasting without timelocks. Better yet if there is no need for reversal you should make it only spendable by the multisig that way only the second party could spend and the first party could just send them a hash preimage.
    – Poseidon
    Jan 27 at 21:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.