From: Erik Aronesty <earonesty@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks
Date: Sat, 30 Nov 2024 09:19:08 -0800 (PST) [thread overview]
Message-ID: <65f9c15a-c2cb-4831-a3dd-00bbbfb465e8n@googlegroups.com> (raw)
In-Reply-To: <30440182-3d70-48c5-a01d-fad3c1e8048en@googlegroups.com>
[-- 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 --]
next prev parent reply other threads:[~2024-11-30 17:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-27 3:05 [bitcoindev] " jeremy
2024-11-30 17:19 ` Erik Aronesty [this message]
2024-11-30 18:29 ` [bitcoindev] " jeremy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65f9c15a-c2cb-4831-a3dd-00bbbfb465e8n@googlegroups.com \
--to=earonesty@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox