path: root/40/3960518e2f3e288fd7f90d7f2f8227d9a177ee

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 83B6DC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:10:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 5ED9E813FE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:10:06 +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 nAm5cV7EvvQO
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:10:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com
 [IPv6:2607:f8b0:4864:20::629])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 979858137C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:10:04 +0000 (UTC)
Received: by mail-pl1-x629.google.com with SMTP id q18so4061702pln.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 08:10:04 -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=1lr9MB5pNiRhOqE7necFvmUTqL4WedOox61hPzVJfwI=;
 b=AhILagtwgxBOFIKA84pCh2qkS/BGmt75N5Gts8Tkr19+gwAdVN+BIFIPkFq3cdRPgh
 JNuB8owIBhUOMh5V/nNutEMU5ArRjkqpQrVE4HhRTLH10+xfk5JFlpwCwCNQVJAHKA47
 BjOzWLWNGEYRtHDT/4nKn+ZGrk9D21RE54nL7tv2dZhtJU9++z4HQJsE5Lq0ZMEKXTDl
 ZNj5FBsGA64Lz5AyYbIOYl6TlZ9Qd5JWa4SSt9DU+eWpuJPafpunk6P5jlKhHYe1IthK
 UPA2s6GpnabH+yaV5RnDzoIGs331RgxVNph4ODr9P1McVZ4bTCfkiZS0MVThv/WOufGY
 H/tg==
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=1lr9MB5pNiRhOqE7necFvmUTqL4WedOox61hPzVJfwI=;
 b=BtHqrTCbq/1gXdcusPJX0f3u6sKGap2jO6rBgVo2OgUW8TBEllfZ1R6lVLpbXuOqme
 hjVwfC3yzgn+xX0vQDJR3Cf3n1kIEE78lyJ6GPwGu1Ffd0sbQdsqFLfSWj6tYN0fBfnB
 CvmVaobq0AGCJGnR/QyGI4TioXsviBYZOEOAYfMKdckZVZ2Y1u6RzjANnsMGI+3YdQhw
 JzB1b6M1WPHyf0N9KEM97POnaCV81TcqymnjauC/mSP66j1UYGC7WLIC2OicxACkvUeu
 IRVjhyp4TSIkyoPBYnRZ7gX4SzId83MlUwWsRZSQ+VHXVZM+rOxUv8oAbfsvTF+BBAog
 uXqw==
X-Gm-Message-State: AOAM5339qZHU5vgwVwisfcVnQU7PYWlVHT8yuB0yE2m+nHVbf7Vg5X/q
 A0tNcI6nVc3VmOfirx3k7qfFbxL5zHnJ+JQtnz8=
X-Google-Smtp-Source: ABdhPJwh89Nqgn+nDK+BGbgAda5KtbeLAXND18WKmk7oImiEU4NealOJDGTWQ9t9mXxy/0MUAoDfIKVYpUmwkLkmAG0=
X-Received: by 2002:a17:90b:1651:b0:1dc:aec3:c17 with SMTP id
 il17-20020a17090b165100b001dcaec30c17mr435411pjb.43.1652195403862; Tue, 10
 May 2022 08:10:03 -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>
 <CALeFGL18ULkGW4UA_5Fod4PVoe_LeF5e97eZdJja-ctf2paLWQ@mail.gmail.com>
In-Reply-To: <CALeFGL18ULkGW4UA_5Fod4PVoe_LeF5e97eZdJja-ctf2paLWQ@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 10 May 2022 10:09:45 -0500
Message-ID: <CAGpPWDYUTCsSgirR7iNmbUw+cjEqHSymtzH4EtH=BQnZRjvgmQ@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000025999205dea9b848"
X-Mailman-Approved-At: Tue, 10 May 2022 15:11:09 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Tue, 10 May 2022 15:10:06 -0000

--00000000000025999205dea9b848
Content-Type: text/plain; charset="UTF-8"

>  So if you don't want to receive restricted coins, just don't generate an
address with those restrictions embedded.

This is an interesting point that I for some reason haven't thought of
before. However...

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

