Signature aggregation for scaling - what is possible?

[BrotherCreamy]

Hi guys,

I have spent a while reading about BIPs 340-342, but I'm struggling to find a definitive answer about how these BIPs will address scaling issues.

To give some context:
I am concerned with the future user scaling of Bitcoin. When there are 5 billion users, no individuals will be able to afford to transact on-chain - 5 billion people => 1 transaction per person per ~20 years - unless there is some highly scalable way of aggregating transactions.
Lightning does not address this problem. Lightning improves transaction speed and volume, but it does not solve the root problem of redeeming one's coins on-chain. There are proposed solutions such as channel factories, but these are still worthless without the possibility to redeem on-chain.
If no one can afford to redeem on-chain, we may as well just create a separate token called LNBTC and operate LN independent of Bitcoin.

My thought was that there needs to be some way of creating a multisig equal-value coinjoin/pool that allows a subset of the users in the pool to aggregate their signatures together and move their coins into another pool in a single transaction, while still retaining ownership of the coins.
Each pool may include thousands of equal-valued inputs. In order to spend your input, you would assemble a transaction with a subset of the pool participants which would have the effect of spending an amount from the pool that is proportional to the number of people in the subset.
This way users would be able to reduce their transaction fee to a small fraction of a standard transaction fee - e.g. 1/1000th of a regular transaction - *if* such a functionality was possible.

Marginal improvements in transaction cost - e.g. 50% cheaper, or even 95% cheaper - are still not enough to make Bitcoin scalable to billions of users.
Additionally, scriptless scripts which rely on a cooperative n-of-n keyspend branch are no good, since if even one user in the pool becomes non-responsive, the whole thing becomes unusable.

In my opinion, without such an aggregation functionality, Bitcoin is unable to be scaled in a decentralised manner.
There can still exist banks who issue promises backed by Bitcoin, which would solve the scaling problem in a centralised manner, but users would not have the means to redeem their coins in the event the bank breaks their promise.

Please tell me what you think.

Cheers,
BrotherCreamy

[1715155105]

1715155105

[1715155105]

1715155105

[1715155105]

1715155105

[1715155105]

1715155105

[jackg]

I don't think it'd reduce much size wise really and there might be better ways of doing this.

There may be a possibility size could be reduced by making mempool transactions bigger and storing old transactions as hashes so you submit the raw transaction (that could be hashed into your txid - the thing stored on chain) and then be able to spend your coins - such systems would come with a 10x+ reduction on transaction size but would likely take a lot of implementing imo.

[BrotherCreamy]

I don't think it'd reduce much size wise really and there might be better ways of doing this.

There may be a possibility size could be reduced by making mempool transactions bigger and storing old transactions as hashes so you submit the raw transaction (that could be hashed into your txid - the thing stored on chain) and then be able to spend your coins - such systems would come with a 10x+ reduction on transaction size but would likely take a lot of implementing imo.

I’m talking about some kind of imaginary signature aggregation scheme that provides the ability to see if a provided multisig Schnorr (or similar) signature is a subset of another.

For example, Alice, Bob and Carol craft a signature ABC to sign a multisig contract.
The resulting signature is a single 64 bit number, similar to Schnorr
Later, Alice and Bob wish to interact with this contract, but Carol is either unavailable or does not wish to participate.
Alice and Bob craft a signature AB and use it to sign a transaction to interact with the previous multisig contract.
This signature is also a single 64 bit number.

Is there any way to verify that AB is a subset of ABC, without any other information, that is extensible to k of n signers?
Even better, is there a signature scheme that gives verifiers information about how many participants k have signed of the original n - i.e. some algorithm which takes AB and ABC as inputs, and outputs 2. Or takes AB...k and AB...n as inputs, and outputs k?

It seems like it should not be possible, but I would like confirmation of this from someone who has a good understanding of cryptography.

The idea is that this would allow users to construct massive equal-value pools of BTC - perhaps thousands of participants - then when they wish to transact, instead of Alice creating her own transaction to pull her share out to send BTC to Tom, and Bob creating his own transaction to send his share to Tom, Alice and Bob can craft a transaction which sends both of their shares of the pool to Tom in a single transaction, even in Carol's absence, with no additional cost.

Thanks.

