Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks

[jeremy]

Esteemed Bitcoin Developers,

Sharing below an approach to implementing Bitcoin covenants without requiring native protocol changes. The approach uses covenant emulators signing servers.

Unlike approaches to date for covenant emulation, the oracle signers put up bonds to BitVM auditors subject to a BITVM style fraud proof, whereby their funds can be stolen if the emulator oracle ever signs a transaction in violation of the covenant rules.

you can find the paper here: https://rubin.io/bitcoin/2024/11/26/unfed-covenants/

Regards,

Jeremy

[Erik Aronesty]

like all other "incentive-driven honesty" proposals, it only works if the value locked in the bonds is greater than thevalue locked in the covenants.   but that's a reasonable restriction for many "l2" use cases, where the purpose of l2 is to enable low-valued "vtxo's"  that allow an emulated self custody of small amounts that would otherwise be too expensive to move on-chain

some analysis of the relationship between the bond lock value and the maximum "incentive-safe"  covenant value, and the fees the oracles are paid vs the loss of liquidy needs to be done in order to drive the incentives home both for would-be oracles and would-be users.

this is unlikely, for example, to be valueable for any vault-ing use case, but should be possible to enable ark2, enigma-network and other protocols designed to falicitate small-value-transactions-at-scale  

[jeremy]

Great point, for the most part I agree with this analysis around difficulty applying this to vaults v.s. things like Ark.

One point I'd make, is that if you set it up such that the signing oracle is getting paid somehow, over time, and people prefer to use the longest running signing oracles, you create a strong incentive to have long running honest bonds since then you forgoe a recurring revenue for a one-time sweep.

Further, given that the covenant creation using my keygen mechanism happens private from the oracle (entirely offline even!), the oracles aren't aware of which utxos they could even possibly do something with until a signature request is made.

Even then (and this part isn't in the paper, but I should add it as an addendum), it'd be possible to either restructure the oracle to be SIGHASH(tx) + ZKP(SIGHASH(tx), E_i(tx)), such that the oracle blind signs the TX without learning details / gaining broadcastability, or to do the signing in a homomorphic computation such that the txs are checked before sent back.

Then, in a single-party vault context:

-  you'd be able to punish any misbehavior

- the oracle themselves wouldn't really be able to outright steal coins

- you'd likely also 2-of-2 with your own key so that you're both enforcing the same ruleset

the only further issue is liveness, which you'd have to handle with a different mechanism (e.g., 5-of-8 "ultra cold" keys + timelock in a tapleaf).