path: root/74/501ae20d1842b89e67930c743d2ad38043bbd6

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 738BFC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Feb 2022 15:59:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 54E2B813E7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Feb 2022 15:59:18 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id L5dbN7YtVYQ2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Feb 2022 15:59:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [IPv6:2a00:1450:4864:20::62a])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 5AE7C813DE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Feb 2022 15:59:16 +0000 (UTC)
Received: by mail-ej1-x62a.google.com with SMTP id qk11so8356127ejb.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Feb 2022 07:59:15 -0800 (PST)
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
 :cc; bh=Zo/6vHuDXtWKhXGk6r8xg/jfR+s0bv9DtAwkoW5Tj6I=;
 b=m2SqPDG2YGylF0WbkaZe7kIiY12c/K+LfwU/xg81Hsh1/guQ6lq99pjHw/C8nIeLrI
 HBAO0cNUnTcp3Lbre8DSnYYWx5KFfyIRzwUHAwwgO67Ugllk4H6qx565LOJizsa+nA6c
 z9YpdtRQR6/xOtP1yJC/25VnhQCg8YaUKZmEX0nBn4upaFcrsthRmgilk6fxVEyd+zOT
 AtZZ9VOu8alah5yDblCimqn95anXCM65ANHQMi3HuXBnC5vDVe13+RdojA+JGt3+94aB
 yyM4MCr51Ukhi9ZJFWNxsmkgv1Z9AzV4iZphL0bR43ROxz1HsnxHrPh1i3vtrYEJUh2G
 DuOA==
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:cc;
 bh=Zo/6vHuDXtWKhXGk6r8xg/jfR+s0bv9DtAwkoW5Tj6I=;
 b=UqkVdQJ2TechKzQ8YdqNPRrHShnOTg1toBS1TUPriKYqZBNxG/7+0V2eYMxxDlQXww
 i+X/CO4DJCidxorKOi9XjKTAOUN1P9cgVUVaemzza+N5ejKIjNZmamNsYLyl6LF0NsVx
 aZU4sD7vtdtXPI+Gs+PB6EPFGgXa09pvKdmu5hOyI384tWAob9zM1pDRP7bBvmOiia+1
 zym75LLKrm/fGHVroIlUqD/vACcLEc6gtGVXz7xTD2d6zJTA44rfWU4pngxARjjreaHM
 HSrMRFsf9qfTcCSfHrLsvOSd/EPAZAxbaPdFjVkJ4uu90oKuEDLpZAaKnfLb8hoe1dcz
 +tvw==
X-Gm-Message-State: AOAM5304sWo6qsU/gaw7ATq8ky85KUSiY5B9hFFObj/biiUo8cwkKuOk
 DbYB6i32qeMp4O/CH6L0aJTQUwtqS15P0kLmvAU=
X-Google-Smtp-Source: ABdhPJyrTBibvS63uErrGgVS+VRa/Z6Z2x1JeWYs7sROVbvz0sMqmvLA4reP8ULB06Y3GPH911Pgvx0Oi46PfsNszjo=
X-Received: by 2002:a17:907:1b0f:: with SMTP id
 mp15mr5297082ejc.493.1644681554252; 
 Sat, 12 Feb 2022 07:59:14 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
 <87leymuiu8.fsf@rustcorp.com.au>
 <CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@mail.gmail.com>
 <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>
 <CAPfvXf+q-0JiM+qap9wgUB1FTAeHGio_XeWVBdRwKj-_GffeUQ@mail.gmail.com>
 <CAFSEESFg0Ep-eL50B-JXh1omTa4kXiwn98rwJD3X5iyQrfA_6g@mail.gmail.com>
 <iq1vWg-YFgTSTCo-6bJYhArOget9i6QJlFj_6-k-R39KJ8zCNpv55m6evffRzGcsuEm-ibsAcLtGN-_jz7JBvbmQXBJ1zxlpVoT_l9fe2EU=@protonmail.com>
In-Reply-To: <iq1vWg-YFgTSTCo-6bJYhArOget9i6QJlFj_6-k-R39KJ8zCNpv55m6evffRzGcsuEm-ibsAcLtGN-_jz7JBvbmQXBJ1zxlpVoT_l9fe2EU=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sat, 12 Feb 2022 09:59:03 -0600
Message-ID: <CAGpPWDa+nPrHgUgdeNz5Zk14-Q2dp1h2x4W7rNFONtr-eitNMg@mail.gmail.com>
To: darosior <darosior@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cf583405d7d44349"
X-Mailman-Approved-At: Sat, 12 Feb 2022 17:06:50 +0000
Subject: Re: [bitcoin-dev] Recursive covenant opposition,
 or the absence thereof,
 was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
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: Sat, 12 Feb 2022 15:59:18 -0000

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

