Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 50054C002D for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: > * OP_CTLV OP_DROP 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. >=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: `* OP_CTLV OP_DROP 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