path: root/9c/18ac9272847c8fff24aa3c4f69c6ab0d555b4b

Return-Path: <j@rubin.io>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EA0A0C002C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 15:11:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id D7C1040C8D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 15:11:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id cp7eDyef7xq4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 15:11:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240])
 by smtp2.osuosl.org (Postfix) with ESMTPS id DD84940499
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 15:11:05 +0000 (UTC)
Received: from relay3-d.mail.gandi.net (unknown [217.70.183.195])
 by mslow1.mail.gandi.net (Postfix) with ESMTP id 7E8B8CB3E9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 15:05:37 +0000 (UTC)
Received: (Authenticated sender: j@rubin.io)
 by mail.gandi.net (Postfix) with ESMTPSA id 1A8576001B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 15:05:32 +0000 (UTC)
Received: by mail-lf1-f52.google.com with SMTP id w1so9236145lfa.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 08:05:32 -0700 (PDT)
X-Gm-Message-State: AOAM531AMtS1RphSJ/1CgfABWYKXQQjvEmHz2/G39l5Tgr0XTpPGlkCL
 TuvDQQfga7cVghnX0MdZsThEKVNk8i4HcX/Goqk=
X-Google-Smtp-Source: ABdhPJwhzTdpQjYwPwlocujyMZ6U9Mf5VsLE7OMAAFmLVL9ajRmgYqQe/kVJ/46b9aLJxt0stDPGs3EmEQR1f30OvG4=
X-Received: by 2002:ac2:5285:0:b0:471:afb7:e794 with SMTP id
 q5-20020ac25285000000b00471afb7e794mr8514121lfm.436.1650553532101; Thu, 21
 Apr 2022 08:05:32 -0700 (PDT)
MIME-Version: 1.0
References: <cROVGM8-pKj4YzUX0QMipX3pYW6M5ps8HMrpHD9MJDey8cWBUBJSKc9tNeAJ6XOL2WVPWVwfNYI_LIAmJ4A0lLtolVIF-F1Zn2m27boTO-U=@protonmail.com>
 <20220421050351.GA5616@erisian.com.au>
 <CAMZUoKnCzX6yNaMxaG_hZ1=w_Sa7NPZMbHM=oJ8WsB0sLYVcTw@mail.gmail.com>
In-Reply-To: <CAMZUoKnCzX6yNaMxaG_hZ1=w_Sa7NPZMbHM=oJ8WsB0sLYVcTw@mail.gmail.com>
From: Jeremy Rubin <j@rubin.io>
Date: Thu, 21 Apr 2022 10:05:20 -0500
X-Gmail-Original-Message-ID: <CAD5xwhhB+HmAt=7ySx-zm1MU4pdkYq3gk-ZfMw__ivViQN4hVA@mail.gmail.com>
Message-ID: <CAD5xwhhB+HmAt=7ySx-zm1MU4pdkYq3gk-ZfMw__ivViQN4hVA@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f6bcc405dd2b70cb"
X-Mailman-Approved-At: Thu, 21 Apr 2022 15:37:52 +0000
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] CTV Signet Parameters
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: Thu, 21 Apr 2022 15:11:08 -0000

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

Hi Russell,

Thank you for your feedback here.



> However, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told
> that bare-CTV hasn't even appeared on the CTV signet).  Unlike the general
> smart-contracting case, bare-CTV does not have any branches.  All it can do
> is commit to a subsequent transaction's outputs.  At first glance this
> appears to be a waste because, for less bandwidth, that transaction could
> just realize those outputs immediately, so why would anyone want to delay
> the inevitable?
>

