Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Signature aggregation for scaling - what is possible?
by
NotATether
on 11/10/2022, 14:05:51 UTC
⭐ Merited by n0nce (1)
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).

There are actually no such thing as channels in my scheme. "Channels" in LN are like 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. 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).

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.