Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3C808C002D for ; Fri, 19 Aug 2022 21:01:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id EAE178425F for ; Fri, 19 Aug 2022 21:01:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org EAE178425F Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=hPKTHlHG X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 G1V78SkpV1vV for ; Fri, 19 Aug 2022 21:01:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 90AC584076 Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) by smtp1.osuosl.org (Postfix) with ESMTPS id 90AC584076 for ; Fri, 19 Aug 2022 21:01:39 +0000 (UTC) Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-334dc616f86so152766587b3.8 for ; Fri, 19 Aug 2022 14:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc; bh=S66iQQif2giKniQM8VvbpXfmnDAnRfFhNob8VTym6gE=; b=hPKTHlHGzmYzON2eOLOHmbY2N5XtqMYqPvTjVhv0mPz0wbKJNTHlIXq5+J4r4LVp4a rPO1H2gqpx5H5UNhjeGnKRfwCpY1c0PJgFQQzOV3PnDtBK9n3LYzN5U6XDaCKxQeUyLB IrmSkyB+9CMz5t5nL+ce76v7M4V/1yCG7KQ71CsPgQsOgKxdOmbj7nmSuqpmjVfcT+vf 5QcSan8Xwt1KzNySvUIlzUplKycctCRgYDGhm6y+w7IcBEHeGLi1p8Jo1qMSeS+LfUv8 nRA6oGgIC/FgnXoaH5Lz14bp5rZOlLQXF1Dt/d5OTdmaRMF/fk8xQnxTj3VIN6trMAa/ Xohg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc; bh=S66iQQif2giKniQM8VvbpXfmnDAnRfFhNob8VTym6gE=; b=4rjmBoT8wHEXww8mrJ551x+D5DvhUrMt8Cj+Il8XTVe+nJXjwXVrIUjFA3QDYXkZYx GGaarNK41YfVtFmcSHEYnmX83bsYXSWdWZY1l7WHlD8q3u7AiqgxXDGZrly07qcB+3U8 a2fbMd6Jvjrx3PiJontMPhCRmGK0lckSfeuC7iobI6vMg+CgX5XXobawCgqCSKLjYRW6 iI+wD7EYeDepVyHOjQEUmCcaIsqJtoyG1pQc/JX6sBZ3/tkLwbKEUYJG6Oq+C8s6fSeI CucmVgmY/Sp0ixTnrNSnK2KHYG09NY7iqDSqNk/lHn6tPXJLIOtHXE1veMpVO7PqcO/T 1ujw== X-Gm-Message-State: ACgBeo33SNKaXKFYUk9a/nhYWo/bUwCaRinkU/f9xcyW8Kg9GNdAqsmt q124X+JzybECGd4+NLY6AUW4yfEuOK1by+lASvlijXv9v1Y= X-Google-Smtp-Source: AA6agR4c2avx+t+U2poopdL//Z2NXIBdQrlS7qiqDN3N1XWt0MoxPU7GSFjWiK5WVbxrU8g4Ozvs/n/HZDKX5X6R8FU= X-Received: by 2002:a25:1404:0:b0:692:6f18:c9d6 with SMTP id 4-20020a251404000000b006926f18c9d6mr9673420ybu.195.1660942898037; Fri, 19 Aug 2022 14:01:38 -0700 (PDT) MIME-Version: 1.0 References: <813858beca9d1d033fbb0a26921162d6@dtrt.org> In-Reply-To: <813858beca9d1d033fbb0a26921162d6@dtrt.org> From: Jeremy Rubin Date: Fri, 19 Aug 2022 14:01:25 -0700 Message-ID: To: "David A. Harding" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000006e1f4305e69e671c" 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 21:01:41 -0000 --0000000000006e1f4305e69e671c Content-Type: text/plain; charset="UTF-8" Presigned transactions have to use a N-of-N (2-2 for ln, more for pools) multisignature which is computed over the network whereas in-script commitments can be done 1 key that is a non-secret point (e.g., just the generator I think works). For large protocol trees (e.g., of size N) the savings can be substantial! It also reduces the amount of state that needs to be stored since the in-script sigs can be deterministic. Rene has some nice work demonstrating that latency in generating state transitions has a very substantial cost to the efficiency of routing, maybe he can chime in further. You can also do a "back-filling" where you get the best of both, by (after you commit to the quick to generate in-script version) lazily backfilling with an equivalent p2wpkh version. If you have a channel, when you are in "burst mode", you can cancel the longer to generate p2wpkh version when newer states come in. (data hazard/ bypass). With respect to mining pools and size constraints, https://rubin.io/bitcoin/2021/12/12/advent-15/ shows how paying into batches of channels can be used to trustlessly compress payouts without custodial relationship. -- @JeremyRubin On Fri, Aug 19, 2022 at 11:53 AM David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000006e1f4305e69e671c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Presigned transactions ha= ve to use a N-of-N (2-2 for ln, more for pools) multisignature which is com= puted over the network whereas in-script commitments can be done 1 key that= is a non-secret point (e.g., just the generator I think works).

For = large protocol trees (e.g., of size N) the savings can be substantial! It a= lso reduces the amount of state that needs to be stored since the in-script= sigs can be deterministic.

Rene has some nice work demonstrating tha= t latency in generating state transitions has a very substantial cost to th= e efficiency of routing, maybe he can chime in further.


You can also do a "back-filling" wh= ere you get the best of both, by (after you commit to the quick to generate= in-script version) lazily backfilling with an equivalent p2wpkh version. I= f you have a channel, when you are in "burst mode", you can cance= l the longer to generate=C2=A0p2wpkh version when newer states come in. (da= ta hazard/ bypass).


With r= espect to mining pools and size constraints,=C2=A0https://rubin.io/bitcoin/2021/12/12/adven= t-15/ shows how paying into batches of channels can be used to trustles= sly compress payouts without custodial relationship.



On Fri, Aug 19, 2022 at 11:53 AM David A. Harding = via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
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?=C2= =A0 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. =C2=A0 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.=C2=A0 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.=C2=A0 This advantage probably isn= 9;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<= br> > of pool participants could be paid out "atomically" within a= single
> coinbase.=C2=A0 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.=C2=A0 What is the size limitation on coinbase out= puts,
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-coll= ision-attack-risks-on-two-party-ecdsa
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000006e1f4305e69e671c--