Signature aggregation for scaling - what is possible?

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

[1714773307]

1714773307

[1714773307]

1714773307

[1714773307]

1714773307

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