There's a bunch of applications for BIP 119 on
Some that are listed (and I understand, there's some technical stuff on there too which I can't explain fully):
  • Protect your coins by enforcing for example a list of addresses you can send to from cold storage
  • Help Lightning increase the HTLC limit by embedding HTLCs in a OP_CTV "tree" of HTLCs, that can gradually be unwrapped on-chain. Right now the maximum outstanding HTLCs any Lightning channel can have at once is 483 (any transaction with more than these can't be relayed). Having more HTLCs at any given time could allow LN nodes to process more transactions per second as well.
  • Batch channels for Lightning. As far as I can tell this uses OP CTV to "embed" multiple channels into a single output. I guess this could enable channel factories perhaps - not sure about this. But it could also make channels have a smaller footprint on-chain. I wonder if you could open multiple channels for different people using a single UTXO at once, that'd lead to a smaller on-chain footprint
  • There are a bunch of other examples there too. For example a chain could first put all withdrawals into a single OP_CTV tree when blockspace demand is high, and gradually process those withdrawals later on
The biggest alarm I've seen raised with OP_CTV is that it could lead to censorship, for example the government requiring that all your addresses have OP_CTV scripts that would only allow you to send to approved/KYC addresses or not to blacklisted addresses. But such censorship could be possible through other means too. For example, the government could require that each address have a tapleaf script that allows the government to seize your funds.
Blacklist/whitelist through ctv isn’t practical. Other solutions (like AMP) are. This one is bunk
What is AMP?
its a service from Blockstream aimed at regulated assets on Liquid.
The usecase is something like: you want to issue a tokenized security on Liquid. Because of regulatory requirements, only registered investors are allowed to trade that token, but you want it to be freely transferrable between anyone who is "allowed".
So the way that it works is people use an AMP-enabled wallet. That wallet gives them a unique ID. The register that ID with whatever company who then puts them on a whitelist. When you receive an asset into you AMP-enabled wallet, it goes into a 2/2 multisig where you hold one key and the AMP server holds the other key. When you want to send the asset to someone else, your wallet signs and then the AMP server signs but ONLY if the destination address is on the whitelist.
The whitelist can be updated anytime without needing to re-roll all the UTXOs (which is something you'd have to do with a covenant), and is cheap and easy to manage.
It's literally a service to do whitelist-only token transfers for something that's bitcoin-compatible.
The "covenants will create whitelists/blacklists for bitcoin" thing is fud. it already exists.
Shorthand for Asian massage parlor