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.