A Last Resort: Un'FE'd Covenants For Bitcoin

Jeremy Rubin released a proposal two weeks ago titled Un’FE’d Covenants (FE = Functional Encryption). Given the ongoing debate over covenant proposals for Bitcoin the last year or two, his proposal marks a new practical option. All covenant proposals so far require a soft fork (actual opcodes), the development and implementation of unproven cryptography (Functional Encryption), or an absurdly high monetary cost to use (ColliderScript).

Jeremy’s proposal requires no softforks, and does not impose a burdensome and impractical cost on users to utilize. The trade off for that capability is a radically different security model. By using a system of oracles, and BitVM based bonds capable of slashing, covenants can be emulated on Bitcoin right now.

The Oracles

The first part of the scheme is obviously the oracles that enforce different covenant conditions. This is a relatively straightforward set up, and the first building block necessary for Jeremy’s proposal. The oracle has custody of the funds in this scheme, and is entrusted with the enforcement of the covenant conditions. You want the oracle to not have to locally keep track of the covenant conditions being enforced for each coin it custodies. This introduces state risk where if the oracles database is corrupted or lost it has no idea how to handle honest enforcement for everyone’s coins. In order to get around this problem, Jeremy makes use of Taproot.

Schnorr based keys can be “tweaked” by using the hash of data to modify a public key. This enables the tweaking of the corresponding private key to be able to sign for the modified key, as well as prove that whatever data was used to tweak the public key is committed to by that key. Having the oracle generate a key, and then the user tweaking that key with their covenant program allows a commitment to what the oracle is supposed to enforce while keeping the burden of storing that information on the user.

Oracles can also be federated in order to minimize the trust required in a single party to enforce things. From here, users can simply load the resulting address, and whenever they want to enforce the condition, approach the oracle(s) with the spending transaction, the oracle program, and the witness data necessary to prove that the transaction given to the oracle meets the conditions of the covenant. If the transaction is valid according to the covenant rules, the oracle signs it.

For any simple covenant where the outcomes are known ahead of time, such as CHECKTEMPLATEVERIFY (CTV), users can immediately have the oracle pre-sign the transactions enforcing the covenant and simply delay using them until necessary.

An important scenario to consider requiring extra functionality is state based covenants, such as rollups, that progress regularly and have an actual state (the current balance of users) to keep track of. In the case of such covenants, the transactions the oracle signs must commit to the current state of the covenant using OP_RETURN so that the oracle can efficiently verify each transaction updating the rollup or other system without having to download witness data for the entire history. This is to keep the oracle from having to store state locally themselves, which as noted above creates risks.

In the long term the data requirements of oracles can be optimized by using zero knowledge proofs, so that the oracle can simply verify a proof that the transaction they are being asked to sign follows the rules of the covenant without having to verify the raw witness data for larger more complex covenants. Again though, in the case of systems like rollups, care must be taken in designing them to guarantee that data required to exit the system is made available to users so they have it in their possession if they need to contact the oracle directly to reclaim their funds.

The BitVM Bond

So far the scheme is entirely trusted. You are essentially just giving someone else your money and hoping they can be trusted to enforce the conditions of arbitrary covenants. By modifying the scheme above slightly, this can be secured with a crypto-economic incentive rather than pure trust.

Above it was described how OP_RETURN is required to be used to track state for stateful covenants. OP_RETURN can also be used to publish the witness data of any covenant transactions to prove the conditions were correctly fulfilled.

A BitVM circuit can be constructed to verify whether a transaction signed by the oracle successfully matches the conditions of the covenant it is enforcing. Remember that the key itself that is generated and funds sent to commits to the conditions of any covenant being enforced. Meaning that data, as well as a transaction being spent from the address, can be fed into a BitVM instance.

Oracles can then be required to post a collateral bond with a BitVM operator (who must also post a bond for the Oracle to claim if they are falsely accused). This way, as long as the bond value is greater than the value secured in covenants by an oracle, the system can be securely used. There would be no way for an oracle to violate the conditions of a covenant they are enforcing without losing money in aggregate.

Trade Offs

There are clear trade offs here that are materially worse than simply implementing covenants in consensus rules. Firstly, the oracle must be online and reachable in order to make use of oracle enforced covenants. With the exception of pre-signed covenants such as CTV, if the oracle is offline when users need to enforce a covenant, they can’t. The oracle must be present to sign.

Secondly, the liquidity requirements for oracle bonds can become massive if the system was ever widely adopted. This makes it unbelievably inefficient compared to native implementation of covenant opcodes at the consensus level.

Lastly, the extra data required to be posted on-chain in order for the BitVM bond scheme to work is much less efficient with use of blockspace than native covenant implementations.

Overall, the proposal is nowhere near as efficient and secure as native covenants. On the other hand, if we do wind up in the worst case scenario of pre-mature ossification, this is a very workable way to shoehorn covenants into Bitcoin without depending on unproven cryptography or completely impractical costs imposed on end users.

Jeremy has given us a worst case scenario option to expand the design space of what can be built on Bitcoin.