> in the case of a multisig/non-consensus based system, exit from that
restriction is still possible

But why do we care if someone reduces the value of coins they own by
permanently encumbering them in some way? Burning coins permanently
encumbers them so much they can't be spent at all. If the worry is
depleting the supply of sats, don't worry, the amount of value lost by
those encumbered is gained but the rest of the coins. Just like burning,
encumbering your coins in a way that devalues them is a donation to the
rest of us.

Could you clarify what harm there is to those who choose not to accept such
encumbered coins? Or are you just saying that those who do accept such
encumbered coins may be harmed by doing so?

On Sat, Feb 12, 2022, 06:11 darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Such a construct would present dangerous implications to the fungibility
> of individual UTXOs by introducing a totally different risk model in bein=
g
> paid with such a coin compared to any other coin not encumbered by such a
> condition
>
>
> How is that different from being paid in an altcoin?
> It seems to me that being able to say "sorry, your money isn't good here"
> is at the heart of Bitcoin's security (similarly to enforcing the network
> rules with your node). If someone can coerce you into using another
> currency, you've already lost.
>
> Now there is left the influence on the system of an user being coerced
> into using gov coin (on another chain) or an encumbered bit coin. Sure th=
e
> latter would decrease the supply available, but that's already possible t=
o
> do today.
>
> ------- Original Message -------
> Le vendredi 11 f=C3=A9vrier 2022 =C3=A0 7:12 PM, digital vagabond via bit=
coin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
> This is Shinobi (can verify out of band at @brian_trollz on Twitter, I
> only signed up to the list with this email to read initially, but feel li=
ke
> I should reply to this as I think I am one of the only people in this spa=
ce
> who has voiced concerns with recursive covenants).
>
> My concerns don't really center specifically around recursion itself
> necessarily, but unbounded recursion in combination with too much
> generality/flexibility in what types of conditions future UTXOs can be
> encumbered with based on the restriction of such covenants. Forgive the
> hand waiving arguments without getting into specific opcodes, but I would
> summarize my concerns with a hypothetical construct that I believe would =
be
> incredibly damaging to fungibility. Imagine a covenant design that was
> flexible enough to create an encumbrance like this: a script specifies a
> specific key in a multisig controlled by some authority figure (or a bran=
ch
> in the script that would allow unilateral control by such an authority),
> and the conditions of the covenant would perpetually require than any spe=
nd
> from the covenant can only be sent to a script involving that key from sa=
id
> authority, preventing by consensus any removal of that central authoritie=
s
> involvement in control over that UTXO. Such a construct would present
> dangerous implications to the fungibility of individual UTXOs by
> introducing a totally different risk model in being paid with such a coin
> compared to any other coin not encumbered by such a condition, and also
> potentially introduce a shift in the scope of what a 51% attack could
> accomplish in terms of permanent consequences attempting to coerce coins
> into such covenants, as opposed to right now only being able to accomplis=
h
> censorship or temporary network disruption.
>
> I know that such a walled garden could easily be constructed now with
> multisig and restrictions on where coins can be withdrawn to from exchang=
es
> or whatever place they initially purchased from, as is demonstrated by th=
e
> implementation of the Asset Management Platform by Blockstream for use on
> Liquid with regulated equity tokens, but I think the important distinctio=
n
> between such non-consensus system designed to enforce such restrictions a=
nd
> a recursive covenant to accomplish the same is that in the case of a
> multisig/non-consensus based system, exit from that restriction is still
> possible under the consensus rules of the protocol. If such a construct w=
as
> possible to build with a recursive covenant enforced by consensus, coins
> encumbered by such a covenant would literally be incapable of escaping
> those restrictions without hardforking the protocol, leaving any such UTX=
Os
> permanently non-fungible with ones not encumbered by such conditions.
>
> I'm not that deeply familiar with all the working pieces involved in the
> recent TXHASH + CSFS proposal, and whether such a type of overly (IMO)
> generalized recursion would be possible to construct, but one of the
> reasons CTV does not bother me in terms of such concerns is the inability
> to infinitely recurse in such a generalized way given the requirements to
> exactly specify the destination of future spends in constructing a chain =
of
> CTV encumbrances. I'd very much appreciate any feedback on my concerns, a=
nd
> if this side tracks the discussion I apologize, but I felt given the issu=
e
> has been mentioned a few times in this thread it was appropriate for me t=
o
> voice the concerns here so they could be addressed directly.
>
> On Fri, Feb 11, 2022 at 11:42 AM James O'Beirne via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I don't oppose recursive covenants per se, but in prior posts I have
>> expressed uncertainty about proposals that enable more "featureful"
>> covenants by adding more kinds of computation into bitcoin script.
>>
>> Not that anyone here is necessarily saying otherwise, but I am very
>> interested in limiting operations in bitcoin script to "verification" (v=
s.
>> "computation") to the extent practical, and instead encouraging general
>> computation be done off-chain. This of course isn't a new observation an=
d I
>> think the last few years have been very successful to that effect, e.g. =
the
>> popularity of the "scriptless scripts" idea and Taproot's emphasis on
>> embedding computational artifacts in key tweaks.
>>
>> My (maybe unfounded?) worry about opcodes like OP_CAT and OP_TX is that
>> more logic will live in script than is necessary, and so the burden to
>> verify the chain may grow and the extra "degrees of freedom" in script m=
ay
>> make it harder to reason about. But I guess at this point there aren't
>> alternative means to construct new kinds of sighashes that are necessary
>> for some interesting covenants.
>>
>> One thing I like about CTV is that it buys a lot of functionality withou=
t
>> increasing the "surface area" of script's design. In general I think the=
re
>> is a lot to be said for this "jets"-style approach[0] of codifying the
>> script operations that you'd actually want to do into single opcodes. Th=
is
>> adds functionality while introducing minimal surface area to script, giv=
ing
>> script implementers more flexibility for, say, optimization. But of cour=
se
>> this comes at the cost of precluding experimentation, and probably
>> requiring more soft-forking. Though whether the place for script
>> experimentation using more general-purpose opcodes on the main chain is
>> another interesting debate...
>>
>> Sorry for going a little off-topic there.
>>
>> [0]: https://medium.com/blockstream/simplicity-jets-release-803db10fd589
>>
>>
>> On Thu, Feb 10, 2022 at 7:55 PM David A. Harding via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev
>>> wrote:
>>> > Whether [recursive covenants] is an issue or not precluding this sort
>>> > of design or not, I defer to others.
>>>
>>> For reference, I believe the last time the merits of allowing recursive
>>> covenants was discussed at length on this list[1], not a single person
>>> replied to say that they were opposed to the idea.
>>>
>>> I would like to suggest that anyone opposed to recursive covenants spea=
k
>>> for themselves (if any intelligent such people exist). Citing the risk
>>> of recursive covenants without presenting a credible argument for the
>>> source of that risk feels to me like (at best) stop energy[2] and (at
>>> worst) FUD.
>>>
>>> -Dave
>>>
>>> [1]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/01920=
3.html
>>> [2]
>>> http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWin=
er.html
>>> (thanks to AJ who told me about stop energy one time when I was
>>> producing it)
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto"><div dir=3D"auto">&gt;=C2=A0<span style=3D"font-size:12.8=
px">in the case of a multisig/non-consensus based system, exit from that re=
striction is still possible=C2=A0</span></div><div dir=3D"auto"><span style=
=3D"font-size:12.8px"><br></span></div><div dir=3D"auto"><span style=3D"fon=
t-size:12.8px">But why do we care if someone reduces the value of coins the=
y own by permanently encumbering them in some way? Burning coins permanentl=
y encumbers them so much they can&#39;t be spent at all. If the worry is de=
pleting the supply of sats, don&#39;t worry, the amount of value lost by th=
ose encumbered is gained but the rest of the coins. Just like burning, encu=
mbering your coins in a way that devalues them is a donation to the rest of=
 us.=C2=A0</span></div><div dir=3D"auto"><span style=3D"font-size:12.8px"><=
