path: root/47/7244c56a8750151f9d4af559dbc763e1fcf779

Delivery-date: Mon, 24 Mar 2025 06:55:47 -0700
Received: from mail-yb1-f190.google.com ([209.85.219.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD3YNWFH7IHBBWGIQW7QMGQEALQNY7Q@googlegroups.com>)
	id 1twiHK-0004vS-JI
	for bitcoindev@gnusha.org; Mon, 24 Mar 2025 06:55:47 -0700
Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e6409f9185dsf6420870276.0
        for <bitcoindev@gnusha.org>; Mon, 24 Mar 2025 06:55:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1742824540; x=1743429340; 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=iL09ATbrc7WJzNLil+GPOAUHMvz3XrPCjyRhfc7Tx1g=;
        b=k72Vg9CP3zCKjA9crYfXTz+oDvYriBE9D9ndrx68yq0IUBB05h21Ye8rubG1KIQswn
         U+/hLWph2hdx1WdLvGEFfDHeVZ2RD8NWL+NrtP/o98lZQUtLJj9vU/VtdfZbXlaR6RE4
         ut0L57ky0Jvbjv1GYHRSJgvtTR/gfGFH5WJ/bqJu4LjhyeAaQa0rM1ceLlw8epGUNhLb
         2Kd2plXUgyaOkSR5dJJ18zIJSVJ++uoSvxhxbLrg7Gsw/CirVWoVYM42Kj99BmVwgUlt
         aVWlgyd90AnJN/zt1aKSPYsCtRXLLKXqqUVhZfLNeKQWXYBWNhlEPBEWkNSfQ6VuuudC
         /guQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1742824540; x=1743429340;
        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=iL09ATbrc7WJzNLil+GPOAUHMvz3XrPCjyRhfc7Tx1g=;
        b=F7TnUVikIMrar5MLfhENeGYI3AFcpP8Qjc4WroijsHC51nCSW39GMnKY/33CWomvFD
         +/uOQ+Y7UPyyMgfCpjROwyv0/kO+Egu1WTC2SQGJo5dH5B+53gKcIBAsl/TLft1rS1iD
         dFRD9bKqVDYAUSnMwQuz/hiQc5pM5P4Y2Ux69Y8buyVvoee2XFWxDQ2oYU5I/wHApuUX
         3CyvQkhAyBtm6Q4cmgyOsDBn14uFP8VJCFfW5605atjnccL9/ZZfvrv1xBXNiDgjMl3h
         odImO54BCjhKmTnlBUFwU8EY7ozRA5h2V5Fb0GuN4F7vQ8G7+KR/Np4uKNv3aC7S4SDG
         b5zg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUY6SZLTjPpZZZoZffAyrEtXjo0RmHkIsMzmVdibaWzELwOA58D8bpzQxJjmf5IO31/yg+o1nyVRPto@gnusha.org
X-Gm-Message-State: AOJu0Yyd+Pv9OkqG/57kdAg4v9yPgYrLNIHmU21hdIyw+NhIhHnjtNmX
	mjOrRwNvY4A3tVdSFEU+/jKnqmWgkvZGlLrbIXBDUe5/uj0icmoi
X-Google-Smtp-Source: AGHT+IHVKXAlI5hP4RjyFZp1RUoJXeyRfSF7eS4zd3fjnpJx7y5lTGpt/qgihN2y5t5HB9b9LW8QFQ==
X-Received: by 2002:a05:6902:11ce:b0:e38:c0ed:8128 with SMTP id 3f1490d57ef6-e66a4d3dacbmr15488335276.3.1742824540252;
        Mon, 24 Mar 2025 06:55:40 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAIkKs/beoSwooURRKEaDmAtDtR3rwRaZlMA8g3/GSuR6A==
Received: by 2002:a25:e043:0:b0:e5b:3ee5:4212 with SMTP id 3f1490d57ef6-e66908f4604ls1190597276.0.-pod-prod-01-us;
 Mon, 24 Mar 2025 06:55:36 -0700 (PDT)
X-Received: by 2002:a05:690c:368e:b0:6fe:bfb7:68bd with SMTP id 00721157ae682-700babf8753mr180253237b3.1.1742824535886;
        Mon, 24 Mar 2025 06:55:35 -0700 (PDT)
Received: by 2002:a05:690c:3187:b0:6fd:27d2:c7f1 with SMTP id 00721157ae682-700ba4170b4ms7b3;
        Mon, 24 Mar 2025 06:41:27 -0700 (PDT)
X-Received: by 2002:a05:690c:7406:b0:6f9:3e3d:3f2e with SMTP id 00721157ae682-700bad4b5admr162553877b3.33.1742823685004;
        Mon, 24 Mar 2025 06:41:25 -0700 (PDT)
Date: Mon, 24 Mar 2025 06:41:24 -0700 (PDT)
From: Hunter Beast <hunter@surmount.systems>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <da040025-3ddd-4333-9c64-b4aab483ebb2n@googlegroups.com>
In-Reply-To: <CAEM=y+V_jUoupVRBPqwzOQaUVNdJj5uJy3LK9JjD7ixuCYEt-A@mail.gmail.com>
References: <CAEM=y+V_jUoupVRBPqwzOQaUVNdJj5uJy3LK9JjD7ixuCYEt-A@mail.gmail.com>
Subject: [bitcoindev] Re: Slashing covenants
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_393892_460953735.1742823684688"
X-Original-Sender: hunter@surmount.systems
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.7 (/)

------=_Part_393892_460953735.1742823684688
Content-Type: multipart/alternative; 
	boundary="----=_Part_393893_1835729378.1742823684688"

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

I'm surprised nobody's noticed this. It's an interesting approach. I=20
wouldn't discount it because it relies on incentives, since bitcoin mining=
=20
itself is secure only through cryptoeconomic incentives, and yet that's=20
good enough. Plenty of things on bitcoin aren't perfect, but they're good=
=20
enough to do the job.

Some questions...
- What are some of the advantages of using slashing covenants instead of=20
BitVM? Could this make the approach more practical?
- Does this absolutely require OP_CAT to work?
- What is the rough size of such a transaction?

On Sunday, November 24, 2024 at 2:26:20=E2=80=AFPM UTC-7 Ethan Heilman wrot=
e:

> Slashing covenants is a protocol for covenants in Bitcoin via
> incentives. A covenant is a set of rules about what transactions can
> spend a Bitcoin output which is encumbered by that covenant. Typically
> a covenant is enforced by preventing someone from spending that
> output. In this protocol we instead allow the spending of the output
> and then punish the spender by a loss of funds, i.e. we slash them, if
> they do not follow the rules of the covenant. This is less secure than
> a covenant enforced by an opcode, FE or ColliderScript, because it
> relies on incentives over enforcement. The advantage of this approach
> is that it is efficient, does not add new cryptographic assumptions
> and is possible on Bitcoin today.
>
> This protocol uses very similar mechanisms to BitVM, originally I
> thought this was how BitVM worked, which is why I didn=E2=80=99t publish =
it.
> After talking to many people it appears this technique is not used in
> BitVM.
>
>
> Notation
> =3D=3D=3D=3D
> By <x>32 we denote a value, x, in Bitcoin Script which is encoded as a
> list of 32-bit stack elements. We can perform arbitrary computation on
> such values using Bitcoin=E2=80=99s math opcodes, a.k.a., Small Script.
>
> Protocol
> =3D=3D=3D=3D
> The essential problem for enforcing covenants in Bitcoin outputs is
> showing that a signature s1 that will pass CHECKSIGVERIFY is equal to
> a signature s2 encoded for Small Script. This is because once we get a
> signature into Small Script, we extract the sighash and do transaction
> introspection. ColliderScript gets us covenants by using hash
> collisions to check equality between s1 and <s2>32. CAT gets us
> covenants by simply concatenating all the <s2>32 and then comparing
> against s1 using EQUAL:
>
> s2 =3D CAT(<s2>32 [0], <s2>32 [1], <s2>32 [2], =E2=80=A6 <s2>32 [15])
> EQUAL s1, s2
>
> Slashing covenants works by removing the requirement for this equality
> check, but instead providing a fraud proof ifs1!=3Ds2, and posting that
> fraud proof to punish the spending party. To do this we construct a
> Bitcoin script output which takes as input:
>
> s1 - the spending signature.
> <s2>32 - the spending signature encoded in small script. An honest
> spender will set s1 =3D s2.
> L - a Lamport signature on <s2>32.
> <txn data>32 - data about the spending transaction that we use to open
> the sighash
>
> The Bitcoin script covenant output then:
> 1. checks s1 is a valid spending signature.
> 2. Checks that <s2>32 is validly signed by the Lamport signature L
> 3. Supplies <s2>32 and <txn data>32 to Small Script which enforces the
> covenant under the assumption that s1=3Ds2.
>
> Covenant output (s1, <s2>32, L, <txn data>32):
> CHECKSIGVERIFY s1
> Lamport-Verify <s2>32, L
> SmallScript Enforce-Cov <s2>32, <txn data>32
>
> As long as s1=3Ds2 the covenant is enforced. However if s1!=3Ds2 the
> covenant can be broken. To punish spenders who set s1!=3Ds2, we create
> an output that allows anyone to burn/slash the coins of the rule
> breaker if and only if they spent a covenant and supplied s1 and s2
> such that s1!=3Ds2.
>
> The Bitcoin script slash output takes as input: <s1>32, <s2>32, and L.
>
> Slashing output (<s1>32, <s2>32, L):
> SmallScript CHECKSIGVERIFY <s1>32
> Lamport-Verify <s2>32, L
> IF <s1>32 !=3D <s2>32: Verify
>
> Thus the slashing output can only be spent if the rule breaker spent
> the covenant with s1!=3Ds2. SmallScript CHECKSIGVERIFY is used to prove
> the rule breaker signed s1, the lamport signature is used to prove the
> rule breaker signed s2. Thus, we have a fraud proof that the rule
> breaker signed s1!=3Ds2. The Lamport signature is only used here to
> avoid having to do ECC math in Small Script in the covenant.
>
> Note that because we are doing CHECKSIGVERIFY in Small Script, the
> spending transaction will be massive. The slashing occurs because of
> the fees incurred by spending the slashing transaction. Note that such
> a slashing output could also be done on ethereum. This would simplify
> the construction.
>
> For the purposes of explanation, we assumed the spender is also the
> party who is slashed. In actual practice it is more likely you could
> have a set of N slashable cosigners who could attest to a spend not
> violating the covenant. Using pre-signed transactions you could
> recover an output if all n slashable cosigners were indefinitely
> offline. If you could fit a SNARKS in Small Script, you could have
> people join and leave the cosigner set dynamically for already posted
> covenant outputs by simply proving they have posted slash outputs and
> that the value in covenants < value in slash outputs.
>

--=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/=
da040025-3ddd-4333-9c64-b4aab483ebb2n%40googlegroups.com.

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

I'm surprised nobody's noticed this. It's an interesting approach. I wouldn=
't discount it because it relies on incentives, since bitcoin mining itself=
 is secure only through cryptoeconomic incentives, and yet that's good enou=
gh. Plenty of things on bitcoin aren't perfect, but they're good enough to =
do the job.<div><br /></div><div>Some questions...</div><div>- What are som=
e of the advantages of using slashing covenants instead of BitVM? Could thi=
s make the approach more practical?</div><div>- Does this absolutely requir=
e OP_CAT to work?</div><div>- What is the rough size of such a transaction?=
<br /><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gma=
il_attr">On Sunday, November 24, 2024 at 2:26:20=E2=80=AFPM UTC-7 Ethan Hei=
lman 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;">S=
lashing covenants is a protocol for covenants in Bitcoin via
<br>incentives. A covenant is a set of rules about what transactions can
<br>spend a Bitcoin output which is encumbered by that covenant. Typically
<br>a covenant is enforced by preventing someone from spending that
<br>output. In this protocol we instead allow the spending of the output
<br>and then punish the spender by a loss of funds, i.e. we slash them, if
<br>they do not follow the rules of the covenant. This is less secure than
<br>a covenant enforced by an opcode, FE or ColliderScript, because it
<br>relies on incentives over enforcement. The advantage of this approach
<br>is that it is efficient, does not add new cryptographic assumptions
<br>and is possible on Bitcoin today.
<br>
<br>This protocol uses very similar mechanisms to BitVM, originally I
<br>thought this was how BitVM worked, which is why I didn=E2=80=99t publis=
h it.
<br>After talking to many people it appears this technique is not used in
<br>BitVM.
<br>
<br>
<br>Notation
<br>=3D=3D=3D=3D
<br>By &lt;x&gt;32 we denote a value, x, in Bitcoin Script which is encoded=
 as a
<br>list of 32-bit stack elements. We can perform arbitrary computation on
<br>such values using Bitcoin=E2=80=99s math opcodes, a.k.a., Small Script.
<br>
<br>Protocol
<br>=3D=3D=3D=3D
<br>The essential problem for enforcing covenants in Bitcoin outputs is
<br>showing that a signature s1 that will pass CHECKSIGVERIFY is equal to
<br>a signature s2 encoded for Small Script. This is because once we get a
<br>signature into Small Script, we extract the sighash and do transaction
<br>introspection. ColliderScript gets us covenants by using hash
<br>collisions to check equality between s1 and &lt;s2&gt;32. CAT gets us
<br>covenants by simply concatenating all the &lt;s2&gt;32 and then compari=
ng
<br>against s1 using EQUAL:
<br>
<br>s2 =3D CAT(&lt;s2&gt;32 [0], &lt;s2&gt;32 [1],  &lt;s2&gt;32 [2], =E2=
=80=A6 &lt;s2&gt;32 [15])
<br>EQUAL s1, s2
<br>
<br>Slashing covenants works by removing the requirement for this equality
<br>check, but instead providing a fraud proof ifs1!=3Ds2, and posting that
<br>fraud proof to punish the spending party. To do this we construct a
<br>Bitcoin script output which takes as input:
<br>
<br>s1 - the spending signature.
<br>&lt;s2&gt;32 - the spending signature encoded in small script. An hones=
t
<br>spender will set s1 =3D s2.
<br>L - a Lamport signature on &lt;s2&gt;32.
<br>&lt;txn data&gt;32 - data about the spending transaction that we use to=
 open
<br>the sighash
<br>
<br>The Bitcoin script covenant output then:
<br>1. checks s1 is a valid spending signature.
<br>2. Checks that &lt;s2&gt;32 is validly signed by the Lamport signature =
L
<br>3. Supplies &lt;s2&gt;32 and &lt;txn data&gt;32 to Small Script which e=
nforces the
<br>covenant under the assumption that s1=3Ds2.
<br>
<br>Covenant output (s1, &lt;s2&gt;32, L, &lt;txn data&gt;32):
<br>  CHECKSIGVERIFY s1
<br>  Lamport-Verify &lt;s2&gt;32, L
<br>  SmallScript Enforce-Cov &lt;s2&gt;32, &lt;txn data&gt;32
<br>
<br>As long as s1=3Ds2 the covenant is enforced. However if s1!=3Ds2 the
<br>covenant can be broken. To punish spenders who set s1!=3Ds2, we create
<br>an output that allows anyone to burn/slash the coins of the rule
<br>breaker if and only if they spent a covenant and supplied s1 and s2
<br>such that  s1!=3Ds2.
<br>
<br>The Bitcoin script slash output takes as input: &lt;s1&gt;32, &lt;s2&gt=
;32, and L.
<br>
<br>Slashing output (&lt;s1&gt;32, &lt;s2&gt;32, L):
<br>  SmallScript CHECKSIGVERIFY &lt;s1&gt;32
<br>  Lamport-Verify &lt;s2&gt;32, L
<br>  IF &lt;s1&gt;32 !=3D &lt;s2&gt;32: Verify
<br>
<br>Thus the slashing output can only be spent if the rule breaker spent
<br>the covenant with s1!=3Ds2. SmallScript CHECKSIGVERIFY is used to prove
<br>the rule breaker signed s1, the lamport signature is used to prove the
<br>rule breaker signed s2. Thus, we have a fraud proof that the rule
<br>breaker signed s1!=3Ds2.  The Lamport signature is only used here to
<br>avoid having to do ECC math in Small Script in the covenant.
<br>
<br>Note that because we are doing CHECKSIGVERIFY in Small Script, the
<br>spending transaction will be massive. The slashing occurs because of
<br>the fees incurred by spending the slashing transaction. Note that such
<br>a slashing output could also be done on ethereum. This would simplify
<br>the construction.
<br>
<br>For the purposes of explanation, we assumed the spender is also the
<br>party who is slashed. In actual practice it is more likely you could
<br>have a set of N slashable cosigners who could attest to a spend not
<br>violating the covenant. Using pre-signed transactions you could
<br>recover an output if all n slashable cosigners were indefinitely
<br>offline. If you could fit a SNARKS in Small Script, you could have
<br>people join and leave the cosigner set dynamically for already posted
<br>covenant outputs by simply proving they have posted slash outputs and
<br>that the value in covenants &lt; value in slash outputs.
<br></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/da040025-3ddd-4333-9c64-b4aab483ebb2n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/da040025-3ddd-4333-9c64-b4aab483ebb2n%40googlegroups.com</a>.<br />

------=_Part_393893_1835729378.1742823684688--

------=_Part_393892_460953735.1742823684688--