MIME-Version: 1.0
References: <OPZNUXvYVkB6kyu7Xvw5-lLIwwwftN_pz0iavHInWvQtQaxIzJhYQrx3dkITo9Yge02emrXY3obveywkH04dyAJdETIeeq9-zcH3DA7OxKs=@protonmail.com>
 <CAPv7TjadLN0X31vdo6ATy_aYepbcykZ8Vp8ghQA9W-GEV4axmg@mail.gmail.com>
 <l8iSmPDtMssCoGR0b4twwHMB551xnJBL1wK1jDZcvA8ipKlnBOdZw8ZFVBc4vZzLUlOC3qKB0aEoF6XT7tyFKr6OPThemVD2SiIliCj3-P8=@protonmail.com>
 <CAPv7TjaFW8oOjrJGjUCkMLy2nfSOkjsR0Dg3Rbzq7__WOVir7Q@mail.gmail.com>
 <2RqMBHD1F81zChgG5I40iCbuAriXQARjeDcMWuFDiPFh3cegBC-GDfsj6rr7pzU2myZLWf65DatR9eHpBSZOmWDP0XHRycg8Y3T-Y85H8vI=@protonmail.com>
In-Reply-To: <2RqMBHD1F81zChgG5I40iCbuAriXQARjeDcMWuFDiPFh3cegBC-GDfsj6rr7pzU2myZLWf65DatR9eHpBSZOmWDP0XHRycg8Y3T-Y85H8vI=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Wed, 20 Jul 2022 00:23:40 +0200
Message-ID: <CAPv7Tja_E5e=3J_XSxchFoFbz0jiXqn5b4FnjBYb8d44QKAB+g@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000773aa105e42ff0af"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] How to do Proof of Micro-Burn?
Precedence: list

--000000000000773aa105e42ff0af
Content-Type: text/plain; charset="UTF-8"

Good evening ZmnSCPxj,

>I suppose that means that the knower of `k` is a trusted party; it is
trusted to only issue commitments and not generate fake ones

Then you can reduce the scheme to just committing to K and having that key
sign whatever the burn was intended for. I doubt this is useful in practice.

>can you please explain

The goal is to burn multiple amounts (10, 20, 30, 40) in a single OP_RETURN
(100) and specifically indicating how much of the total is intended for
what use case. A merkle sum tree achieves this.

(1a)  100      (1b)  ABCD       (2a)  100     (2b)  ABCD
    /    \          /    \          /    \         /    \
  30      70      AB      CD      30      70     AB      CD
 /  \    /  \    /  \    /  \    /  \           /  \
10  20  30  40   A  B    C  D   10  20          A  B

(view as monospace font, e.g. via bitcoin-dev archive)

So while in a normal merkle tree (1a) you hash e.g. A and B to get AB, with
a sum tree (1b) you also hash 10 and 20 to get 30.

When you verify the full merkle sum proof (2a + 2b, combined in a single
tree), you verify that 10 (A) + 20 (B) add up to 30 (AB), and 30 (AB) + 70
(CD) add up to 100 (ABCD), else the root hash won't match.

This ensures that you can't create a valid tree with commitments that
add up to more than the burned amount (essentially a "double spend").

>the buyer has every incentive to actually pay

Not if you never had any intention of buying it and are just trying to run
them out of business.

Hope this helps!

Cheers,
Ruben



On Tue, Jul 19, 2022 at 4:48 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

>
> Good morning Ruben,
>
> > Good evening ZmnSCPxj,
> > Interesting attempt.
> >
> > >a * G + b * G + k * G
> >
> > Unfortunately I don't think this qualifies as a commitment, since one
> could trivially open the "commitment" to some uncommitted value x (e.g. a
> is set to x and b is set to a+b-x). Perhaps you were thinking of Pedersen
> commitments (a * G + b * H + k * J)?
>
> I believe this is only possible for somebody who knows `k`?
> As mentioned, an opening here includes a signature using `b + k` as the
> private key, so the signature can only be generated with knowledge of both
> `b` and `k`.
>
> I suppose that means that the knower of `k` is a trusted party; it is
> trusted to only issue commitments and not generate fake ones.
>
> > Even if we fixed the above with some clever cryptography, the crucial
> merkle sum tree property is missing, so "double spending" a burn becomes
> possible.
>
> I do not understand what this property is and how it is relevant, can you
> please explain this to a non-mathematician?
>
> > You also still run into the same atomicity issue, except the risk is
> moved to the seller side, as the buyer could refuse to finalize the
> purchase after the on-chain commitment was made by the seller. Arguably
> this is worse, since generally only the seller has a reputation to lose,
> not the buyer.
>
> A buyer can indeed impose this cost on the seller, though the buyer then
> is unable to get a valid opening of its commitment, as it does not know `k`.
> Assuming the opening of the commitment is actually what has value (since
> the lack of such an opening means the buyer cannot prove the commitment)
> then the buyer has every incentive to actually pay for the opening.
>
> Regards,
> ZmnSCPxj
>

