Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 88C7FC002D for ; Fri, 19 Aug 2022 18:53:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5D4D160ABE for ; Fri, 19 Aug 2022 18:53:43 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5D4D160ABE X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW8thFD4Hsef for ; Fri, 19 Aug 2022 18:53:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 575E26064D Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [IPv6:2607:fe70:0:3::d]) by smtp3.osuosl.org (Postfix) with ESMTPS id 575E26064D for ; Fri, 19 Aug 2022 18:53:42 +0000 (UTC) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id E547C2800049; Fri, 19 Aug 2022 11:53:39 -0700 (PDT) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Fri, 19 Aug 2022 11:53:39 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 19 Aug 2022 08:53:39 -1000 From: "David A. Harding" To: James O'Beirne , Bitcoin Protocol Discussion In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.10 Message-ID: <813858beca9d1d033fbb0a26921162d6@dtrt.org> X-Sender: dave@dtrt.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 6d8.62ffdc33.b3217.0 Subject: Re: [bitcoin-dev] More uses for CTV 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: Fri, 19 Aug 2022 18:53:43 -0000 On 2022-08-19 06:33, James O'Beirne via bitcoin-dev wrote: > Multiple parties could > trustlessly collaborate to settle into a single CTV output using > SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction > similar to coinjoins. Just to make sure I understand, is the reason for SH_ALL|SH_ACP so that any of the parties can subsequently RBF fee bump the transaction? > Conceptually, CTV is the most parsimonious way to do such a scheme, > since you can't really get smaller than a SHA256 commitment What's the advantage of CTV here compared to presigned transactions? If multiple parties need to interact to cooperatively sign a transaction, no significant overhead is added by having them simultaneously sign a second transaction that spends from the output of the first transaction. Presigned transactions actually have two small benefits I can think of: 1. The payment from the first transaction (containing the spends from the channel setup transactions) can be sent to a P2WPKH output, which is actually smaller than a SHA256 commitment. Though this probably does require an extra round of communication for commit-and-reveal to prevent a collision attack on the P2WPKH address.[1] 2. Having the first transaction pay a either a P2WPKH or bech32m output and the second transaction spend from that UTXO may blend in better with other transactions, enhancing privacy. This advantage probably isn't compatible with SH_ALL|SH_ACP, though, and it would require other privacy upgrades to LN. > direct-from-coinbase payouts seem like a > desirable feature which avoids some trust in pools. > [...] > If the payout was instead a single OP_CTV output, an arbitrary number > of pool participants could be paid out "atomically" within a single > coinbase. One limitation is > the size of the coinbase outputs owed to constituent miners; this > limits the number of participants in the pool. I'm confused by this. What is the size limitation on coinbase outputs, how does it limit the number of participants in a pool, and how does CTV fix that? Thanks, -Dave [1] https://bitcoinops.org/en/newsletters/2020/06/24/#reminder-about-collision-attack-risks-on-two-party-ecdsa