NEWSLETTER
Jeremy Rubin published a proposal two weeks ago titled Un'FE'd Covenants (FE = Functional Encryption). Given the ongoing debate over bitcoin pact proposals over the past two years, his proposal marks a practical new option. All pact proposals so far require either a soft fork (real opcodes), the development and implementation of untested cryptography (Functional Encryption), or an absurdly high monetary cost to use (ColliderScript).
Jeremy's proposal does not require soft forks and does not impose an burdensome and impractical cost for users to use it. The trade-off for that capability is a radically different security model. By using a BitVM-based oracle system and bonds capable of clipping, conventions can be emulated in bitcoin right now.
The Oracles
The first part of the scheme is obviously the oracles that impose different conditions of the covenant. This is a relatively simple setup and the first element needed for Jeremy's proposal. The oracle has custody of the funds of this plan and is entrusted with the implementation of the conditions of the pact. He wants the oracle to not have to keep track locally of the pact conditions that apply for each coin it custody. This introduces a state risk where if Oracles database gets corrupted or lost, you have no idea how to handle the honest application of everyone's coins. To solve this problem, Jeremy uses Taproot.
Schnorr-based keys can be “modified” using data hashing to modify a public key. This allows you to modify the corresponding private key so that you can sign with the modified key, as well as demonstrate that any data that was used to modify the public key is committed to that key. Having Oracle generate a key and then having the user modify that key with their convention program allows for a compromise on what Oracle is supposed to enforce while keeping the burden of storing that information on the user.
Oracles can also be federated to minimize the trust required in a single party to enforce things. From here, users can simply upload the resulting address and, when they want to enforce the condition, approach the oracle with the spending transaction, the oracle program, and the witness data needed to prove that the transaction given to the oracle meets the conditions. of the pact. If the transaction is valid according to the rules of the pact, the oracle signs it.
For any simple convention where the results are known in advance, such as CHECKTEMPLATEVERIFY (CTV), users can have Oracle immediately presign transactions that enforce the convention and simply delay using it until needed.
An important scenario to consider that requires additional functionality is state-based agreements, such as rollups, that progress regularly and have an actual state (the current user balance) to track. In the case of such agreements, the transactions that Oracle signs must be committed to the current state of the agreement using OP_RETURN so that Oracle can efficiently verify each transaction by updating the summary or other system without having to download witness data for the entire history. This is to prevent Oracle from having to store state locally, which, as noted above, creates risks.
In the long term, oracles' data requirements can be optimized by using zero-knowledge proofs, so that the oracle can simply verify a proof that the transaction they are asked to sign follows the rules of the pact without having have to verify the raw data of the witnesses. for larger and more complex agreements. However, again, for systems such as rollups, care must be taken when designing them to ensure that the data needed to exit the system is available to users so that they have it in their possession if they need to communicate directly. with the oracle to claim your account. funds.
The BitVM Link
So far, there is full confidence in the plan. Basically, you're just giving your money to someone else and hoping that they can be trusted to enforce the terms of arbitrary agreements. By slightly modifying the above scheme, this can be ensured with a cryptoeconomic incentive rather than pure trust.
Above we described how OP_RETURN is required to be used to track the status of stateful conventions. OP_RETURN can also be used to post witness data for any covenant transaction to demonstrate that the conditions were correctly met.
A BitVM circuit can be built to verify whether a transaction signed by the oracle successfully matches the conditions of the convention it is enforcing. Please remember that the key itself that is generated and the funds sent are bound by the terms of any agreement that applies. Which means that data, as well as a transaction that is made from the address, can be entered into a BitVM instance.
Oracles can then be required to post a bond with a BitVM operator (who must also post a bond for Oracle to claim if falsely accused). In this way, as long as the value of the bond is greater than the value guaranteed in the pacts by an oracle, the system can be used safely. There would be no way for an oracle to violate the conditions of a pact he is enforcing without losing money altogether.
Compensations
There are clear trade-offs here that are materially worse than simply implementing agreements in consensus rules. First, the oracle must be online and accessible in order to use the covenants imposed by the oracle. With the exception of pre-signed conventions like CTV, if the oracle is offline when users need to enforce a convention, they cannot do so. The oracle must be present to sign.
Second, the liquidity requirements for oracle bonds could become enormous if the system were ever widely adopted. This makes it incredibly inefficient compared to the native implementation of consensus-level pact opcodes.
Finally, the additional data that must be published on-chain for the BitVM bonus scheme to work is much less efficient with block space usage than native convention implementations.
In general, the proposal is not as efficient and secure as native pacts. On the other hand, if we end up with the worst-case scenario of premature ossification, this is a very viable way to shoehorn covenants into bitcoin without relying on unproven cryptography or completely impractical costs imposed on end users.
Jeremy has given us the worst-case option to expand the design space of what can be built in bitcoin.