I can probably make some show up sometime soon. Note that James' vault uses
one at the top-level https://github.com/jamesob/simple-ctv-vault, but I
think the second use of it (since it's not segwit wrapped) wouldn't be
broadcastable since it's nonstandard.




>
> One reason might be that you want to commit to the output early during a
> high-fee time, and then complete the transaction later during a low-fee
> time.  While there are fee-rate situations where this could result in lower
> fees than committing to the outputs all at once, it would be even cheaper
> still to just wait to do the payout at the low-fee time.  I'm struggling to
> understand the advantages of the advanced commitment, along with all the
> overhead that entails.  Doesn't it just cause more blockspace to be used
> overall?
>

One case where you actually use less space is if you have a few different
sets of customers at N different fee priority level. Then, you might need
to have N independent batches, or risk overpaying against the customer's
priority level. Imagine I have 100 tier 1 customers and 1000 tier 2
customers. If I batcher tier 1 with tier 2, to provide tier 1 guarantees
I'd need to pay tier 1 rate for 10x the customers. With CTV, I can combine
my batch into a root and N batch outputs. This eliminates the need for
inputs, signatures, change outputs, etc per batch, and can be slightly
smaller. Since the marginal benefit on that is still pretty small, having
bare CTV improves the margin of byte wise saving.

I give this as an example where CTV uses less space, it is detailed more
here: https://utxos.org/analysis/batching_sim/. This benefit might be
marginal and absurd, given these are already big transactions, but it may
_also_ be absurd that feerates only ever go up and congestion control is
not valuable.

Another example where this arises is where you have a transaction set you
need to pay top-of-mempool rate for the soonest confirmation you can get.
CTV has a decongesting effect, because your top-of-mempool transaction is
small, which doesn't trigger as much rivalrous behavior with other
transactors. Concretely, the current policy max txn size is 100kb, or 10%
of a block. If you bump out of next block window 10% of the mempool, then
if those transactors care to maintain their positioning, they will need to
put themselves into a higher percentile with e.g. RBF or CPFP. Whereas if
you put in a transaction that is just 100 bytes, you only bump out 100
bytes of rivals (0.01%), not 10%.

Lastly, perhaps a more realistic scenario, is where I am batching to 100
customers who all wish to do something else after I pay them. E.g., open a
lightning channel. Being able to use CTV noninteractive channels cuts
through the extra hop transaction (unless dual funded channels, unless the
channels are opened between two customers, then they can be dual funded
again). So using CTV here also saves in net blockspace (although, note,
this is sort of orthogonal to using CTV over the batch itself, just a good
example for the related question of 'doesn't ctv generally use more
blockspace').


> There are some other proposed use cases for bare-CTV.  A bare-CTV can be
> used to delay a "trigger"-transaction.  Some contracts, such as vaults, use
> a relative-locktime as part of their construction and it could make sense
> to make an output commitment but not realize those outputs yet until you
> are ready to start your relative-time lock clock.  But bare-CTV doesn't
> support any co-signing ability here, so you are relying entirely on keeping
> the transaction data secret to prevent a third-party from triggering your
> relative-lock clock.  More specifically for a vault scheme, since
> bare-CTV's are currently unaddressable, and AFAIK, there is no address
> format proposal yet, it is impossible to receive funds directly into a
> vault.  You must shuffle received funds into your vault yourself, which
> seems very likely to negate the cost savings of using bare-CTV in the first
> place (please correct me if I'm wrong).  Better to receive funds directly
> into a taproot-CTV vault, which has an address, and while you are at it,
> you could place the cold-key as the taproot key to save even more when
> using the cold-key to move vault funds.
>
>
This is not quite true, you can receive funds into a bare-CTV from your
vault software, and you can send into one from your vault software. What
doesn't work is exporting or creating an address for that. As a reminder
for those following along at home, not all standard output types have
addresses, even today. For example, OP_RETURN.

However, this is a standarness question. If the market _wanted_ such an
address, one could be adopted without requiring consensus processes.

Generally, the vault designs I work on use Sapio and therefore also use
Taproot since I have not added support for non-taproot scripts / removed
support for witness v0. I will eventually add these back, but it's a
marginal fee savings optimization and I'm focused primarily on feature
completeness.


> There might be even more exotic use cases of bare-CTV.  For example you
> could commit to a transaction that has a second input that doesn't yet
> exist in the UTXO set in an attempt to coax it into existence. I don't know
> if there have been any proposals to take advantage of this.
>

There are, but it's not specific to how bare ctv works, it should work from
any CTV context.

>
> With that said, everything that bare-CTV can do, can also be done by
> tapscript-CTV; so it is just a matter of cost.  I'm struggling to
> understand where this cost savings is and how much those savings are going
> to be given that bare-CTV is unaddressable and seems to ultimately occupy
> more-blockspace than if the outputs were directly committed to.
>
> I also believe the bare-CTV question is material, because if bare-CTV were
> not part of the spec, then I'd be advocating for using an OP_SUCCESS code
> from tapscript instead, and either use push-style semantics for CTV, which
> would be composed with EQUAL_VERIFY to mimic the currently proposed
> verification style-semantics, or a hybrid push-or-verify semantics that
> would either push or verify depending on the size of the input.  (And I
> still think a more general TXHASH would be even better, though if I cannot
> convince aj then perhaps I'm wrong.)
>

Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we
couldn't use OP_SUCCESSx there either. segwitv0 might be desired if someone
has e.g. hardware modules or MPC Threshold Crypto that only support ECDSA
signatures, but still want CTV.

>
> I'm not saying bare-CTV is necessarily a bad idea.  I'm just struggling
> with its justification.
>


Fair. I wouldn't have a big problem removing it, if it were clear that were
it to become desired, we could add it back. I think the case for CTV in
Segwitv0 is stronger, which has the same implication for a PUSH variant of
CTV.


Thanks again,

Jeremy



> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)">Hi Russell,</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)">Thank you for your feedback here.</div><b=
r></div><div>=C2=A0</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"><div dir=3D"ltr"><div class=3D"gm=
ail_quote"><div>However, I&#39;m still skeptical of the bare-CTV part of BI=
P-119 (and I&#39;m told that bare-CTV hasn&#39;t even appeared on the CTV s=
ignet).=C2=A0 Unlike the general smart-contracting case, bare-CTV does not =
have any branches.=C2=A0 All it can do is commit to a subsequent transactio=
n&#39;s outputs.=C2=A0 At first glance this appears to be a waste because, =
for less bandwidth, that transaction could just realize those outputs immed=
iately, so why would anyone want to delay the inevitable?<br></div></div></=
div></blockquote><div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)">I can probably make some show up sometime soon=
. Note that James&#39; vault uses one at the top-level=C2=A0<a href=3D"http=
s://github.com/jamesob/simple-ctv-vault">https://github.com/jamesob/simple-=
ctv-vault</a>, but I think the second use of it (since it&#39;s not segwit =
wrapped) wouldn&#39;t be broadcastable since it&#39;s nonstandard.</div><br=
></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:sol=
id;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_quote"><div></div><div><br></div><div>One reason might be=
 that you want to commit to the output early during a high-fee time, and th=
en complete the transaction later during a low-fee time.=C2=A0 While there =
are fee-rate situations where this could result in lower fees than committi=
ng to the outputs all at once, it would be even cheaper still to just wait =
to do the payout at the low-fee time.=C2=A0 I&#39;m struggling to understan=
d the advantages of the advanced commitment, along with all the overhead th=
at entails.=C2=A0 Doesn&#39;t it just cause more blockspace to be used over=
all?</div></div></div></blockquote><div><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">One case where you actually use less space is if you have a few =
different sets of customers at N different fee priority level. Then, you mi=
ght need to have N independent batches, or risk overpaying against the cust=
omer&#39;s priority level. Imagine I have 100 tier 1 customers and 1000 tie=
r 2 customers. If I batcher tier 1 with tier 2, to provide tier 1 guarantee=
s I&#39;d need to pay tier 1 rate for 10x the customers. With CTV, I can co=
mbine my batch into a root and N batch outputs. This eliminates the need fo=
r inputs, signatures, change outputs, etc per batch, and can be slightly sm=
aller. Since the marginal benefit on that is still pretty small, having bar=
e CTV improves the margin of byte wise saving.</div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I give this as a=
n example where CTV uses less space, it is detailed more here:=C2=A0<a href=
=3D"https://utxos.org/analysis/batching_sim/">https://utxos.org/analysis/ba=
tching_sim/</a>. This benefit might be marginal and absurd, given these are=
 already big transactions, but it may _also_ be absurd that feerates only e=
ver go up and congestion control is not valuable.</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Another examp=
le where this arises is where you have a transaction set you need to pay to=
p-of-mempool rate for the soonest confirmation=C2=A0you can get. CTV has a =
decongesting effect, because your top-of-mempool transaction is small, whic=
h doesn&#39;t trigger as much rivalrous behavior with other transactors. Co=
ncretely, the current policy max txn size is 100kb, or 10% of a block. If y=
ou bump out of next block window 10% of the mempool, then if those transact=
ors care to maintain their positioning, they will need to put themselves in=
to a higher percentile with e.g. RBF or CPFP. Whereas if you put in a trans=
action that is just 100 bytes, you only bump out 100 bytes of rivals (0.01%=
), not 10%.</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">Lastly,=C2=A0perhaps a more realistic scenario, i=
s where I am batching to 100 customers who all wish to do something else af=
ter I pay them. E.g., open a lightning channel. Being able to use CTV nonin=
teractive channels cuts through the extra hop transaction (unless dual fund=
ed channels, unless the channels are opened between two customers, then the=
y can be dual funded again). So using CTV here also saves in net blockspace=
 (although, note, this is sort of orthogonal to using CTV over the batch it=
self, just a good example for the related question of &#39;doesn&#39;t ctv =
generally use more blockspace&#39;).</div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)"><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(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><=
div><br></div><div>There are some other proposed use cases for bare-CTV.=C2=
=A0 A bare-CTV can be used to delay a &quot;trigger&quot;-transaction.=C2=
=A0 Some contracts, such as vaults, use a relative-locktime as part of thei=
r construction and it could make sense to make an output commitment but not=
 realize those outputs yet until you are ready to start your relative-time =
lock clock.=C2=A0 But bare-CTV doesn&#39;t support any co-signing ability h=
ere, so you are relying entirely on keeping the transaction data secret to =
prevent a third-party from triggering your relative-lock clock.=C2=A0 More =
specifically for a vault scheme, since bare-CTV&#39;s are currently unaddre=
ssable, and AFAIK, there is no address format proposal yet, it is impossibl=
e to receive funds directly into a vault.=C2=A0 You must shuffle received f=
unds into your vault yourself, which seems very likely to negate the cost s=
avings of using bare-CTV in the first place (please correct me if I&#39;m w=
rong).=C2=A0 Better to receive funds directly into a taproot-CTV vault, whi=
ch has an address, and while you are at it, you could place the cold-key as=
 the taproot key to save even more when using the cold-key to move vault fu=
nds.</div><div><br></div></div></div></blockquote><div><br></div><div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">This is not quite true, you can receive fund=
s into a bare-CTV from your vault software, and you can send into one from =
your vault software. What doesn&#39;t work is exporting or creating an addr=
ess for that. As a reminder for those following along at home, not all stan=
dard output types have addresses, even today. For example, OP_RETURN.</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)">However, this is a standarness question. If the market _wanted_ such=
 an address, one could be adopted without requiring consensus processes.</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)"><br></div></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)">Generally, the vault designs I work on use Sapio and theref=
ore also use Taproot since I have not added support for non-taproot scripts=
 / removed support for witness v0. I will eventually add these back, but it=
&#39;s a marginal fee savings optimization and I&#39;m focused primarily on=
 feature completeness.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-sty=
le:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div></div><div>There might be even more exo=
tic use cases of bare-CTV.=C2=A0 For example you could commit to a transact=
ion that has a second input that doesn&#39;t yet exist in the UTXO set in a=
n attempt to coax it into existence. I don&#39;t know if there have been an=
y proposals to take advantage of this.</div></div></div></blockquote><div><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)">There are, but it&#39;s not sp=
ecific to how bare ctv works, it should work from any CTV context.</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><br></div><d=
iv><div>With that said, everything that bare-CTV can do, can also be done b=
y tapscript-CTV; so it is just a matter of cost.=C2=A0 I&#39;m struggling t=
o understand where this cost savings is and how much those savings are goin=
g to be given that bare-CTV is unaddressable and seems to ultimately occupy=
 more-blockspace than if the outputs were directly committed to.</div><div>=
