Subject: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

From: Billy Tetrud <[email-masked]>
Date: Tue, 20 Jul 2021 22:56:10 -0700

Hi All,

I have been working on a proposal for an opcode I call
OP_CONSTRAINDESTINATION. The purpose of the opcode is to allow a spend-path
to restrict the destination address that an output's coins can be directed
to. When the destination address is something like a P2SH address, this
allows step-wise covenant scripts (where one script must lead to another).

This involves both specifying particular addresses the output is allowed to
send coins to, as well as constraining the amount of the fee that output is
allowed to contribute to. For example, if you had an output that contains
1000 satoshi, you could specify that a maximum of ~100 sats of that output
go to the miner fee and the other ~900 sats must go to one of a list of
specified addresses (~ meaning approximately, because the fee is specified
relative to recent median fee rates - details in the proposal).

This opcode has a few different applications, but my primary motivation for
creating this opcode is to create more flexible wallet vaults
<https://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-vaults>
.

To compare this opcode to OP_CHECKTEMPLATEVERIFY, wallet vaults that can be
created with OP_CTV must be created in specified chunks: the address is
explicitly tied to a particular utxo sent to it. To retrieve coins from the
vault, the output must be spent by one of a specific set of transactions
(potentially one per spend path). Outputs cannot be arbitrarily combined
into a transaction, and there is no flexibility whatsoever in deciding
options at the time of spending from the vault - all options must be
premeditated and encoded into the address itself when sending money to the
vault. This has some related foot-gun scenarios, where the wallet vault has
addresses that if sent to would generally result in burning those coins,
unless done in a very specific way by the owner of the vault.

By contrast, OP_CD allows a lot more flexibility because it only constrains
the address to be sent to from the vault, but doesn't put additional
constraints on the transaction. This means that outputs can be combined
into a single transaction like you would expect in a normal transaction. It
also means that external users (people who don't own the vault) can safely
send money directly into the vault without coins being burned.

*I have the proposal for this opcode up here:
https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>*.
I'd love to hear what people think about it, what problems it might have
that I've missed, or other issues or suggestions surrounding this. I'd also
appreciate any input that would help me improve the presentation of the
opcode.

Thanks!