1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 83FCAC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Jul 2022 22:34:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 4F98960AE5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Jul 2022 22:34:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4F98960AE5
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=FCyPywmz
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.298
X-Spam-Level:
X-Spam-Status: No, score=0.298 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id rtBKMgRO0XXm
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Jul 2022 22:34:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5E10A60881
Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25])
by smtp3.osuosl.org (Postfix) with ESMTPS id 5E10A60881
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Jul 2022 22:34:30 +0000 (UTC)
Date: Sun, 17 Jul 2022 22:34:24 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1658097267; x=1658356467;
bh=cKlMGBuzt/Ah+FYDib+iwNJdh3xdu93xk3rjLc2JIqU=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
Feedback-ID:Message-ID;
b=FCyPywmzgAj7ejC1r5GoXSDJIwDoWJeOy2j+pfFnChHq0J8ksnPgR5NjkQu2I55oA
vc5nRt1eqjiQHiMPZj7iOb6zrj3e6sLA17MpUPy4R4Dfyv/pIYGhV7j/zxQlfjYI5G
Pk9ui+L7EbQGJVXfHyWXpUOeNeLiijETJk3fOn6aBE9HFVyjw9U7yIBMb9xd7sqxJK
20GlqLrPNNREN9haj4n/McE/RfoyEvzwb3zi7vpRYctnyTqYzdJslTUixW3fh/2d08
h8rv0MSRl288IAl+P5/489gg93zq1I7JTF+2IU/LQ/8o3Fo+qhf4dRjh1evf6tei/m
6thCxNLSFxsVA==
To: Ruben Somsen <rsomsen@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <l8iSmPDtMssCoGR0b4twwHMB551xnJBL1wK1jDZcvA8ipKlnBOdZw8ZFVBc4vZzLUlOC3qKB0aEoF6XT7tyFKr6OPThemVD2SiIliCj3-P8=@protonmail.com>
In-Reply-To: <CAPv7TjadLN0X31vdo6ATy_aYepbcykZ8Vp8ghQA9W-GEV4axmg@mail.gmail.com>
References: <OPZNUXvYVkB6kyu7Xvw5-lLIwwwftN_pz0iavHInWvQtQaxIzJhYQrx3dkITo9Yge02emrXY3obveywkH04dyAJdETIeeq9-zcH3DA7OxKs=@protonmail.com>
<CAPv7TjadLN0X31vdo6ATy_aYepbcykZ8Vp8ghQA9W-GEV4axmg@mail.gmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] How to do Proof of Micro-Burn?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Jul 2022 22:34:31 -0000
Good morning Ruben and Veleslav,
> Hi Veleslav,
>
> This is something I've been interested in.
>
>
> What you need is a basic merkle sum tree (not sparse), so if e.g. you wan=
t to burn 10, 20, 30 and 40 sats for separate use cases, in a single tx you=
can burn 100 sats and commit to a tree with four leaves, and the merkle pr=
oof contains the values. E.g. the rightmost leaf is 40 and has 30 as its ne=
ighbor, and moves up to a node of 70 which has 30 (=3D10+20) as its neighbo=
r, totalling 100.
>
>
> The leaf hash needs to commit to the intent/recipient of the burn, so tha=
t way you can't "double spend" the burn by reusing it for more than one pur=
pose.
>
>
> You could outsource the burn to an aggregating third party by paying them=
e.g. over LN but it won't be atomic, so they could walk away with your pay=
ment without actually following through with the burn (but presumably take =
a reputational hit).
If LN switches to PTLCs (payment points/scalars), it may be possible to ens=
ure that you only pay if they release an opening of the commitment.
WARNING: THIS IS ROLL-YOUR-OWN-CRYPTO.
Rather than commit using a Merkle tree, you can do a trick similar to what =
I came up with in `OP_EVICT`.
Suppose there are two customers who want to commit scalars `a` and `b`, and=
the aggregating third party has a private key `k`.
The sum commitment is then:
a * G + b * G + k * G
The opening to show that this commits to `a` is then:
a, b * G + k * G, sign(b + k, a)
...where `sign(k, m)` means sign message `m` with the private key `k`.
Similarly the opening for `b` is:
b, a * G + k *G, sign(a + k, b)
The ritual to purchase a proof goes this way:
* Customer provides the scalar they want committed.
* Aggregator service aggregates the scalars to get `a + b + ....` and adds =
their private key `k`.
* Aggregator service reveals `(a + b + ... + k) * G` to customer.
* Aggregator creates an onchain proof-of-burn to `(a + b + ... + k) * G`.
* Everyone waits until the onchain proof-of-burn is confirmed deeply enough=
.
* Aggregator creates the signatures for each opening for `a`, `b`,.... of t=
he commitment.
* Aggregator provides the corresponding `R` of each signature to each custo=
mer.
* Customer computes `S =3D s * G` for their own signature that opens the co=
mmitment.
* Customer offers a PTLC (i.e. pay for signature scheme) that pays in excha=
nge for `s`.
* Aggregator claims the PTLC, revealing the `s` for the signature.
* Customer now has an opening of the commitment that is for their specific =
scalar.
WARNING: I am not a cryptographer, I only portray one on bitcoin-dev.
There may be cryptographic failures in the above scheme.
Regards,
ZmnSCPxj
|
