path: root/2b/784e04b306a929fcd539cb8fcb3a8cf8f52c85

Return-Path: <keagan.mcclelland@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CF432C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 May 2022 15:23:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id AEDA781C21
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 May 2022 15:23:54 +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 8jNdG-sp121i
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 May 2022 15:23:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [IPv6:2a00:1450:4864:20::330])
 by smtp1.osuosl.org (Postfix) with ESMTPS id E84D181BA8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 May 2022 15:23:52 +0000 (UTC)
Received: by mail-wm1-x330.google.com with SMTP id
 k126-20020a1ca184000000b003943fd07180so8477055wme.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 09 May 2022 08:23:52 -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
 :cc; bh=r3EYTe5nkWjftN2/tztr4aOj/hnGLsag9hL4NwAk9LE=;
 b=C3oHnWmAl5nsCF/Q32r9geL6q4NgzvVz9bPxZzzldg6hgpSTHjr4cKe7gKIw3da+BA
 sTs1UbxQeXKZWmXXWc17jVdxVMZG4Rrlbk9xUoi2s6I9OIvSnj4CemMJw7W+Q98vI2lq
 MaJO+4an3HxUaPcILnqR1JEgisBFlFKAQ154BLdGhtAZp6JvyMxX8QGO2T2xlYHR/kXI
 awb1hLGLoO4t0Cs58lqZgLea7DoLtbtxV4+VGkJ7rzuTOYiIxUKt493fAiyiH554J9np
 dlaRl8wZppzvC+8vhPhZV/6z7ukDRgrOR8mEuVX14oyIJo61OJL5mEtX3tN1XklJkxeJ
 kgYw==
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=r3EYTe5nkWjftN2/tztr4aOj/hnGLsag9hL4NwAk9LE=;
 b=IbcaOnPF6ktFuBPygMw1x23CpCfOkDGWl+z4qEBISW6ZmgAnUS3PhnjqAftpCJsxXh
 v9SjfnYdmKTVKAQzQrAWNmLnl21hPwrmYbAJdXLou55mpIU1MWPQ44hwhifDbPqSSUmp
 cDBjJrtAr7YaSOfxpIGO38IYdAsw+ZHdF3c5GN2oe4RieJuH9e4b5lbm4EF9Y5feqdh0
 Pvt7XUJ6Fb9stNhtsIr/jzjBl1UtHIpeEalRxsGUApzYccgYlUj/1VqhDbrFCKnkqovQ
 2a0KGnT8hF3278GMaaPv0wvsSgtfVSjuH4Ea1iOp7JMjNCZzEDpmea2SDqeb7TdHiyFB
 7njw==
X-Gm-Message-State: AOAM532Kk3Ke2Bw8UEhI3/J/fVZKxhFzUNldud4tmTjpOtbeIoEygKAR
 krNE76D3g6oDPBhAX3nRZ6Pq7S4MDQXTtqioMV0=
X-Google-Smtp-Source: ABdhPJxQB/AonVXuXiMN5GAYwQB42Sa9ebkJEGmxNNon4MAOmysZOTGuMSl0PaPTbTXkYuvkWrn4y0zZhGEDScCvR/U=
X-Received: by 2002:a05:600c:4fce:b0:394:5f8e:8124 with SMTP id
 o14-20020a05600c4fce00b003945f8e8124mr23455560wmq.107.1652109830812; Mon, 09
 May 2022 08:23:50 -0700 (PDT)
MIME-Version: 1.0
References: <kbrvpw3Y5y3ko3Wf2VtcywN462JjMW6YjqecduPOXwrek2sR9FkWfSv6G2Fph22UTAAbgII88MtOn1AFo223jjryNAz8YNbbQlFRVQo_HMY=@protonmail.com>
 <CABm2gDqxOtrMrTu2Ovx32USJT2T+6DRpexct1-k3zwEEnsDPMA@mail.gmail.com>
 <HfqjtQb_3TfhHaAZzYOcUoMic1iG40qUjqlKpzOZY6PSBW1bXVFtFW4zCHFRUdOoIhrard9ZPslzbrIYO0cM-Oi37mLzeEv6MZiQ7JtulE4=@protonmail.com>
 <CAGpPWDZVqas6v9nQtGtgk2mMOw9KQ+=dytBc+fBE6SNL=F3bqQ@mail.gmail.com>