--000000000000773aa105e42ff0af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Good evening ZmnSCPxj,<div><br></div><div>&gt;I suppose th=
at means that the knower of `k` is a trusted party; it is trusted to only i=
ssue commitments and not generate fake ones</div><div><br></div><div>Then y=
ou can reduce the scheme to just committing to K and having that key sign w=
hatever the burn was intended for. I doubt this is useful in practice.</div=
><div><br></div><div>&gt;can you please explain</div><div><br></div><div>Th=
e goal is to burn multiple amounts (10, 20, 30, 40) in a single OP_RETURN (=
100) and specifically indicating how much of the total is intended for what=
 use case. A merkle sum tree achieves this.<br><br><font face=3D"monospace"=
>(1a) =C2=A0100 =C2=A0 =C2=A0 =C2=A0(1b) =C2=A0ABCD =C2=A0 =C2=A0 =C2=A0 (2=
a) =C2=A0100 =C2=A0 =C2=A0 (2b) =C2=A0ABCD<br>=C2=A0 =C2=A0 / =C2=A0 =C2=A0=
\ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ =C2=A0 =C2=A0\ =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0/ =C2=A0 =C2=A0\ =C2=A0 =C2=A0 =C2=A0 =C2=A0 / =C2=A0 =C2=A0\<=
br>=C2=A0 30 =C2=A0 =C2=A0 =C2=A070 =C2=A0 =C2=A0 =C2=A0AB =C2=A0 =C2=A0 =
=C2=A0CD =C2=A0 =C2=A0 =C2=A030 =C2=A0 =C2=A0 =C2=A070 =C2=A0 =C2=A0 AB =C2=
=A0 =C2=A0 =C2=A0CD<br>=C2=A0/ =C2=A0\ =C2=A0 =C2=A0/ =C2=A0\ =C2=A0 =C2=A0=
/ =C2=A0\ =C2=A0 =C2=A0/ =C2=A0\ =C2=A0 =C2=A0/ =C2=A0\ =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 / =C2=A0\<br>10 =C2=A020 =C2=A030 =C2=A040 =C2=A0 A =C2=
=A0B =C2=A0 =C2=A0C =C2=A0D =C2=A0 10 =C2=A020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0A =C2=A0B</font><br><br>(view as monospace font, e.g. via bitcoin-dev=
 archive)<br><br>So while in a normal merkle tree (1a) you hash e.g. A and =
B to get AB, with a sum tree (1b) you also hash 10 and 20 to get 30.<br><br=
>When you verify the full merkle sum proof (2a + 2b, combined in a single t=
ree), you verify that 10 (A) + 20 (B) add up to 30 (AB), and 30 (AB) + 70 (=
CD) add up to 100 (ABCD), else the root hash won&#39;t match.<br><br>This e=
nsures that you can&#39;t create a valid tree with=C2=A0commitments that ad=
d=C2=A0up to more than the burned amount (essentially a &quot;double spend&=
quot;).<br></div><div><br></div><div>&gt;the buyer has every incentive to a=
ctually pay</div><div><br></div><div>Not if you never had any intention of =
buying it and are just trying to run them out of business.</div><div><br></=
div><div>Hope this helps!</div><div><br></div><div>Cheers,</div><div>Ruben<=
/div><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 19, 2022 at 4:48 PM ZmnSCPxj=
 &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Good morning Ruben,<br>
<br>
&gt; Good evening ZmnSCPxj,<br>
&gt; Interesting attempt.<br>
&gt;<br>
&gt; &gt;a * G + b * G + k * G<br>
&gt;<br>
&gt; Unfortunately I don&#39;t think this qualifies as a commitment, since =
one could trivially open the &quot;commitment&quot; to some uncommitted val=
ue x (e.g. a is set to x and b is set to a+b-x). Perhaps you were thinking =
of Pedersen commitments (a * G + b * H + k * J)?<br>
<br>
I believe this is only possible for somebody who knows `k`?<br>
As mentioned, an opening here includes a signature using `b + k` as the pri=
vate key, so the signature can only be generated with knowledge of both `b`=
 and `k`.<br>
<br>
I suppose that means that the knower of `k` is a trusted party; it is trust=
ed to only issue commitments and not generate fake ones.<br>
<br>
&gt; Even if we fixed the above with some clever cryptography, the crucial =
merkle sum tree property is missing, so &quot;double spending&quot; a burn =
becomes possible.<br>
<br>
I do not understand what this property is and how it is relevant, can you p=
lease explain this to a non-mathematician?<br>
<br>
&gt; You also still run into the same atomicity issue, except the risk is m=
oved to the seller side, as the buyer could refuse to finalize the purchase=
 after the on-chain commitment was made by the seller. Arguably this is wor=
se, since generally only the seller has a reputation to lose, not the buyer=
.<br>
<br>
A buyer can indeed impose this cost on the seller, though the buyer then is=
 unable to get a valid opening of its commitment, as it does not know `k`.<=
br>
Assuming the opening of the commitment is actually what has value (since th=
e lack of such an opening means the buyer cannot prove the commitment) then=
 the buyer has every incentive to actually pay for the opening.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000773aa105e42ff0af--