path: root/1d/c4d472a3c67db5f8fdc5c89bf5bcdd7d8ff5ed

Return-Path: <pointlesscacophany@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D97CFC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Feb 2022 18:12:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id B533D4168C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Feb 2022 18:12:41 +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 X9olhw90kDdn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Feb 2022 18:12:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com
 [IPv6:2607:f8b0:4864:20::d33])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 6176841684
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Feb 2022 18:12:40 +0000 (UTC)
Received: by mail-io1-xd33.google.com with SMTP id e79so12334504iof.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Feb 2022 10:12:40 -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;
 bh=zUP2oVIHarbvo67kyLJYDQEPH8V3zUKX89Urla5e1fE=;
 b=c3V3lez454Z/GIxjl91TWhcoJ9+SFoVwkE7ciT4QoeoH1+LXlWM443/DxMl/X+IRKJ
 QCLBFNuuFMJ8PTnVldCZQIV9EoGJV8HjtzURewxWNC9SNrvFbc13huldPYalkjp9lAh8
 KDrg9sovdHxAo/W46+S2BS2C38Wsrnz9DOusjw98Mim8isnqB+/IcLAVI2PTBBXQ5WeW
 T5e5IL3nwF5ZIT8qGjoPGGp7z5rS2KRHlXqyv2RzIwX40IdbwynsYkqDy+nlz0EMYhEJ
 72ecVWTF3eumd63/RB1ZekqW9PhTdaCLqRI3KS713u2Jpj76uEbREiZ9LZV+hizfVhjO
 R/IQ==
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=zUP2oVIHarbvo67kyLJYDQEPH8V3zUKX89Urla5e1fE=;
 b=gD/ZPJkCkkoRwdpY5fa3D1Sv+6N24bx3wFR7m471JApt9MvmN69L8AsLwWvFH7bi1O
 3cQjxpdnUfCDiZu8AXZD5mhrh9UN2RK4rHhAPUUcSYiIX24xuQQ61Q2Uv3YI+chSCTli
 XMNFtyrbsWMw6YYgzuxuj0L9fn6NHrXoV8Mc+CRwbQOQgUM1xCeWFolt7ENb87wQsy6D
 j8jJWxPvWPWnX5ANQdq1H1dlJZnva14gnd1JCp3GwP1K0fDy4rupTdYPeyV3amsxdzmX
 QKUszm7KhHrHuO398shbclbvPemmRxvCebUmrNUzRKPZmmQORGHNvOU/c1G6lyEXbwVc
 7uZw==
X-Gm-Message-State: AOAM533MmGW7b9aqwy4SaFZTqPlRoy3Jyko9HIvhtSbmrR4CVdOslzLE
 FeTCMz038uNXnmz+pINlgj4XHVNPyc2hdFnmorE=
X-Google-Smtp-Source: ABdhPJzVCzU+grwTFG3NRA1ykU46ntd5bvNBihs8I+m3GMGs5ynM4owjLXHD+8IR549mvD0ERoSpNgTo8RXd1A/KPI8=
X-Received: by 2002:a6b:8b4a:: with SMTP id n71mr1503867iod.206.1644603159446; 
 Fri, 11 Feb 2022 10:12:39 -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>
In-Reply-To: <CAPfvXf+q-0JiM+qap9wgUB1FTAeHGio_XeWVBdRwKj-_GffeUQ@mail.gmail.com>
From: digital vagabond <pointlesscacophany@gmail.com>
Date: Fri, 11 Feb 2022 12:12:28 -0600
Message-ID: <CAFSEESFg0Ep-eL50B-JXh1omTa4kXiwn98rwJD3X5iyQrfA_6g@mail.gmail.com>
To: "James O'Beirne" <james.obeirne@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000001d8c6605d7c20363"
X-Mailman-Approved-At: Fri, 11 Feb 2022 18:47:06 +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: Fri, 11 Feb 2022 18:12:42 -0000

--0000000000001d8c6605d7c20363
Content-Type: text/plain; charset="UTF-8"

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

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 branch
in the script that would allow unilateral control by such an authority),
and the conditions of the covenant would perpetually require than any spend
from 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
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 accomplish
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 exchanges
or whatever place they initially purchased from, as is demonstrated by the
implementation of the Asset Management Platform by Blockstream for use on
Liquid with regulated equity tokens, but I think the important distinction
between such non-consensus system designed 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 protocol. If such a construct was
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 UTXOs
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, and
if this side tracks the discussion 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 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" (vs.
> "computation") to the extent practical, and instead encouraging general
> computation be done off-chain. This of course isn't a new observation and 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 may
> 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 without
> increasing the "surface area" of script's design. In general I think there
> 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. This
> adds functionality while introducing minimal surface area to script, giving
> script implementers more flexibility for, say, optimization. But of course
> 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 speak
>> 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/019203.html
>> [2]
>> http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.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
>

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