In-Reply-To: <CAGpPWDZVqas6v9nQtGtgk2mMOw9KQ+=dytBc+fBE6SNL=F3bqQ@mail.gmail.com>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Mon, 9 May 2022 09:23:39 -0600
Message-ID: <CALeFGL18ULkGW4UA_5Fod4PVoe_LeF5e97eZdJja-ctf2paLWQ@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000987bfd05de95cbb5"
X-Mailman-Approved-At: Mon, 09 May 2022 15:38:44 +0000
Subject: Re: [bitcoin-dev] CTV BIP Meeting #8 Notes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2022 15:23:54 -0000

--000000000000987bfd05de95cbb5
Content-Type: text/plain; charset="UTF-8"

> > > To me the most scary one is visacoin, specially seeing what happened
in canada and other places lately and the general censorship in the west,
the supposed war on "misinformation" going on (really a war against truth
imo, but whatever) it's getting really scary. But perhaps someone else can
be more scared about a covenant to add demurrage fees to coins or
something, I don't know.
> > > https://bitcointalk.org/index.php?topic=278122

> > This requires *recursive* covenants.

> Actually, for practical use, any walled-garden requires *dynamic*
covenants, not recursive covenants.

There's actually also a very straight forward defense for those who do not
want to receive "tainted" coins. In every covenant design I've seen to date
(including recursive designs) it requires that the receiver generate a
script that is "compliant" with the covenant provisions to which the sender
is bound. The consequence of this is that you can't receive coins that are
bound by covenants you weren't aware of*. So if you don't want to receive
restricted coins, just don't generate an address with those restrictions
embedded. As long as you can specify the spend conditions upon the receipt
of your funds, it really doesn't matter how others are structuring their
own spend conditions. So long as the verification of those conditions can
be predictably verified by the rest of the network, all risk incurred is
quarantined to the receiver of the funds. Worst case scenario is that no
one wants to agree to those conditions and the funds are effectively burned.

It's not hard to make the case that any time funds are being transferred
between organizations with incompatible interests (external to a firm),
that they will want to be completely free to choose their own spend
conditions and will not wish to inherit the conditions of the spender.
Correspondingly, any well implemented covenant contract will include
provisions for escaping the recursion loop if some sufficiently high bar is
met by the administrators of those funds. Unless governments can mandate
that you generate these addresses AND force you to accept funds bound by
them for your services**, I don't actually see how this is a real concern.

*This requires good wallet tooling and standards but that isn't materially
different than wallets experimenting with non-standard recovery policies.

**This is a reason to oppose legal tender laws for Bitcoin imo.

Keagan

