diff options
| author | Jeremy Rubin <jeremy.l.rubin@gmail.com> | 2022-08-19 14:01:25 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-08-19 21:01:41 +0000 |
| commit | fb79267941e8e5bb705c68f4c09ee465fa981eb4 (patch) | |
| tree | 2dcd96f40fe1056818edfb336d0244a75cb3db4c | |
| parent | 9e4ef9ad325cd96543e36a9f3091d04f7e2f246a (diff) | |
| download | pi-bitcoindev-fb79267941e8e5bb705c68f4c09ee465fa981eb4.tar.gz pi-bitcoindev-fb79267941e8e5bb705c68f4c09ee465fa981eb4.zip | |
Re: [bitcoin-dev] More uses for CTV
| -rw-r--r-- | aa/c11ea11a4542a8833d73d103addc90ae037375 | 306 |
1 files changed, 306 insertions, 0 deletions
diff --git a/aa/c11ea11a4542a8833d73d103addc90ae037375 b/aa/c11ea11a4542a8833d73d103addc90ae037375 new file mode 100644 index 000000000..f84b14e04 --- /dev/null +++ b/aa/c11ea11a4542a8833d73d103addc90ae037375 @@ -0,0 +1,306 @@ +Return-Path: <jeremy.l.rubin@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 3C808C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 19 Aug 2022 21:01:39 +0000 (UTC) +Received: by mail-yw1-x1130.google.com with SMTP id + 00721157ae682-334dc616f86so152766587b3.8 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CAPfvXfLvYbKWSWatkunwdcOYN_YTCayr=B_Rm90R+1nUW_zFCg@mail.gmail.com> + <813858beca9d1d033fbb0a26921162d6@dtrt.org> +In-Reply-To: <813858beca9d1d033fbb0a26921162d6@dtrt.org> +From: Jeremy Rubin <jeremy.l.rubin@gmail.com> +Date: Fri, 19 Aug 2022 14:01:25 -0700 +Message-ID: <CAD5xwhhE=wt+XUJsUdMrSR+GpuEHpYoig=-Nk+mux6=bh1FrEA@mail.gmail.com> +To: "David A. Harding" <dave@dtrt.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <https://twitter.com/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 + +<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:#000000">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).</div><div = +class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon= +t-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D= +"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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.</div><div class=3D"gmail_default" style=3D"font= +-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div= +><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser= +if;font-size:small;color:#000000">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.</div><div class=3D"= +gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm= +all;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fam= +ily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><di= +v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f= +ont-size:small;color:#000000">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).</div><div class=3D"gmail_default" style=3D"font-family:= +arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cl= +ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-= +size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"f= +ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000">With r= +espect to mining pools and size constraints,=C2=A0<a href=3D"https://rubin.= +io/bitcoin/2021/12/12/advent-15/">https://rubin.io/bitcoin/2021/12/12/adven= +t-15/</a> shows how paying into batches of channels can be used to trustles= +sly compress payouts without custodial relationship.</div><div class=3D"gma= +il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small= +;color:#000000"><br></div><br clear=3D"all"><div><div dir=3D"ltr" class=3D"= +gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br>= +<a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin<= +/a><br></div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"l= +tr" class=3D"gmail_attr">On Fri, Aug 19, 2022 at 11:53 AM David A. Harding = +via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org= +">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote= + class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:= +1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left= +:1ex">On 2022-08-19 06:33, James O'Beirne via bitcoin-dev wrote:<br> +> Multiple parties could<br> +> trustlessly collaborate to settle into a single CTV output using<br> +> SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction<br> +> similar to coinjoins.<br> +<br> +Just to make sure I understand, is the reason for SH_ALL|SH_ACP so that <br= +> +any of the parties can subsequently RBF fee bump the transaction?<br> +<br> +> Conceptually, CTV is the most parsimonious way to do such a scheme,<br= +> +> since you can't really get smaller than a SHA256 commitment<br> +<br> +What's the advantage of CTV here compared to presigned transactions?=C2= +=A0 If <br> +multiple parties need to interact to cooperatively sign a transaction, <br> +no significant overhead is added by having them simultaneously sign a <br> +second transaction that spends from the output of the first transaction. <b= +r> +=C2=A0 Presigned transactions actually have two small benefits I can think = +of:<br> +<br> +1. The payment from the first transaction (containing the spends from <br> +the channel setup transactions) can be sent to a P2WPKH output, which is <b= +r> +actually smaller than a SHA256 commitment.=C2=A0 Though this probably does = +<br> +require an extra round of communication for commit-and-reveal to prevent <b= +r> +a collision attack on the P2WPKH address.[1]<br> +<br> +2. Having the first transaction pay a either a P2WPKH or bech32m output <br= +> +and the second transaction spend from that UTXO may blend in better with <b= +r> +other transactions, enhancing privacy.=C2=A0 This advantage probably isn= +9;t <br> +compatible with SH_ALL|SH_ACP, though, and it would require other <br> +privacy upgrades to LN.<br> +<br> +> direct-from-coinbase payouts seem like a<br> +> desirable feature which avoids some trust in pools.<br> +> [...]<br> +> 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<br> +> coinbase.=C2=A0 One limitation is<br> +> the size of the coinbase outputs owed to constituent miners; this<br> +> limits the number of participants in the pool.<br> +<br> +I'm confused by this.=C2=A0 What is the size limitation on coinbase out= +puts, <br> +how does it limit the number of participants in a pool, and how does CTV <b= +r> +fix that?<br> +<br> +Thanks,<br> +<br> +-Dave<br> +<br> +[1] <br> +<a href=3D"https://bitcoinops.org/en/newsletters/2020/06/24/#reminder-about= +-collision-attack-risks-on-two-party-ecdsa" rel=3D"noreferrer" target=3D"_b= +lank">https://bitcoinops.org/en/newsletters/2020/06/24/#reminder-about-coll= +ision-attack-risks-on-two-party-ecdsa</a><br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--0000000000006e1f4305e69e671c-- + |