path: root/06/66dcc2c414df26f033ee62b395e31e3a754cad

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8B490C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Aug 2022 17:20:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 5F57241D29
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Aug 2022 17:20:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5F57241D29
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=dDixXW1c
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id l1gA_HviiJOh
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Aug 2022 17:20:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6A5C041D27
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com
 [IPv6:2607:f8b0:4864:20::102d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 6A5C041D27
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Aug 2022 17:20:53 +0000 (UTC)
Received: by mail-pj1-x102d.google.com with SMTP id g18so5269680pju.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Aug 2022 10:20:53 -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=sI19BtDvupdAAFAMdzhnLVNNj3zkkHyIeMYPv5rwj7o=;
 b=dDixXW1cW2mTmAl+TO5HcRIbYtm72+b60jO8mtSOo2qgHKdbhnHogUX+rV23icktR3
 H+tOPodB8MWhj8MhSe6eBAibgg+7JKRzJKdnpBJyuO59fxXJ5TxgpB0nUDEYPqk85Ajy
 dk6sSyjKLXtQsbw8IrmG5dT62HgJPSr0QbT0KzVRlxiq71SzmzRRY4r57x3HcMLqRprU
 5DHyOHicZ0JACZi+DVM064523AK2nWxN2Ukehkmgvauk+oVY2gQ82MYX1pzPJubeJNB4
 t97fHx9SWncnK369VJZykd5FJBCNKYyYpLNQGfUJOaqT79h5Ym87yahooCjgTduu22kg
 XYZg==
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=sI19BtDvupdAAFAMdzhnLVNNj3zkkHyIeMYPv5rwj7o=;
 b=BwmUw2T2x+/MYPyiTJX+v7UcXZPefLgEPMi5vnX+LRyppyvpncA6ZYn1l/GKBC/A7u
 FvK9Be76g4NfZnNjQMP5jghVqANPWAxGNT2ECdF6HAQTEiEFdqhc8PgszdwhUzOilNdQ
 gdBywD9bHOIWFZEU3Zrsv1pi/dQ72rnKvZ2Yf8LsU7zFYWpjMOGGtHx70e/XngHS+sTK
 dMbQt3umOUMpUptBmX+DpZAsmf8hkzVAD2HuOvArpQkd8E99OEN7YXIyMs9khO1QTITH
 hXBcIBiniLtrdD61trbSgab15VJD8pxuCfrYl9D+htCRaEiEURDrv/hztWMr/SwK7bQt
 oO2A==
X-Gm-Message-State: ACgBeo1MB/ls4ef78DH0+Exj0DpLbyyw+0HCyVPMYqJB072YPss8NwGM
 TKzMLsq3rgV7ZD5AscHLdHbXMriGRXKfJzCPapQ=
X-Google-Smtp-Source: AA6agR5EFzgULGxxtHeUb8y1tkKM7KD2uG6RZJ1vtJf1Okg1N5cZfKcAMKMhW55ZmAxa+8wYgrELY2uPFOnsjK3XhDE=
X-Received: by 2002:a17:902:d403:b0:172:9f0a:e591 with SMTP id
 b3-20020a170902d40300b001729f0ae591mr8353828ple.109.1660929652607; Fri, 19
 Aug 2022 10:20:52 -0700 (PDT)
MIME-Version: 1.0
References: <CAPfvXfLvYbKWSWatkunwdcOYN_YTCayr=B_Rm90R+1nUW_zFCg@mail.gmail.com>
In-Reply-To: <CAPfvXfLvYbKWSWatkunwdcOYN_YTCayr=B_Rm90R+1nUW_zFCg@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Fri, 19 Aug 2022 13:20:41 -0400
Message-ID: <CAB3F3DvMMjfV0eS4DvEzXdKLNa+549-ctLNHON8JQBzxWjKD-A@mail.gmail.com>
To: "James O'Beirne" <james.obeirne@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f0d07105e69b51d1"
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 17:20:55 -0000

--000000000000f0d07105e69b51d1
Content-Type: text/plain; charset="UTF-8"

Hi James,

Could you elaborate on a L2 contract where speedy
settlement of the "first part" can be done, while having the rest
take their time? I'm more thinking about time-out based protocols.

Naturally my mind drifts to LN, where getting the proper commitment
transaction confirmed in a timely fashion is required to get the proper
balances back. The one hitch is that for HTLCs you still need speedy
resolution otherwise theft can occur. And given today's "layered
commitment" style transaction where HTLCs are decoupled from
the balance output timeouts, I'm not sure this can save much.

I don't know enough about vault designs to judge.

CTV style commitments have popped up in a couple places in my
work on eltoo(emulated via APO sig-in-script), but mostly in the
context of reducing interactivity in protocols, not in byte savings per se.

Thanks!

Greg

On Fri, Aug 19, 2022 at 12:34 PM James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Over the past few months there have been a few potential uses of
> OP_CHECKTEMPLATEVERIFY (BIP-119)
> (https://github.com/bitcoin/bitcoin/pull/21702) that I've found
> interesting.
>
> # Congestion control redux
>
> When I first heard of CTV, a presentation Jeremy did at Chaincode back
> in 2018 or '19, he cited congestion control as one of its main use
> cases.
>
> The pitch went something like
>
> > When there is a high demand for blockspace it becomes very expensive
> > to make transactions. By using OP_CHECKTEMPLATEVERIFY, a large volume
> > payment processor may aggregate all their payments into a single O(1)
> > transaction for purposes of confirmation. Then, some time later, the
> > payments can be expanded out of that UTXO when the demand for
> > blockspace is decreased.
>
> (from https://utxos.org/uses/scaling/)
>
> At the time that didn't particularly grab me; the idea of smoothing fee
> rates seemed nice but marginal.
>
> But recently, two particular cases have made me reassess the value of
> congestion control.
>
> The first stems from the necessity of L2 protocols (payment channels,
> vaults, etc.) to, under certain circumstances, settle to the chain in a
> timely way in order to prevent abuse of the protocol. If some
> unexpected condition (a protocol exploit, large network disconnect, en
> masse vault breach, etc.) creates a situation where a large number of
> contracts need to settle to the chain in short order, mempools could
> fill up and protocol failures could happen for want of mempool/block
> space
> (
> https://github.com/jamesob/mempool.work#failure-one-mempool-to-rule-them-all
> ).
>
> In such a case, CTV could be used effectively to "compress" settlement
> commitments, get them on-chain, and then facilitate later unpacking of
> the CTV ouputs into the contract's true end state.
>
> This amounts to `n` contract-control outputs (e.g. a lightning funding
> transaction outputs) being spent into a single CTV output, which
> commits to the final settlement state. 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.
>
> Put simply, CTV allows deferring the chainspace required for the final
> settlement outputs, but still immediately requires space for the
> inputs. This might sound like a temporary reprieve from half-ish of the
> space required to settle, but in many (most?) cases the outputs require
> substantially more space than the inputs, given that often we're
> settling a single UTXO into multiple payouts per party. A 2, 3, or
> 4-fold increase (depending on the contracting pattern) in capacity
> isn't a silver bullet, but it could ameliorate the damage of unexpected
> settlement "tidal waves."
>
> Conceptually, CTV is the most parsimonious way to do such a scheme,
> since you can't really get smaller than a SHA256 commitment, and that's
> essentially all CTV is.
>
> The second congestion control case is related to a recent post Bram
> made about stability under a no-block-subsidy regime. He posted
>
> > If transaction fees came in at an even rate over time all at the
> > exact same level then they work fine for security, acting similarly
> > to fixed block rewards. Unfortunately that isn't how it works in the
> > real world. There's a very well established day/night cycle with fees
> > going to zero overnight and even longer gaps on weekends and
> > holidays. If in the future Bitcoin is entirely dependent on fees for
> > security (scheduled very strongly) and this pattern keeps up
> > (overwhelmingly likely) then this is going to become a serious
> > problem.
>
> (from
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html
> )
>
> Ryan Grant points out that CTV's congestion control use could help to
> smooth fees, creating a less spiky incentive to mine
> (
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html
> ).
>
> Admittedly the original concern is speculative and a ways off from now,
> as others in the thread pointed out. But having CTV-based fee smoothing
> as an option certainly doesn't seem like a bad thing.
>
>
> # Atomic mining pool payouts
>
> Laurentia is a mining pool design that pays participants out directly
> from the coinbase of found blocks.
>
> > Block solve reward is distributed directly from the block to each
> > user, meaning each user gets a 'mined' transaction directly into
> > their wallet as soon as the block is solved so there is no wait to
> > get paid and no pool wallet storing user's rewards.
>
> (from
>
> https://laurentiapool.org/wp-content/uploads/2020/05/laurentiapool_whitepaper.pdf
> )
>
> I'm not a mining expert and so I can't speak to the efficacy of the
> paper as a whole, but direct-from-coinbase payouts seem like a
> desirable feature which avoids some trust in pools. One limitation is
> the size of the coinbase outputs owed to constituent miners; this
> limits the number of participants in the pool.
>
> 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.
>
> ---
>
> CTV both in concept and implementation is very simple, and I think it
> is likely to continue to yield potential applications.
> "Settlement compression" seems like a useful thing, especially in light
> of a possible increase in L2 usage, and CTV seems like the simplest
> means to enable it.
>
> Interestingly, an analogue for this pattern going the other direction
> is possible, e.g. non-interactive channel openings
> (https://utxos.org/uses/non-interactive-channels/), which would allow
> e.g. opening a lightning channel with a merchant who doesn't want to
> have their spending keys constantly accessible from a point-of-sale,
> but can still parse/verify CTV commitments.
>
> Regards,
> James
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000f0d07105e69b51d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi James,<div><br></div><div>Could you elaborate on a L2 c=
ontract=C2=A0where speedy</div><div>settlement of the &quot;first part&quot=
; can be done, while having the rest</div><div>take their time? I&#39;m mor=
e thinking=C2=A0about time-out based protocols.</div><div><br></div><div>Na=
turally my mind drifts to LN, where getting the proper commitment<br></div>=
<div>transaction=C2=A0confirmed in a timely fashion is required to get the =
proper</div><div>balances back. The one hitch is that for HTLCs you still n=
eed speedy</div><div>resolution otherwise theft can occur. And given today&=
#39;s &quot;layered</div><div>commitment&quot; style transaction where=C2=
=A0HTLCs are decoupled from</div><div>the balance output timeouts, I&#39;m =
not sure this can save much.</div><div><br></div><div>I don&#39;t know enou=
gh about vault designs to judge.</div><div><br></div><div>CTV style commitm=
ents have popped up in a couple places in my</div><div>work on eltoo(emulat=
ed via APO sig-in-script), but mostly in the</div><div>context of reducing =
interactivity in protocols,=C2=A0not in byte savings per se.</div><div><br>=
</div><div>Thanks!</div><div><br></div><div>Greg</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Aug 19, 2022=
 at 12:34 PM James O&#39;Beirne via bitcoin-dev &lt;<a href=3D"mailto:bitco=
in-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:1px solid rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr">Over the past few months there have been a few potential uses =
of<br>OP_CHECKTEMPLATEVERIFY (BIP-119)<br>(<a href=3D"https://github.com/bi=
tcoin/bitcoin/pull/21702" target=3D"_blank">https://github.com/bitcoin/bitc=
oin/pull/21702</a>) that I&#39;ve found<br>interesting.<br><br># Congestion=
 control redux<br><br>When I first heard of CTV, a presentation Jeremy did =
at Chaincode back<br>in 2018 or &#39;19, he cited congestion control as one=
 of its main use<br>cases.<br><br>The pitch went something like<br><br>&gt;=
 When there is a high demand for blockspace it becomes very expensive<br>&g=
t; to make transactions. By using OP_CHECKTEMPLATEVERIFY, a large volume<br=
>&gt; payment processor may aggregate all their payments into a single O(1)=
<br>&gt; transaction for purposes of confirmation. Then, some time later, t=
he<br>&gt; payments can be expanded out of that UTXO when the demand for<br=
>&gt; blockspace is decreased.<br><br>(from <a href=3D"https://utxos.org/us=
es/scaling/" target=3D"_blank">https://utxos.org/uses/scaling/</a>)<br><br>=
At the time that didn&#39;t particularly grab me; the idea of smoothing fee=
<br>rates seemed nice but marginal.<br><br>But recently, two particular cas=
es have made me reassess the value of<br>congestion control.<br><br>The fir=
st stems from the necessity of L2 protocols (payment channels,<br>vaults, e=
tc.) to, under certain circumstances, settle to the chain in a<br>timely wa=
y in order to prevent abuse of the protocol. If some<br>unexpected conditio=
n (a protocol exploit, large network disconnect, en<br>masse vault breach, =
etc.) creates a situation where a large number of<br>contracts need to sett=
le to the chain in short order, mempools could<br>fill up and protocol fail=
ures could happen for want of mempool/block<br>space<br>(<a href=3D"https:/=
/github.com/jamesob/mempool.work#failure-one-mempool-to-rule-them-all" targ=
et=3D"_blank">https://github.com/jamesob/mempool.work#failure-one-mempool-t=
o-rule-them-all</a>).<br><br>In such a case, CTV could be used effectively =
to &quot;compress&quot; settlement<br>commitments, get them on-chain, and t=
hen facilitate later unpacking of<br>the CTV ouputs into the contract&#39;s=
 true end state.<br><br>This amounts to `n` contract-control outputs (e.g. =
a lightning funding<br>transaction outputs) being spent into a single CTV o=
utput, which<br>commits to the final settlement state. Multiple parties cou=
ld<br>trustlessly collaborate to settle into a single CTV output using<br>S=
IGHASH_ALL | ANYONECANPAY. This requires a level of interaction<br>similar =
to coinjoins.<br><br>Put simply, CTV allows deferring the chainspace requir=
ed for the final<br>settlement outputs, but still immediately requires spac=
e for the<br>inputs. This might sound like a temporary reprieve from half-i=
sh of the<br>space required to settle, but in many (most?) cases the output=
s require<br>substantially more space than the inputs, given that often we&=
#39;re<br>settling a single UTXO into multiple payouts per party. A 2, 3, o=
r<br>4-fold increase (depending on the contracting pattern) in capacity<br>=
isn&#39;t a silver bullet, but it could ameliorate the damage of unexpected=
<br>settlement &quot;tidal waves.&quot;<br><br>Conceptually, CTV is the mos=
t parsimonious way to do such a scheme,<br>since you can&#39;t really get s=
maller than a SHA256 commitment, and that&#39;s<br>essentially all CTV is.<=
br><br>The second congestion control case is related to a recent post Bram<=
br>made about stability under a no-block-subsidy regime. He posted<br><br>&=
gt; If transaction fees came in at an even rate over time all at the<br>&gt=
; exact same level then they work fine for security, acting similarly<br>&g=
t; to fixed block rewards. Unfortunately that isn&#39;t how it works in the=
<br>&gt; real world. There&#39;s a very well established day/night cycle wi=
th fees<br>&gt; going to zero overnight and even longer gaps on weekends an=
d<br>&gt; holidays. If in the future Bitcoin is entirely dependent on fees =
for<br>&gt; security (scheduled very strongly) and this pattern keeps up<br=
>&gt; (overwhelmingly likely) then this is going to become a serious<br>&gt=
; problem.<br><br>(from<br><a href=3D"https://lists.linuxfoundation.org/pip=
ermail/bitcoin-dev/2022-July/020702.html" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html</a>)<br><br>=
Ryan Grant points out that CTV&#39;s congestion control use could help to<b=
r>smooth fees, creating a less spiky incentive to mine<br>(<a href=3D"https=
://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html" t=
arget=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
22-July/020702.html</a>).<br><br>Admittedly the original concern is specula=
tive and a ways off from now,<br>as others in the thread pointed out. But h=
aving CTV-based fee smoothing<br>as an option certainly doesn&#39;t seem li=
ke a bad thing.<br><br><br># Atomic mining pool payouts<br><br>Laurentia is=
 a mining pool design that pays participants out directly<br>from the coinb=
ase of found blocks.<br><br>&gt; Block solve reward is distributed directly=
 from the block to each<br>&gt; user, meaning each user gets a &#39;mined&#=
39; transaction directly into<br>&gt; their wallet as soon as the block is =
solved so there is no wait to<br>&gt; get paid and no pool wallet storing u=
ser&#39;s rewards.<br><br>(from<br><a href=3D"https://laurentiapool.org/wp-=
content/uploads/2020/05/laurentiapool_whitepaper.pdf" target=3D"_blank">htt=
ps://laurentiapool.org/wp-content/uploads/2020/05/laurentiapool_whitepaper.=
pdf</a>)<br><br>I&#39;m not a mining expert and so I can&#39;t speak to the=
 efficacy of the<br>paper as a whole, but direct-from-coinbase payouts seem=
 like a<br>desirable feature which avoids some trust in pools. One limitati=
on is<br>the size of the coinbase outputs owed to constituent miners; this<=
br>limits the number of participants in the pool.<br><br>If the payout was =
instead a single OP_CTV output, an arbitrary number<br>of pool participants=
 could be paid out &quot;atomically&quot; within a single<br>coinbase.<br><=
br>---<br><br>CTV both in concept and implementation is very simple, and I =
think it<br>is likely to continue to yield potential applications.<br>&quot=
;Settlement compression&quot; seems like a useful thing, especially in ligh=
t<br>of a possible increase in L2 usage, and CTV seems like the simplest<br=
>means to enable it.<br><br>Interestingly, an analogue for this pattern goi=
ng the other direction<br>is possible, e.g. non-interactive channel opening=
s<br>(<a href=3D"https://utxos.org/uses/non-interactive-channels/" target=
=3D"_blank">https://utxos.org/uses/non-interactive-channels/</a>), which wo=
uld allow<br>e.g. opening a lightning channel with a merchant who doesn&#39=
;t want to<br>have their spending keys constantly accessible from a point-o=
f-sale,<br>but can still parse/verify CTV commitments.<br><br>Regards,<br>J=
ames</div>
_______________________________________________<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>

--000000000000f0d07105e69b51d1--