br></span></div><div dir=3D"auto"><span style=3D"font-size:12.8px">Could yo=
u clarify what harm there is to those who choose not to accept such encumbe=
red coins? Or are you just saying that those who do accept such encumbered =
coins may be harmed by doing so?</span></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Feb 12, 2022, 06:11 darosior=
 via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" rel=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxf=
oundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><block=
quote><div style=3D"font-family:arial;font-size:14px">Such a construct woul=
d present dangerous implications to the fungibility
 of individual UTXOs by introducing a totally different risk model in
being paid with such a coin compared to any other coin not encumbered by
 such a condition<br></div></blockquote><div style=3D"font-family:arial;fon=
t-size:14px"><div style=3D"font-family:arial;font-size:14px"><div><div><br>=
</div></div><div></div></div><div style=3D"font-family:arial;font-size:14px=
">How is that different from being paid in an altcoin?<br></div><div style=
=3D"font-family:arial;font-size:14px">It seems to me that being able to say=
 &quot;sorry, your money isn&#39;t good here&quot; is at the heart of Bitco=
in&#39;s security (similarly to enforcing the network rules with your node)=
. If someone can coerce you into using another currency, you&#39;ve already=
 lost.<br></div><div style=3D"font-family:arial;font-size:14px"><br></div><=