<div dir=3D"ltr">This is Shinobi (can verify out of band at=C2=A0@brian_tro=
llz on Twitter, I only signed up to the list with this email to read initia=
lly, but feel like I should reply to this as I think I am one of the only p=
eople in this space who has voiced concerns with recursive covenants).=C2=
=A0<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=C2=A0arguments 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 tha=
t was flexible enough to create an encumbrance like this: a script specifie=
s a specific key in a multisig controlled by some authority figure (or a br=
anch in the script that would allow unilateral control by such an authority=
), and the conditions of the covenant would perpetually require than any sp=
end from the covenant can only be sent to a script involving that key from =
said authority, preventing by consensus any removal of that central authori=
ties involvement in control over that UTXO. Such a construct would present =
dangerous implications to the fungibility of individual UTXOs by introducin=
g 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 in=
troduce a shift in the scope of what a 51% attack could accomplish in terms=
 of permanent=C2=A0consequences attempting to coerce coins into such covena=
nts, as opposed to right now only being able to accomplish censorship or te=
mporary network disruption.=C2=A0</div><div><br></div><div>I know that such=
 a walled garden could easily be constructed now with multisig and restrict=
ions on where coins can be withdrawn to from exchanges or whatever place th=
ey initially purchased from, as is demonstrated by the implementation of th=
e Asset Management Platform by Blockstream for use on Liquid with regulated=
 equity tokens, but I think the important distinction between such non-cons=
ensus system designed to enforce such restrictions and a recursive covenant=
 to accomplish the same is that in the case of a multisig/non-consensus bas=
ed system, exit from that restriction is still possible under the consensus=
 rules of the protocol. If such a construct was possible to build with a re=
cursive covenant enforced by consensus, coins encumbered by such a covenant=
 would literally be incapable of escaping those restrictions without hardfo=
rking the protocol, leaving any such UTXOs permanently=C2=A0non-fungible wi=
th ones not encumbered by such conditions.=C2=A0</div><div><br></div><div>I=
&#39;m not that deeply familiar with all the working pieces involved in the=
 recent TXHASH=C2=A0+ CSFS proposal, and whether such a type of overly (IMO=
) generalized recursion would be possible to construct, but one of the reas=
ons CTV does not bother me in terms of such concerns is the inability to in=
finitely recurse in such a generalized way given the requirements to exactl=
y specify the destination of future spends in constructing a chain of CTV e=
ncumbrances. I&#39;d very much appreciate any feedback on my concerns, and =
if this side tracks the discussion 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 they could be addressed directly.=C2=A0</div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Fri, Feb 11, 2022 at 11:42 AM James O&#39;Beirne via bitcoin-dev &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxf=
oundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div>I don&#39;t oppose recursive covenants p=
er se, but in prior posts I have expressed uncertainty about proposals that=
 enable more &quot;featureful&quot; covenants by adding more kinds of compu=
tation into bitcoin script.</div><div><br></div><div>Not that anyone here i=
s necessarily saying otherwise, but I am very interested in limiting operat=
ions in bitcoin script to &quot;verification&quot; (vs. &quot;computation&q=
uot;) to the extent practical, and instead encouraging general computation =
be done off-chain. This of course isn&#39;t a new observation and I think t=
he last few years have been very successful to that effect, e.g. the popula=
rity of the &quot;scriptless scripts&quot; idea and Taproot&#39;s emphasis =
on embedding computational artifacts in key tweaks.</div><div><br></div><di=
v>My (maybe unfounded?) worry about opcodes like OP_CAT and OP_TX is that m=
ore logic will live in script than is necessary, and so the burden to verif=
y the chain may grow and the extra &quot;degrees of freedom&quot; in script=
 may make it harder to reason about. But I guess at this point there aren&#=
39;t alternative means to construct new kinds of sighashes that are necessa=
ry for some interesting covenants. <br></div><div><br></div><div>One thing =
I like about CTV is that it buys a lot of functionality without increasing =
the &quot;surface area&quot; of script&#39;s design. In general I think the=
re is a lot to be said for this &quot;jets&quot;-style approach[0] of codif=
ying the script operations that you&#39;d actually want to do into single o=
pcodes. This adds functionality while introducing minimal surface area to s=
cript, giving script implementers more flexibility for, say, optimization. =
But of course this comes at the cost of precluding experimentation, and pro=
bably requiring more soft-forking. Though whether the place for script expe=
rimentation using more general-purpose opcodes on the main chain is another=
 interesting debate...</div><div><br></div><div>Sorry for going a little of=
f-topic there.<br></div><div><br></div><div>[0]: <a href=3D"https://medium.=
com/blockstream/simplicity-jets-release-803db10fd589" target=3D"_blank">htt=
ps://medium.com/blockstream/simplicity-jets-release-803db10fd589</a></div><=
br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">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" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">On Mon, Feb 07, 2022 at 08:34:30PM -0800,=
 Jeremy Rubin via bitcoin-dev wrote:<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).=C2=A0 Citing the ris=
k<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 href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021=
-July/019203.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2021-July/019203.html</a><br>
[2] <a href=3D"http://radio-weblogs.com/0107584/stories/2002/05/05/stopEner=
gyByDaveWiner.html" rel=3D"noreferrer" target=3D"_blank">http://radio-weblo=
gs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html</a><br>
=C2=A0 =C2=A0 (thanks to AJ who told me about stop energy one time when I w=
as<br>
=C2=A0 =C2=A0 producing it)<br>
<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>
_______________________________________________<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>

--0000000000001d8c6605d7c20363--