path: root/84/23420dacdd1cb73ef8cdf320e3a0351fbd427a

Delivery-date: Sat, 30 Nov 2024 10:35:18 -0800
Received: from mail-yb1-f188.google.com ([209.85.219.188])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD7O3WHWY4JRBXFVVW5AMGQEJCTTVNA@googlegroups.com>)
	id 1tHSJJ-0006gs-KK
	for bitcoindev@gnusha.org; Sat, 30 Nov 2024 10:35:18 -0800
Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e398dd8031asf3551818276.3
        for <bitcoindev@gnusha.org>; Sat, 30 Nov 2024 10:35:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1732991711; x=1733596511; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=JFcZByRiHYI+VrBWEEN1LHrVj2SvSkL3Bj2OamAkTng=;
        b=Z64+gsC2vgRdaC7t+7lxqyj/A79fJeagcB7dqsegJNi2oO2nsEJiH55vdaU/gksN9U
         5SYA4gZGYEWsaDmZOx2PDDNVMt5uEzAbmneOryf/uFVqOvIy7pvsNYUAHL1VGdrWyaTH
         BZ57HVLwuOZz6/k2rzqgmbIDRMk7n6abCDPpttoWkK3m2Cs10lzdI1fF0fCqqKTQMWWJ
         lB6FWj49/GH5vHQeA0t/pj6MdYGDfSjFXfOrzaoNZVB9CoQTl2FLB4awhTil5gBQ8yJ2
         cTBoPr4zSNSpFprQklfY24p386Hezdzgo01MZsCahAezSI3RTBFLUw/G570CGgc6UsGs
         ftXQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1732991711; x=1733596511; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=JFcZByRiHYI+VrBWEEN1LHrVj2SvSkL3Bj2OamAkTng=;
        b=ML4+qHW+ytu5SjXXlS47AS2pxqNXzzlW5qvDbvN4KxU1aTPidSGotr6Lkyj+iTiSHO
         4qkI9MiwrNT7mIkd6QY5DH08u3wCds97GMJ1ltV3agruG9AFIWMVxD8ubqgt8kwdR3zZ
         NGVbh5EIG9TwM7PCXykLVH5kYkqJXuM9lqZw/0azqhG7koXomH0uAyIHFtTyrpz7FPgj
         CoQ5vrUbRCGcFasQKpf9HvhSKczLpCBSyWH7S/qhs6exopgML5AkZTl/EGJ6ZU/5bjJK
         Sp2ccKWR3t5/V2b/GH49O2L+XfuH+Su7RKATasdo7AAIWGO+k1UQq9S2ghfPJgf628CN
         shJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1732991711; x=1733596511;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=JFcZByRiHYI+VrBWEEN1LHrVj2SvSkL3Bj2OamAkTng=;
        b=NlCSRaokesyL3f1KzZLJeL7PzlKrpSAkambPoGz0tscK6mqRmNrvaaSyBsG5+EWAWg
         eTzASuZNQFYtAjbdAuB9L5EAKYQUnlk9LEsKM38+8ciVwdTXBlR1gCVciMGuNz9utQ3/
         PNNJ3m/hbiTmN288XxdtrPRAOPcfnNwv9A1mUUDnBpy+zarUiModdJtPJ23coU5cwjy0
         Aj2WqkjduxoXjugvLpYmoTbQ7UQJ8BYXhugF84/L6+1wYNP5ETRixuxfUexi2YzeKxW9
         rbUEVpxDW6xu53BuFtt82bJ1ZddYb+tRBhygDWWMBVj+kfD92d+FdoHA8skW38QzVhmz
         68jA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVhlWdvGhNNu1vkJR3fw86YMqtLTFvml/I9VJt8am26cpSxlX+ERNLbStJ2j6n+TNAKil4bZiFuEE63@gnusha.org
X-Gm-Message-State: AOJu0YwrMGEm0KWVjX0keFDv0KAqhw7NhMC2qsb5eudzjF78Q/MtpnUw
	U/IXVf91vh5ag8J5UHIOzZfWYX6bhuGVYGB7kYWgQ9nk8vM3kSFO
X-Google-Smtp-Source: AGHT+IH2lpj6kZVAby/XR5+Vy+YVuji9Y/xJ4crZ6ayf+JnHI69wz45Vy8CJa30ClRDPFekNLk8PTw==
X-Received: by 2002:a05:6902:993:b0:e39:8507:17a7 with SMTP id 3f1490d57ef6-e39850718ccmr10000199276.21.1732991711244;
        Sat, 30 Nov 2024 10:35:11 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:ce8c:0:b0:e30:84f1:999f with SMTP id 3f1490d57ef6-e3970dc0790ls3090187276.0.-pod-prod-02-us;
 Sat, 30 Nov 2024 10:35:08 -0800 (PST)
X-Received: by 2002:a05:690c:25c5:b0:6ef:5097:5daa with SMTP id 00721157ae682-6ef50975fc3mr128697887b3.34.1732991708004;
        Sat, 30 Nov 2024 10:35:08 -0800 (PST)
Received: by 2002:a05:690c:2f87:b0:6ef:7d10:5a2f with SMTP id 00721157ae682-6ef7d105e70ms7b3;
        Sat, 30 Nov 2024 10:29:50 -0800 (PST)
X-Received: by 2002:a05:690c:64c6:b0:6ef:5119:6f39 with SMTP id 00721157ae682-6ef51198190mr107543727b3.30.1732991389471;
        Sat, 30 Nov 2024 10:29:49 -0800 (PST)
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"
X-Original-Sender: Jeremy.L.Rubin@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_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--