<div dir="ltr"><div>Hi All,</div><div><br></div>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).<br><br>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).<br><br>This opcode has a few different applications, but my primary motivation for creating this opcode is to create more flexible <a href="https://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-vaults">wallet vaults</a>.<br><br>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.<div><br>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.<br><br><b>I have the proposal for this opcode up here: <a href="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</a></b>. 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.<br><br>Thanks!<br></div></div>