From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8760FC002D for ; Tue, 3 May 2022 09:15:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 65EAC4037C for ; Tue, 3 May 2022 09:15:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl 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 ncD0JjCxtOiB for ; Tue, 3 May 2022 09:15:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpo115.poczta.onet.pl (smtpo115.poczta.onet.pl [213.180.149.168]) by smtp2.osuosl.org (Postfix) with ESMTPS id 16067400FB for ; Tue, 3 May 2022 09:15:47 +0000 (UTC) Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4KsvSr39gBzlg8Gj for ; Tue, 3 May 2022 11:15:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1651569340; bh=y98AFewBT7v9lMkmFW0TJI4NgBSDCszo8Z8/BeUfvhw=; h=From:To:Date:Subject:From; b=PDuqoql2R3bSU6AREehSzfYExcu850MH+vSLhU4hz1hZ0vHvqOoW1FQuOBygqjsST RrreWj6oN2zVyrtUKHJ+eE7q44UCvSBJQHp/qgI+itFj03rAnoak1NFMLGCY76Oxnu Hw+czBp7nbdMgOZNhrMuYKQVOLhy8KNmktQuIi+c= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.224.171] by pmq5v.m5r2.onet via HTTP id ; Tue, 03 May 2022 11:15:40 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: "bitcoin-dev@lists.linuxfoundation.org" Date: Tue, 03 May 2022 11:15:36 +0200 Message-Id: <160827995-4aa198ec768a1ec2f886b21056804946@pmq5v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.224.171;PL;1 X-Mailman-Approved-At: Tue, 03 May 2022 09:24:43 +0000 Subject: [bitcoin-dev] CoinPool should focus on different sighashes 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: Tue, 03 May 2022 09:15:49 -0000 It seems that the current consensus with Taproot is enough to implement Coi= nPool. There are no needed changes if we want to form a basic version of th= at protocol, so it probably should be done now (or at least started, even i= n some signet or testnet3). Later, if some features like SIGHASH_ANYPREVOUT= (or the same with ANYSCRIPT) would be added, then it could be improved, ju= st in the same way, as Lightning Network is moving from P2WSH to P2TR. To start with, we assume there are six participants that are going to form = a CoinPool. They start their journey by moving all of their coins to a 6-of= -6 multisig channel. Nothing is signed, first we focus on making transactio= ns, then we will sign them backwards to make it trustless. +------------------------------------------------+ | Alice 3.51 -> ABCDEF (6-of-6 multisig) 19.94 | | Bob 0.90 | | Charlie 6.81 | | Daniel 7.29 | | Elaine 0.84 | | Frank 0.60 | +------------------------------------------------+ That first transaction is simple, we could sign it later with SIGHASH_ALL. = But it seems we can handle it better: what about SIGHASH_ANYONECANPAY? Then= , all outputs (so just one) will be signed, but anyone could attach another= inputs if needed. Also, the first person could use SIGHASH_SINGLE | SIGHAS= H_ANYONECANPAY, but it is optional, and I assume we don't need any "group l= eader" or "coordinator", so anyone will just use SIGHASH_ANYONECANPAY, they= will only switch destination and amount, to form a channel in a P2P way. C= hannel forming could work in a similar way as mempools in Bitcoin: all mess= ages will fly, until there will be some agreement, and some group will coll= ect all needed signatures. But for now, nothing is signed, so let's go to t= he next transaction. To close that channel, a group should still exist, and just detach some par= ticipant. Closing the whole group is not an option, we want to encourage Co= inPool formation, so we don't want to continuously open and close the whole= channel. Let's assume that Alice wants to leave. That means, we should get= a group of five participants and Alice, nothing more is needed: +-----------------------------------------------------------------+ | ABCDEF (6-of-6 multisig) 19.94 -> BCDEF (5-of-5 multisig) 16.43 | | Alice 3.50 | +-----------------------------------------------------------------+ When we talk about sighashes, that case is quite interesting. The group of = five participants could use SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, and just= bind that to the first output. But Alice cannot use the same sighash, beca= use then her funds could be stolen by miners. She can use SIGHASH_ANYONECAN= PAY, then all outputs will be protected by her signature. However, combinin= g two different sighashes is not going to work well with Schnorr signatures= . For that reason, we need two of them. So, the TapScript branch for that A= BCDEF multisig could be: " OP_CHECKSIGVERIFY OP_= CHECKSIG". Also, this case is even more interesting: Alice could also use SIGHASH_SING= LE | SIGHASH_ANYONECANPAY in that ABCDEF multisig and spend by key, but the= n she needs some on-chain output. It could be anything, even some output sh= e received from dust attack. Then, she could use SIGHASH_ANYONECANPAY on th= at dust output, just to protect her coins. The total transaction size will = be roughly the same, but then she could hide the whole group under a single= Schnorr signature. The missing part here is of course SIGHASH_ANYPREVOUT, then less transactio= ns are needed. But even without that, the basic protocol can be deployed he= re and now, the only overhead will be transaction storage, because we need = to sign every possible transaction for closing the channel. Also, it will b= e larger in case where all participants are going to close the channel, the= n each detachment will be processed in a separate transaction. When it comes to handling costs, the cost of leaving the channel is paid by= the detached person. That means, even if going through the least compresse= d path is possible, it would be costly for all participants trying to do th= at, so it should discourage them and encourage to play by the rules, and mo= ve all coins through N-of-N multisig. Also, when we talk about covenants, it is in fact some kind of covenant. By= having different sighashes for different signatures, we can easily restric= t outputs to any scripts we want (and every participant can just collect ot= her signatures, and later decide, where to send its own coins, so it is pos= sible to pay someone directly, instead of first moving coins to some person= al address, so there is one less transaction; tldr: another payment can be = done during closing the channel). So, my conclusion is that changing sighashes is far easier and more powerfu= l than my previous idea of "paying to signatures", so I will probably focus= on that instead.