path: root/8d/d6199388ee2879804e20b6419fa4a4e7142334

Return-Path: <james.obeirne@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AF214C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 17:06:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 81B7A41583
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 17:06:56 +0000 (UTC)
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
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 yVh4837CoeoD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 17:06:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com
 [IPv6:2607:f8b0:4864:20::232])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 5399141581
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 17:06:53 +0000 (UTC)
Received: by mail-oi1-x232.google.com with SMTP id w194so9680954oiw.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 10:06:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=duQPpGsoZjGRnU6Aik5zi8SXWPWHu0OTTKPys1JTHCQ=;
 b=K5l+lyueUmm2OzBn1BUYuX0r3pxc31ROVYt0PC+rQL4D2dldMyRh+NXm2pU0MJj3nW
 osCyq4r5YSSNEyioF1ANwcofCAZhcFW7icMeSYmrVzV2uuG62vVyCiaRaahvUeQyEaLB
 JjtwJdyd4GJ6zSOjkr5VrrvH0g4J0FCZCoC/nUF4i8uMsQuveL0ZAT91hzVvX2VQQyyg
 feOfI+ozG9HgfW0qURkDUoVyE7LKw6JxFjaHfK5lQWxrQyUeYnm6bLVECcEju+buhf7f
 kO3L+xKHgFnQ2NW7uwa1zDH8Ow4emPGGRjcYmNs5reSQdGULO95TAWeZzDQ/LMJnFX+v
 N4CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=duQPpGsoZjGRnU6Aik5zi8SXWPWHu0OTTKPys1JTHCQ=;
 b=2VQJCxMQYdeCW7pNjczLeLK6nMTo1hDs+/LPd+IpyBCfyl02QIr9V+ZMK+1cHrz5o4
 vA9bgqlT2099SgW83AQ8BjCivhtNqwrzFj+zAmcyetxOc9eLlVYMapFTHAdnTMFELTy8
 2B7yXqHOFJNCFyyaeX21sfaIdRjS9eYdp+/zFCbExFfxOpS+wVEiZcYHAdAY/yKBp9nn
 HroDweFvd03dIjaG0xcQR9WqBILklSxfD1YMEfLBgagf/3TPdevc76RNozOxta/q9pVx
 g/U/zmhgNex9Vx4Pd5Sp+1dofJyaHPvRxTKwvv46VCt5cxxTBnGVyuT4iflxGYlwIJWQ
 UnmQ==
X-Gm-Message-State: AOAM530xG5AJiOyWiBCF6GiF5DtOVk7ZSYf3fuii6WeAUgJDmirVbZyu
 mFjgs/gbwVjwDcMBrTwSc6JhsxdmNlQaeITYD+lg5Hszg7AIHw==
X-Google-Smtp-Source: ABdhPJzd5yXTPbC8dOBIWA8mMMSB7gHaM5ekotPSM3Swl7oG8Ze3kl6uDy625eSCdGVjzsyLw4RxH4zEgh5BgG2u+fM=
X-Received: by 2002:a05:6808:1788:b0:322:eae3:5d3c with SMTP id
 bg8-20020a056808178800b00322eae35d3cmr2842026oib.222.1650647212180; Fri, 22
 Apr 2022 10:06:52 -0700 (PDT)
MIME-Version: 1.0
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
 <d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
 <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
 <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
 <4056eca7e1ff018bff03918b8c266d76@dtrt.org>
 <CAPfvXfJ+x5gysRU+H7hwxL2cYB9=2-YshrpqQm-OEFsSWf1GDA@mail.gmail.com>
In-Reply-To: <CAPfvXfJ+x5gysRU+H7hwxL2cYB9=2-YshrpqQm-OEFsSWf1GDA@mail.gmail.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Fri, 22 Apr 2022 13:06:41 -0400
Message-ID: <CAPfvXfLu29OGCuJqttZAgkT_Nfbj_yhw9CZEpoDyyUpwHi8sWQ@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bb472e05dd414001"
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks,
 e.g. 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, 22 Apr 2022 17:06:56 -0000

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

> The enumeration of covenants uses here excludes vaulting,
> which I see as far and away the highest utility use for covenants

Apologies for the double post, but I need to caveat this.

To be more accurate, I see "coin pools" as the most potentially
valuable use of covenants, since we need to address the scalability of
UTXO ownership as an existential issue at some point down the road - but
because a workable design has not yet been proposed (I don't think e.g.
CoinPools is scalable as-written... but that's for another
post), I am omitting that use in favor of vaults, which are well
understood and can be implemented workably in various ways.

