path: root/b2/97c1c433edbc33a4992579d495a73bd1882dfa

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 83061C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 19 Sep 2022 01:22:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 5C0C960ADC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 19 Sep 2022 01:22:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5C0C960ADC
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=Y57aXgFt
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id FZ1XHFt2M8sn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 19 Sep 2022 01:22:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7935D60AB8
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com
 [IPv6:2607:f8b0:4864:20::130])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 7935D60AB8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 19 Sep 2022 01:22:55 +0000 (UTC)
Received: by mail-il1-x130.google.com with SMTP id g6so1688596ild.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Sep 2022 18:22:55 -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:subject:date;
 bh=hPjTwGsrjL1QFOo43VCJGy660KWJPsN3RK6APugNzVU=;
 b=Y57aXgFt1A7fuTQVU6htXEsXTarDm0LXMPPO2Xt69EYle/C50SZPpHkZYSzgEjY7H8
 EdIIc4S43OHh4DOss0SxsnMGt7O8f00/HQ3WpgkpcuYExqgHrZ0mIcIRh9SVBycztXms
 C6OwiYsqLyExJWB+YfJw0b06mg6L2zcel/Ed0N79cD9fXz0hAvd+n9HpHhzAJwBbnWln
 WT4S3VAtz8P2m5HNKclxiKwoT6wzKN5J0uCl9mBdfchE4xYJUnOCYXZ0vTK+GBbHe+qr
 j5+TxDiudT1qrMAmrzw84QAUUvp0+wHTTVJ/5Hbvp4HagXpTVCXa0kRhUJWhA9L7z9tJ
 IzPQ==
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:subject:date;
 bh=hPjTwGsrjL1QFOo43VCJGy660KWJPsN3RK6APugNzVU=;
 b=7Gsb873FKvVkcOcQV3jU5yvvOysqmaJkfhEGzNacX5qeZCkiXwYtMqhWxgBHJGWWxN
 hXIQIybOGzcBIzum3nPR+OTKd5WS6dKJbO5R58iQIF1DyohkblnTgqvJv3WT5pjUERbL
 XbwfF+3GGUiz3JMHx7oh54BjrMoiBpGLIwds6SkTbFl8GuxFJ88LzaYLGBxaQd5364gY
 Kl83szB2W6S/2nEcTPWeMVziLEDObpjOlDtLfxowqQQRNKSHGyKbumXiBc3F2x1xMHSc
 94mnIQR+Zaf0hj+XJb1rQHiEM8m5UqnCmhhpqavS0w8y6kb02Yz0qe68ZmUavoBQkFBv
 vN4A==
X-Gm-Message-State: ACrzQf397V7DQvZ3mv6nu2yBjQuAUcsUXGokll+yXRBQ/mo99fzoDBh7
 RcZuLEcoENdiM9QD6JgMKkAuIujf/U8Ny17ohvHkuzAS+fU=
X-Google-Smtp-Source: AMsMyM63UdiOb3fINJHJ4mtsbxk9aHPZA5f+D6OvLDsSgMx5Oc/Iu0TZWqO1ejoPdl1MNq8Acac2F+Cp8+QLAQ3RDNQ=
X-Received: by 2002:a05:6e02:1347:b0:2ea:e939:fef1 with SMTP id
 k7-20020a056e02134700b002eae939fef1mr6830936ilr.114.1663550574394; Sun, 18
 Sep 2022 18:22:54 -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: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 18 Sep 2022 21:22:43 -0400
Message-ID: <CALZpt+Gn0rSOBOkMsLyjbapJCU1NmzRn=aZ4ktS4iCKmFbzU2w@mail.gmail.com>
To: "James O'Beirne" <james.obeirne@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000d813205e8fd8d4b"
X-Mailman-Approved-At: Mon, 19 Sep 2022 17:48:01 +0000
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: Mon, 19 Sep 2022 01:22:57 -0000

--0000000000000d813205e8fd8d4b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi James,

Thanks to bringing to awareness the atomic mining pool thing, it's
interesting.

> 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.

I'm neither a mining expert, but I wonder if there is not some weird
dependency here. The coinbase output scriptpubkey being part of the
header's merkle root commitment, the CTV hash being part of the
scriptpubkey and the payout outputs being part of the CTV hash, everytime
the payout outputs as re-evaluated in function of the last work share
submitted, as Laurentia is proposing, the whole payout transaction must be
updated, then the CTV hash, then the merkle root commitment, leading all
the mining devices to re-fetch a header from the job negotiator (in Stratum
V2 parlance), I think ? I don't know the average shares submission
frequency for a local pool of size 100 as targeted by Laurentia though the
latency hit might downgrade the worthiness of this CTV-based atomic mining
pool payouts design...

Beyond, I'm not sure about the trust removal statement of this design, as
the job negotiator operator, sounds to always have malleability to select
the coinbase output scriptpubkey, therefore selecting any CTV hash
assigning all the reward to itself, at the detriment of other mining pool
participant. I believe this is not a downside of CTV usage itself, but the
fact that the coinbase output scriptpubkey is ultimately signed by the
proof-of-work itself.

