From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id E1284C002D for ; Sun, 4 Sep 2022 22:31:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 1A377813C5 for ; Sun, 4 Sep 2022 22:31:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1A377813C5 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=notatether.com header.i=@notatether.com header.a=rsa-sha256 header.s=protonmail header.b=LHxXJ5d8 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2wEYWxLAJ2h for ; Sun, 4 Sep 2022 22:31:53 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 83D5F813C1 Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) by smtp1.osuosl.org (Postfix) with ESMTPS id 83D5F813C1 for ; Sun, 4 Sep 2022 22:31:51 +0000 (UTC) Date: Sun, 04 Sep 2022 22:31:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com; s=protonmail; t=1662330708; x=1662589908; bh=rFheFWpP3ueeBowyJhBEkUbVLnvl5II8UpvON3gae9w=; h=Date:To:From:Reply-To:Subject:Message-ID:Feedback-ID:From:To:Cc: Date:Subject:Reply-To:Feedback-ID:Message-ID; b=LHxXJ5d8a6Zn8M4t4vJ9BhxQbyJDd7NpLXwacTD7dHzWaY+rZRgF90HiTbQlurLYF QDp5+HD34rh4wWA4aOcLylDGXmUesssn9fffeKqzO+nTxLBA7SzANaTEdFwHBzzn99 FLqAI6OVZDrF1bVPkPBNnJXjFG+6RcD21tNPp+3zIK1RC6ZWtHTAVsd1SVPVZaMfbR HpsjxMEofJo9q6oDhSMiE6fVgDgKkPGGsTVBHy/PYLU1gpe3SMQoqvFdKhmcjvqyF7 oSLf2OCTepu3BZ9sFwNfAHyyepp+zH6/AdwoCu3dFIbxGyruF7hxMiaHb6xLi1PeRx D9kOD6RwCgjpA== To: bitcoin-dev@lists.linuxfoundation.org From: Ali Sherief Reply-To: Ali Sherief 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 X-Mailman-Approved-At: Sun, 04 Sep 2022 22:49:48 +0000 Subject: [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: Sun, 04 Sep 2022 22:31:56 -0000 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: * OP_CTLV OP_DROP = 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. - 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: OP_CHECKMUSIG in a public scenario where none of the participants want to= face the prospect of losing their money, and * OP_CTLV OP_DROP 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