On Sun, May 8, 2022 at 11:32 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >  This requires *recursive* covenants.
>
> Actually, for practical use, any walled-garden requires *dynamic*
> covenants, not recursive covenants. CTV can get arbitrarily close to
> recursive covenants, because you can have an arbitrarily long string of
> covenants. But this doesn't help someone implement visacoin because CTV
> only allows a specific predefined iteration of transactions, meaning that
> while "locked" into the covenant sequence, the coins can't be used in any
> way like normal coins - you can't choose who you pay, the sequence is
> predetermined.
>
> Even covenants that allow infinite recursion (like OP_TLUV and OP_CD
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>)
> don't automatically allow for practical walled gardens. Recursion
> definitely allows creating walled gardens, but those gardens would be
> impractically static. You could add millions of potential addresses to send
> to, which would "only" quadruple the size of your transactions, but if
> anyone creates a new address you want to send to, you wouldn't be able to.
> Everyone would have to have a single address whitelisted into every
> government-bitcoin output. If someone lost their key and needs to create a
> new wallet, suddenly no one would be able to pay them.
>
> In order to really build a wallet garden, infinite recursion isn't really
> necessary nor sufficient. You need to be able to dynamically specify
> destination addresses. For example, if you were a government that wants to
> make a walled garden where you (the government) could confiscate the funds
> whenever you wanted, you'd have to have a covenant that allows the end-user
> to specify an arbitrary public key to send money to. The covenant might
> require that user to send to another covenant that has a government spend
> path, but also has a spend path for that user-defined public key. That way,
> you (the government) could allow people to send to each other arbitrarily,
> while still ensuring that you (the government) could spend the funds no
> matter where they may have been sent. Even without recursive covenants, you
> could have arbitrarily long chains of these, say 1 million long, where at
> the end of the chain the user must send your coins back to the government
> who can then send them back with another million-long chain of covenants to
> work with.
>
> OP_CHECKOUTPUTVERIFY <https://fc16.ifca.ai/bitcoin/papers/MES16.pdf> can
> do this kind of dynamicness, and OP_PUSHOUTPUTSTACK
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md> can
> enable it for things like OP_TLUV and OP_CD. I personally think dynamic
> covenants are a *good* thing, as it enables more secure wallet vaults,
> among other things. And I'm not worried about a government creating a
> in-bitcoin visa-coin. Why? Because they can already do it today. They have
> been able to do it for 9 years already. How?
>
> Replace the covenant above with a multisig wallet. The government has 2
> keys, you have 1 key. Every time you make a transaction, you request the
> government's signature on it. The government then only signs if you're
> sending to a wallet they approve of. They might only sign when you're
> sending to another multisig wallet that the government has 2 of 3 keys for.
> Its a very similar walled garden, where the only difference is that the
> government needs to actively sign, which I'm sure wouldn't be a huge
> challenge for the intrepid dictator of the land. You want to add
> demurage fees? Easy, the government just spends the fee out of everyone's
> wallets every so often.
>
> On the other hand, OP_CTV *cannot* be used for such a thing. No
> combination of future opcodes can enable either recursion or dynamicness to
> an OP_CTV call.
>
>
>
> On Sat, May 7, 2022 at 5:40 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning Jorge,
>>
>> > I think people may be scared of potential attacks based on covenants.
>> For example, visacoin.
>> > But there was a thread with ideas of possible attacks based on
>> covenants.
>> > To me the most scary one is visacoin, specially seeing what happened in
>> canada and other places lately and the general censorship in the west, the
>> supposed war on "misinformation" going on (really a war against truth imo,
>> but whatever) it's getting really scary. But perhaps someone else can be
>> more scared about a covenant to add demurrage fees to coins or something, I
>> don't know.
>> > https://bitcointalk.org/index.php?topic=278122
>>
>> This requires *recursive* covenants.
>>
>> At the time the post was made, no distinction was seen between recursive
>> and non-recursive covenants, which is why the post points out that
>> covenants suck.
>> The idea then was that anything powerful enough to provide covenants
>> would also be powerful enough to provide *recursive* covenants, so there
>> was no distinction made between recursive and non-recursive covenants (the
>> latter was thought to be impossible).
>>
>> However, `OP_CTV` turns out to enable sort-of covenants, but by
>> construction *cannot* provide recursion.
>> It is just barely powerful enough to make a covenant, but not powerful
>> enough to make *recursive* covenants.
>>
>> That is why today we distinguish between recursive and non-recursive
>> covenant opcodes, because we now have opcode designs that provides
>> non-recursive covenants (when previously it was thought all covenant
>> opcodes would provide recursion).
>>
>> `visacoin` can only work as a recursive covenant, thus it is not possible
>> to use `OP_CTV` to implement `visacoin`, regardless of your political views.
>>
>> (I was also misinformed in the past and ignored `OP_CTV` since I thought
>> that, like all the other covenant opcodes, it would enable recursive
>> covenants.)
>>
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> 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
>

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

<div dir=3D"ltr"><div><span style=3D"color:rgb(80,0,80)">&gt; &gt; &gt; To =
me the most scary one is visacoin, specially seeing what happened in canada=
 and other places lately and the general censorship in the west, the suppos=
