path: root/ed/48971c12b8e6a7373c4c49fbec357e5a1ecce3

Return-Path: <jtimon@jtimon.cc>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 915B4C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 11:47:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 6BBF240154
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 11:47:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.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 5yLJRErkYKRD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 11:46:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com
 [IPv6:2607:f8b0:4864:20::112f])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 2CD2940095
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 11:46:57 +0000 (UTC)
Received: by mail-yw1-x112f.google.com with SMTP id
 00721157ae682-2f7d621d1caso52666807b3.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 04:46:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=jtimon-cc.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=vUDiN2Q4tQH9HGvpkLAuzUunTgkYw5tAod3bknNI0OA=;
 b=Kdn3UVPkTAX4KIheurcRbd01sxzj6yz/w3KTSvCSnMPueq1wq3waj61m/dbCC/tHnh
 VfBpOhtQfrV0//ij6xyQFHtnd9Bjx2OB9V/ifW4DGF9mtIYh8FIEe1q38/uJMRuyno2T
 1S3BykM96qBbdR0cFAdntqIzxv0LR9fK+J1Y4sEZ8pxnv6hDoYaKdJ7V4P4EeHpzQZZE
 XK7JDNy4y475PAbB/m5ZfXqwbihv4kS5pAGDHKnP1LFiCWuRKJ5uW77J8xG7Be0z8mNs
 5Xfmpa3YT8SfqyjM2A84QyCeHn//vTpy54xQzoV1WcVdL8fqa9ZEK51hF4F31tHwoga1
 wbeQ==
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=vUDiN2Q4tQH9HGvpkLAuzUunTgkYw5tAod3bknNI0OA=;
 b=CYlULqzv5mTMMjKooT0zqKOh75avREn+IVuXDKqqxO7MuArZwub8fZ0/xDJmVi9ltS
 s1fhNmOugWUXC4SEkQGTxVPnPtA70TSW93PLv2VQ2nI8B5aZ5hATY/hx4PMzGxyK/wes
 nC6juKV5VH1fuMmurlNX7yw2Gh+G5DH0zi+GYzmNlake4p8oHgzlgM/k42HaO+/0qdaX
 mfUgMhSIFNwJexWE0ToeyU6OEBqgw4PXX+lYZ3aEExP4VYzWLB+6skGVeVK/ickq4xNI
 rt1ACF4HAHJpDcrg/k1foFnSxmlY9jceUYwUZCrge1aQgzCUk9XxdYTEW8v51MrOq8fx
 QMYg==
X-Gm-Message-State: AOAM5335bYBMl+GMvtQHsXuI23FkqvURZuifCc7BQB+ruA3/J86zhnqn
 DiPTt3KyxTfqyJRsaAvdCg2dRaP+nxsEqeCQ1lafPw==
X-Google-Smtp-Source: ABdhPJyCAUW4aFw98nfrA5heaUh3IGzqPMeSlQl1PWsjHZ4YaMt8HAWxuMt+KY44K6N1UkKVHvpbeJvA5zW6bYSEAz8=
X-Received: by 2002:a81:af59:0:b0:2f4:d869:b5df with SMTP id
 x25-20020a81af59000000b002f4d869b5dfmr30550801ywj.367.1652356016963; Thu, 12
 May 2022 04:46:56 -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>
 <CAGpPWDYUTCsSgirR7iNmbUw+cjEqHSymtzH4EtH=BQnZRjvgmQ@mail.gmail.com>
In-Reply-To: <CAGpPWDYUTCsSgirR7iNmbUw+cjEqHSymtzH4EtH=BQnZRjvgmQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Thu, 12 May 2022 13:46:45 +0200
Message-ID: <CABm2gDqVcAAz-Nqwt+SPBZrFyTUN3kizSTYkbuWSkoG0xJtoPQ@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006f162e05decf1d98"
X-Mailman-Approved-At: Thu, 12 May 2022 11:50:00 +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: Thu, 12 May 2022 11:47:00 -0000

--0000000000006f162e05decf1d98
Content-Type: text/plain; charset="UTF-8"

I think something like visacoin could be kind of feasible without recursive
covenants. But as billy points out, I guess they could kind of do it with
multisig too.

I fail to understand why non recursive covenants are called covenants at
all. Probably I'm missing something, but I guess that's another topic.


On Tue, May 10, 2022 at 5:11 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >  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
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>I think something like visacoin could be kind of feas=
ible without recursive covenants. But as billy points out, I guess they cou=
ld kind of do it with multisig too.</div><div><br></div><div>I fail to unde=
rstand why non recursive covenants are called covenants at all. Probably I&=
#39;m missing something, but I guess that&#39;s another topic.</div><div><b=
r></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Tue, May 10, 2022 at 5:11 PM Billy Tetrud via bitcoin-dev &lt;<a=
 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.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);p=
adding-left:1ex"><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>
_______________________________________________<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>

--0000000000006f162e05decf1d98--