EDIT:
After doing some reading (https://eprint.iacr.org/2020/852.pdf), it seems like this could possibly be implemented in a roundabout way using FROST, by generating a Merkle tree with scriptpath spends for multiple threshold values.
For example, 1000 users get together to create an equal-value pool of total value 1 BTC - 100,000 sats per user. A number of threshold signature scriptpath spends are created, each with differing values of t (threshold value) - e.g. a 100 user, 0.1 BTC scriptpath spend, then a 200 user, and so on all the way up to the full size of the pool; or perhaps only up to half the pool size to preclude the possibility of diminishing the pool size too much, making spending too expensive for the remaining pool participants.

Then, if say 300 users wish to get together to spend their coins, they would each co-operatively sign a transaction for the 300 user threshold scriptpath, and provide the Merkle branch for that scriptpath to indicate the script they are using.
This way, a range of different subsets of users can spend their bitcoin co-operatively, without any additional cost. I imagine they would also have to co-operate with the users of the pool they are sending to, who would then need to provide the Merkle hash for the receiving pool as the receiving address.

EDIT 2:
Actually, I'm not sure how the change address would work - once the 300 users spend their share, where would the change go, considering we are operating under the assumption that the other pool participants are not available or not co-operating, and considering we don't know *which* 300 users are performing the spend? It would allow the same set of users to spend multiple times. So probably not possible.

[BlackHatCoiner]

When there are 5 billion users, no individuals will be able to afford to transact on-chain - 5 billion people => 1 transaction per person per ~20 years - unless there is some highly scalable way of aggregating transactions.

There's a big if lying here. What makes you think billions of people will be incentivized to make transactions with bitcoin? Only a tiny fraction of them currently knows bitcoin, few of which do self-custody. I don't say they might never recognize benefits, but there are unbelievably many people who don't want to be responsible for their funds, and prefer leaving them to a third party, and countless of others who don't have the technical knowledge to hold some properly.

Lightning does not address this problem. Lightning improves transaction speed and volume, but it does not solve the root problem of redeeming one's coins on-chain.

What's "redeeming one's coins" anyway? Lightning isn't a common IOU. Sure, the coins only move locally, off-chain, but the system requires no trust to work, and it does reduce the median transaction cost.

My thought was that there needs to be some way of creating a multisig equal-value coinjoin/pool that allows a subset of the users in the pool to aggregate their signatures together and move their coins into another pool in a single transaction, while still retaining ownership of the coins.

Have you checked CoinPool?

[jackg]

For example, Alice, Bob and Carol craft a signature ABC to sign a multisig contract.
The resulting signature is a single 64 bit number, similar to Schnorr
Later, Alice and Bob wish to interact with this contract, but Carol is either unavailable or does not wish to participate.
Alice and Bob craft a signature AB and use it to sign a transaction to interact with the previous multisig contract.
This signature is also a single 64 bit Is there any way to verify that AB is a subset of ABC, without any other information, that is extensible to k of n signers?
Even better, is there a signature scheme that gives verifiers information about how many participants k have signed of the original n - i.e. some algorithm which takes AB and ABC as inputs, and outputs 2. Or takes AB...k and AB...n as inputs, and outputs k?

From what I know, you should be able to add signature and be able to verify them (in some way) with a lot of assymetric algorithms.

Generally, you'd need the public keys of A, B and C to verify the ABC's signature.
If you then had that signature you could use it to spend and aggregate that new signature with other signatures (with just the txid being needed to spend that transaction - like already works). You'd probably have to make the transaction ID just be one of the transactions outputs and inputs though as the signature would be in a separate place and unverifiable - from a quick search, this was already done with segwit but still stores individual signatures afaik.

[BrotherCreamy]

When there are 5 billion users, no individuals will be able to afford to transact on-chain - 5 billion people => 1 transaction per person per ~20 years - unless there is some highly scalable way of aggregating transactions.

There's a big if lying here. What makes you think billions of people will be incentivized to make transactions with bitcoin? Only a tiny fraction of them currently knows bitcoin, few of which do self-custody. I don't say they might never recognize benefits, but there are unbelievably many people who don't want to be responsible for their funds, and prefer leaving them to a third party, and countless of others who don't have the technical knowledge to hold some properly.

Isn't everyone here basically betting on the idea that bitcoin will one day be the world's reserve currency? If that is your belief, then it only makes sense to concern yourself with issues related to scalability.
Regarding self-custody, sure, there will be bitcoin banks. They will just be able to trade receipts with one another and settle onchain at the end of every day, no need for Lightning or any other decentralised L2 technology.
I don't have a problem with other people using bitcoin banks, but also I don't really see any development in that space.
For my own purposes however I would like to see truly decentralised L2. I don't trust a bank not to lose their keys, have their customers' coins forcefully confiscated by government, or to rugpull me.

Lightning does not address this problem. Lightning improves transaction speed and volume, but it does not solve the root problem of redeeming one's coins on-chain.

What's "redeeming one's coins" anyway? Lightning isn't a common IOU. Sure, the coins only move locally, off-chain, but the system requires no trust to work, and it does reduce the median transaction cost.

Redeeming coins as in getting the coins into your L1 wallet. Even though Lightning is built around the idea that you can always close your channel and get your payout, if the cost of doing so is prohibitive then the L2 doesn't work - it's foreseeable that the cost of opening/closing a Lightning channel would be more than the balance of the channel for someone living in a third-world country.

My thought was that there needs to be some way of creating a multisig equal-value coinjoin/pool that allows a subset of the users in the pool to aggregate their signatures together and move their coins into another pool in a single transaction, while still retaining ownership of the coins.

Have you checked CoinPool?

CoinPool still doesn't address the scaling problem. Again, even if a single user in the pool theoretically has the power to unilaterally withdraw their funds, if it is cost-prohibitive then it might as well not exist as an option. If I'm keeping my life savings of 100,000 sats in a CoinPool, and the transaction cost is 50,000 sats, then the option to withdraw my funds unilaterally basically doesn't exist.
CoinPool still doesn't solve the problem of fees when redeeming your own share.

[BlackHatCoiner]

Again, even if a single user in the pool theoretically has the power to unilaterally withdraw their funds, if it is cost-prohibitive then it might as well not exist as an option.

There's a cost for everything. Perhaps there could be a mechanism, wherein the user who closes the channel / pool pays most, but there will always be a cost. If you increased the block size, the fee rate would surely drop, but the cost would later be translated in decentralization.

If I'm keeping my life savings of 100,000 sats in a CoinPool, and the transaction cost is 50,000 sats, then the option to withdraw my funds unilaterally basically doesn't exist.

You talk with numbers, but there's no indication that you will pay 50,000 sats for an on-chain transaction.

[NotATether]

There is one idea I cane up with which I [finally] gave a name to: Ephemeral Settlements.

I wrote about this a few days ago:

meanwhile what you describe sounds like a type of CoinJoin (sending multiple transactions at once)?

Well no, because CoinJoin transactions are actually quite large, and it is necessary to settle many transactions at once using a small amount of bytes if we want to see scalability improve at all.

MuSig is just the aggregation of all signatures in a multisig. My solution for scalability leverages MuSig for transactions where you have a bunch of inputs from different people, went to a single MuSig output held by all of them. A sort of "side-chain" can be started at this point, though it is ephemeral and for bitcoin transactions only, and only exists as long as the MuSig UTXO is not spent - this would be like the regular blockchain but with a very low difficulty that only accepts Proof-of-Works that have a MuSig signature from one of the participants (hence N will be very large).

To settle the transactions, the MuSig will be spent by the users (ideally all of them, but this is a diamond's rough edge I have not polished yet*) and the outputs will go to addresses according to the predefined arrangement.

I'm anticipating that in the distant future, the vast majority of Bitcoin transactions (remember, transactions - you still own your keys) will be settled on this new layer that has nothing to do with Lightning - this is going to be the Layer that makes payment networks like VISA obsolete.

*I'm thinking about introducing some centralized oracles from among the N participants - a "leader" as opposed to an anarchy/jungle law - who ensure that thieves who attempt to steal money from the system lose the funds they committed to it. Theft is not possible unless you are one of the participants in the settlement scheme. It would be more like the way Liquid does things, except anyone can make an oracle if they can convince other people to use theirs - so most nodes won't be controlled by a cartel of companies.

But let's polish it a little more now that you asked:

A settlement can be started by any person (with access to a bitcoin node) to create a settlement node on a second layer separate from LN.

Settlement nodes should be started by the person who wants to receive bitcoins: not every participant needs to run a settlement node.

A list of all settlement nodes are kept in each nodes' database: Nodes discover each other with P2P messages similar to Bitcoin Core. Starting a settlement node entails creating a WebSocket, hence the participants must remain connected to the internet at all times to connect to the settlement node's WebSocket.

People can give their public keys to the settlement node. A MuSig address with is created when the number of settlers (people who want to buy stuff) on the settlement node reaches a threshold. It will be a 1-of-N+1 MuSig, where N is the number of settlers and the extra pubkey/signature belongs to the settlement node. Also, the settlement node has each settler's public key. This is to generate the MuSig address and a "logical" Taproot address that is used for invoicing only and doesn't actually receive bitcoins.

Now these users can send and receive transactions to any invoice address on any settlement node. These transactions are collected in an ephemeral ledger by all settlement nodes.

In addition to the logical address, there is an associated physical address of any type. The settlement node uses this to create the coin distribution. At any time, a settler can request the settlement node to transfer his balance to L1, and he will receive a signed transaction that can he can broadcast.

When a new L1 block is mined, the ephemeral ledger is deleted and the settlement node uses his public key to create a L1 transaction that sends the virtual transaction amounts to the physical addresses. The remainder is sent to a new MuSig address with possibly a different N public keys.

In case a settler leaves the settlement node, the node makes a transaction that sends the settler's remaining balance to the physical address addresses to the settler's logical address.

A settlement node earns fees for aggregating transactions. The fees are stored in a ceil(N/2)-N MuSig address, where each public key belongs to a settlement node. If a node attempts to steal the balance of its local MuSig wallet, the nodes will forfeit its fees and distribute them among themselves.

Benefits:

- Scalable (thanks to MuSig)
- Instant settlement
- There are no timelocks, so connections can stay open indefinitely
- L1 state is updated at every block as opposed to when transactions end - this eliminates previous state attacks assuming honest settlement nodes (working on mitigations for the dishonesty part)

Drawbacks:

- Not private (public keys are shared)
- Settlement nodes must always be connected to the internet (working on a solution to allow honest funds recovery)

[BrotherCreamy]

There is one idea I cane up with which I [finally] gave a name to: Ephemeral Settlements.

I wrote about this a few days ago:

meanwhile what you describe sounds like a type of CoinJoin (sending multiple transactions at once)?

Well no, because CoinJoin transactions are actually quite large, and it is necessary to settle many transactions at once using a small amount of bytes if we want to see scalability improve at all.

MuSig is just the aggregation of all signatures in a multisig. My solution for scalability leverages MuSig for transactions where you have a bunch of inputs from different people, went to a single MuSig output held by all of them. A sort of "side-chain" can be started at this point, though it is ephemeral and for bitcoin transactions only, and only exists as long as the MuSig UTXO is not spent - this would be like the regular blockchain but with a very low difficulty that only accepts Proof-of-Works that have a MuSig signature from one of the participants (hence N will be very large).

To settle the transactions, the MuSig will be spent by the users (ideally all of them, but this is a diamond's rough edge I have not polished yet*) and the outputs will go to addresses according to the predefined arrangement.

I'm anticipating that in the distant future, the vast majority of Bitcoin transactions (remember, transactions - you still own your keys) will be settled on this new layer that has nothing to do with Lightning - this is going to be the Layer that makes payment networks like VISA obsolete.

*I'm thinking about introducing some centralized oracles from among the N participants - a "leader" as opposed to an anarchy/jungle law - who ensure that thieves who attempt to steal money from the system lose the funds they committed to it. Theft is not possible unless you are one of the participants in the settlement scheme. It would be more like the way Liquid does things, except anyone can make an oracle if they can convince other people to use theirs - so most nodes won't be controlled by a cartel of companies.

But let's polish it a little more now that you asked:

A settlement can be started by any person (with access to a bitcoin node) to create a settlement node on a second layer separate from LN.

Settlement nodes should be started by the person who wants to receive bitcoins: not every participant needs to run a settlement node.

A list of all settlement nodes are kept in each nodes' database: Nodes discover each other with P2P messages similar to Bitcoin Core. Starting a settlement node entails creating a WebSocket, hence the participants must remain connected to the internet at all times to connect to the settlement node's WebSocket.

People can give their public keys to the settlement node. A MuSig address with is created when the number of settlers (people who want to buy stuff) on the settlement node reaches a threshold. It will be a 1-of-N+1 MuSig, where N is the number of settlers and the extra pubkey/signature belongs to the settlement node. Also, the settlement node has each settler's public key. This is to generate the MuSig address and a "logical" Taproot address that is used for invoicing only and doesn't actually receive bitcoins.

Now these users can send and receive transactions to any invoice address on any settlement node. These transactions are collected in an ephemeral ledger by all settlement nodes.

In addition to the logical address, there is an associated physical address of any type. The settlement node uses this to create the coin distribution. At any time, a settler can request the settlement node to transfer his balance to L1, and he will receive a signed transaction that can he can broadcast.

When a new L1 block is mined, the ephemeral ledger is deleted and the settlement node uses his public key to create a L1 transaction that sends the virtual transaction amounts to the physical addresses. The remainder is sent to a new MuSig address with possibly a different N public keys.

In case a settler leaves the settlement node, the node makes a transaction that sends the settler's remaining balance to the physical address addresses to the settler's logical address.

A settlement node earns fees for aggregating transactions. The fees are stored in a ceil(N/2)-N MuSig address, where each public key belongs to a settlement node. If a node attempts to steal the balance of its local MuSig wallet, the nodes will forfeit its fees and distribute them among themselves.

Benefits:

- Scalable (thanks to MuSig)
- Instant settlement
- There are no timelocks, so connections can stay open indefinitely
- L1 state is updated at every block as opposed to when transactions end - this eliminates previous state attacks assuming honest settlement nodes (working on mitigations for the dishonesty part)

Drawbacks:

- Not private (public keys are shared)
- Settlement nodes must always be connected to the internet (working on a solution to allow honest funds recovery)

That's a nice idea but I still don't see how it reduces the number of onchain transactions required. If anything it increases the number of transactions required because it performs transactions on every block.

The core issue is what to do in the future when many many more people are using Bitcoin and so transactions become prohibitively expensive for individuals (or small groups). Imagine a transaction costs a thousand dollars - which is likely considering Bitcoin's throughput is no more than 10-20 transactions per second. Very very few individuals could afford to transact onchain more often than once a month or year. So opening and closing channels onchain (or settlements) would be cost prohibitive.

How can Bitcoin address this problem while remaining decentralised?

[BrotherCreamy]

Again, even if a single user in the pool theoretically has the power to unilaterally withdraw their funds, if it is cost-prohibitive then it might as well not exist as an option.

There's a cost for everything. Perhaps there could be a mechanism, wherein the user who closes the channel / pool pays most, but there will always be a cost. If you increased the block size, the fee rate would surely drop, but the cost would later be translated in decentralization.

If I'm keeping my life savings of 100,000 sats in a CoinPool, and the transaction cost is 50,000 sats, then the option to withdraw my funds unilaterally basically doesn't exist.

You talk with numbers, but there's no indication that you will pay 50,000 sats for an on-chain transaction.

Regardless of what the cost is in sats or dollars, the fact is that 500,000 transactions per day / 5 billion people = 1 transaction per person per 10,000 days.
Even if Bitcoin were one one-hundredth the size, it would still be 1 transaction per person per 100 days, which is unworkable - it would still be likely too expensive for anyone in the third-world, for example.

If everyone were using LN - assuming channel factories become a thing - then a large percentage of people would not be able to afford to receive any of their sats onchain.
Their theoretical ability to receive/redeem their LNBTC onchain would be meaningless, because the transaction cost would be a significant portion of their total wealth.

[n0nce]

Again, even if a single user in the pool theoretically has the power to unilaterally withdraw their funds, if it is cost-prohibitive then it might as well not exist as an option.

There's a cost for everything. Perhaps there could be a mechanism, wherein the user who closes the channel / pool pays most, but there will always be a cost. If you increased the block size, the fee rate would surely drop, but the cost would later be translated in decentralization.

Block size was never and will never be a sufficient scaling mechanism, at least not on its own.
If we talk about signature aggregation as a scaling mechanism, have a look at MuSig2 - it sounds pretty promising to me. Combining signatures off-chain instead of on-chain saves fees and blockchain space, while not requiring channel opening and closing transactions.

[...]
It's good that a MuSig2 BIP is finally about to roll though. It's about time that something like this happens and has profound implications in both scaling with off-chain threshold transactions or with aggregated transactions.

If I'm keeping my life savings of 100,000 sats in a CoinPool, and the transaction cost is 50,000 sats, then the option to withdraw my funds unilaterally basically doesn't exist.

You talk with numbers, but there's no indication that you will pay 50,000 sats for an on-chain transaction.

Regardless of what the cost is in sats or dollars, the fact is that 500,000 transactions per day / 5 billion people = 1 transaction per person per 10,000 days.

What is your proposal to make Bitcoin scale by a factor of 10,000 (to allow everyone to do 1tx/day)?

[NotATether]

That's a nice idea but I still don't see how it reduces the number of onchain transactions required. If anything it increases the number of transactions required because it performs transactions on every block.

Well first of all, settlement nodes won't be spitting out multiple L1 transactions in each block. It will be just one transaction, and all of the output addresses are added to that one transaction.

MuSig will drastically reduce the size of this one transaction. Instead of several inputs and outputs, it will have several outputs but just 1 input.

MuSig addresses are multisig addresses where the public keys are combined into one shared public key, instead of using all those individual public keys individually. The same goes for signatures - everyone still has to make a signature, but now they can combine it into one shared signature, which dramatically saves space.

Of course, the MuSig addresses must be funded by people on L1 who want to use Ephemeral Settlements. My anticipation is that the less savvy users like those closed-source wallets, exchanges, PayPal and others will be making their bitcoin addresses exclusively on the Ephemeral Settlements layer instead of directly on Layer 1. The underlying exchange/service will then make one giant (in terms of money) transaction to one of these MuSig addresses. This brings two conclusions:

1) The amount of funding transactions to Ephemeral Settlement MuSig addresses are expected to go down over time as people stay on Ephemeral Settlements layer.
2) Exchange and payment processing software will be much simplified as they no longer have to create and maintain their own "virtual reality" of addresses and transactions outside Layer 1.


Come to think of it, I should really post all this to bitcoin-dev mailing list...

[BrotherCreamy]

Again, even if a single user in the pool theoretically has the power to unilaterally withdraw their funds, if it is cost-prohibitive then it might as well not exist as an option.

There's a cost for everything. Perhaps there could be a mechanism, wherein the user who closes the channel / pool pays most, but there will always be a cost. If you increased the block size, the fee rate would surely drop, but the cost would later be translated in decentralization.

Block size was never and will never be a sufficient scaling mechanism, at least not on its own.
If we talk about signature aggregation as a scaling mechanism, have a look at MuSig2 - it sounds pretty promising to me. Combining signatures off-chain instead of on-chain saves fees and blockchain space, while not requiring channel opening and closing transactions.

[...]
It's good that a MuSig2 BIP is finally about to roll though. It's about time that something like this happens and has profound implications in both scaling with off-chain threshold transactions or with aggregated transactions.

If I'm keeping my life savings of 100,000 sats in a CoinPool, and the transaction cost is 50,000 sats, then the option to withdraw my funds unilaterally basically doesn't exist.

You talk with numbers, but there's no indication that you will pay 50,000 sats for an on-chain transaction.

Regardless of what the cost is in sats or dollars, the fact is that 500,000 transactions per day / 5 billion people = 1 transaction per person per 10,000 days.

What is your proposal to make Bitcoin scale by a factor of 10,000 (to allow everyone to do 1tx/day)?

I don't have a proposal... that's why I created this thread.
I'm trying to figure how Bitcoin scales in a decentralised way when there are a billion plus users in the network.

[BrotherCreamy]

That's a nice idea but I still don't see how it reduces the number of onchain transactions required. If anything it increases the number of transactions required because it performs transactions on every block.

Well first of all, settlement nodes won't be spitting out multiple L1 transactions in each block. It will be just one transaction, and all of the output addresses are added to that one transaction.

MuSig will drastically reduce the size of this one transaction. Instead of several inputs and outputs, it will have several outputs but just 1 input.

MuSig addresses are multisig addresses where the public keys are combined into one shared public key, instead of using all those individual public keys individually. The same goes for signatures - everyone still has to make a signature, but now they can combine it into one shared signature, which dramatically saves space.

Of course, the MuSig addresses must be funded by people on L1 who want to use Ephemeral Settlements. My anticipation is that the less savvy users like those closed-source wallets, exchanges, PayPal and others will be making their bitcoin addresses exclusively on the Ephemeral Settlements layer instead of directly on Layer 1. The underlying exchange/service will then make one giant (in terms of money) transaction to one of these MuSig addresses. This brings two conclusions:

1) The amount of funding transactions to Ephemeral Settlement MuSig addresses are expected to go down over time as people stay on Ephemeral Settlements layer.
2) Exchange and payment processing software will be much simplified as they no longer have to create and maintain their own "virtual reality" of addresses and transactions outside Layer 1.


