Jeremy Rubin published a proposal titled Un’FE’d covenants two weeks ago (FE = functional encryption). In light of the current debate on Bitcoin’s covenant proposals over the last two years, Rubin’s proposal represents a more practical alternative. The only covenant proposal that has been made so far requires a “soft fork” (actual opcodes), to develop and implement unproven encryption (Functional Encryption), as well as an outrageously expensive cost of use (ColliderScript).
Jeremy’s proposal does not call for softforks. It also doesn’t impose a heavy and unpractical burden on users. In exchange for this capability, a new security model is required. Covenants are now possible on Bitcoin by using BitVM bonds that can be slashed.
The Oracles
Oracles are the first element of this scheme. They enforce the different covenant requirements. The first part of Jeremy’s plan is based on a fairly simple set-up. In this scheme, the oracle is in charge of all funds and is responsible for the enforced covenant conditions. Oracles should be able to track the conditions of covenants for every coin they hold. It introduces a state risk, where the oracle’s database can be corrupted and lost. The oracle will not know how to enforce honest laws for all coins. Jeremy uses Taproot to solve this issue.
The keys that are based on the Schnorr system can also be “tweaked” The hashing of the data is used to modify the public key. The tweaking private key can then sign the new key and prove the data used for tweaking the public key. The oracle can generate the key and the user will tweak it with the covenant program. This allows the user to commit to the information that the oracle should enforce, while still keeping their burden to store that data on them.
It is possible to federate Oracles to lessen the trust needed in any one entity to enforce certain things. Users can then load this address and, whenever they wish to enforce the condition of the covenant, contact the oracles with the spent transaction, oracle software, and witness data. The oracle will sign the transaction if it is in compliance with the rules of the covenant.
Users can pre-sign transactions enforcing covenants for simple covenants where outcomes are already known, like CHECKTEMPLATEVERIFY.
State-based covenants (such as rollups) that are regularly updated and maintain a current state of balance for users is a scenario worth considering. When signing such covenants the Oracle must use OP_RETURN to commit to its current state. The oracle will then be able to verify the transaction without downloading witness data. It is done to prevent the oracle storing state locally, which can be risky.
Oracle data can be minimized by using zero-knowledge proofs. The oracle will only need to check the proof of a transaction that follows the rules in the covenant and not the raw data of witnesses for more complicated covenants. When designing systems such as rollups it is important to ensure that all data necessary to leave the system can be made accessible to the users.
BitVM Bond
The scheme has been a complete success so far. In essence, you are giving your money to someone else and trusting them to enforce the terms of arbitrarily imposed covenants. This can be done by modifying the above scheme slightly and using a cryptoeconomic incentive instead of pure trust.
In the above description, we have described how OP_RETURN can be used to track covenants that are stateful. OP_RETURN also allows you to use witness data to validate that the covenant conditions have been met.
BitVM can be used to check if a signed transaction by an oracle matches up with the conditions that it enforces. It is important to remember that the generated key and any funds sent will commit to any conditions that may be enforced. Data, along with a payment being made from the address can also be input into BitVM.
Oracles may be required to provide a guarantee with BitVM (the operator must post an additional bond to cover the Oracle in case they are wrongfully accused). The system is secure as long as it’s bond amount exceeds the covenant value. Oracles cannot violate covenant conditions without losing aggregate money.
Exchange Offs
The tradeoffs are far worse here than simply adopting covenants into consensus rules. Oracle enforced agreements require that the oracle be available online. If the oracle goes offline, users cannot enforce covenants, with the exception of covenants that have been pre-signed, such as CTV. Oracles are required to be present when signing.
If the oracle system is ever adopted widely, then the requirements of liquidity for these bonds could become enormous. The system is utterly inefficient, compared to the native implementation at consensus of covenant opcodes.
The extra data that must be added to the chain in order to make the BitVM Bond scheme work are much more efficient at using blockspace than the native covenant implementations.
The proposal, in general, is not as secure and efficient as native covenants. In the worst-case scenario, where we are forced to ossify Bitcoin too early, the proposal can be a viable way of integrating covenants without relying on cryptography that is unproven or imposing costs which end users cannot afford.
Jeremy gave us a worse case scenario to increase the range of design options that can be created on Bitcoin.
“This article is not financial advice.”
“Always do your own research before making any type of investment.”
“ItsDailyCrypto is not responsible for any activities you perform outside ItsDailyCrypto.”
Source: bitcoinmagazine.com
