path: root/f8/13e6cc4431aac7f2343d80dea5a654700c0b06

Return-Path: <james.obeirne@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D749DC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Aug 2022 16:33:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id ADA9441CAC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Aug 2022 16:33:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org ADA9441CAC
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=dSqYRPYo
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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id cMv3V4TOWzIo
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Aug 2022 16:33:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org A9991408EF
Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com
 [IPv6:2001:4860:4864:20::35])
 by smtp4.osuosl.org (Postfix) with ESMTPS id A9991408EF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Aug 2022 16:33:49 +0000 (UTC)
Received: by mail-oa1-x35.google.com with SMTP id
 586e51a60fabf-11c5ee9bf43so5791578fac.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Aug 2022 09:33:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:mime-version:from:to:cc;
 bh=O+UcQ5GNL3XIGuajAydzzq+tAnt3jx46+8ua0vTgYSw=;
 b=dSqYRPYojxqyHZnT2wtQJg9zfHlVsnaC17sxvMhC2HpS3I0BqNw4arlEa3/a2/CY9/
 3yOoB2+pIgASnEGfZcrSWlkuIfUeOpnjHXCUQOJoSABUFWjveEIbTgJVJoeAXLOBrJGh
 sFG7ORFHM5vGz1qnwR1uhnQ+NoM1qBJD7PrNtuAcKVAxCAlayMViLzoBhWhgPub4oBof
 kW/sDBypKsICEeE8e5KHTQ67Rf48hglUuo2SJWKeOJzdUgmxWvkLOnguQv4zfg0ZpPWo
 sYRgo2t5hpvtn9EK4V8RAecdg6kDTrAHWqA8evhqW5qoHsk0GvR8KWuRe10WtDgPj/g6
 jxCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc;
 bh=O+UcQ5GNL3XIGuajAydzzq+tAnt3jx46+8ua0vTgYSw=;
 b=qjzw5qi8oA9POA81tgzxhCx7X8wLoL4PQH/aQmj1ap0lc4qCytJybRFnw4d272qaAF
 IVPCJ9gliXALIPc7lGsL0HKS0t9m8wd9LLeA/xLg6RkofUhyE0/QuC+8Hku5CFQC5bdW
 xmxyin03upkYbLLs5WoLVK9ryEMaQg8D9u3FY4OkOb0zLitEY3eSPNEuY85rMpai5RA8
 Gu3DGgIuaQ1qbx1mbN4YEhqSmG1108aXfeS1Dk6D2fX/za0n8atpL2VLwcQOE26obNHf
 aWloR0zD0UnRu8O4rThRTEb3xafJR4sQUQMJNTJKnURGBCyabkZ6pzVTNPCXRMvXTA7p
 Lh4Q==
X-Gm-Message-State: ACgBeo2HcxYsOaZ3rUg/tX8eEvaaV9Xbc8jxNpE4x+VfK5hbyQSzFFsn
 q5nrm5R/ojXoZ8fN1w9F7EBOgaFnCgAbQrmrJhbvmXprKJs=
X-Google-Smtp-Source: AA6agR7x1VaIe0QWlr+dmcuI4FcxEg0vabMRz39/sp/ItqczsSTziqhD64C96AcEIOiNwQuIVATHFHzbQbB/cgBLON8=
X-Received: by 2002:a05:6870:a68e:b0:f2:bc5e:1ab7 with SMTP id
 i14-20020a056870a68e00b000f2bc5e1ab7mr7008146oam.193.1660926828003; Fri, 19
 Aug 2022 09:33:48 -0700 (PDT)