Come to think of it, I should really post all this to bitcoin-dev mailing list...

And then, once all these outputs are created, where do the coins go from there?
Then you need a single transaction for every output to recombine them into a new pool.
And we're back to square one.

[n0nce]

I don't have a proposal... that's why I created this thread.
I'm trying to figure how Bitcoin scales in a decentralised way when there are a billion plus users in the network.

I guess the answer to your question then, would be that there is currently no on-chain scaling solution that allows +1bn users to use Bitcoin regularly.

~

Please make yourself familiar with:

Forum rules
[...]
32. Posting multiple posts in a row (excluding bumps and reserved posts by the thread starter) is not allowed.
[...]

[NotATether]

That's a nice idea but I still don't see how it reduces the number of onchain transactions required. If anything it increases the number of transactions required because it performs transactions on every block.

Well first of all, settlement nodes won't be spitting out multiple L1 transactions in each block. It will be just one transaction, and all of the output addresses are added to that one transaction.

MuSig will drastically reduce the size of this one transaction. Instead of several inputs and outputs, it will have several outputs but just 1 input.

MuSig addresses are multisig addresses where the public keys are combined into one shared public key, instead of using all those individual public keys individually. The same goes for signatures - everyone still has to make a signature, but now they can combine it into one shared signature, which dramatically saves space.