ed war on &quot;misinformation&quot; going on (really a war against truth i=
mo, but whatever) it&#39;s getting really scary. But perhaps someone else c=
an be more scared about a covenant to add demurrage fees to coins or someth=
ing, I don&#39;t know.</span><br style=3D"color:rgb(80,0,80)"><span style=
=3D"color:rgb(80,0,80)">&gt;=C2=A0&gt; &gt;=C2=A0</span><a href=3D"https://=
bitcointalk.org/index.php?topic=3D278122" rel=3D"noreferrer" target=3D"_bla=
nk">https://bitcointalk.org/index.php?topic=3D278122</a><br></div><div><br>=
</div><div>&gt; &gt; This requires *recursive* covenants.<br></div><div><br=
></div><div>&gt; Actually, for practical use, any walled-garden requires *d=
ynamic* covenants, not recursive covenants.</div><div><br></div><div>There&=
#39;s actually also a very straight forward defense for those who do not wa=
nt to receive &quot;tainted&quot; coins. In every covenant design I&#39;ve =
seen to date (including recursive designs) it requires that the receiver ge=
nerate a script that is &quot;compliant&quot; with the covenant provisions =
to which the sender is bound. The consequence of this is that you can&#39;t=
 receive coins that are bound by covenants you weren&#39;t aware of*. So if=
 you don&#39;t want to receive restricted coins, just don&#39;t generate an=
 address with those restrictions embedded. As long as you can specify the s=
pend conditions upon the receipt of your funds, it really doesn&#39;t matte=
r how others are structuring their own spend conditions. So long as the ver=
ification of those conditions can be predictably=C2=A0verified by the rest =
of the network, all risk incurred is quarantined to the receiver of the fun=
ds. Worst case scenario is that no one wants to agree to those conditions a=
nd the funds are effectively burned.</div><div><br></div><div>It&#39;s not =
hard to make the case that any time funds are being transferred between org=
anizations with incompatible interests (external to a firm), that they will=
 want to be completely free to choose their own spend conditions and will n=
ot wish to inherit the conditions of the spender. Correspondingly, any well=
 implemented covenant contract will include provisions for escaping the rec=
ursion loop if some sufficiently high bar is met by the administrators of t=
hose funds. Unless governments can mandate that you generate these addresse=
s AND force you to accept funds bound by them for your services**, I don&#3=
9;t actually see how this is a real concern.</div><div><br></div><div>*This=
 requires good wallet tooling and standards but that isn&#39;t materially d=
ifferent than wallets experimenting with non-standard recovery policies.</d=
iv><div><br></div><div>**This is a reason to oppose legal tender laws for B=
itcoin imo.</div><div><br></div><div>Keagan</div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, May 8, 2022 at 11:=
32 AM Billy Tetrud via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
&gt;=C2=A0

