Re: [bitcoin-dev] Multipayment Channels - A scalability solution for Layer 1

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Ali,

> Over the past few days I've figured out a novel way to batch transactions together into blocks, thereby compacting the transaction size and increasing the transactions-per-second. This is all on layer 1, without any hardforks - only a single softfork is required to add MuSig1 support for individual invoice addresses.
> 
> The nucleus of the idea was born after a discussion with Greg Maxwell about a different BIP (Implementing multisig using Taproot, to be specific)[1]. He suggested to me that I should add MuSig1 signatures into the Taproot script paths.
> 
> After some thinking, I realized a use case for MuSig1 signatures as a kind of on-chain Lightning Network. Allow me to explain:
> 
> LN is very attractive to users because it keeps intermediate transaction states off-chain, and only broadcasts the final state. But without mitigations in the protocol, it suffers from two disadvantages:
> 
> - You have to trust the other channel partner not to broadcast a previous state
> - You also have to trust all the middlemen in intermediate channels not to do the above.
> 
> Most of us probably know that many mitigations have been created for this problem, e.g. penalty transactions. But what if it were possible to create a scheme where so-called technical fraud is not possible? That is what I'm going to demonstrate here.

The fact that you need to invoke trust later on ("Because the N-of-N signature is given to all participants, it might be leaked into the public") kinda breaks the point of "technical fraud is not possible".

At least with the penalty transactions of Poon-Dryja and the update transactions of Decker-Russell-Osuntokun you never have to worry about other parties leaking information and possibly changing the balance of the channel.
You only need to worry about ensuring you have an up-to-date view of the blockchain, which can be mitigated further by e.g. running a "spare" fullnode on a Torv3 address that secretly connects to your main fullnode (making eclipse attacks that target your known IP harder), connecting to Blockstream Satellite, etc.
You can always get more data yourself, you cannot stop data being acquired by others.

> My scheme makes use of MuSig1, OP_CHECKLOCKTIMEVERIFY (OP_CLTV) timelock type, and negligible OP_RETURN data. It revolves around constructs I call "multipayment channels", called so because they allow multiple people to pay in one transaction - something that is already possible BTW, but with much larger tx size (for large number of cosigners) than when using MuSig1. These have the advantage over LN channels that the intermediate state is also on the blockchain, but it's very compact.

How is this more advantageous than e.g. CoinPools / multiparticipant channels / Statechains ?

> A channel consists of a fixed amount of people N. These people open a channel by creating a (optionally Taproot) address with the following script:
> <blockheightofoutput+desiredwaitingblocks>* OP_CTLV OP_DROP <N-of-N MuSig1> OP_CHECKMUSIG**

If it is Taproot, then `OP_CHECKSIG` is already `OP_CHECKMUSIG`, since MuSig1 (and MuSig2, for that matter....) is just an ordinary Schnorr signature.
In a Tapscript, `OP_CHECKSIG` validates Schnorr signatures (as specified in the relevant BIP), not the ECDSA signatures.

> Simultaneously, each of the N participants receives the N signatures and constructs the N-of-N MuSig. Each participant will use this MuSig to generate his own independent "commitment transaction" with the following properties:
> 
> - It has a single input, the MuSig output. It has an nSequence of desiredwaitingblocks. <This prevents the output from being spent immediately.>
> 
> - It has outputs corresponding to the addresses and balances of each of the participants in the agreed-upon distribution.
> Disadvantage: Because the N-of-N signature is given to all participants, it might be leaked into the public and consequentially anybody can spend this transaction after the timelock, to commit the balance.*** On the other hand, removing the timelocks means that if one of the participants goes missing, all funds are locked forever.****

As I understand it, in your mechanism:

* Onchain, there is an output with the above SCRIPT: `<blockheightofoutput+desiredwaitingblocks>* OP_CTLV OP_DROP <N-of-N MuSig1> OP_CHECKMUSIG`
  * Let me call this the "channel UTXO".
* Offchain, you have a "default transaction" which spends the above output, and redistributes it back to the original owners of the funds, with a timelock requirement (as needed by `OP_CLTV`).

Is that correct?

Then I can improve it in the following ways:

* Since everyone has to sign off the "default transaction" anyway, everyone can ensure that the `nLockTime` field is correct, without having `OP_CLTV` in the channel UTXO SCRIPT.
  * So, the channel UTXO does not need a SCRIPT --- it can just use a Taproot-address Schnorr MuSig point directly.
  * This has the massive advantage that the "default transaction" does not have any special SCRIPTs, improving privacy (modulo the fact that you are cooperating with others who could leak their data).
* If the participants can agree on a new distribution of the funds, then they can sign off with the current blockheight without waiting for the later blockheight.
  * This improves security, since the new distribution can appear on the mempool first and be confirmed first before the "default transaction" can.


Now I want you to look at the literature on channel constructions, particularly "Spilman channels".
For example, see this:

* https://old.reddit.com/r/Bitcoin/comments/cc9psl/technical_a_brief_history_of_payment_channels/

My modifications to your scheme are just a modernization of the Spilman channels.

Regards,
ZmnSCPxj