Of course, the MuSig addresses must be funded by people on L1 who want to use Ephemeral Settlements. My anticipation is that the less savvy users like those closed-source wallets, exchanges, PayPal and others will be making their bitcoin addresses exclusively on the Ephemeral Settlements layer instead of directly on Layer 1. The underlying exchange/service will then make one giant (in terms of money) transaction to one of these MuSig addresses. This brings two conclusions:

1) The amount of funding transactions to Ephemeral Settlement MuSig addresses are expected to go down over time as people stay on Ephemeral Settlements layer.
2) Exchange and payment processing software will be much simplified as they no longer have to create and maintain their own "virtual reality" of addresses and transactions outside Layer 1.


Come to think of it, I should really post all this to bitcoin-dev mailing list...

And then, once all these outputs are created, where do the coins go from there?
Then you need a single transaction for every output to recombine them into a new pool.
And we're back to square one.

Like I said, I am expecting the majority of BTC to be contained in these settlement pools, so that services can just check with some settlement pool to see if they have been paid. It's non-custodial because funds are stored in 1-of-N multisignatures and the protocol allows for you to get out any time you wish, but there are incentives in place to prevent people from making off with the BTC e.g the MuSig funds are stored in a private key that has a particular public key, which is generated by aggregating the pubsloc keys of each settlement pool (large M-of-N) to prevent individual pool fraud, and each of those keys are generated by a 1-of-N MuSig of all the participants.

Thus, no pool member can just craft a transaction that drains the pool because they only have a part of the private key, they would need to collude with a majority of the other pools (or their members) to make the other parts of the main MuSig key.

An additional measure would be to restrict IPs to connect to one settlement sat a time, and not to support hidden services (which easily circumvent this restriction).

Settlement pools collectively broadcast one transaction to L1 that includes the MuSig input (and any other inputs that want to join the protocol), a MuSig output (and any outputs that want to leave). As transaction fees go up, the number of people moving to he settlement pools will spike momentarily and then drop off, and when they go down the reverse will happen.

The conclusion is that momentary spikes in tx size will happen in the beginning, and then these will gradually drop off until transaction size converge to a small value.

[PrimeNumber7]

Hi guys,

I have spent a while reading about BIPs 340-342, but I'm struggling to find a definitive answer about how these BIPs will address scaling issues.

To give some context:
I am concerned with the future user scaling of Bitcoin. When there are 5 billion users, no individuals will be able to afford to transact on-chain - 5 billion people => 1 transaction per person per ~20 years - unless there is some highly scalable way of aggregating transactions.
Lightning does not address this problem. Lightning improves transaction speed and volume, but it does not solve the root problem of redeeming one's coins on-chain. There are proposed solutions such as channel factories, but these are still worthless without the possibility to redeem on-chain.
If no one can afford to redeem on-chain, we may as well just create a separate token called LNBTC and operate LN independent of Bitcoin.

I have to disagree with you on this point.

With LN, it is possible to redeem your coin from LN and claim your coin on-chain. The LN protocol makes it unnecessary for users to do this on a regular basis, and as such they will not redeem their coin via an on-chain transaction on a regular basis.

If an individual wants to redeem the coin they have on LN, they can do so. This does not mean that every individual needs to be able to transfer between LN and on-chain every day.

In terms of scalability, I don't think it is possible to increase the number of transactions in a block by one without increasing the total block size by some constant. In other words, the total time incremented block size will be at best O(1) in relation to the number of users who have at least one on-chain transaction during that time increment.

[n0nce]

In terms of scalability, I don't think it is possible to increase the number of transactions in a block by one without increasing the total block size by some constant. In other words, the total time incremented block size will be at best O(1) in relation to the number of users who have at least one on-chain transaction during that time increment.

That's correct. A decentralized blockchain by design, 'scales' extremely badly.
Because instead of just requiring to add a few more servers (traditional 'scaling' method in computing), every single node / 'server' on the network would need to drastically improve their hardware.

Meanwhile off-chain solutions allow us to handle a much higher maximum number of transactions per unit time per processor. Whether that will be LN or not, remains to be seen. It's possible that there will be a whole ecosystem of off-chain protocols that are compatible with each other.

[BrotherCreamy]

I guess the answer to your question then, would be that there is currently no on-chain scaling solution that allows +1bn users to use Bitcoin regularly.

Yep, that's what I thought, but I was hoping to find out if there was any theoretical way of achieving such scaling, or any such development in that area.
As far as I'm aware, there is also no trustless off-chain scaling solution that exists yet.
The closest you might come to this would be FediMint, which requires you to trust your guardians. Lightning addresses payment scaling, but not user scaling.

That's correct. A decentralized blockchain by design, 'scales' extremely badly.
Because instead of just requiring to add a few more servers (traditional 'scaling' method in computing), every single node / 'server' on the network would need to drastically improve their hardware.

Meanwhile off-chain solutions allow us to handle a much higher maximum number of transactions per unit time per processor. Whether that will be LN or not, remains to be seen. It's possible that there will be a whole ecosystem of off-chain protocols that are compatible with each other.

I'd posit that it is not possible to implement user scaling (to say 1 billion users) off-chain in a trustless fashion with the current bitcoin protocol, since any 1-of-N fallback (e.g. the ability to close an LN channel) relies on the assumption that on-chain transactions are not cost prohibitive for most individuals, which they will be when there are 1 billion users.
For example, if your life savings are 1,000,000 sats - say $10,000 in today's money - and a single on-chain transaction is 100,000 sats - $1,000 in today's money - then using LN is basically untenable.
I suppose for LN to work in this context, there would basically have to be huge penalties in LN for unresponsiveness or dishonesty to mitigate the need for cost-prohibitive on-chain transactions, and then all channel operators would be essentially required to have no more than a few days downtime over a timespan of many years, and never slip up in terms of sending outdated transactions. This is especially difficult for people who live in places with poor internet or no guarantee of internet access. Imagine your internet goes down for a week and you lose $2000 as a result.