I do not want to suggest that I don't want more general covenant
abilities - I do! But it's clear that both the designs and exact
usages of recursive covenants need *a lot* of work, probably years.

Throwing CTV to the wayside because it isn't a 100% solution to
every possible covenant use we can dream up feels a bit like
slamming the door on P2SH because Taproot might come along
a few years later.

On Fri, Apr 22, 2022 at 12:48 PM James O'Beirne <james.obeirne@gmail.com>
wrote:

> > APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to
> > certain usecases (respectively: Eltoo, congestion control, and
> > joinpools)
>
> The enumeration of covenants uses here excludes vaulting,
> which I see as far and away the highest utility use for covenants given
> that it allows significant derisking of custody for any user of Bitcoin
> interested in holding their own coins (which is debatably redundant
> with a strict definition of "Bitcoin user" ;).
>
> A lot of why I like CTV is the simple fact that it is a low-risk way of
> getting us vaults. That feature in itself is more than enough to
> justify (to me) CTV's added validation complexity, which is very modest
> - in contrast every other covenant proposal I've seen so far.
>
> On Thu, Apr 21, 2022 at 6:28 PM David A. Harding via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 21.04.2022 08:39, Matt Corallo wrote:
>> > We add things to Bitcoin because (a) there's some demonstrated
>> > use-cases and intent to use the change (which I think we definitely
>> > have for covenants, but which only barely, if at all, suggests
>> > favoring one covenant design over any other)
>>
>> I'm unconvinced about CTV's use cases but others have made reasonable
>> claims that it will be used.  We could argue about this indefinitely,
>> but I would love to give CTV proponents an opportunity to prove that a
>> significant number of people would use it.
>>
>> > (b) because its
>> > generally considered aligned with Bitcoin's design and goals, based on
>> > developer and more broad community response
>>
>> I think CTV fulfills this criteria.  At least, I can't think of any way
>> BIP119 itself (notwithstanding activation concerns) violates Bitcoin's
>> designs and goals.
>>
>> > (c) because the
>> > technical folks who have/are wiling to spend time working on the
>> > specific design space think the concrete proposal is the best design
>> > we have
>>
>> This is the criteria that most concerns me.  What if there is no
>> universal best?  For example, I mentioned in my previous email that I'm
>> a partisan of OP_CAT+OP_CSFS due to their min-max of implementation
>> simplicity versus production flexibility.  But one problem is that
>> spends using them would need to contain a lot of witness data.  In my
>> mind, they're the best for experimentation and for proving the existence
>> of demand for more optimized constructions.
>>
>> OP_TX or OP_TXHASH would likely offer almost as much simplicity and
>> flexibility but be more efficient onchain.  Does that make them better
>> than OP_CAT+OP_CSFS?  I don't know how to objectively answer that
>> question, and I don't feel comfortable with my subjective opinion of
>> CAT+CSFS being better than OP_TX.
>>
>> APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to
>> certain usecases (respectively: Eltoo, congestion control, and
>> joinpools), providing maximum onchain efficiency for those cases but
>> requiring contortions or larger witnesses to accomplish other covenant
>> usecases.  Is their increased efficiency better than more general
>> constructions like CSFS or TX?  Again, I don't know how to answer that
>> question objectively, although subjectively I'm ok with optimized
>> constructions for cases of proven demand.
>>
>> > , and finally (d) because the implementation is well-reviewed
>> > and complete.
>>
>> No comment here; I haven't followed CTV's review progress to know
>> whether I'd consider it well enough reviewed or not.
>>
>> > I do not see how we can make an argument for any specific covenant
>> > under (c) here. We could just as well be talking about
>> > TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
>> > CTV can probably just as easily use those instead - ie this has
>> > nothing to do with "will people use it".
>>
>> I'm curious how we as a technical community will be able to determine
>> which is the best approach.  Again, I like starting simple and general,
>> gathering real usage data, and then optimizing for demonstrated needs.
>> But the simplest and most general approaches seem to be too general for
>> some people (because they enable recursive covenants), seemingly forcing
>> us into looking only at application-optimized designs.  In that case, I
>> think the main thing we want to know about these narrow proposals for
>> new applications is whether the applications and the proposed consensus
>> changes will actually receive significant use.  For that, I think we
>> need some sort of test bed with real paying users, and ideally one that
>> is as similar to Bitcoin mainnet as possible.
>>
>> > we
>> > cannot remove the validation code for something ever, really - you
>> > still want to be able to validate the historical chain
>>
>> You and Jeremy both brought up this point.  I understand it and I
>> should've addressed it better in my OP, but I'm of the opinion that
>> reverting to earlier consensus rules gives future developers the
>> *option* of dropping no-longer-used consensus code as a practical
>> simplification of the same type we've used on several occasions before,
>> and which is an optional default in newly started Bitcoin Core nodes for
>> over a decade now (i.e. skipping verification of old signatures).  If
>> future devs *want* to maintain code from a set of temporary rules used
>> millions of blocks ago, that's great, but giving them the option to
>> forget about those rules eliminates one of my concerns about making
>> consensus changes without fully proven demand for that change.
>>
>> I just wanted to mention the above in case this discussion comes back to
>> serious consideration of a transitory soft fork.  For now, I think we
>> can table a debate over validating reverted rules and focus on how we'll
>> come to agreement that a particular covenant-related consensus change is
>> warranted.
>>
>> Thanks for your thoughtful response,
>>
>> -Dave
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<div dir=3D"ltr">&gt; The enumeration of covenants uses here excludes vault=
ing,<br>&gt; which I see as far and away the highest utility use for covena=
nts<br><br>Apologies for the double post, but I need to caveat this. <br><b=
r>To be more accurate, I see &quot;coin pools&quot; as the most potentially=
<br>valuable use of covenants, since we need to address the scalability of<=
br>UTXO ownership as an existential issue at some point down the road - but=
<br>because a workable design has not yet been proposed (I don&#39;t think =
e.g.<br>CoinPools is scalable as-written... but that&#39;s for another<br>p=
ost), I am omitting that use in favor of vaults, which are well<br>understo=
od and can be implemented workably in various ways.<br><br>I do not want to=
 suggest that I don&#39;t want more general covenant<br>abilities - I do! B=