Actually, I think only the second is necessary. For example, if there was a
law that compelled giving a good or service if payment of a publicly
advertised amount was paid, and someone pays to an address that can be
shown is spendable by the merchant's keys in a way that the government
accepts, it doesn't matter whether the recipient can or has generated the
address.

Regardless I do think its still important to note that a government could
do that today using multisig.

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

I agree.

On Mon, May 9, 2022 at 10:23 AM Keagan McClelland <
keagan.mcclelland@gmail.com> wrote:

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

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

<div dir=3D"ltr">&gt;=C2=A0

So if you don&#39;t want to receive restricted coins, just don&#39;t genera=
te an address with those restrictions embedded.<div><br></div><div>This is =
an interesting point that I for some reason haven&#39;t thought of before. =
However...</div><div><br></div><div>&gt; Unless governments can mandate tha=
t you generate these addresses AND force you to accept funds bound by them =
for your services**, I don&#39;t actually see how this is a real concern.</=
div><div><br></div><div>Actually, I think only the second is necessary. For=
 example, if there was a law that compelled giving a good or service if pay=
ment of a publicly advertised amount was paid, and someone pays to an addre=
ss that can be shown is spendable by the merchant&#39;s=C2=A0keys in a way =
that the government accepts, it doesn&#39;t matter whether the recipient ca=
n or has generated the address.=C2=A0</div><div><br></div><div>Regardless I=
 do think its still important to note that a government could do that today=
 using multisig.=C2=A0</div><div><br></div><div>&gt; This is a reason to op=
pose legal tender laws for Bitcoin imo.</div><div><br></div><div>I agree.=
=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"=
gmail_attr">On Mon, May 9, 2022 at 10:23 AM Keagan McClelland &lt;<a href=
=3D"mailto:keagan.mcclelland@gmail.com" target=3D"_blank">keagan.mcclelland=
@gmail.com</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);padding=
-left:1ex"><div dir=3D"ltr"><div><span style=3D"color:rgb(80,0,80)">&gt; &g=
t; &gt; To me the most scary one is visacoin, specially seeing what happene=
d in canada and other places lately and the general censorship in the west,=
 the supposed war on &quot;misinformation&quot; going on (really a war agai=
nst truth imo, but whatever) it&#39;s getting really scary. But perhaps som=
eone else can be more scared about a covenant to add demurrage fees to coin=
s or something, I don&#39;t know.</span><br style=3D"color:rgb(80,0,80)"><s=
pan 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" targe=
t=3D"_blank">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 re=
quires *dynamic* covenants, not recursive covenants.</div><div><br></div><d=
iv>There&#39;s actually also a very straight forward defense for those who =
do not want to receive &quot;tainted&quot; coins. In every covenant design =
I&#39;ve seen to date (including recursive designs) it requires that the re=
ceiver generate a script that is &quot;compliant&quot; with the covenant pr=
ovisions 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 o=
f*. So if you don&#39;t want to receive restricted coins, just don&#39;t ge=
nerate an address with those restrictions embedded. As long as you can spec=
ify the spend conditions upon the receipt of your funds, it really doesn&#3=
9;t matter how others are structuring their own spend conditions. So long a=
s the verification of those conditions can be predictably=C2=A0verified by =
the rest of the network, all risk incurred is quarantined to the receiver o=
f the funds. Worst case scenario is that no one wants to agree to those con=
ditions and 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 be=
tween organizations with incompatible interests (external to a firm), that =
they will want to be completely free to choose their own spend conditions a=
nd will not wish to inherit the conditions of the spender. Correspondingly,=
 any well implemented covenant contract will include provisions for escapin=
g the recursion loop if some sufficiently high bar is met by the administra=
tors 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&#39;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 mat=
erially different than wallets experimenting with non-standard recovery pol=
icies.</div><div><br></div><div>**This is a reason to oppose legal tender l=
aws for Bitcoin imo.</div><div><br></div><div>Keagan</div></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, May 8, 20=
22 at 11:32 AM Billy Tetrud via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoun=
dation.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);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>
</blockquote></div>

--00000000000025999205dea9b848--