Addendum:
For anyone who thinks that an on-chain transaction will never cost 100,000 sats, don't forget that the supply of block space is highly inelastic. You cannot easily create more space on-chain to match demand.
At the moment, BTC transactions are cheap because the network is not yet saturated. When the demand for block space surpasses available block space, then we will see a significant increase in transaction cost.
If we see a hundredfold increase in monthly users, then the increase in transaction cost will be very steep.

Please make yourself familiar with:

Noted. Thank you.

It's non-custodial because funds are stored in 1-of-N multisignatures and the protocol allows for you to get out any time you wish

Again, this 1-of-N fallback option is irrelevant when it's cost-prohibitive for individuals to transact on chain.
For the purposes of this thought experiment, assume a single transaction on chain is more than the net worth of most individuals.
The 1-of-N may as well not exist.

We need to combine many possible option to increase transaction throughput, whether it's block size increase, signature aggregation, LN or even different cryptography which have smaller signature size (obviously while remain secure).

These are all only incremental improvements though. Even if block size increases by a factor of 5 - which I know almost no one on here would support - and signature aggregation techniques further improve transaction density by a factor of 5, assuming we have a billion users, each user would still only be able to transact on-chain - e.g. to perform a channel open/close - once every 80 days, which is still very tough.
We really need a 1000x improvement.

[NotATether]

It's non-custodial because funds are stored in 1-of-N multisignatures and the protocol allows for you to get out any time you wish

Again, this 1-of-N fallback option is irrelevant when it's cost-prohibitive for individuals to transact on chain.
For the purposes of this thought experiment, assume a single transaction on chain is more than the net worth of most individuals.
The 1-of-N may as well not exist.

The 1-of-N is a shared address that identifies a shared pool and allows settlers to identify themselves as from it.

I've modified the design a bit so that you don't directly transact from the 1-of-N address.

Now, each settlement aggregates their MuSig key into a larger, M-of-N key (where M > N/2).

Which means, all of the funds of this protocol will now be stored in a single, shared MuSig. Now there are no fund loss issues when the computer running a settlement pool shuts down abruptly.

Whereas before, if one settlement pool goes down, everyone in that settlement loses control of their funds. But now, a majority of settlements will go down for that to happen.

The settlement pools keep network connections with each other, so if any of them go down and don't come up by the next block, then the network of settlement pools will make a new M-of-N signature without them. This constant re-balancing keeps funds always available when the number of settlements goes down, and makes funds storage more secure when it goes up.

All settlement pools keep a state of settlement public keys and each pubkey and virtual/physical address assigned to each user on that pool. But they do not share any private keys of course.

If a settlement is shut down for whatever reason, any settler from that settlement can start a connection with any other settlement, send them a BIP322 signed transaction for the 1-of-N MuSig (to prove that they were part of a pool). Once the settlement verifies the signature, the settler can send a proper 1-of-N MuSig transaction for the desired amount [of course this tx will be invalid on-chain, because the 1-of-N MuSig is not funded]. The settlement will then make an entry in its database to credit whatever addresses were specified inside it with their respective amounts, when the next block is mined and a global M-of-N MuSig transaction is made for it.

Settlement pool owners earn fees proportional to the volume of transactions they process, so all tx fees for L1 will be paid from settlement pool fees.

[BlackHatCoiner]

For example, if your life savings are 1,000,000 sats - say $10,000 in today's money - and a single on-chain transaction is 100,000 sats - $1,000 in today's money - then using LN is basically untenable.

But, for once more, you use numbers that aren't backed by facts. Paying 100,000 for an on-chain transaction is already untenable, and such transaction would be considered overspent in fees. Such fee would make some sense if all the billion users tried to open a channel within October.

Besides that, Lightning cannot cover a billion users alone. The simple answer is that if there's demand for something, it will be supplied. See Lightning. Before 2017, people paid nickles in fees, but an abrupt rise in median fee incentivized some hobbyists to take it one step further. Currently, fees are also nickles. Precisely, and at the time speaking, it costs less than 5 cents to have your transaction confirmed with low priority.

[NotATether]

Besides that, Lightning cannot cover a billion users alone. The simple answer is that if there's demand for something, it will be supplied. See Lightning. Before 2017, people paid nickles in fees, but an abrupt rise in median fee incentivized some hobbyists to take it one step further. Currently, fees are also nickles. Precisely, and at the time speaking, it costs less than 5 cents to have your transaction confirmed with low priority.

Lightning is a bit like hard cash, no government lets its private citizens hold s total of billions of dollars in hard cash any more  

Settlement pools are more like a VISA card, except that it's a) transparent, audible and has all the other advantages of L1, and b) scalable - as long as the average disk size keeps up with the total size of each epheremal blockchain. And c) provided that there are thousands of nodes, it will be decentralized as well, considering that it's 1 node per IPv4 address only (IPv6 is counted separately) with no Tor or anonymity network support to prevent this limitation from being defeated.