ut it&#39;s clear that both the designs and exact<br>usages of recursive co=
venants need *a lot* of work, probably years.<br><br><div>Throwing CTV to t=
he wayside because it isn&#39;t a 100% solution to <br></div><div>every pos=
sible covenant use we can dream up feels a bit like <br></div><div>slamming=
 the door on P2SH because Taproot might come along <br></div><div>a few yea=
rs later.<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Fri, Apr 22, 2022 at 12:48 PM James O&#39;Beirne &lt;=
<a href=3D"mailto:james.obeirne@gmail.com">james.obeirne@gmail.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">&gt; APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very speci=
fic to<br>&gt; certain usecases (respectively: Eltoo, congestion control, a=
nd<br>&gt; joinpools)<br><br><div>The enumeration of covenants uses here ex=
cludes vaulting, <br></div><div>which I see as far and away the highest uti=
lity use for covenants given <br></div><div>that it allows significant deri=
sking of custody for any user of Bitcoin<br></div><div>interested in holdin=
g their own coins (which is debatably redundant <br></div><div>with a stric=
t definition of &quot;Bitcoin user&quot; ;).<br></div><br>A lot of why I li=
ke CTV is the simple fact that it is a low-risk way of<br>getting us vaults=
. That feature in itself is more than enough to<br>justify (to me) CTV&#39;=
s added validation complexity, which is very modest<br>- in contrast every =
other covenant proposal I&#39;ve seen so far.<br></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 21, 2022 at 6:=
28 PM David A. Harding via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">On 21.04.2022 08:39, Matt Corallo wrote:<br>
&gt; We add things to Bitcoin because (a) there&#39;s some demonstrated<br>
&gt; use-cases and intent to use the change (which I think we definitely<br=
>
&gt; have for covenants, but which only barely, if at all, suggests<br>
&gt; favoring one covenant design over any other)<br>
<br>
I&#39;m unconvinced about CTV&#39;s use cases but others have made reasonab=
le <br>
claims that it will be used.=C2=A0 We could argue about this indefinitely, =
<br>
but I would love to give CTV proponents an opportunity to prove that a <br>
significant number of people would use it.<br>
<br>
&gt; (b) because its<br>
&gt; generally considered aligned with Bitcoin&#39;s design and goals, base=
d on<br>
&gt; developer and more broad community response<br>
<br>
I think CTV fulfills this criteria.=C2=A0 At least, I can&#39;t think of an=
y way <br>
BIP119 itself (notwithstanding activation concerns) violates Bitcoin&#39;s =
<br>
designs and goals.<br>
<br>
&gt; (c) because the<br>
&gt; technical folks who have/are wiling to spend time working on the<br>
&gt; specific design space think the concrete proposal is the best design<b=
r>
&gt; we have<br>
<br>
This is the criteria that most concerns me.=C2=A0 What if there is no <br>
universal best?=C2=A0 For example, I mentioned in my previous email that I&=
#39;m <br>
a partisan of OP_CAT+OP_CSFS due to their min-max of implementation <br>
simplicity versus production flexibility.=C2=A0 But one problem is that <br=
>
spends using them would need to contain a lot of witness data.=C2=A0 In my =
<br>
mind, they&#39;re the best for experimentation and for proving the existenc=
e <br>
of demand for more optimized constructions.<br>
<br>
OP_TX or OP_TXHASH would likely offer almost as much simplicity and <br>
flexibility but be more efficient onchain.=C2=A0 Does that make them better=
 <br>
