Jeremy Rubin released a proposal a couple of weeks ago called Un’FE’d Covenants (FE = Functional Encryption). Given the controversy surrounding Covenant’s proposals for Bitcoin in the past year or two, his proposal represents a new practical option. All treaty proposals so far require a soft fork (the actual opcodes), the development and implementation of unproven cryptography (functional cryptography), or an absurdly high financial cost of use (ColliderScript).
Jeremy’s proposal does not require any soft forks, nor does it impose a cumbersome and unwieldy cost on users to take advantage of it. The trade-off for this capability is a radically different security model. Using an oracle system, and BitVM-based bonds capable of severing, covenants on Bitcoin can be emulated today.
oracle
The first part of the scheme is clearly the sayings that impose the various terms of the covenant. This is a relatively straightforward setup, and is the first necessary building block of Jeremy’s proposal. The oracle has custody of the funds in this scheme, and is charged with enforcing the terms of the covenant. You want the oracle to not have to keep track of the covenant terms that are implemented locally for each coin you hold. This creates state risk as if the oracle database is corrupted or lost, it has no idea how to handle honest execution of the coins for everyone. To overcome this problem, Jeremy uses Taproot.
Schnorr-based keys can be “modified” using a data hash to modify a public key. This allows you to modify the corresponding private key so you can sign for the modified key, as well as proving that any data that was used to modify the public key is committed by that key. Having Oracle create a key, and then having the user modify that key using its own covenant program allows for compliance with what Oracle is supposed to do while keeping the burden of storing that information on the user.
Oracles can also be standardized to reduce the trust required in one party to enforce matters. From here, users can simply upload the resulting address, and when they want to fulfill the covenant, they approach the oracle (the oracle) with the spending transaction, the oracle software, and the witness data necessary to prove that the transaction submitted to the oracle satisfies the terms of the covenant. If the transaction is valid according to the rules of the covenant, the oracle signs it.
For any simple covenant where the results are known in advance, such as CHECKTEMPLATEVERIFY (CTV), users can immediately get the oracle to pre-sign the transactions implementing the covenant and simply delay their use until necessary.
One important scenario to consider when requesting additional functionality is state-based charters, such as batch lists, that progress regularly and have an actual state (current balance of users) to track. In the case of such covenants, oracle tokens must adhere to the current state of the covenant using OP_RETURN so that oracle can efficiently verify every transaction that updates aggregate data or any other system without having to download witness data for the entire history. This is to prevent oracles from having to store state locally themselves, which creates risks as mentioned above.
In the long term, oracles’ data requirements could be improved with zero-knowledge proofs, so that oracles can simply verify proof that the transaction they are being asked to sign follows the rules of the covenant without having to verify raw witness data for larger, more complex covenants. Again, in the case of systems such as clusters, care must be taken when designing them to ensure that the data required to exit the system is available to users so that they have them if they need to contact Oracle directly to regain their rights. funds.
BitVM Bonds
So far this scheme is quite reliable. You are essentially giving your money to someone else and hoping that they will be trusted to carry out the terms of arbitrary covenants. By slightly modifying the above scheme, this can be secured through a cryptographic economic incentive rather than pure trust.
It was described above how to use OP_RETURN to track the state of stateful covenants. OP_RETURN can also be used to publish witness data for any undertaking transactions to prove that conditions have been properly met.
A BitVM circuit can be created to check whether a transaction signed by an oracle successfully complies with the terms of the covenant it is executing. Remember that the key itself that is generated and the funds sent to it are bound by the terms of any covenant executed. This means that data, as well as the transaction being spent from the address, can be fed into the BitVM instance.
Oracles can then be required to post a surety bond with the BitVM operator (who must also post a bond to Oracle for the claim if they are falsely accused). In this way, as long as the value of the bond is greater than the value guaranteed in the covenants by the oracle, the system can be used safely. There would be no way for the oracle to violate the terms of the covenant they are executing without losing money overall.
Business deals
There are clear trade-offs here that are materially worse than simply implementing covenants in consensus rules. First, Oracle must be online and accessible in order to take advantage of Oracle-enforced conventions. With the exception of pre-signed charters like CTV, if Oracle is offline when users need to execute a charter, they won’t be able to. The oracle must be present to sign.
Second, the liquidity requirements for Oracle Bonds could become huge if the system is widely adopted. This makes it incredibly inefficient compared to the native implementation of covenant opcodes at the consensus level.
Finally, the additional data required to be published on-chain for the BitVM bond system to work is much less efficient when using block space than with native covenant implementations.
Overall, the proposal is nowhere near as efficient and safe as local charters. On the other hand, if we end up in the worst-case scenario of ossification before maturity, this is a very practical way to introduce conventions into Bitcoin without relying 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 for what can be built on Bitcoin.
Comments are closed, but trackbacks and pingbacks are open.