Considering that some people are estimating blockchain size to be at 450GB (!) - I remember it was like 380GB last year -, settlement pools should be able to handle block sizes that large and beyond. Because being ephemeral, they are deleted when a block is mined, and even more importantly and because of this, the architecture pushes the maximum blocksize to infinity (or your free HDD space, whichever's smaller  )

[BlackHatCoiner]

Lightning is a bit like hard cash, no government lets its private citizens hold s total of billions of dollars in hard cash any more

It's not down to the government to decide that. Bitcoin is non-negotiable. It's money you can't fuck with. If some citizens, not necessarily all or most, because if they were most, they could overthrow their government, but if some citizens want to own bitcoin, there's nothing preventing them so. Granted, the government can disincentivize them, with fines, taxes etc., but in the end, they don't control it, in the same way they don't control alcohol.

I'd be this doubtful for the citizens instead. What's the last time you witnessed a friend or relative who's annoyed by the fact that he holds no custody over his funds?

[NotATether]

Lightning is a bit like hard cash, no government lets its private citizens hold s total of billions of dollars in hard cash any more

It's not down to the government to decide that. Bitcoin is non-negotiable. It's money you can't fuck with. If some citizens, not necessarily all or most, because if they were most, they could overthrow their government, but if some citizens want to own bitcoin, there's nothing preventing them so. Granted, the government can disincentivize them, with fines, taxes etc., but in the end, they don't control it, in the same way they don't control alcohol.

I'd be this doubtful for the citizens instead. What's the last time you witnessed a friend or relative who's annoyed by the fact that he holds no custody over his funds?

I meant the analogy for technical and not political reasons - LN's liquidity is stored in separate P2P channels, so without injecting more bitcoins into the LN, it's not possible to do 5-digit USD transactions efficiently if someone wanted to do that.

Essentially, this means that all L2 solutions will be competing with each other for L1 Bitcoin liquidity, even if one protocol has different design goals than another.

[n0nce]

As far as I'm aware, there is also no trustless off-chain scaling solution that exists yet.
The closest you might come to this would be FediMint, which requires you to trust your guardians. Lightning addresses payment scaling, but not user scaling.

Let's not confuse things here. Lightning may not enable 5bn people to settle their balance on-chain, but it definitely is trustless. There should be no doubt about that.
I've yet to study more about sidechains such as Liquid, so I can't say whether those off-chain solutions are trustless, but I'm relatively confident they are; otherwise nobody would use them.

I'd posit that it is not possible to implement user scaling (to say 1 billion users) off-chain in a trustless fashion with the current bitcoin protocol, since any 1-of-N fallback (e.g. the ability to close an LN channel) relies on the assumption that on-chain transactions are not cost prohibitive for most individuals, which they will be when there are 1 billion users.

That's an interesting thought; I understand where you're coming from. One could argue (similar to the question 'what to do after the block subsidy ends in 2140') that it's a problem for later and that it's pointless to put in time looking for solutions right now.
Another reply I can give you is that there are ideas, theories and models (not sure whether also prototypes) for even higher layers. The high-level idea is that there will never be 5bn Lightning operators, but merely a few thousand (like now) who can thus also settle on-chain if needed. Common users would operate on an even higher layer, using Lightning as the settlement layer.

For example, if your life savings are 1,000,000 sats - say $10,000 in today's money - and a single on-chain transaction is 100,000 sats - $1,000 in today's money - then using LN is basically untenable.

In the scenario I described above then, you would not create or open Lightning channels with 1m sats, but be a higher-level user that merely uses technology leveraging such channels. Operators will either have channels from 'cheaper times' (like now) or invest thousands or even millions to create a reasonably sized Lightning channel and do their best to find reliable channel partners & keep it open for as long as possible (best-case forever).

I suppose for LN to work in this context, there would basically have to be huge penalties in LN for unresponsiveness or dishonesty to mitigate the need for cost-prohibitive on-chain transactions, and then all channel operators would be essentially required to have no more than a few days downtime over a timespan of many years, and never slip up in terms of sending outdated transactions.

Do keep in mind that both channel partners pay for the closing transaction. So it's in both partners' interest to keep it open.

We really need a 1000x improvement.

True, but that will never work on-chain. Either L2, L3 or another off-chain mechanism is required for that.

[tromp]

I've yet to study more about sidechains such as Liquid, so I can't say whether those off-chain solutions are trustless, but I'm relatively confident they are; otherwise nobody would use them.

You definitely need to trust the federation that controls peg-outs [1]. From the whitepaper [2]:

> As a sidechain, Liquid supports transfers of bitcoins into and out of the system by means
of a cryptographic peg. Bitcoin pegged into Liquid is referred to as Liquid Bitcoin or LBTC. The forward progress of the Liquid ledger and custody of the underlying bitcoin are
controlled by a federation, and remain secure as long as over 2/3 of its members are honest.

> This option requires no changes to Bitcoin, since the peg is enforced by means of ordinary
multisignature transactions. It does require a consortium to exist, and for participants of
the system to trust that at least 2/3 of the federation is acting honestly.

[1] https://help.blockstream.com/hc/en-us/articles/900001551783-What-is-a-Liquid-peg-out-

[2] https://blockstream.com/assets/downloads/pdf/liquid-whitepaper.pdf

[n0nce]

I've yet to study more about sidechains such as Liquid, so I can't say whether those off-chain solutions are trustless, but I'm relatively confident they are; otherwise nobody would use them.

You definitely need to trust the federation that controls peg-outs [1]. From the whitepaper [2]:
[...]

I see.. There's some decentralization happening at least, but for me it's not comfortable using a system that requires trust. At least not as the only way to use BTC.
It's possible to have a light wallet to use for small purchases that relies on such a system, but I'd agree that nobody should put majority of their wealth into such a trust-based sidechain.

But again, to highlight: this doesn't exist in Lightning. Such type of trust doesn't exist, you just have to take care of your node by yourself and not fuck things up (like restoring an outdated backup or not have backups..).

[NotATether]

I've yet to study more about sidechains such as Liquid, so I can't say whether those off-chain solutions are trustless, but I'm relatively confident they are; otherwise nobody would use them.

You definitely need to trust the federation that controls peg-outs [1]. From the whitepaper [2]:
[...]

I see.. There's some decentralization happening at least, but for me it's not comfortable using a system that requires trust. At least not as the only way to use BTC.
It's possible to have a light wallet to use for small purchases that relies on such a system, but I'd agree that nobody should put majority of their wealth into such a trust-based sidechain.

But again, to highlight: this doesn't exist in Lightning. Such type of trust doesn't exist, you just have to take care of your node by yourself and not fuck things up (like restoring an outdated backup or not have backups..).

In the case of LN this can be solved by more responsible wallet clients that keep track of channel backups and prohibit you from restoring old backups, and does that kind of stuff automatically.

What you are describing is akin to Bitcoin wallets who provide controls for users to directly send and reserve messages on Layer 1's P2P network - completely unnecessary, and should be abstracted from almost everyone.

[n0nce]

I've yet to study more about sidechains such as Liquid, so I can't say whether those off-chain solutions are trustless, but I'm relatively confident they are; otherwise nobody would use them.

You definitely need to trust the federation that controls peg-outs [1]. From the whitepaper [2]:
[...]

I see.. There's some decentralization happening at least, but for me it's not comfortable using a system that requires trust. At least not as the only way to use BTC.
It's possible to have a light wallet to use for small purchases that relies on such a system, but I'd agree that nobody should put majority of their wealth into such a trust-based sidechain.

But again, to highlight: this doesn't exist in Lightning. Such type of trust doesn't exist, you just have to take care of your node by yourself and not fuck things up (like restoring an outdated backup or not have backups..).

In the case of LN this can be solved by more responsible wallet clients that keep track of channel backups and prohibit you from restoring old backups, and does that kind of stuff automatically.

What you are describing is akin to Bitcoin wallets who provide controls for users to directly send and reserve messages on Layer 1's P2P network - completely unnecessary, and should be abstracted from almost everyone.

Great point! I should look into adding this to Core Lightning and doing a pull request. It sounds like an extremely good idea, in case it's not already implemented in their new built-in backup functionality.

The only question is if your whole node goes down, where is the information stored / backed up as to which backup is the most recent or whether there were any channel state updates after the last backup?

[NotATether]

The only question is if your whole node goes down, where is the information stored / backed up as to which backup is the most recent or whether there were any channel state updates after the last backup?

You can connect a cluster of computers to each other, each with the node state, so that if one goes down, you can simply restore it from another machine.

I would've also suggested storing it in the cloud, but I'm assuming you're only interested in decentralized solutions.

[n0nce]

The only question is if your whole node goes down, where is the information stored / backed up as to which backup is the most recent or whether there were any channel state updates after the last backup?

You can connect a cluster of computers to each other, each with the node state, so that if one goes down, you can simply restore it from another machine.

I would've also suggested storing it in the cloud, but I'm assuming you're only interested in decentralized solutions.

That's all basically already possible by mounting a network drive for your backups.

It is recommended that you use a network-mounted filesystem for the backup destination. For example, if you have a NAS you can access remotely.

The backup plugin also allows to use multiple destinations, e.g. a secondary drive (local redundancy), a NAS within the LAN and another somewhere else (remote redundancy).

Sadly, no built-in encryption == no cloud backups are recommended.

Do note that files are not stored encrypted, so you should really not do this with rented space (”cloud storage”).

[NotATether]

Sadly, no built-in encryption == no cloud backups are recommended.

Do note that files are not stored encrypted, so you should really not do this with rented space (”cloud storage”).

Why so? Nobody bought of making a password protection option with AES256?

I don't think this should be specified as a BOLT because that's supposed to be related to protocol-related things. Given that there's no Bitcoin Core of Lightning network, the best way forward is to take a wallet such as Electrum and implement the backup encryption there a just reuse the wallet password for encrypting the backups. Then if other people think that's a good idea, they'll copy the design.

[n0nce]

Sadly, no built-in encryption == no cloud backups are recommended.

Do note that files are not stored encrypted, so you should really not do this with rented space (”cloud storage”).

Why so? Nobody bought of making a password protection option with AES256?

I don't think this should be specified as a BOLT because that's supposed to be related to protocol-related things. Given that there's no Bitcoin Core of Lightning network, the best way forward is to take a wallet such as Electrum and implement the backup encryption there a just reuse the wallet password for encrypting the backups. Then if other people think that's a good idea, they'll copy the design.

Is that the best way forward? I would have probably instead tried to add it to Core Lightning directly and submit a pull request..
Or forked the backup plugin and added encryption; the plugin interface is kind of the usual method to add functionality to Core LN.

[NotATether]

Sadly, no built-in encryption == no cloud backups are recommended.

Do note that files are not stored encrypted, so you should really not do this with rented space (”cloud storage”).

Why so? Nobody bought of making a password protection option with AES256?

I don't think this should be specified as a BOLT because that's supposed to be related to protocol-related things. Given that there's no Bitcoin Core of Lightning network, the best way forward is to take a wallet such as Electrum and implement the backup encryption there a just reuse the wallet password for encrypting the backups. Then if other people think that's a good idea, they'll copy the design.

Is that the best way forward? I would have probably instead tried to add it to Core Lightning directly and submit a pull request..
Or forked the backup plugin and added encryption; the plugin interface is kind of the usual method to add functionality to Core LN.

This is just the "fallback" strategy in case they don't merge your PR. Believe me, there are many political reasons why such an outcome can happen nowadays, especially in larger projects.

Also, forking a plug-in just to add a single feature is going to drain you in the long run as you have to mirror the other updates from upstream.

[BrotherCreamy]

Let's not confuse things here. Lightning may not enable 5bn people to settle their balance on-chain, but it definitely is trustless. There should be no doubt about that.

Agreed.

That's an interesting thought; I understand where you're coming from. One could argue (similar to the question 'what to do after the block subsidy ends in 2140') that it's a problem for later and that it's pointless to put in time looking for solutions right now.
Another reply I can give you is that there are ideas, theories and models (not sure whether also prototypes) for even higher layers. The high-level idea is that there will never be 5bn Lightning operators, but merely a few thousand (like now) who can thus also settle on-chain if needed. Common users would operate on an even higher layer, using Lightning as the settlement layer.

That's something I didn't think of. I have to think about that a bit more.
In any case, I'm officially coining the term Lightning² haha.

In the scenario I described above then, you would not create or open Lightning channels with 1m sats, but be a higher-level user that merely uses technology leveraging such channels. Operators will either have channels from 'cheaper times' (like now) or invest thousands or even millions to create a reasonably sized Lightning channel and do their best to find reliable channel partners & keep it open for as long as possible (best-case forever).

For sure, agreed that it would be ridiculous to open such a small Lightning channel especially if an on-chain txn is 100,000 sats.
And yes, I think you might be right about L2 being only used by higher-level users, a la Lightning²  

True, but that will never work on-chain. Either L2, L3 or another off-chain mechanism is required for that.

Agreed.

If a settlement is shut down for whatever reason, any settler from that settlement can start a connection with any other settlement, send them a BIP322 signed transaction for the 1-of-N MuSig (to prove that they were part of a pool). Once the settlement verifies the signature, the settler can send a proper 1-of-N MuSig transaction for the desired amount [of course this tx will be invalid on-chain, because the 1-of-N MuSig is not funded]. The settlement will then make an entry in its database to credit whatever addresses were specified inside it with their respective amounts, when the next block is mined and a global M-of-N MuSig transaction is made for it.
Settlement pool owners earn fees proportional to the volume of transactions they process, so all tx fees for L1 will be paid from settlement pool fees.

Are you saying if a settlement pool goes down, that *every user* from that settlement must create an on-chain transaction, or only one user from that pool?
If the former, then we are back to square one. If the latter, then I need more time to wrap my head around this.

Each of them may only increase by a factor of 5 (example number), but if you combine them you could get 25x improvement. Obviously it's not enough to billion users, but i'd take small improvement over nothing. Besides, IMO it's just matter of time before block size is increased and it'll be faster if Bitcoin community want higher transaction throughput.

The point of bitcoin is decentralisation, and throughput scales only linearly with block size (obviously).
As block size limit is increased, the number of node operators must decrease - i.e. everyone running a node on a Raspberry Pi and 1TB external hard drive will have to buy 10 or 100x the storage.

Actually it's a bit of a catch 22. If we:
a) keep the block size the same, this necessitates the use of Bitcoin banks. If you are storing all your funds in a Bitcoin bank, then running your own node is pointless, because the bank has ultimate control over your BTC.
b) increase the block size 100x say, this would permit individuals to continue transacting on-chain in a hyperbitcoinised world, but it would also drastically increase the hardware requirement to run your own node, making it much more difficult for the average person to run their own node.