than OP_CAT+OP_CSFS?=C2=A0 I don&#39;t know how to objectively answer that =
<br>
question, and I don&#39;t feel comfortable with my subjective opinion of <b=
r>
CAT+CSFS being better than OP_TX.<br>
<br>
APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to <br>
certain usecases (respectively: Eltoo, congestion control, and <br>
joinpools), providing maximum onchain efficiency for those cases but <br>
requiring contortions or larger witnesses to accomplish other covenant <br>
usecases.=C2=A0 Is their increased efficiency better than more general <br>
constructions like CSFS or TX?=C2=A0 Again, I don&#39;t know how to answer =
that <br>
question objectively, although subjectively I&#39;m ok with optimized <br>
constructions for cases of proven demand.<br>
<br>
&gt; , and finally (d) because the implementation is well-reviewed<br>
&gt; and complete.<br>
<br>
No comment here; I haven&#39;t followed CTV&#39;s review progress to know <=
br>
whether I&#39;d consider it well enough reviewed or not.<br>
<br>
&gt; I do not see how we can make an argument for any specific covenant<br>
&gt; under (c) here. We could just as well be talking about<br>
&gt; TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use<=
br>
&gt; CTV can probably just as easily use those instead - ie this has<br>
&gt; nothing to do with &quot;will people use it&quot;.<br>
<br>
I&#39;m curious how we as a technical community will be able to determine <=
br>
which is the best approach.=C2=A0 Again, I like starting simple and general=
, <br>
gathering real usage data, and then optimizing for demonstrated needs.=C2=
=A0 <br>
But the simplest and most general approaches seem to be too general for <br=
>
some people (because they enable recursive covenants), seemingly forcing <b=
r>
us into looking only at application-optimized designs.=C2=A0 In that case, =
I <br>
think the main thing we want to know about these narrow proposals for <br>
new applications is whether the applications and the proposed consensus <br=
>
changes will actually receive significant use.=C2=A0 For that, I think we <=
br>
need some sort of test bed with real paying users, and ideally one that <br=
>
is as similar to Bitcoin mainnet as possible.<br>
<br>
&gt; we<br>
&gt; cannot remove the validation code for something ever, really - you<br>
&gt; still want to be able to validate the historical chain<br>
<br>
You and Jeremy both brought up this point.=C2=A0 I understand it and I <br>
should&#39;ve addressed it better in my OP, but I&#39;m of the opinion that=
 <br>
reverting to earlier consensus rules gives future developers the <br>
*option* of dropping no-longer-used consensus code as a practical <br>
simplification of the same type we&#39;ve used on several occasions before,=
 <br>
and which is an optional default in newly started Bitcoin Core nodes for <b=
r>
over a decade now (i.e. skipping verification of old signatures).=C2=A0 If =
<br>
future devs *want* to maintain code from a set of temporary rules used <br>
millions of blocks ago, that&#39;s great, but giving them the option to <br=
>
forget about those rules eliminates one of my concerns about making <br>
consensus changes without fully proven demand for that change.<br>
<br>
I just wanted to mention the above in case this discussion comes back to <b=
r>
serious consideration of a transitory soft fork.=C2=A0 For now, I think we =
<br>
can table a debate over validating reverted rules and focus on how we&#39;l=
l <br>
come to agreement that a particular covenant-related consensus change is <b=
r>
warranted.<br>
<br>
Thanks for your thoughtful response,<br>
<br>
-Dave<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>
</blockquote></div>

--000000000000bb472e05dd414001--