Test of timestamp? 
Lightning coins are easily withdrawn to be on-chain without any encumbrance to your coins afterward. I don't see how financial authorities/institutions can restrict that or use lightning to segregate/control coins. I don't see the enforcement mechanism.
Are you suggesting all on-chain transactions can be effectively stopped?. Maybe in the extreme case, but has serious property rights issues and hard to enforce worldwide. Adding a covenants erodes your property rights gradually, until you have only the illusion of control of your property. You effectively will need permission to use your coins, just as you do with a Visa card today.
The more programmability that is added to the L1 protocol, the larger the attack vector. The legacy system will use every tool it can to make Bitcoin submit to its control.
Yes it course we can know if we receive a coin that has a covenant impairment. And I also understand the potential benefits..That is not the concern.
The problem is that covenants will hurt fungibility by creating classes of coins that have or do not have covenants. This can be much easier to enforce than a multisig scheme. Ultimately exchanges, custodian's and merchants can be forced to only accept coin with approved covenants.. while the captured institutions will have he power to add approved conenants. I can foresee price fragmentation between coins with or without various convenient impairments. Ultimately you will have no choice but to use the approved coins for nearly transactions.
If Bitcoin loses it's special qualities as an uncensorable bearer asset, it i
Will be no different that USDC, JP Morgan coin, or a CBDC, and therefore no more valuable.
there’s a lot of talk about “covenants” but not a lot of understanding what that entails. lets do a little dive into how i think about the opcode proposals and how they relate to “enabling covenants on bitcoin”
what is a covenant?
great question. a covenant is the ability to specify what the transaction that spends your bitcoin must look like. for example, you could say “the transaction that spends this bitcoin must pay 500k sats to this address” or “the transaction that spends this bitcoin must have a locktime set to block 880,000”
in order to make these kinds of assertions in bitcoin transactions, you need the ability to find out what information is in the transaction that is spending an output. this information needs to be accessible when the script is running.
bitcoin script is a limited programming language that you use to write locks for bitcoin. one of the limitations is what data you have access to while the program is running.
so in order to write more “expressive” bitcoin scripts, which can say “one output must be to my address and pay 500k sats”, for example, you need to be able to look at the outputs on a transaction.
this ability to look at the info on a transaction is called “introspection”. being able to introspect a transaction is a big missing piece in bitcoin. adding introspection enables you to write covenants.
so how do you get introspection in bitcoin script?
you have to add a new opcode for it. in fact, we’ve added two opcodes to bitcoin that enable introspection already: op-checklocktimeverify (op-cltv) and op-checksequenceverify (op-csv)
these look at the locktime/sequence of a transaction and require a certain value to be set in order to be valid. they were added in order to enable lightning, which uses both op-cltv and op-csv to make “primitive” covenants. these were added to enable LN, to help scale bitcoin.
today you could write a bitcoin script that asserts “the transaction that spends this bitcoin must have a locktime set to block 880,000”. you’d use op-cltv to make that script, and any coins locked to that script wouldn’t be spendable til block 880,000.
there’s no way to look at the output fields in a transaction though. you cant write a script that requires funds to go somewhere, you’d have to use presigned txs (like how lightning does) to make that kind of assertion.
ok so the goal of introspection is to let you look at what information is in a transaction that’s spending a bitcoin output. we can do this already with op-cltv and op-csv. but this is limited just to timelocks, and doesn’t let us make assertions about outputs, or other inputs.
in the next post i’ll talk about how the current opcode proposals (op-ctv, op-txhash, op-tx, op-cat) work and how they enable more broad tx introspection !
if you found this interesting, check out nostr:npub1vmpf90hq56wzyxht6teg3llpa74rzcepw9suj5unxl3tph24zd4qgtxhm7 and our classes on bitcoin transactions!
Covenants have the potential to be extremely dangerous to Bitcoin censorship resistance and fungibility. It allows the enforcement of blacklists, whitelists and the ability to freeze funds and enforce KYC rules.
For instance, a regulated exchange could be required to reject a TX that doesn't have a required covenant attached. And it might attach a covenant the to all withdrawals. Wallets could be legally required to check for certain covenants
The risks outweigh the potential benefits
I wish we counted votes like this in the US. Little room for fraud