I think ultimately Bitcoin banks are the future. The vast majority of people will never run their own node, regardless of the barrier to entry. Sure, you will have to trust the bank with your coins, but I think that is fine. If a bitcoin bank tries to run off with 100,000 customer's coins, there are not many places in the world they would be able to hide from the 100,000 strong angry mob that would form.

But, for once more, you use numbers that aren't backed by facts. Paying 100,000 for an on-chain transaction is already untenable, and such transaction would be considered overspent in fees. Such fee would make some sense if all the billion users tried to open a channel within October.

There is a fixed supply of block space. Supply of block space is completely inelastic.
The math is very simple.
For a billion users, that would be one channel open/close txn per person per ~4 years.
That is not enough.

Besides that, Lightning cannot cover a billion users alone. The simple answer is that if there's demand for something, it will be supplied. See Lightning. Before 2017, people paid nickles in fees, but an abrupt rise in median fee incentivized some hobbyists to take it one step further. Currently, fees are also nickles. Precisely, and at the time speaking, it costs less than 5 cents to have your transaction confirmed with low priority.

The kind of scaling achieved by Lightning is only good for scaling the number of payments possible for the same size set of users, but it DOES NOT address user scaling.
The whole point I'm making is that I don't believe it is possible to scale the number of users without changes to L1 and even then I don't think it is possible without a 100-1000x block size increase, or some cryptographic black magic fuckery.

[NotATether]

If a settlement is shut down for whatever reason, any settler from that settlement can start a connection with any other settlement, send them a BIP322 signed transaction for the 1-of-N MuSig (to prove that they were part of a pool). Once the settlement verifies the signature, the settler can send a proper 1-of-N MuSig transaction for the desired amount [of course this tx will be invalid on-chain, because the 1-of-N MuSig is not funded]. The settlement will then make an entry in its database to credit whatever addresses were specified inside it with their respective amounts, when the next block is mined and a global M-of-N MuSig transaction is made for it.
Settlement pool owners earn fees proportional to the volume of transactions they process, so all tx fees for L1 will be paid from settlement pool fees.

Are you saying if a settlement pool goes down, that *every user* from that settlement must create an on-chain transaction, or only one user from that pool?
If the former, then we are back to square one. If the latter, then I need more time to wrap my head around this.

Neither.

I think the prior talk about the 1-of-N MuSig having funds must have confused you, so let's clear things up:

- The 1-of-N MuSig is for identity purposes only; its sole purpose is to keep track who has funds on the (off-chain) network.
- Actual finds are stored in an M-of-N MuSig (a completely different N from above), where each key is the aggregate 1-of-N MuSig key.

Two important things to note here:

- M is greater than half of N, which means you need a greater than 50% network "approval" (actually just settlement pools signing the M-of-N) to spend a transaction on this network.
- This network is designed so that anybody running or connecting to a pool - anybody part of a 1-of-N identity MuSig - can sign one (1) part of the M-of-N transaction.

It means that if a pool goes down between any period of two consecutive L1 blocks being mined, users can still access their funds by connecting to some other pool and showing them their 1-of-N identity MuSig signature (signed with their own key of course - they don't have and don't need to know the pool operator's private key).

In fact, it would take over 50% of the settlement pools to go down to make the funds inaccessible to everyone (but if enough of those nodes come back online, the funds can be accessed again). Why? Because they're aren't enough signers for the M-of-N MuSig.

M is automatically adjusted based on the number of pools existing when a block is mined. By making a new M-of-N MuSig from every pool's (constant) 1-of-N MuSig aggregate (identity) key, and sending all the funds there.

PS: For fees I decided to use the same calculation to determine transaction weight - since the format for posting a transaction remains the same as L1 - but the fee rate in sats/byte will be fixed to a constant. That will make it profitable to use Settlement Pools at certain times of the day and vice versa. The fee goes to the pool who is sent the transaction first, as timestamps for all requests are recorded.

This is like Lightning Network, but all the channel funds are in one central store. In fact, there are no channels at all, so users do not need to worry about liquidity management - they can crash 1000 times and their funds can still be accessed without any recent "state" as long as they still have their identity private key that forms part of a 1-of-N Settlement Pool MuSig. [By contrast in LN if your channel goes down long enough, perhaps if you lost internet connectivity or your service, then your funds are either locked up or gone forever].

[n0nce]

Actually it's a bit of a catch 22. If we:
a) keep the block size the same, this necessitates the use of Bitcoin banks. If you are storing all your funds in a Bitcoin bank, then running your own node is pointless, because the bank has ultimate control over your BTC.
b) increase the block size 100x say, this would permit individuals to continue transacting on-chain in a hyperbitcoinised world, but it would also drastically increase the hardware requirement to run your own node, making it much more difficult for the average person to run their own node.

