Hi all,
Since there's recently been a lot more interest in discussing covenants and alternative covenant proposals because of CTV, I figured I'd bring up my own proposed covenant opcode again while the urge is still fresh.
To be clear upfront, this opcode has a spec, but nothing else. No tests. No implementation. No signet. No tooling. While this is a serious proposal that I think has a lot of benefits over any other covenant opcode proposal, I am not suggesting that this should supplant CTV. I also don't have any plans to work on an implementation of OP_CONSTRAINDESTINATION, and I certainly wouldn't without more interest and an equal partner on a project like this. I think CTV is a quite useful opcode that is simple and incremental. OP_CD on the other hand is significantly more powerful, which would be likely to lead to even more contention than what CTV has had.
To the opcode itself, there is already plenty of exposition about it in the spec:
So I wanted to discuss it from the perspective of what it enables, pros and cons, and key considerations:
OP_CONSTRAINDESTINATION alone
- Like OP_CTV
- Is fully enumerated (not open ended)
- Unlike OP_CTV
- Enables infinitely recursive covenants
- Does not and cannot prevent malleability on its own
The wallet vaults that
can be created using this are more flexible than ones that can be created with OP_CTV:
- Spends from a wallet vault can spend arbitrary amounts, and send the rest back to a change address, just like a normal transaction.
- Arbitrary amounts of coins can be sent directly to any of the addresses involved in the wallet vault without any risk of loss of funds.
- Anchor outputs are not (necessarily) necessary for fee bumping. A user can have the option of creating a transaction that includes other inputs that can contribute to the fee. Those inputs can also send to other outputs, allowing one to basically attach an anchor output at transaction-creation-time if they think they want it for CPFP fee bumping.
One less-than-ideal property shared with CTV wallet vaults:
- If the hot wallet / intermediate wallet key is stolen, the attacker can steal funds after the owner initiates a normal spend.
The opcode requires some mechanism for fee limiting:
- As currently specified, an attacker who gets access to the hot key can fee-grief the owner of the vault by spending all the coins as fees. The proposed solution to this is to add an addition opcode to limit the fees, called OP_LIMITFEECONTRIBUTION. Another solution would be to require 100% of the output values go to the destinations passed to OP_CONSTRAINDESTINATION, and rely on CPFP on an anchor output to pay the fees, which seems less than ideal. A third solution would be to include sponsor transactions alongside the opcode and rely on those instead of CPFP. While I think sponsor transactions would be very useful, always relying on an external wallet to pay the fees is IMO not super great since it allows for inconvenient scenarios if all your money is in this secure vault, in which case you simply wouldn't be able to get it out without either first acquiring more bitcoin in a hotter wallet, or doing a full recovery transaction with all your wallet vault keys.
The downsides compared to CTV:
- Increased implementation complexity and complexity of the possibility space. The opcode's main purpose of ensuring that only certain addresses are sent to might be simpler than CTV, but the aspect of counting output values pushes it into more complex territory. And when you consider the solutions to fee-griefing, that adds additional implementation and possibility-space complexity (depending on how its done).
- txid malleability
OP_CONSTRAINDESTINATION + OP_PUSHOUTPUTSTACK
OP_PUSHOUTPUTSTACK is an opcode that allows a script to dynamically add local state to an output being created.
- Unlike OP_CTV
- Also enables infinitely recursive covenants and does not prevent malleability.
- Can be open ended (not fully enumerated)
- Can produce dynamic state.
The wallet vaults that can be created with this combination of opcodes is a bit better than ones with just OP_CD on its own:
- Even if the hot wallet key is stolen, the attacker cannot steal funds without compromising all the seeds that make up the wallet vault.
However, the complexity is substantially higher:
- Being able to push dynamic state onto transactions substantially increases the possibility space of covenant chains. There may be significant consequences of this that no one has thought of yet.
Summary
These opcodes would allow the creation of wallet vaults that could be intuitively used in almost the same way that a standard wallet can be used, including mixing in arbitrary inputs and outputs (including ones you don't own). With
one more opcode, funds could be sent directly out of a wallet vault in a single transaction (whereas most wallet vaults require two transactions to send money out to an arbitrary destination).
The opcodes are significantly more complex and powerful than OP_CTV, and also substantially less developed. However, I think they demonstrate a number of important considerations for covenants in the context of wallet vaults. Please feel free to respond or ask questions here or as a github issue.
I think wallet vaults in particular are a very important mechanism to enable much more secure self-custody setups without sacrificing so much usability as normal multisig wallets require. Wallet vaults could enable significantly faster growth in the rate of bitcoin holders who self-custody. CTV is the only opcode that is ready, and no other opcode is even being developed, let alone close to being ready. I don't see APO as a good practical covenant mechanism as currently defined. Any "next" covenant opcode would likely be 4-6 years out. I believe centralized custody is a huge problem in the bitcoin ecosystem, so I think making it easier for people to securely self-custody their bitcoins is an incredibly important area of development. I believe even *if* some other covenant opcode makes CTV completely obsolete (which it isn't at all clear to me is a likely scenario), a 4-6 year head start on better self-custody mechanisms could go a long way to saving a lot of people who need bitcoin a lot of pain (from both custodial shenanigans and self-custody mishaps).
Cheers,
BT