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
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
|
Return-Path: <nico.gregory@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9C9D0C0881
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Dec 2019 12:32:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 7D91220368
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Dec 2019 12:32:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 75k4E2Y7j8WW
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Dec 2019 12:32:38 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com
[209.85.166.47])
by silver.osuosl.org (Postfix) with ESMTPS id 634372014B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Dec 2019 12:32:38 +0000 (UTC)
Received: by mail-io1-f47.google.com with SMTP id c16so21704801ioh.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Dec 2019 04:32:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=QK1Rj35PX1tHQZSZK1Vd+rfo0BiJSh9lLGt6yWQVDrE=;
b=bCXbJwWyz90qtWwKtpi8Am3ql9Zsy3w60X6ILcVoIez0dsjg4wGGOkGF0dGuliawaY
5HLxGN5tnsk0B+xITKZiJXrBCFcbJAlpggg2wTs3IpuJ2bQmpP6UNRuVZgP2fuUI2Efq
ForKnCF01J/Yp0zVVM3wmZjR2i7kdZoDojOaHXVGYGhctQ6Zdt1/FW/SJDhpPcSjFZd4
fDisazFnJbROiOdqN1eVpCcEO4j5YGEEnN7MY4/cNJJjOk288XoR66mGzlLsLpCEi2g7
JVNTA1aUmYkhK9RL5Je/u2Aqe7XLhiG89TSeJ2Ob+w76/eKjgaSM/1I2Wy/iEymxYxyf
qgKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=QK1Rj35PX1tHQZSZK1Vd+rfo0BiJSh9lLGt6yWQVDrE=;
b=IxcfzfCtCFtoenIy2wap3uzwc9Vkf5bZasPSGXrnncjg0FN0DDd2v7cREkdYuBDhJ/
Q4q2cakTwavo7nA46P91jo1QkAE34zwr2teih8i62Vipx5hUBht9FkYJ/m+zHX/Jj/hy
q/JSUKv0swXKIC7yujZklvXJhnsh0spfvbaJLWx6EzUAuYpGEStRvDq65T9108+rVGqG
adEAwcSA0XLMTfbNJ4qmklXJ2YFQJMpSz0/V12hKJYzKhGDffwBJhjfKRCdvMfhyfN0F
gFplFCynNloX5Pp8oBmP4BKtOCrFa7neMRk1Ra7xW3sMEwvi+4xpdYL6ihtQwTq2Vii0
kzcQ==
X-Gm-Message-State: APjAAAWrXDRFcSKK9IZtsfpo5BN61+iED9UGl+WUaE+XW/QqYqpoFXU3
2tikvbDhV3CxTdYO11/Bejt6dS8OqeN6/id7UnM=
X-Google-Smtp-Source: APXvYqwS0C5RlYEkFbVCt2hM6cA1QXmNvA9s8VtBLAlN2GSlpIEdSowKByOoXqXMzscezsax+M5XCGU0H2Jy1aqFdwo=
X-Received: by 2002:a5d:87c8:: with SMTP id q8mr32671347ios.108.1577363557524;
Thu, 26 Dec 2019 04:32:37 -0800 (PST)
MIME-Version: 1.0
References: <CAPv7TjYb3u9wauHQ_U9tTRKotuJushnnoAGu-MLgA_djMkdNdw@mail.gmail.com>
In-Reply-To: <CAPv7TjYb3u9wauHQ_U9tTRKotuJushnnoAGu-MLgA_djMkdNdw@mail.gmail.com>
From: Nick Gregory <nico.gregory@gmail.com>
Date: Thu, 26 Dec 2019 12:32:26 +0000
Message-ID: <CAEqdS56_LaRfGihpDy7U+F-2jSzFxCFwCnFztdo2Lze0Ot-Riw@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000872841059a9a9266"
X-Mailman-Approved-At: Thu, 26 Dec 2019 16:28:11 +0000
Subject: Re: [bitcoin-dev] Blind Merged Mining with covenants (
sighash_anyprevout / op_ctv )
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: Thu, 26 Dec 2019 12:32:41 -0000
--000000000000872841059a9a9266
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
This not similar to MainStay?
https://commerceblock.readthedocs.io/en/latest/mainstay/index.html
https://mainstay.xyz
On Thu, Dec 26, 2019 at 2:25 AM Ruben Somsen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Blind Merged Mining (BMM) is the idea of committing the hash of another
> blockchain into a unique location on the Bitcoin blockchain, and paying a
> Bitcoin fee to miners for the privilege of deciding this hash and capturi=
ng
> the fees inside the other blockchain. Since miners don=E2=80=99t have to =
know what
> the hash represents and are simply incentivized to choose the highest
> bidder, it requires no extra validation on their part (=E2=80=9Cblind=E2=
=80=9D). This idea
> was originally conceived of by Paul Sztorc, but required a specific soft
> fork. [0]
>
> In essence, BMM is a mechanism that allows external blockchains (altcoins=
,
> tokens) to outsource their mining to the Bitcoin blockchain. Instead of
> burning electricity with ASICs, they pay bitcoins to miners, who in turn
> will perform Proof-of-Work (PoW) for the privilege of obtaining this
> payment. This increases the total PoW on the Bitcoin blockchain, which ad=
ds
> to the security of the Bitcoin network. It's an easy consensus mechanism =
to
> implement, and simple to mine, only requiring full node software for both
> chains and some bitcoins.
>
> While it may be hard to justify this as a soft fork, it turns out that th=
e
> inclusion of sighash_anyprevout (previously sighash_noinput) into Bitcoin
> is sufficient to make BMM work, because, as noted by Anthony Towns [1],
> sighash_anyprevout allows for the creation of op_checktemplateverify
> (op_ctv, previously op_securethebag) style covenants [2]. With that, we c=
an
> generate the following without any trusted setup:
>
> - A long string of sighash_anyprevout transactions, each only spendable b=
y
> the next (the spending signature is placed in the output script, making i=
t
> a covenant)
> - RBF enabled and signed with sighash flags single, anyonecanpay, and
> anyprevout, allowing the addition of inputs and outputs in order to pay
> fees (similar to fees in eltoo [3])
> - A relative locktime of one block, ensuring only one transaction gets
> mined per block
>
> A complete transaction flow diagram can be found here:
>
> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file=
-bmm-svg
>
> (Note that op_ctv instead of sighash_anyprevout would require the use of
> CPFP, because all outputs need to be pre-defined.)
>
> This setup generates a unique location for the hash, which can be freely
> competed for by anyone with the help of RBF. The hash can be committed in=
to
> the fee paying output via taproot. If the block corresponding to the hash
> is not revealed or invalid, then the BMM block simply gets orphaned, just
> like in Sztorc=E2=80=99s proposal.
>
> While the Bitcoin blockchain will be unaware of the BMM chain, the
> opposite does not have to be true. This enables some interesting
> possibilities. For instance, you could make a conditional BMM token
> transfer that only goes through if a specific Bitcoin transaction occurs
> within a certain period of time, thus enabling atomic swaps (especially
> useful when combined with asset issuance/colored coins/pegged tokens). It
> would also be possible to create contracts based on Bitcoin=E2=80=99s has=
hrate and
> such.
>
> It seems inevitable that this chain will need some kind of native token i=
n
> order to pay for fees. This makes me uneasy. The fairest and least
> speculation-inducing method I can think of is a perpetual one-way peg,
> where at any time 1 BTC can be burned for 1 token, essentially preserving
> the 21M coin limit. Coins that are burned will never return, benefiting a=
ll
> BTC holders equally. Holding BTC will always be preferable, because the
> option to move is always open to you. This should disincentivize
> speculation -- it only makes sense to move coins if they serve an immedia=
te
> purpose.
>
> Given the lack of a block subsidy, there may not be enough impetus to mov=
e
> the chain forward instead of enacting a reorg. However, BMM reorgs are
> somewhat unique in that they will have to compete for the same unique
> location that the original chain is using. A 10-block reorg would take 10=
0
> minutes on average to catch up, during which the original chain won=E2=80=
=99t move
> forward. If fee pressure of new transactions is targeted exclusively
> towards the original chain during this time [4], there would be forward
> pressure that makes reorgs more expensive. Whether this mitigation is
> sufficient is an open question.
>
> Finally, it is worth asking whether BMM interferes too much with the
> existing incentive structure of Bitcoin. I don=E2=80=99t have a clear ans=
wer, but
> it should be noted that a much more inefficient version of BMM is already
> possible today. One could simply use up lots of block space instead of
> specifying a unique location for the hash, as demonstrated by Veriblock
> [5]. I therefore believe that the same argument as adding data via
> op_return applies here -- if it=E2=80=99s not supported, more wasteful me=
thods may
> be utilized instead.
>
> Some technical details (thanks to Anthony Towns for providing his
> insights):
>
> - Since the exact signature is committed to ahead of time, private key
> security is actually irrelevant. You can simply use G to replace both R a=
nd
> P instead of the usual s =3D r + e*p. This means anyone can easily
> pre-compute all the sighash_anyprevout signatures with s =3D 1 + e.
>
> - Assuming taproot, the spending script will be inside a taproot leaf,
> meaning there is a key spend path which should be made unusable in order =
to
> enforce the covenant. This can be achieved with a NUMS such as
> hashToCurve(G) =3D H, which can then be used as the internal taproot key=
T =3D
> H + hash(H||bmm_hash)*G.
>
> -- Ruben Somsen
>
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki
>
> [1]
> https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg080=
75.html
>
> [2] https://github.com/JeremyRubin/bips/blob/ctv-v2/bip-ctv.mediawiki
>
> [3] https://blockstream.com/eltoo.pdf
>
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/01=
6352.html
>
> [5] https://twitter.com/lopp/status/1081558829454802945
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000872841059a9a9266
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div dir=3D"ltr" class=3D"gmail_signature" data-smart=
mail=3D"gmail_signature"><div>This not similar to MainStay?</div><div><br><=
/div><div><a href=3D"https://commerceblock.readthedocs.io/en/latest/mainsta=
y/index.html">https://commerceblock.readthedocs.io/en/latest/mainstay/index=
.html</a><br></div><div><br></div><div><a href=3D"https://mainstay.xyz">htt=
ps://mainstay.xyz</a></div></div></div><br></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Dec 26, 2019 at 2:25 AM =
Ruben Somsen via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Blind =
Merged Mining (BMM) is the idea of committing the hash of another blockchai=
n into a unique location on the Bitcoin blockchain, and paying a Bitcoin fe=
e to miners for the privilege of deciding this hash and capturing the fees =
inside the other blockchain. Since miners don=E2=80=99t have to know what t=
he hash represents and are simply incentivized to choose the highest bidder=
, it requires no extra validation on their part (=E2=80=9Cblind=E2=80=9D). =
This idea was originally conceived of by Paul Sztorc, but required a specif=
ic soft fork. [0]<br><br>In essence, BMM is a mechanism that allows externa=
l blockchains (altcoins, tokens) to outsource their mining to the Bitcoin b=
lockchain. Instead of burning electricity with ASICs, they pay bitcoins to =
miners, who in turn will perform Proof-of-Work (PoW) for the privilege of o=
btaining this payment. This increases the total PoW on the Bitcoin blockcha=
in, which adds to the security of the Bitcoin network. It's an easy con=
sensus mechanism to implement, and simple to mine, only requiring full node=
software for both chains and some bitcoins.<br><br>While it may be hard to=
justify this as a soft fork, it turns out that the inclusion of sighash_an=
yprevout (previously sighash_noinput) into Bitcoin is sufficient to make BM=
M work, because, as noted by Anthony Towns [1], sighash_anyprevout allows f=
or the creation of op_checktemplateverify (op_ctv, previously op_securetheb=
ag) style covenants [2]. With that, we can generate the following without a=
ny trusted setup:<br><br>- A long string of sighash_anyprevout transactions=
, each only spendable by the next (the spending signature is placed in the =
output script, making it a covenant)<br>- RBF enabled and signed with sigha=
sh flags single, anyonecanpay, and anyprevout, allowing the addition of inp=
uts and outputs in order to pay fees (similar to fees in eltoo [3])<br>- A =
relative locktime of one block, ensuring only one transaction gets mined pe=
r block<br><br>A complete transaction flow diagram can be found here:<br><a=
href=3D"https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16=
a5#file-bmm-svg" target=3D"_blank">https://gist.github.com/RubenSomsen/5e4b=
e6d18e5fa526b17d8b34906b16a5#file-bmm-svg</a><br><br>(Note that op_ctv inst=
ead of sighash_anyprevout would require the use of CPFP, because all output=
s need to be pre-defined.)<br><br>This setup generates a unique location fo=
r the hash, which can be freely competed for by anyone with the help of RBF=
. The hash can be committed into the fee paying output via taproot. If the =
block corresponding to the hash is not revealed or invalid, then the BMM bl=
ock simply gets orphaned, just like in Sztorc=E2=80=99s proposal.<br><br>Wh=
ile the Bitcoin blockchain will be unaware of the BMM chain, the opposite d=
oes not have to be true. This enables some interesting possibilities. For i=
nstance, you could make a conditional BMM token transfer that only goes thr=
ough if a specific Bitcoin transaction occurs within a certain period of ti=
me, thus enabling atomic swaps (especially useful when combined with asset =
issuance/colored coins/pegged tokens). It would also be possible to create =
contracts based on Bitcoin=E2=80=99s hashrate and such.<br><br>It seems ine=
vitable that this chain will need some kind of native token in order to pay=
for fees. This makes me uneasy. The fairest and least speculation-inducing=
method I can think of is a perpetual one-way peg, where at any time 1 BTC =
can be burned for 1 token, essentially preserving the 21M coin limit. Coins=
that are burned will never return, benefiting all BTC holders equally. Hol=
ding BTC will always be preferable, because the option to move is always op=
en to you. This should disincentivize speculation -- it only makes sense to=
move coins if they serve an immediate purpose.<br><br>Given the lack of a =
block subsidy, there may not be enough impetus to move the chain forward in=
stead of enacting a reorg. However, BMM reorgs are somewhat unique in that =
they will have to compete for the same unique location that the original ch=
ain is using. A 10-block reorg would take 100 minutes on average to catch u=
p, during which the original chain won=E2=80=99t move forward. If fee press=
ure of new transactions is targeted exclusively towards the original chain =
during this time [4], there would be forward pressure that makes reorgs mor=
e expensive. Whether this mitigation is sufficient is an open question.<br>=
<br>Finally, it is worth asking whether BMM interferes too much with the ex=
isting incentive structure of Bitcoin. I don=E2=80=99t have a clear answer,=
but it should be noted that a much more inefficient version of BMM is alre=
ady possible today. One could simply use up lots of block space instead of =
specifying a unique location for the hash, as demonstrated by Veriblock [5]=
. I therefore believe that the same argument as adding data via op_return a=
pplies here -- if it=E2=80=99s not supported, more wasteful methods may be =
utilized instead.<br><br>Some technical details (thanks to Anthony Towns fo=
r providing his insights):<br><br>- Since the exact signature is committed =
to ahead of time, private key security is actually irrelevant. You can simp=
ly use G to replace both R and P instead of the usual s =3D r + e*p. This m=
eans anyone can easily pre-compute all the sighash_anyprevout signatures wi=
th s =3D 1 + e.<br><br>- Assuming taproot, the spending script will be insi=
de a taproot leaf, meaning there is a key spend path which should be made u=
nusable in order to enforce the covenant. This can be achieved with a NUMS =
such as hashToCurve(G) =3D =C2=A0H, which can then be used as the internal =
taproot key T =3D H + hash(H||bmm_hash)*G.<br><br>-- Ruben Somsen<br><br><b=
r>[0] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0301.media=
wiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-030=
1.mediawiki</a><br><br>[1] <a href=3D"https://www.mail-archive.com/bitcoin-=
dev@lists.linuxfoundation.org/msg08075.html" target=3D"_blank">https://www.=
mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg08075.html</a><br=
><br>[2] <a href=3D"https://github.com/JeremyRubin/bips/blob/ctv-v2/bip-ctv=
.mediawiki" target=3D"_blank">https://github.com/JeremyRubin/bips/blob/ctv-=
v2/bip-ctv.mediawiki</a><br><br>[3] <a href=3D"https://blockstream.com/elto=
o.pdf" target=3D"_blank">https://blockstream.com/eltoo.pdf</a><br><br>[4] <=
a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Sept=
ember/016352.html" target=3D"_blank">https://lists.linuxfoundation.org/pipe=
rmail/bitcoin-dev/2018-September/016352.html</a><br><br>[5] <a href=3D"http=
s://twitter.com/lopp/status/1081558829454802945" target=3D"_blank">https://=
twitter.com/lopp/status/1081558829454802945</a><br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000872841059a9a9266--
|