Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 83B6DC002D for ; 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 ; 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 ; 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 ; Tue, 10 May 2022 15:10:04 +0000 (UTC) Received: by mail-pl1-x629.google.com with SMTP id q18so4061702pln.12 for ; 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: In-Reply-To: From: Billy Tetrud Date: Tue, 10 May 2022 10:09:45 -0500 Message-ID: To: Keagan McClelland Content-Type: multipart/alternative; boundary="00000000000025999205dea9b848" X-Mailman-Approved-At: Tue, 10 May 2022 15:11:09 +0000 Cc: Bitcoin Protocol Discussion 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: 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 >> ) >> 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 >> > --00000000000025999205dea9b848 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=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
--00000000000025999205dea9b848--