Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 915B4C002D for ; 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 ; 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 ; 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 ; Thu, 12 May 2022 11:46:57 +0000 (UTC) Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-2f7d621d1caso52666807b3.11 for ; 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: In-Reply-To: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Thu, 12 May 2022 13:46:45 +0200 Message-ID: To: Billy Tetrud , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >>> ) >>> 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 can >>> do this kind of dynamicness, and OP_PUSHOUTPUTSTACK >>> 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
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.

I fail to unde= rstand why non recursive covenants are called covenants at all. Probably I&= #39;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.li= nuxfoundation.org> wrote:
>=C2=A0 So if you don't want to receive restricted coins, just don't genera= te 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 tha= t 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 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's=C2=A0keys in a way = that the government accepts, it doesn't matter whether the recipient ca= n or has generated the address.=C2=A0

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

> This is a reason to op= pose legal tender laws for Bitcoin imo.

I agree.= =C2=A0

On Mon, May 9, 2022 at 10:23 AM Keagan McClelland <keagan.mcclelland= @gmail.com> wrote:
> &g= t; > 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 "misinformation" going on (really a war agai= nst truth imo, but whatever) it'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't know.
>=C2=A0> >=C2=A0https://bitcointalk.org/index.php?topic=3D278122
=

> > This requires *recursive* covenants.

> Actually, for practical use, any walled-garden re= quires *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 re= ceiver generate a script that is "compliant" with the covenant pr= ovisions 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 o= f*. So if you don't want to receive restricted coins, just don'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= 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.

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't actually see how this is a real concern.

<= div>*This requires good wallet tooling and standards but that isn't mat= erially different than wallets experimenting with non-standard recovery pol= icies.

**This is a reason to oppose legal tender l= aws for Bitcoin imo.

Keagan

On Sun, May 8, 20= 22 at 11:32 AM Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxfoun= dation.org> wrote:
>=C2=A0 This requires *recursive* covenants.

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't help = someone implement visacoin because CTV only allows a specific predefined it= eration of transactions, meaning that while "locked" into the cov= enant sequence, the coins can't be used in any way like normal coins - = you can't choose who you pay, the sequence is predetermined.=C2=A0

Even covenants that allow infinite recursion (like OP_= TLUV and OP_CD)= don'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 "only" quadruple the size of your=C2=A0transactions, but = if anyone creates a new address you want to send to, you wouldn'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

=
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 w= ants to make a walled garden where you (the government) could confiscate th= e funds whenever you wanted, you'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.

OP_CHECKOUTPUTVERIFY<= /a>=C2=A0can do this kind of dynamicness, and OP_PUSHOUTPUTSTACK=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'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?

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's signature o= n 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 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'm sure wouldn'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'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 dyn= amicness to an OP_CTV call.=C2=A0


=
On Sat= , May 7, 2022 at 5:40 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.lin= uxfoundation.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 covenan= ts.
> 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 "misinformation" going on (really a war against= truth imo, but whatever) it'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't know.
> https://bitcointalk.org/index.php?topic=3D27812= 2

This requires *recursive* covenants.

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

However, `OP_CTV` turns out to enable sort-of covenants, but by constructio= n *cannot* provide recursion.
It is just barely powerful enough to make a covenant, but not powerful enou= gh to make *recursive* covenants.

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

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

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


Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000006f162e05decf1d98--