path: root/d1/c2a5dcfd1bcff965d52a028669a1ea58bbd210

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 50054C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Sep 2022 03:17:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 2449F4013F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Sep 2022 03:17:41 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2449F4013F
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=fmWTSTDn
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id R1tpTsq5KutW
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Sep 2022 03:17:39 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 082314012E
Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 082314012E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Sep 2022 03:17:38 +0000 (UTC)
Date: Mon, 05 Sep 2022 03:17:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1662347855; x=1662607055;
 bh=SVEyW7Gp/tIHoHSxy1aMxIt1qyaOPtzyhiiC70rusck=;
 h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID;
 b=fmWTSTDn4yN79xMV7e7405pDxvSYiLnYSS+TUY6w45NW+6B/xUExoN3rM3P651vcV
 0bAHzXI3SI4Z7QllS+KIREYOXtmbAT+fsgaltiorcrug8jcVuRiS371PzIkAUddvtQ
 PfmtrGqoICZABoVtUd6rPfdS9D3lPeuBIgCw7kwHb8T7GYYFhY4BEUCUzywV00YVPt
 7okfGBGlgByT6gQa9KkHgctyv0gyOX7k93M2tIhBgTeTaR0SBBob8fg3srJmIcXOGA
 39GhPHptitQJlD2CFakindWxPQCnrV+RpIqEHP5cQaEmhS2iemeT30sGJ0rGjOwShK
 IllWqbxKrG1ng==
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Sep 2022 03:17:41 -0000

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