path: root/aa/9bce0f7aad44f2eb1f231ad17fa265801cb59f

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 32CBCC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  8 May 2022 16:33:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 0BE4060ED7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  8 May 2022 16:33:05 +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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id C_o9VVVTX7o6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  8 May 2022 16:33:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com
 [IPv6:2607:f8b0:4864:20::62b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 9040360EC0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  8 May 2022 16:33:03 +0000 (UTC)
Received: by mail-pl1-x62b.google.com with SMTP id s14so11830305plk.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 08 May 2022 09:33:03 -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=m8NzT1W+hX9Y72z/jPaw0Yx8Qjeo8J7NgIn1o2nZZvc=;
 b=Mb6ydPvow0EJ+9zm94BwSU84HbMyxx31WiytSwYkOvnZHP60rwQdjVt51rggNlHKc8
 oXvy+kNT582ZSCXhtQqtYk78o//LsdxIO/zVnOkwGvuHZ6nwNR8TgEt3wlWVsQEPCCLL
 jNDBqHxZc6cIiBIfpOxwJq9wLAVWHZOEfE/CU7HwCtJSigKn30Vq3E2p0vAZPfaTbaMo
 inCuAFTgEphGJauPTUQcuImKBPp04jGPaHqWcogGNWo0cjhh0hTdi9TpTqORZo1jDF2s
 fTpTtmcra5BnwEPi3MrgALiAYfOH3pdx0Qs3lMJy/yjJ23oa14JbEdG0fwrQla98z2eG
 4GOQ==
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=m8NzT1W+hX9Y72z/jPaw0Yx8Qjeo8J7NgIn1o2nZZvc=;
 b=IQPZu2sqjXt9K1yL20AhVGMEVBaS7HnxbQqAiWaB1EcgpJlNWg1Lnkzh7pOf7LRgqU
 Atwhi65gTBlaW0EKu5L5CMsjZhcrfsoC9T6SmE5Ce2I9Ga51Yb2bWt09ipyQ594MED4Z
 R+CJ4FFTrUdKiqjOqoie6Q1Vag1vkQ4trjkGVUIFDSdmk75y6xnZhm3cnr7LAPI9DvfU
 qx2DA7+rC6ta1nMKQSc0ZTjtS9ojDy/dMoRsD0V0gpoMGwaGpdxZKEfnZO9FbpydIPzg
 zp2ymbFJS+gynAaeRJwz+pSgAXTWj9TFndWayzXlEmkc5cRqPXpBrSRPOTdFhU20IzdU
 QRBA==
X-Gm-Message-State: AOAM533pPdFpSyzi/O3E+8Owfx8hyovjX36DhOLgEq5E5zbc0OIBYN6e
 KG7mJrOAPHkX9y6RTXi0Ez/yFktkWIrwewSzhX65+gxUqG4=
X-Google-Smtp-Source: ABdhPJzLp1HoNP/5X6jhlRF1M9dZ46ipxfhPa4nYWxRW/x21cDGZX3Pg53sYoLuOjHKrazoJ8tBXdWEsmXzgKHu5emg=
X-Received: by 2002:a17:902:c952:b0:15e:9e3d:8e16 with SMTP id
 i18-20020a170902c95200b0015e9e3d8e16mr12929253pla.51.1652027582617; Sun, 08
 May 2022 09:33:02 -0700 (PDT)
MIME-Version: 1.0
References: <kbrvpw3Y5y3ko3Wf2VtcywN462JjMW6YjqecduPOXwrek2sR9FkWfSv6G2Fph22UTAAbgII88MtOn1AFo223jjryNAz8YNbbQlFRVQo_HMY=@protonmail.com>
 <CABm2gDqxOtrMrTu2Ovx32USJT2T+6DRpexct1-k3zwEEnsDPMA@mail.gmail.com>
 <HfqjtQb_3TfhHaAZzYOcUoMic1iG40qUjqlKpzOZY6PSBW1bXVFtFW4zCHFRUdOoIhrard9ZPslzbrIYO0cM-Oi37mLzeEv6MZiQ7JtulE4=@protonmail.com>
In-Reply-To: <HfqjtQb_3TfhHaAZzYOcUoMic1iG40qUjqlKpzOZY6PSBW1bXVFtFW4zCHFRUdOoIhrard9ZPslzbrIYO0cM-Oi37mLzeEv6MZiQ7JtulE4=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 8 May 2022 11:32:45 -0500
Message-ID: <CAGpPWDZVqas6v9nQtGtgk2mMOw9KQ+=dytBc+fBE6SNL=F3bqQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000389d0c05de82a5bf"
X-Mailman-Approved-At: Sun, 08 May 2022 17:31:49 +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: Sun, 08 May 2022 16:33:05 -0000

--000000000000389d0c05de82a5bf
Content-Type: text/plain; charset="UTF-8"

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

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

<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">OP_CD</a>) don&#39;t automat=
ically allow for practical walled gardens. Recursion definitely allows crea=
ting walled gardens, but those gardens would be impractically static. You c=
ould add millions of potential addresses to send to, which 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 able to. Everyone wo=
uld have to have a single address whitelisted into every government-bitcoin=
 output. If someone lost their key and needs to create a new wallet, sudden=
ly no one would be able to pay them.=C2=A0</div><div><br></div><div>In orde=
r to really build a wallet garden, infinite recursion isn&#39;t really nece=
ssary nor sufficient. You need to be able to dynamically specify destinatio=
n addresses. For example, if you were a government that wants to make a wal=
led garden where you (the government) could confiscate the funds whenever y=
ou wanted, you&#39;d have to have a covenant that allows the end-user to sp=
ecify an arbitrary public key=C2=A0to send money to. The covenant might req=
uire 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=C2=A0arbitrarily=
, while still ensuring that you (the government) could spend the funds no m=
atter where they may have been sent. Even without recursive covenants, you =
could have arbitrarily long chains of these, say 1 million long, where at t=
he end of the chain the user must send your coins back to the government wh=
o can then send them back with another million-long chain of covenants to w=
ork with.</div><div><br></div><div><a href=3D"https://fc16.ifca.ai/bitcoin/=
papers/MES16.pdf">OP_CHECKOUTPUTVERIFY</a>=C2=A0can do this kind of dynamic=
ness, and <a href=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-v=
aults/blob/main/pos/bip-pushoutputstack.md">OP_PUSHOUTPUTSTACK</a>=C2=A0can=
 enable it for things like OP_TLUV and OP_CD. I personally think dynamic co=
venants are a *good* thing,=C2=A0as it enables more secure=C2=A0wallet vaul=
ts, among other things. And I&#39;m not worried about a government creating=
 a in-bitcoin visa-coin. Why? Because they can already do it today. They ha=
ve been able to do it for 9 years already. How?</div><div><br></div><div>Re=
place 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 governm=
ent&#39;s signature on it. The government then only signs if you&#39;re sen=
ding to a wallet they approve of. They might only sign when you&#39;re send=
ing 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 govern=
ment needs to actively sign, which I&#39;m sure wouldn&#39;t be a huge chal=
lenge for the intrepid dictator of the land. You want to add demurage=C2=A0=
fees? Easy, the government just spends the fee out of everyone&#39;s wallet=
s every so often.</div><div><br></div><div>On the other hand, OP_CTV *canno=
t* be used for such a thing. No combination of future opcodes can enable ei=
ther recursion or dynamicness 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:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-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>

--000000000000389d0c05de82a5bf--