Delivery-date: Sat, 30 Nov 2024 09:21:45 -0800
Sender: bitcoindev@googlegroups.com
Date: Sat, 30 Nov 2024 09:19:08 -0800 (PST)
From: Erik Aronesty <earonesty@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <65f9c15a-c2cb-4831-a3dd-00bbbfb465e8n@googlegroups.com>
In-Reply-To: <30440182-3d70-48c5-a01d-fad3c1e8048en@googlegroups.com>
References: <30440182-3d70-48c5-a01d-fad3c1e8048en@googlegroups.com>
Subject: =?UTF-8?Q?=5Bbitcoindev=5D_Re=3A_Un=2DFE=E2=80=99d_Covenants=3A_Char=2Dting_a_ne?=
	=?UTF-8?Q?w_path_to_Emulated_Covenants_via_BitVM_Integrity_Checks?=
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_293622_781025926.1732987148316"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_293622_781025926.1732987148316
Content-Type: multipart/alternative; 
	boundary="----=_Part_293623_1027010153.1732987148316"

------=_Part_293623_1027010153.1732987148316
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

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

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

On Tuesday, November 26, 2024 at 7:21:03=E2=80=AFPM UTC-8 jeremy wrote:

Esteemed Bitcoin Developers,

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

Unlike approaches to date for covenant emulation, the oracle signers put up=
=20
bonds to BitVM auditors subject to a BITVM style fraud proof, whereby their=
=20
funds can be stolen if the emulator oracle ever signs a transaction in=20
violation of the covenant rules.
you can find the paper here:=20
https://rubin.io/bitcoin/2024/11/26/unfed-covenants/

Regards,

Jeremy

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
65f9c15a-c2cb-4831-a3dd-00bbbfb465e8n%40googlegroups.com.

------=_Part_293623_1027010153.1732987148316
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

like all other "incentive-driven honesty" proposals, it only works if the v=
alue locked in the bonds is greater than thevalue locked in the covenants.=
=C2=A0 =C2=A0but that's a reasonable restriction for many "l2" use cases, w=
here the purpose of l2 is to enable low-valued "vtxo's"=C2=A0 that allow an=
 emulated self custody of small amounts that would otherwise be too expensi=
ve to move on-chain<div><br />some analysis of the relationship between the=
 bond lock value and the maximum "incentive-safe"=C2=A0 covenant value, and=
 the fees the oracles are paid vs the loss of liquidy needs to be done in o=
rder to drive the incentives home both for would-be oracles and would-be us=
ers.</div><div><br /></div><div>this is unlikely, for example, to be valuea=
ble for any vault-ing use case, but should be possible to enable ark2, enig=
ma-network and other protocols designed to falicitate small-value-transacti=
ons-at-scale=C2=A0=C2=A0<br /><br /></div><div><div dir=3D"auto">On Tuesday=
, November 26, 2024 at 7:21:03=E2=80=AFPM UTC-8 jeremy wrote:<br /></div><b=
lockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(20=
4, 204, 204); padding-left: 1ex;"><div><span style=3D"color: rgb(0, 0, 0);"=
>Esteemed Bitcoin Developers,</span><br /></div><div><p style=3D"color: rgb=
(0, 0, 0);">Sharing below an approach to implementing Bitcoin covenants wit=
hout requiring native protocol changes. The approach uses covenant emulator=
s signing servers.</p><p style=3D"color: rgb(0, 0, 0);">Unlike approaches t=
o date for covenant emulation, the oracle signers put up bonds to BitVM aud=
itors subject to a BITVM style fraud proof, whereby their funds can be stol=
en if the emulator oracle ever signs a transaction in violation of the cove=
nant rules.</p></div>you can find the paper here: <a href=3D"https://rubin.=
io/bitcoin/2024/11/26/unfed-covenants/" target=3D"_blank" rel=3D"nofollow">=
https://rubin.io/bitcoin/2024/11/26/unfed-covenants/</a><br /><div><br /></=
div><div>Regards,</div><div><br /></div><div>Jeremy</div></blockquote></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/65f9c15a-c2cb-4831-a3dd-00bbbfb465e8n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/65f9c15a-c2cb-4831-a3dd-00bbbfb465e8n%40googlegroups.com</a>.<br />

------=_Part_293623_1027010153.1732987148316--

------=_Part_293622_781025926.1732987148316--