About compactness, I wonder if an atomic payment pool payouts design
favoring the payouts settlement directly over Lightning channels wouldn't
offer a smaller on-chain footprint. E.g, maybe the mining pool operator
could send a long-term PTLC to each participant covering the period during
which a block has odds to be mined by the pool. The PTLCs amounts should be
stable once the block template is agreed on. The coinbase output is locked
with some scriptless script point. When it is spent by the mining operator,
the PTLCs could be fetched by the participant. If the mining operator
doesn't spend before time lock expiration, there could be some on-chain
fan-out transaction kicking-out. That type of scheme would allow you to
save on-chain fees and not to leak the mining pool hashrate distribution.
However, I believe it is more complex to make it fit with the SPLNS
"real-time"  calculation as it sounds to be proposed by the paper. Just a
strawman proposal, if relevant, deserves more thinking.

The paper would deserve to have a fully fleshed-out "coinbase generation"
scheme as the description is a bit loose, imo, like:

"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"

Anyway, left a scratch of further scheme analysis there:
https://github.com/ariard/bitcoin-contracting-primitives-wg/pull/8

Best,
Antoine

Le ven. 19 ao=C3=BBt 2022 =C3=A0 12:33, James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> 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_whitep=
aper.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
>

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

<div dir=3D"ltr">Hi James,<br><br>Thanks to bringing to awareness the atomi=
c mining pool thing, it&#39;s interesting.<br><br>&gt; I&#39;m not a mining=
 expert and so I can&#39;t speak to the efficacy of the<br>&gt; paper as a =
whole, but direct-from-coinbase payouts seem like a<br>&gt; desirable featu=
re which avoids some trust in pools. One limitation is<br>&gt; the size of =
the coinbase outputs owed to constituent miners; this<br>&gt; limits the nu=
mber of participants in the pool.<br><br>I&#39;m neither a mining expert, b=
ut I wonder if there is not some weird dependency here. The coinbase output=
 scriptpubkey being part of the header&#39;s merkle root commitment, the CT=
V hash being part of the scriptpubkey and the payout outputs being part of =
the CTV hash, everytime the payout outputs as re-evaluated in function of t=
he last work share submitted, as Laurentia is proposing, the whole payout t=
ransaction must be updated, then the CTV hash, then the merkle root commitm=
ent, leading all the mining devices to re-fetch a header from the job negot=
iator (in Stratum V2 parlance), I think ? I don&#39;t know the average shar=
es submission frequency for a local pool of size 100 as targeted by Laurent=
ia though the latency hit might downgrade the worthiness of this CTV-based =
atomic mining pool payouts design...<br><br>Beyond, I&#39;m not sure about =
the trust removal statement of this design, as the job negotiator operator,=
 sounds to always have malleability to select the coinbase output scriptpub=
key, therefore selecting any CTV hash assigning all the reward to itself, a=
t the detriment of other mining pool participant. I believe this is not a d=
ownside of CTV usage itself, but the fact that the coinbase output scriptpu=
bkey is ultimately signed by the proof-of-work itself.<br><br>About compact=
ness, I wonder if an atomic payment pool payouts design favoring the payout=
s settlement directly over Lightning channels wouldn&#39;t offer a smaller =
on-chain footprint. E.g, maybe the mining pool operator could send a long-t=
erm PTLC to each participant covering the period during which a block has o=
dds to be mined by the pool. The PTLCs amounts should be stable once the bl=
ock template is agreed on. The coinbase output is locked with some scriptle=
ss script point. When it is spent by the mining operator, the PTLCs could b=
e fetched by the participant. If the mining operator doesn&#39;t spend befo=
re time lock expiration, there could be some on-chain fan-out transaction k=
icking-out. That type of scheme would allow you to save on-chain fees and n=
ot to leak the mining pool hashrate distribution. However, I believe it is =
more complex to make it fit with the SPLNS &quot;real-time&quot;=C2=A0 calc=
ulation as it sounds to be proposed by the paper. Just a strawman proposal,=
 if relevant, deserves more thinking.<br><br>The paper would deserve to hav=
