* [bitcoindev] Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks
@ 2024-11-27 3:05 jeremy
2024-11-30 17:19 ` [bitcoindev] " Erik Aronesty
0 siblings, 1 reply; 3+ messages in thread
From: jeremy @ 2024-11-27 3:05 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 928 bytes --]
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
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/30440182-3d70-48c5-a01d-fad3c1e8048en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 1461 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* [bitcoindev] Re: Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks
2024-11-27 3:05 [bitcoindev] Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks jeremy
@ 2024-11-30 17:19 ` Erik Aronesty
2024-11-30 18:29 ` jeremy
0 siblings, 1 reply; 3+ messages in thread
From: Erik Aronesty @ 2024-11-30 17:19 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 1904 bytes --]
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
On Tuesday, November 26, 2024 at 7:21:03 PM UTC-8 jeremy wrote:
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
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/65f9c15a-c2cb-4831-a3dd-00bbbfb465e8n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2621 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* [bitcoindev] Re: Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks
2024-11-30 17:19 ` [bitcoindev] " Erik Aronesty
@ 2024-11-30 18:29 ` jeremy
0 siblings, 0 replies; 3+ messages in thread
From: jeremy @ 2024-11-30 18:29 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3529 bytes --]
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).
On Saturday, November 30, 2024 at 12:21:38 PM UTC-5 Erik Aronesty wrote:
> 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
>
> On Tuesday, November 26, 2024 at 7:21:03 PM UTC-8 jeremy wrote:
>
> 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
>
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/cadcc323-3286-49d2-a77f-c139dd771b04n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4730 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-11-30 18:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-11-27 3:05 [bitcoindev] Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks jeremy
2024-11-30 17:19 ` [bitcoindev] " Erik Aronesty
2024-11-30 18:29 ` jeremy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox