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