This requires *recursive* covenants.<div><br></div><div>Actually, for pract=
ical use, any walled-garden requires *dynamic* covenants, not recursive cov=
enants. CTV can get arbitrarily close to recursive covenants, because you c=
an have an arbitrarily long string of covenants. But this doesn&#39;t help =
someone implement visacoin because CTV only allows a specific predefined it=
eration of transactions, meaning that while &quot;locked&quot; into the cov=
enant sequence, the coins can&#39;t be used in any way like normal coins - =
you can&#39;t choose who you pay, the sequence is predetermined.=C2=A0</div=
><div><br></div><div>Even covenants that allow infinite recursion (like OP_=
TLUV and <a href=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-va=
ults/blob/main/cd/bip-constraindestination.md" target=3D"_blank">OP_CD</a>)=
 don&#39;t automatically allow for practical walled gardens. Recursion defi=
nitely allows creating walled gardens, but those gardens would be impractic=
ally static. You could add millions of potential addresses to send to, whic=
h would &quot;only&quot; quadruple the size of your=C2=A0transactions, but =
if anyone creates a new address you want to send to, you wouldn&#39;t be ab=
le to. Everyone would have to have a single address whitelisted into every =
government-bitcoin output. If someone lost their key and needs to create a =
new wallet, suddenly no one would be able to pay them.=C2=A0</div><div><br>=
</div><div>In order to really build a wallet garden, infinite recursion isn=
&#39;t really necessary nor sufficient. You need to be able to dynamically =
specify destination addresses. For example, if you were a government that w=
ants to make a walled garden where you (the government) could confiscate th=
e funds whenever you wanted, you&#39;d have to have a covenant that allows =
the end-user to specify an arbitrary public key=C2=A0to send money to. The =
covenant might require that user to send to another covenant that has a gov=
ernment spend path, but also has a spend path for that user-defined public =
key. That way, you (the government) could allow people to send to each othe=
r=C2=A0arbitrarily, while still ensuring that you (the government) could sp=
end the funds no matter where they may have been sent. Even without recursi=
ve covenants, you could have arbitrarily long chains of these, say 1 millio=
n long, where at the end of the chain the user must send your coins back to=
 the government who can then send them back with another million-long chain=
 of covenants to work with.</div><div><br></div><div><a href=3D"https://fc1=
6.ifca.ai/bitcoin/papers/MES16.pdf" target=3D"_blank">OP_CHECKOUTPUTVERIFY<=
/a>=C2=A0can do this kind of dynamicness, and <a href=3D"https://github.com=
/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack=
.md" target=3D"_blank">OP_PUSHOUTPUTSTACK</a>=C2=A0can enable it for things=
 like OP_TLUV and OP_CD. I personally think dynamic covenants are a *good* =
thing,=C2=A0as it enables more secure=C2=A0wallet vaults, among other thing=
s. And I&#39;m not worried about a government creating a in-bitcoin visa-co=
in. Why? Because they can already do it today. They have been able to do it=
 for 9 years already. How?</div><div><br></div><div>Replace the covenant ab=
ove with a multisig wallet. The government has 2 keys, you have 1 key. Ever=
y time you make a transaction, you request the government&#39;s signature o=
n it. The government then only signs if you&#39;re sending to a wallet they=
 approve of. They might only sign when you&#39;re sending to another multis=
ig wallet that the government has 2 of 3 keys for. Its a very similar walle=
d garden, where the only difference is that the government needs to activel=
y sign, which I&#39;m sure wouldn&#39;t be a huge challenge for the intrepi=
d dictator of the land. You want to add demurage=C2=A0fees? Easy, the gover=
nment just spends the fee out of everyone&#39;s wallets every so often.</di=
v><div><br></div><div>On the other hand, OP_CTV *cannot* be used for such a=
 thing. No combination of future opcodes can enable either recursion or dyn=
amicness to an OP_CTV call.=C2=A0</div><div><br></div><div><br></div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat=
, May 7, 2022 at 5:40 PM ZmnSCPxj via bitcoin-dev &lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin=
uxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">Good morning Jorge,<br>
<br>
&gt; I think people may be scared of potential attacks based on covenants. =
For example, visacoin.<br>
&gt; But there was a thread with ideas of possible attacks based on covenan=
ts.<br>
&gt; To me the most scary one is visacoin, specially seeing what happened i=
n canada and other places lately and the general censorship in the west, th=
e supposed war on &quot;misinformation&quot; going on (really a war against=
 truth imo, but whatever) it&#39;s getting really scary. But perhaps someon=
e else can be more scared about a covenant to add demurrage fees to coins o=
r something, I don&#39;t know.<br>
&gt; <a href=3D"https://bitcointalk.org/index.php?topic=3D278122" rel=3D"no=
referrer" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D27812=
2</a><br>
<br>
This requires *recursive* covenants.<br>
<br>
At the time the post was made, no distinction was seen between recursive an=
d non-recursive covenants, which is why the post points out that covenants =
suck.<br>
The idea then was that anything powerful enough to provide covenants would =
also be powerful enough to provide *recursive* covenants, so there was no d=
istinction made between recursive and non-recursive covenants (the latter w=
as thought to be impossible).<br>
<br>
However, `OP_CTV` turns out to enable sort-of covenants, but by constructio=
n *cannot* provide recursion.<br>
It is just barely powerful enough to make a covenant, but not powerful enou=
gh to make *recursive* covenants.<br>
<br>
That is why today we distinguish between recursive and non-recursive covena=
nt opcodes, because we now have opcode designs that provides non-recursive =
covenants (when previously it was thought all covenant opcodes would provid=
e recursion).<br>
<br>
`visacoin` can only work as a recursive covenant, thus it is not possible t=
o use `OP_CTV` to implement `visacoin`, regardless of your political views.=
<br>
<br>
(I was also misinformed in the past and ignored `OP_CTV` since I thought th=
at, like all the other covenant opcodes, it would enable recursive covenant=
s.)<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<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>

--000000000000987bfd05de95cbb5--