Date: Mon, 05 Sep 2022 03:17:27 +0000
To: Ali Sherief <ali@notatether.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <bm20xKm5eaD1AqJh8hDHq8FRjajvA5Ah8f8qFzILCJeTJaLkRflBAi6q3NABipq-XkIwdzo78Rdt1vQcRNcyyUp0G8gCMDVq-9VCraVYJ9E=@protonmail.com>
In-Reply-To: <20220904223132.zpvhw6hcekaowlme@artanis>
References: <20220904223132.zpvhw6hcekaowlme@artanis>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Multipayment Channels - A scalability solution
	for Layer 1
Precedence: list

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 increasi=
ng the transactions-per-second. This is all on layer 1, without any hardfor=
ks - only a single softfork is required to add MuSig1 support for individua=
l invoice addresses.
>=20
> The nucleus of the idea was born after a discussion with Greg Maxwell abo=
ut a different BIP (Implementing multisig using Taproot, to be specific)[1]=
. He suggested to me that I should add MuSig1 signatures into the Taproot s=
cript paths.
>=20
> After some thinking, I realized a use case for MuSig1 signatures as a kin=
d of on-chain Lightning Network. Allow me to explain:
>=20
> LN is very attractive to users because it keeps intermediate transaction =
states off-chain, and only broadcasts the final state. But without mitigati=
ons in the protocol, it suffers from two disadvantages:
>=20
> - 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 t=
o do the above.
>=20
> 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 signat=
ure is given to all participants, it might be leaked into the public") kind=
a breaks the point of "technical fraud is not possible".

At least with the penalty transactions of Poon-Dryja and the update transac=
tions of Decker-Russell-Osuntokun you never have to worry about other parti=
es 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 bl=
ockchain, which can be mitigated further by e.g. running a "spare" fullnode=
 on a Torv3 address that secretly connects to your main fullnode (making ec=
lipse 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. The=
se 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 channe=
ls / Statechains ?

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

If it is Taproot, then `OP_CHECKSIG` is already `OP_CHECKMUSIG`, since MuSi=
g1 (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 genera=
te his own independent "commitment transaction" with the following properti=
es:
>=20
> - It has a single input, the MuSig output. It has an nSequence of desired=
waitingblocks. <This prevents the output from being spent immediately.>
>=20
> - It has outputs corresponding to the addresses and balances of each of t=
he 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 th=
is transaction after the timelock, to commit the balance.*** On the other h=
and, removing the timelocks means that if one of the participants goes miss=
ing, 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 time=
lock 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 Tapro=
ot-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 c=
ooperating with others who could leak their data).
* If the participants can agree on a new distribution of the funds, then th=
ey can sign off with the current blockheight without waiting for the later =
blockheight.
  * This improves security, since the new distribution can appear on the me=
mpool first and be confirmed first before the "default transaction" can.


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

* https://old.reddit.com/r/Bitcoin/comments/cc9psl/technical_a_brief_histor=
y_of_payment_channels/

My modifications to your scheme are just a modernization of the Spilman cha=
nnels.

Regards,
ZmnSCPxj