Re: Signature aggregation for scaling

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.