MIME-Version: 1.0
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Fri, 19 Aug 2022 12:33:37 -0400
Message-ID: <CAPfvXfLvYbKWSWatkunwdcOYN_YTCayr=B_Rm90R+1nUW_zFCg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000094f28905e69aa9c0"
Subject: [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 16:33:51 -0000

--00000000000094f28905e69aa9c0
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr">Over the past few months there have been a few potential u=
ses of<br>OP_CHECKTEMPLATEVERIFY (BIP-119)<br>(<a href=3D"https://github.co=
m/bitcoin/bitcoin/pull/21702">https://github.com/bitcoin/bitcoin/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 b=
ack<br>in 2018 or &#39;19, he cited congestion control as one of its main u=
se<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>&gt; to make tra=
nsactions. By using OP_CHECKTEMPLATEVERIFY, a large volume<br>&gt; payment =
processor may aggregate all their payments into a single O(1)<br>&gt; trans=
action for purposes of confirmation. Then, some time later, the<br>&gt; pay=
ments can be expanded out of that UTXO when the demand for<br>&gt; blockspa=
ce is decreased.<br><br>(from <a href=3D"https://utxos.org/uses/scaling/">h=
ttps://utxos.org/uses/scaling/</a>)<br><br>At the time that didn&#39;t part=
icularly grab me; the idea of smoothing fee<br>rates seemed nice but margin=
al.<br><br>But recently, two particular cases have made me reassess the val=
ue of<br>congestion control.<br><br>The first stems from the necessity of L=
2 protocols (payment channels,<br>vaults, etc.) to, under certain circumsta=
nces, settle to the chain in a<br>timely way in order to prevent abuse of t=
he protocol. If some<br>unexpected condition (a protocol exploit, large net=
work disconnect, en<br>masse vault breach, etc.) creates a situation where =
a large number of<br>contracts need to settle to the chain in short order, =
mempools could<br>fill up and protocol failures could happen for want of me=
mpool/block<br>space<br>(<a href=3D"https://github.com/jamesob/mempool.work=
#failure-one-mempool-to-rule-them-all">https://github.com/jamesob/mempool.w=
ork#failure-one-mempool-to-rule-them-all</a>).<br><br>In such a case, CTV c=
ould be used effectively to &quot;compress&quot; settlement<br>commitments,=
 get them on-chain, and then facilitate later unpacking of<br>the CTV ouput=
s into the contract&#39;s true end state.<br><br>This amounts to `n` contra=
ct-control outputs (e.g. a lightning funding<br>transaction outputs) being =
spent into a single CTV output, which<br>commits to the final settlement st=
ate. Multiple parties could<br>trustlessly collaborate to settle into a sin=
gle CTV output using<br>SIGHASH_ALL | ANYONECANPAY. This requires a level o=
f interaction<br>similar to coinjoins.<br><br>Put simply, CTV allows deferr=
ing the chainspace required for the final<br>settlement outputs, but still =
immediately requires space for the<br>inputs. This might sound like a tempo=
rary reprieve from half-ish of the<br>space required to settle, but in many=
 (most?) cases the outputs require<br>substantially more space than the inp=
uts, given that often we&#39;re<br>settling a single UTXO into multiple pay=
outs per party. A 2, 3, or<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>Con=
ceptually, CTV is the most parsimonious way to do such a scheme,<br>since y=
ou can&#39;t really get smaller than a SHA256 commitment, and that&#39;s<br=
>essentially all CTV is.<br><br>The second congestion control case is relat=
ed to a recent post Bram<br>made about stability under a no-block-subsidy r=
egime. He posted<br><br>&gt; If transaction fees came in at an even rate ov=
er time all at the<br>&gt; exact same level then they work fine for securit=
y, acting similarly<br>&gt; to fixed block rewards. Unfortunately that isn&=
#39;t how it works in the<br>&gt; real world. There&#39;s a very well estab=
lished day/night cycle with fees<br>&gt; going to zero overnight and even l=
onger gaps on weekends and<br>&gt; holidays. If in the future Bitcoin is en=
tirely dependent on fees for<br>&gt; security (scheduled very strongly) and=
 this pattern keeps up<br>&gt; (overwhelmingly likely) then this is going t=
o become a serious<br>&gt; problem.<br><br>(from<br><a href=3D"https://list=
s.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html">https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html</a>)<=
br><br>Ryan Grant points out that CTV&#39;s congestion control use could he=
lp to<br>smooth fees, creating a less spiky incentive to mine<br>(<a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/02070=
2.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/0=
20702.html</a>).<br><br>Admittedly the original concern is speculative and =
a ways off from now,<br>as others in the thread pointed out. But having CTV=
-based fee smoothing<br>as an option certainly doesn&#39;t seem like 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 coinbase of fo=
und 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; trans=
action 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 user&#39;s=
 rewards.<br><br>(from<br><a href=3D"https://laurentiapool.org/wp-content/u=
ploads/2020/05/laurentiapool_whitepaper.pdf">https://laurentiapool.org/wp-c=
ontent/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 a=
s a whole, but direct-from-coinbase payouts seem like a<br>desirable featur=
e which avoids some trust in pools. One limitation is<br>the size of the co=
inbase outputs owed to constituent miners; this<br>limits the number of par=
ticipants in the pool.<br><br>If the payout was instead a single OP_CTV out=
put, an arbitrary number<br>of pool participants could be paid out &quot;at=
omically&quot; within a single<br>coinbase.<br><br>---<br><br>CTV both in c=
oncept and implementation is very simple, and I think it<br>is likely to co=
ntinue to yield potential applications.<br>&quot;Settlement compression&quo=
t; seems like a useful thing, especially in light<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 going the other direction<br>i=
s possible, e.g. non-interactive channel openings<br>(<a href=3D"https://ut=
xos.org/uses/non-interactive-channels/">https://utxos.org/uses/non-interact=
ive-channels/</a>), which would allow<br>e.g. opening a lightning channel w=
ith a merchant who doesn&#39;t want to<br>have their spending keys constant=
ly accessible from a point-of-sale,<br>but can still parse/verify CTV commi=
tments.<br><br>Regards,<br>James</div>

--00000000000094f28905e69aa9c0--