Delivery-date: Sat, 30 Nov 2024 10:35:18 -0800
Sender: bitcoindev@googlegroups.com
Date: Sat, 30 Nov 2024 10:29:49 -0800 (PST)
From: jeremy <jeremy.l.rubin@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <cadcc323-3286-49d2-a77f-c139dd771b04n@googlegroups.com>
In-Reply-To: <65f9c15a-c2cb-4831-a3dd-00bbbfb465e8n@googlegroups.com>
References: <30440182-3d70-48c5-a01d-fad3c1e8048en@googlegroups.com>
 <65f9c15a-c2cb-4831-a3dd-00bbbfb465e8n@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_227544_80577928.1732991389137"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_227544_80577928.1732991389137
Content-Type: multipart/alternative; 
	boundary="----=_Part_227545_555435042.1732991389137"

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

Great point, for the most part I agree with this analysis around difficulty=
=20
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=
=20
is getting paid somehow, over time, and people prefer to use the longest=20
running signing oracles, you create a strong incentive to have long running=
=20
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=
=20
private from the oracle (entirely offline even!), the oracles aren't aware=
=20
of which utxos they could even possibly do something with until a signature=
=20
request is made.

Even then (and this part isn't in the paper, but I should add it as an=20
addendum), it'd be possible to either restructure the oracle to be=20
SIGHASH(tx) + ZKP(SIGHASH(tx), E_i(tx)), such that the oracle blind signs=
=20
the TX without learning details / gaining broadcastability, or to do the=20
signing in a homomorphic computation such that the txs are checked before=
=20
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=
=20
the same ruleset

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

On Saturday, November 30, 2024 at 12:21:38=E2=80=AFPM UTC-5 Erik Aronesty w=
rote:

> 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 pa=
id=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=
=20
> up bonds to BitVM auditors subject to a BITVM style fraud proof, whereby=
=20
> their funds can be stolen if the emulator oracle ever signs a transaction=
=20
> in 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/=
cadcc323-3286-49d2-a77f-c139dd771b04n%40googlegroups.com.

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

Great point, for the most part I agree with this analysis around difficulty=
 applying this to vaults v.s. things like Ark.<div><br /></div><div>One poi=
nt I'd make, is that if you set it up such that the signing oracle is getti=
ng paid somehow, over time, and people prefer to use the longest running si=
gning oracles, you create a strong incentive to have long running honest bo=
nds since then you forgoe a recurring revenue for a one-time sweep.</div><d=
iv><br /></div><div>Further, given that the covenant creation using my keyg=
en mechanism happens private from the oracle (entirely offline even!), the =
oracles aren't aware of which utxos they could even possibly do something w=
ith until a signature request is made.</div><div><br /></div><div>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(SIG=
HASH(tx), E_i(tx)), such that the oracle blind signs the TX without learnin=
g details / gaining broadcastability, or to do the signing in a homomorphic=
 computation such that the txs are checked before sent back.</div><div><br =
/></div><div>Then, in a single-party vault context:</div><div>- =C2=A0you'd=
 be able to punish any misbehavior</div><div>- the oracle themselves wouldn=
't really be able to outright steal coins</div><div>- you'd likely also 2-o=
f-2 with your own key so that you're both enforcing the same ruleset</div><=
div><br /></div><div>the only further issue is liveness, which you'd have t=
o handle with a different mechanism (e.g., 5-of-8 "ultra cold" keys + timel=
ock in a tapleaf).<br /><div><br /></div></div><div class=3D"gmail_quote"><=
div dir=3D"auto" class=3D"gmail_attr">On Saturday, November 30, 2024 at 12:=
21:38=E2=80=AFPM UTC-5 Erik Aronesty wrote:<br/></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, =
204, 204); padding-left: 1ex;">like all other &quot;incentive-driven honest=
y&quot; proposals, it only works if the value locked in the bonds is greate=
r than thevalue locked in the covenants.=C2=A0 =C2=A0but that&#39;s a reaso=
nable restriction for many &quot;l2&quot; use cases, where the purpose of l=
2 is to enable low-valued &quot;vtxo&#39;s&quot;=C2=A0 that allow an emulat=
ed self custody of small amounts that would otherwise be too expensive to m=
ove on-chain<div><br>some analysis of the relationship between the bond loc=
k value and the maximum &quot;incentive-safe&quot;=C2=A0 covenant value, an=
d 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 u=
sers.</div><div><br></div><div>this is unlikely, for example, to be valueab=
le for any vault-ing use case, but should be possible to enable ark2, enigm=
a-network and other protocols designed to falicitate small-value-transactio=
ns-at-scale=C2=A0=C2=A0<br><br></div><div><div dir=3D"auto">On Tuesday, Nov=
ember 26, 2024 at 7:21:03=E2=80=AFPM UTC-8 jeremy wrote:<br></div><blockquo=
te style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div><span style=3D"color:rgb(0,0,0)">Esteemed Bitcoin D=
evelopers,</span><br></div><div><p style=3D"color:rgb(0,0,0)">Sharing below=
 an approach to implementing Bitcoin covenants without requiring native pro=
tocol changes. The approach uses covenant emulators signing servers.</p><p =
style=3D"color:rgb(0,0,0)">Unlike approaches to date for covenant emulation=
, the oracle signers put up bonds to BitVM auditors subject to a BITVM styl=
e fraud proof, whereby their funds can be stolen if the emulator oracle eve=
r signs a transaction in violation of the covenant rules.</p></div>you can =
find the paper here: <a href=3D"https://rubin.io/bitcoin/2024/11/26/unfed-c=
ovenants/" rel=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"https=
://www.google.com/url?hl=3Den&amp;q=3Dhttps://rubin.io/bitcoin/2024/11/26/u=
nfed-covenants/&amp;source=3Dgmail&amp;ust=3D1733077224401000&amp;usg=3DAOv=
Vaw0UswC8gvcz1lRkVjGoztow">https://rubin.io/bitcoin/2024/11/26/unfed-covena=
nts/</a><br><div><br></div><div>Regards,</div><div><br></div><div>Jeremy</d=
iv></blockquote></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/cadcc323-3286-49d2-a77f-c139dd771b04n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/cadcc323-3286-49d2-a77f-c139dd771b04n%40googlegroups.com</a>.<br />

------=_Part_227545_555435042.1732991389137--

------=_Part_227544_80577928.1732991389137--