Date: Sun, 04 Sep 2022 22:31:38 +0000
To: bitcoin-dev@lists.linuxfoundation.org
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <20220904223132.zpvhw6hcekaowlme@artanis>
Feedback-ID: 34210769:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Multipayment Channels - A scalability solution for
	Layer 1
Precedence: list

Over the past few days I've figured out a novel way to batch transactions t=
ogether 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 scr=
ipt 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 st=
ates off-chain, and only broadcasts the final state. But without mitigation=
s in the protocol, it suffers from two disadvantages:

- You have to trust the other channel partner not to broadcast a previous s=
tate
- 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 p=
roblem, 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 g=
oing to demonstrate here.

My scheme makes use of MuSig1, OP_CHECKLOCKTIMEVERIFY (OP_CLTV) timelock ty=
pe, and negligible OP_RETURN data. It revolves around constructs I call "mu=
ltipayment channels", called so because they allow multiple people to pay i=
n one transaction - something that is already possible BTW, but with much l=
arger 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.

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

Simultaneously, each of the N participants receives the N signatures and co=
nstructs 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 desiredwa=
itingblocks. <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 han=
d, removing the timelocks means that if one of the participants goes missin=
g, all funds are locked forever.****

A second output with a script OP_RETURN <32-byte connection ID> can be adde=
d to the transaction to enable L1 channel discovery.

Full nodes parsing the blockchain can maintain a list of connection IDs to =
connect to (but without a non-malleable refund transaction, nobody is going=
 to use this). SPVs can simply export a list of them from Full Nodes.

A connection only lasts for one transaction. Spending the output to another=
 MuSig of the above format will create a new connection if it spends to a s=
imilarly-constructed MuSig output with different signature. In all cases, t=
he current connection is destroyed.

*This introduces a variable grace period, in blocks, after which anybody ca=
n broadcast this transaction to commit the channel funds distribution to ea=
ch of the participants' addresses. blockheightofoutput is the block height =
of the musig output, and desiredwaitingblocks is the maximum number of bloc=
ks the connection can stay alive for.
**This implies that a hypothetical OP_CHECKMUSIG would take a single aggreg=
ated signature, a single aggregated public key, and an integer N that denot=
es how many public keys were combined together. I elected not to overload O=
P_CHECKSIG since MuSig and regular signatures are both valid for the same a=
ddress types. This part is a rought draft and requires lots of work on maki=
ng an OP_CHECKMUSIG opcode that satisfies the requirements of multipayment =
channels.
***This is quite a bad flaw of this scheme because it means that all the pa=
rticipants must be trustworthy - you can't use this in trustless environmen=
ts. I appreciate any ways on how to implement non-malleable refund transact=
ions with single (non-aggregated) signatures!
****Perhaps the best solution is to offer both alternatives: <N-of-N MuSig1=
> OP_CHECKMUSIG in a public scenario where none of the participants want to=
 face the prospect of losing their money, and <blockheightofoutput+desiredw=
aitingblocks>* OP_CTLV OP_DROP <N-of-N MuSig1> OP_CHECKMUSIG with signature=
 sharing in private scenarios.

This draft is very crude and parts have not been fully developed. Tips for =
fleshing it out is much appreciated. Not that there's anything wrong with L=
N for that matter, I'm just concerned about the security reprocussions of n=
ot broadcasting intermediate transactions, and its enabling of crime.

- Ali

[1]: https://bitcointalk.org/index.php?topic=3D5410553.0