div style=3D"font-family:arial;font-size:14px">Now there is left the influe=
nce on the system of an user being coerced into using gov coin (on another =
chain) or an encumbered bit coin. Sure the latter would decrease the supply=
 available, but that&#39;s already possible to do today.<br></div></div><di=
v style=3D"font-family:arial;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        Le vendredi 11 f=C3=A9vrier 2022 =C3=A0 7:12 PM, digital vagabond v=
ia bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
 rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; a =C3=A9crit :<br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr">This is Shinobi (can verify out of band at @br=
ian_trollz on Twitter, I only signed up to the list with this email to read=
 initially, but feel like I should reply to this as I think I am one of the=
 only people in this space who has voiced concerns with recursive covenants=
). <div><br></div><div>My concerns don&#39;t really center specifically aro=
und recursion itself necessarily, but unbounded recursion in combination wi=
th too much generality/flexibility in what types of conditions future UTXOs=
 can be encumbered with based on the restriction of such covenants. Forgive=
 the hand waiving arguments without getting into specific opcodes, but I wo=
uld summarize my concerns with a hypothetical construct that I believe woul=
d be incredibly damaging to fungibility. Imagine a covenant design that was=
 flexible enough to create an encumbrance like this: a script specifies a s=
pecific key in a multisig controlled by some authority figure (or a branch =
in the script that would allow unilateral control by such an authority), an=
d the conditions of the covenant would perpetually require than any spend f=
rom the covenant can only be sent to a script involving that key from said =
authority, preventing by consensus any removal of that central authorities =
involvement in control over that UTXO. Such a construct would present dange=
rous implications to the fungibility of individual UTXOs by introducing a t=
otally different risk model in being paid with such a coin compared to any =
other coin not encumbered by such a condition, and also potentially introdu=
ce a shift in the scope of what a 51% attack could accomplish in terms of p=
ermanent consequences attempting to coerce coins into such covenants, as op=
posed to right now only being able to accomplish censorship or temporary ne=
twork disruption. </div><div><br></div><div>I know that such a walled garde=
n could easily be constructed now with multisig and restrictions on where c=
oins can be withdrawn to from exchanges or whatever place they initially pu=
rchased from, as is demonstrated by the implementation of the Asset Managem=
ent Platform by Blockstream for use on Liquid with regulated equity tokens,=
 but I think the important distinction between such non-consensus system de=
signed to enforce such restrictions and a recursive covenant to accomplish =
the same is that in the case of a multisig/non-consensus based system, exit=
 from that restriction is still possible under the consensus rules of the p=
rotocol. If such a construct was possible to build with a recursive covenan=
t enforced by consensus, coins encumbered by such a covenant would literall=
y be incapable of escaping those restrictions without hardforking the proto=
col, leaving any such UTXOs permanently non-fungible with ones not encumber=
ed by such conditions. </div><div><br></div><div>I&#39;m not that deeply fa=
miliar with all the working pieces involved in the recent TXHASH + CSFS pro=
posal, and whether such a type of overly (IMO) generalized recursion would =
be possible to construct, but one of the reasons CTV does not bother me in =
terms of such concerns is the inability to infinitely recurse in such a gen=
eralized way given the requirements to exactly specify the destination of f=
uture spends in constructing a chain of CTV encumbrances. I&#39;d very much=
 appreciate any feedback on my concerns, and if this side tracks the discus=
sion I apologize, but I felt given the issue has been mentioned a few times=
 in this thread it was appropriate for me to voice the concerns here so the=
y could be addressed directly. </div></div><br><div class=3D"gmail_quote"><=
div class=3D"gmail_attr" dir=3D"ltr">On Fri, Feb 11, 2022 at 11:42 AM James=
 O&#39;Beirne via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" rel=3D"noreferrer nofollow noopener noreferrer noreferrer n=
oreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; =
wrote:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div dir=
=3D"ltr"><div>I don&#39;t oppose recursive covenants per se, but in prior p=
osts I have expressed uncertainty about proposals that enable more &quot;fe=
atureful&quot; covenants by adding more kinds of computation into bitcoin s=
cript.</div><div><br></div><div>Not that anyone here is necessarily saying =
otherwise, but I am very interested in limiting operations in bitcoin scrip=
t to &quot;verification&quot; (vs. &quot;computation&quot;) to the extent p=
ractical, and instead encouraging general computation be done off-chain. Th=
is of course isn&#39;t a new observation and I think the last few years hav=
e been very successful to that effect, e.g. the popularity of the &quot;scr=
iptless scripts&quot; idea and Taproot&#39;s emphasis on embedding computat=
ional artifacts in key tweaks.</div><div><br></div><div>My (maybe unfounded=
?) worry about opcodes like OP_CAT and OP_TX is that more logic will live i=
n script than is necessary, and so the burden to verify the chain may grow =
and the extra &quot;degrees of freedom&quot; in script may make it harder t=
o reason about. But I guess at this point there aren&#39;t alternative mean=
s to construct new kinds of sighashes that are necessary for some interesti=
ng covenants. <br></div><div><br></div><div>One thing I like about CTV is t=
hat it buys a lot of functionality without increasing the &quot;surface are=
a&quot; of script&#39;s design. In general I think there is a lot to be sai=
d for this &quot;jets&quot;-style approach[0] of codifying the script opera=
tions that you&#39;d actually want to do into single opcodes. This adds fun=
ctionality while introducing minimal surface area to script, giving script =
implementers more flexibility for, say, optimization. But of course this co=
mes at the cost of precluding experimentation, and probably requiring more =
soft-forking. Though whether the place for script experimentation using mor=
e general-purpose opcodes on the main chain is another interesting debate..=
.</div><div><br></div><div>Sorry for going a little off-topic there.<br></d=
iv><div><br></div><div>[0]: <a href=3D"https://medium.com/blockstream/simpl=
icity-jets-release-803db10fd589" rel=3D"noreferrer nofollow noopener norefe=
rrer noreferrer noreferrer" target=3D"_blank">https://medium.com/blockstrea=
m/simplicity-jets-release-803db10fd589</a></div><br></div><br><div class=3D=
"gmail_quote"><div class=3D"gmail_attr" dir=3D"ltr">On Thu, Feb 10, 2022 at=
 7:55 PM David A. Harding via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" rel=3D"noreferrer nofollow noopener noreferrer =
noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quot=
e">On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev w=
rote:<br>
&gt; Whether [recursive covenants] is an issue or not precluding this sort<=
br>
&gt; of design or not, I defer to others.<br>
<br>
For reference, I believe the last time the merits of allowing recursive<br>
covenants was discussed at length on this list[1], not a single person<br>
replied to say that they were opposed to the idea.<br>
<br>
I would like to suggest that anyone opposed to recursive covenants speak<br=
>
for themselves (if any intelligent such people exist).  Citing the risk<br>
of recursive covenants without presenting a credible argument for the<br>
source of that risk feels to me like (at best) stop energy[2] and (at<br>
worst) FUD.<br>
<br>
-Dave<br>
<br>
[1] <a rel=3D"noreferrer nofollow noopener noreferrer noreferrer noreferrer=
" href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July=
/019203.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail=
/bitcoin-dev/2021-July/019203.html</a><br>
[2] <a rel=3D"noreferrer nofollow noopener noreferrer noreferrer noreferrer=
" href=3D"http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByD=
aveWiner.html" target=3D"_blank">http://radio-weblogs.com/0107584/stories/2=
002/05/05/stopEnergyByDaveWiner.html</a><br>
    (thanks to AJ who told me about stop energy one time when I was<br>
    producing it)<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
nofollow noopener noreferrer noreferrer noreferrer" target=3D"_blank">bitco=
in-dev@lists.linuxfoundation.org</a><br>
<a rel=3D"noreferrer nofollow noopener noreferrer noreferrer noreferrer" hr=
ef=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" targe=
t=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=
</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
nofollow noopener noreferrer noreferrer noreferrer" target=3D"_blank">bitco=
in-dev@lists.linuxfoundation.org</a><br>
<a rel=3D"noreferrer nofollow noopener noreferrer noreferrer noreferrer" hr=
ef=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" targe=
t=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=
</a><br>
</blockquote></div>

        </blockquote><br>
    </div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000cf583405d7d44349--