e a fully fleshed-out &quot;coinbase generation&quot; scheme as the descrip=
tion is a bit loose, imo, like:<br><br>&quot;Block solve reward is distribu=
ted directly from the block to each user, meaning each user gets<br>a &#39;=
mined&#39; transaction directly into their wallet as soon as the block is s=
olved so there is no wait<br>to get paid and no pool wallet storing user&#3=
9;s rewards&quot;<br><br>Anyway, left a scratch of further scheme analysis =
there:<br><a href=3D"https://github.com/ariard/bitcoin-contracting-primitiv=
es-wg/pull/8">https://github.com/ariard/bitcoin-contracting-primitives-wg/p=
ull/8</a><br><br>Best,<br>Antoine<br></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 19 ao=C3=BBt 2022 =C3=A0=
=C2=A012:33, 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; a =C3=A9crit=C2=A0:<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/bitcoin/bitcoin/pull/21702" target=3D"_blank">https://github.c=
om/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 presentat=
ion 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 l=
ike<br><br>&gt; When there is a high demand for blockspace it becomes very =
expensive<br>&gt; to make transactions. By using OP_CHECKTEMPLATEVERIFY, a =
large volume<br>&gt; payment processor may aggregate all their payments int=
o a single O(1)<br>&gt; transaction for purposes of confirmation. Then, som=
e time later, the<br>&gt; payments can be expanded out of that UTXO when th=
e demand for<br>&gt; blockspace is decreased.<br><br>(from <a href=3D"https=
://utxos.org/uses/scaling/" target=3D"_blank">https://utxos.org/uses/scalin=
g/</a>)<br><br>At the time that didn&#39;t particularly grab me; the idea o=
f smoothing fee<br>rates seemed nice but marginal.<br><br>But recently, two=
 particular cases have made me reassess the value of<br>congestion control.=
<br><br>The first stems from the necessity of L2 protocols (payment channel=
s,<br>vaults, etc.) to, under certain circumstances, settle to the chain in=
 a<br>timely way in order to prevent abuse of the protocol. If some<br>unex=
pected condition (a protocol exploit, large network disconnect, en<br>masse=
 vault breach, etc.) creates a situation where a large number of<br>contrac=
ts need to settle to the chain in short order, mempools could<br>fill up an=
d protocol failures 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" target=3D"_blank">https://github.com/jamesob/mempool.work#failur=
e-one-mempool-to-rule-them-all</a>).<br><br>In such a case, CTV could be us=
ed effectively to &quot;compress&quot; settlement<br>commitments, get them =
on-chain, and then 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 output, which<br>commits to the final settlement state. Multi=
ple parties could<br>trustlessly collaborate to settle into a single CTV ou=
tput using<br>SIGHASH_ALL | ANYONECANPAY. This requires a level of interact=
ion<br>similar to coinjoins.<br><br>Put simply, CTV allows deferring the ch=
ainspace required for the final<br>settlement outputs, but still immediatel=
y requires space for the<br>inputs. This might sound like a temporary repri=
eve from half-ish of the<br>space required to settle, but in many (most?) c=
ases the outputs require<br>substantially more space than the inputs, given=
 that often we&#39;re<br>settling a single UTXO into multiple payouts per p=
arty. 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 damag=
e of unexpected<br>settlement &quot;tidal waves.&quot;<br><br>Conceptually,=
 CTV is the most parsimonious way to do such a scheme,<br>since you can&#39=
;t really get smaller than a SHA256 commitment, and that&#39;s<br>essential=
ly all CTV is.<br><br>The second congestion control case is related to a re=
cent 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 al=
l at the<br>&gt; exact same level then they work fine for security, 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 established day=
/night cycle with fees<br>&gt; going to zero overnight and even longer gaps=
 on weekends and<br>&gt; holidays. If in the future Bitcoin is entirely dep=
endent on fees for<br>&gt; security (scheduled very strongly) and this patt=
ern 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.linuxfou=
ndation.org/pipermail/bitcoin-dev/2022-July/020702.html" target=3D"_blank">=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.ht=
ml</a>)<br><br>Ryan Grant points out that CTV&#39;s congestion control use =
could help to<br>smooth fees, creating a less spiky incentive to mine<br>(<=
a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July=
/020702.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail=
/bitcoin-dev/2022-July/020702.html</a>).<br><br>Admittedly the original con=
cern is speculative and a ways off from now,<br>as others in the thread poi=
nted out. But having CTV-based fee smoothing<br>as an option certainly does=
n&#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 found blocks.<br><br>&gt; Block solve reward is distr=
ibuted 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 a=
s the block is solved so there is no wait to<br>&gt; get paid and no pool w=
allet storing user&#39;s rewards.<br><br>(from<br><a href=3D"https://lauren=
tiapool.org/wp-content/uploads/2020/05/laurentiapool_whitepaper.pdf" target=
=3D"_blank">https://laurentiapool.org/wp-content/uploads/2020/05/laurentiap=
ool_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-coinba=
se payouts seem like a<br>desirable feature which avoids some trust in pool=
s. One limitation is<br>the size of the coinbase outputs owed to constituen=
t 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 po=
ol 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 applica=
tions.<br>&quot;Settlement compression&quot; seems like a useful thing, esp=
ecially 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 t=
his pattern going the other direction<br>is possible, e.g. non-interactive =
channel openings<br>(<a href=3D"https://utxos.org/uses/non-interactive-chan=
nels/" target=3D"_blank">https://utxos.org/uses/non-interactive-channels/</=
a>), which would allow<br>e.g. opening a lightning channel with a merchant =
who doesn&#39;t want to<br>have their spending keys constantly accessible f=
rom a point-of-sale,<br>but can still parse/verify CTV commitments.<br><br>=
Regards,<br>James</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>

--0000000000000d813205e8fd8d4b--