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

[1714187590]

1714187590

[1714187590]

1714187590

[1714187590]

1714187590

[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.