I think ultimately Bitcoin banks are the future. The vast majority of people will never run their own node, regardless of the barrier to entry. Sure, you will have to trust the bank with your coins, but I think that is fine. If a bitcoin bank tries to run off with 100,000 customer's coins, there are not many places in the world they would be able to hide from the 100,000 strong angry mob that would form.

Rather than bank (or other custodial service), people could use various off-chain (such as LN) or side-chain (such as RSK or Liquid) solution.

I think that BrotherCreamy would categorize a sidechain such as Liquid, as a 'Bitcoin bank', too. The distinction being the requirement of trust and ultimately who is in control of the funds.

In my opinion (and hopes), banks (or any other similar service) will not be the main way people use Bitcoin. Instead, upper layers should trustlessly provide users with all the required services, whilst ensuring payments can be settled without 'mass exodus on the Blockchain' or anything similar that brings L1 to its knees.

[BrotherCreamy]

It means that if a pool goes down between any period of two consecutive L1 blocks being mined, users can still access their funds by connecting to some other pool and showing them their 1-of-N identity MuSig signature (signed with their own key of course - they don't have and don't need to know the pool operator's private key).

Right so how does this proof happen?
Does the user have to post on-chain (L1)?

It sounds like an interesting idea nonetheless. It makes sense that a decentralised L2 that allows user scaling will have to rely on some kind of off-chain voting system, because otherwise the problem seems intractable.

[NotATether]

I think that BrotherCreamy would categorize a sidechain such as Liquid, as a 'Bitcoin bank', too. The distinction being the requirement of trust and ultimately who is in control of the funds.

In my opinion (and hopes), banks (or any other similar service) will not be the main way people use Bitcoin. Instead, upper layers should trustlessly provide users with all the required services, whilst ensuring payments can be settled without 'mass exodus on the Blockchain' or anything similar that brings L1 to its knees.

Off-chain networks are not banks. A bank is something with whom you're at mercy* to give you your money. You can withdraw your funds all by yourself on LN. The fact that funds are stored in multisignatures doesn't make it centralized, but rather the opposite.

*somehow this word got deleted by my autocorrect.

It means that if a pool goes down between any period of two consecutive L1 blocks being mined, users can still access their funds by connecting to some other pool and showing them their 1-of-N identity MuSig signature (signed with their own key of course - they don't have and don't need to know the pool operator's private key).

Right so how does this proof happen?
Does the user have to post on-chain (L1)?

It sounds like an interesting idea nonetheless. It makes sense that a decentralised L2 that allows user scaling will have to rely on some kind of off-chain voting system, because otherwise the problem seems intractable.

It's very easy to make a proof that you were part of a settlement pool at any given time.

While you're connected to one, you will get the public keys of all the other participants on the pool. This allows you to create the aggregate MuSig key for the pool all by yourself, even if you're not the pool operator.

Then you can make a BIP322-style signed message (which is actually a regular but invalid transaction) using that MuSig key and using the signature generated only from your own private key.

Now, anybody with the signed BIP322 message (it's a raw transaction) will easily be able to identify it as a MuSig address's transaction which has been signed by one co-signer. So you can send this message via HTTP to any pool to prove your past participation on a settlement pool and the funds you had on it.

The settlement pool does not have to transfer your funds anywhere to make it accessible to you, because this transaction/signed message is only to identify a particular user on this network.

No, a user does not have to broadcast an L1 transaction for any of this to work, although they will make and sign a transaction that looks awfully like one (BIP322 signed messages). That's the beauty of all this - users are completely insulated from L1 transaction fees.

Speaking about tx fees, maybe it would be better for scalability instead of fixing the fee rate, to make the fee rate dynamic based on the number of transactions on all of the pools within the past <X> blocks. Making the fee rate go down per transaction if larger volume of transactions are being made per block, and vice versa. Similar to how mining difficulty is calculated in L1. But maybe instead of every interval of 2016 blocks, it can be a moving average of the last 2016 blocks at any given moment (and by no means does it have to be fixed at 2016 blocks).

[n0nce]

I think that BrotherCreamy would categorize a sidechain such as Liquid, as a 'Bitcoin bank', too. The distinction being the requirement of trust and ultimately who is in control of the funds.

In my opinion (and hopes), banks (or any other similar service) will not be the main way people use Bitcoin. Instead, upper layers should trustlessly provide users with all the required services, whilst ensuring payments can be settled without 'mass exodus on the Blockchain' or anything similar that brings L1 to its knees.

Off-chain networks are not banks. A bank is something with whom you're at to give you your money. You can withdraw your funds all by yourself on LN. The fact that funds are stored in multisignatures doesn't make it centralized, but rather the opposite.

Exactly! Lightning is therefore not a 'Bitcoin bank', but the Liquid sidechain could be categorized as such, as there is a 'federation' that you need to trust.

I've yet to study more about sidechains such as Liquid, so I can't say whether those off-chain solutions are trustless, but I'm relatively confident they are; otherwise nobody would use them.

You definitely need to trust the federation that controls peg-outs [1]. From the whitepaper [2]:

> As a sidechain, Liquid supports transfers of bitcoins into and out of the system by means
of a cryptographic peg. Bitcoin pegged into Liquid is referred to as Liquid Bitcoin or LBTC. The forward progress of the Liquid ledger and custody of the underlying bitcoin are
controlled by a federation, and remain secure as long as over 2/3 of its members are honest.

> This option requires no changes to Bitcoin, since the peg is enforced by means of ordinary
multisignature transactions. It does require a consortium to exist, and for participants of
the system to trust that at least 2/3 of the federation is acting honestly.

[1] https://help.blockstream.com/hc/en-us/articles/900001551783-What-is-a-Liquid-peg-out-

[2] https://blockstream.com/assets/downloads/pdf/liquid-whitepaper.pdf

No, a user does not have to broadcast an L1 transaction for any of this to work, although they will make and sign a transaction that looks awfully like one (BIP322 signed messages). That's the beauty of all this - users are completely insulated from L1 transaction fees.

I think the main question by BrotherCreamy can be paraphrased as:
In Lightning, your 'security' is ensured by your ability to 'fall back' / settle channel balances on-chain. If there is any issue, you publish a channel close transaction to the blockchain and get your funds back out.

The question is how this channel closing (and opening) mechanism is eliminated by Settlement Pools.
You're saying that you basically never need to close your channel / pool?

[NotATether]

No, a user does not have to broadcast an L1 transaction for any of this to work, although they will make and sign a transaction that looks awfully like one (BIP322 signed messages). That's the beauty of all this - users are completely insulated from L1 transaction fees.

I think the main question by BrotherCreamy can be paraphrased as:
In Lightning, your 'security' is ensured by your ability to 'fall back' / settle channel balances on-chain. If there is any issue, you publish a channel close transaction to the blockchain and get your funds back out.

The question is how this channel closing (and opening) mechanism is eliminated by Settlement Pools.
You're saying that you basically never need to close your channel / pool?

Nope, it's totally unnecessary. In Settlement Pools, funds are stored in the global M-of-N MuSig (details of which have already been elaborated on in previous posts). Automatic readjustment per block shields it from funds inaccessibility resulting from many settlements going down at once. It would take a global internet shutdown to make the funds inaccessible like that (but then again, L1 would not be able to function either).

There are actually no such thing as channels in my scheme. "Channels" in LN are like a bidirectional telephone line between two people (but only two people). Since the channel is the atom upon which funds rest, it needs to have liquidity, But in Settlement Pools, the settlement does not have funds. And also, it can have unlimited people subscribed to the settlement at once. It is the network of settlements which collectively have shared access to the global funds address (which is the M-of-N MuSig I keep talking about).

The whole point of having settlement nodes is to decentralize the spending power for the global funds address.

Channels are limited in that they can only deal with two people at once. Funds from multiple channels cannot be "combined" into a single on-gain transaction. This creates a lot of overhead where L1 mainnet is spammed with a bunch of LN closing transactions - though at a slower rate than if you were directly using L1 - so after a while the network will get congested even if it only processed LN transactions.

If Settlement Pools were using ordinary multisig transactions, it would also be susceptible to this problem. But thanks to MuSig[2], it is virtually non-existent - and for this we have Greg Maxwell and co. to thank for their original design proposal. As long as ordinary users are not continuously bouncing their funds between Settlement Pools and L1, the transaction throughout on L1 should handle it all.