<br></div><div>I also believe the bare-CTV question is material, because if=
 bare-CTV were not part of the spec, then I&#39;d be advocating for using a=
n OP_SUCCESS code from tapscript instead, and either use push-style semanti=
cs for CTV, which would be composed with EQUAL_VERIFY to mimic the currentl=
y proposed verification style-semantics, or a hybrid push-or-verify semanti=
cs that would either push or verify depending on the size of the input.=C2=
=A0 (And I still think a more general TXHASH would be even better, though i=
f I cannot convince aj then perhaps I&#39;m wrong.)<br></div></div></div></=
div></blockquote><div><br></div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Even if=
 we got rid of bare ctv, segwit v0 CTV would still exist, so we couldn&#39;=
t use OP_SUCCESSx there either. segwitv0=C2=A0might be desired if someone h=
as e.g. hardware modules or MPC Threshold Crypto that only support ECDSA si=
gnatures, but still want CTV.</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"><div dir=3D"ltr"><div =
class=3D"gmail_quote"><div><div></div><div><br></div><div>I&#39;m not sayin=
g bare-CTV is necessarily a bad idea.=C2=A0 I&#39;m just struggling with it=
s justification.<br></div></div></div></div></blockquote><div><br></div><di=
v><br></div><div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Fair. I wouldn&#39;t h=
ave a big problem removing it, if it were clear that were it to become desi=
red, we could add it back. I think the case for CTV in Segwitv0=C2=A0is str=
onger, which has the same implication for a PUSH variant of CTV.</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks again,</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">J=
eremy</div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v class=3D"gmail_quote"><div><div></div></div></div></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></div>

--000000000000f6bcc405dd2b70cb--