path: root/aa/c11ea11a4542a8833d73d103addc90ae037375

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 &quot;back-filling&quot; 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 &quot;burst mode&quot;, 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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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&#39;Beirne via bitcoin-dev wrote:<br>
&gt; Multiple parties could<br>
&gt; trustlessly collaborate to settle into a single CTV output using<br>
&gt; SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction<br>
&gt; 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>
&gt; Conceptually, CTV is the most parsimonious way to do such a scheme,<br=
>
&gt; since you can&#39;t really get smaller than a SHA256 commitment<br>
<br>
What&#39;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&#3=
9;t <br>
compatible with SH_ALL|SH_ACP, though, and it would require other <br>
privacy upgrades to LN.<br>
<br>
&gt; direct-from-coinbase payouts seem like a<br>
&gt; desirable feature which avoids some trust in pools.<br>
&gt; [...]<br>
&gt; If the payout was instead a single OP_CTV output, an arbitrary number<=
br>
&gt; of pool participants could be paid out &quot;atomically&quot; within a=
 single<br>
&gt; coinbase.=C2=A0 One limitation is<br>
&gt; the size of the coinbase outputs owed to constituent miners; this<br>
&gt; limits the number of participants in the pool.<br>
<br>
I&#39;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--