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 >