On Sun, Jul 04, 2021 at 09:02:25PM -0400, Russell O'Connor via bitcoin-dev wrote: > Bear in mind that when people are talking about enabling covenants, we are > talking about whether OP_CAT should be allowed or not.
In some sense multisig *alone* enables recursive covenants: a government that wants to enforce KYC can require that funds be deposited into a multisig of "2 <recipient> <gov_key> 2 CHECKMULTISIG", and that "recipient" has gone through KYC. Once deposited to such an address, the gov can refus to sign with gov_key unless the funds are being spent to a new address that follows the same rules. (That's also more efficient than an explicit covenant since it's all off-chain -- recipient/gov_key can jointly sign via taproot/MuSig at that point, so that full nodes are only validating a single pubkey and signature per spend, rather than having to do analysis of whatever the underlying covenant is supposed to be [0]) This is essentially what Liquid already does -- it locks bitcoins into a multisig and enforces an "off-chain" covenant that those bitcoins can only be redeemed after some valid set of signatures are entered into the Liquid blockchain. Likewise for the various BTC-on-Ethereum tokens. To some extent, likewise for coins held in exchanges/custodial wallets where funds can be transferred between customers off-chain. You can "escape" from that recursive covenant by having the government (or Liquid functionaries, or exchange admins) change their signing policy of course; but you could equally escape any consensus-enforced covenant by having a hard fork to stop doing consensus-enforcement (cf ETH Classic?). To me, that looks more like a difference of procedure and difficulty, rather than a fundamental difference in kind. Cheers, aj [0] https://twitter.com/pwuille/status/1411533549224693762 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
