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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tamas@bitsofproof.com>) id 1Y0rGZ-0000Ke-RR
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Dec 2014 12:30:15 +0000
X-ACL-Warn:
Received: from wp059.webpack.hosteurope.de ([80.237.132.66])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Y0rGX-0001QH-M5
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Dec 2014 12:30:15 +0000
Received: from [37.143.74.116] (helo=[192.168.0.101]); authenticated
by wp059.webpack.hosteurope.de running ExIM with esmtpsa
(TLS1.0:RSA_AES_128_CBC_SHA1:16)
id 1Y0rGR-0003RM-67; Tue, 16 Dec 2014 13:30:07 +0100
From: Tamas Blummer <tamas@bitsofproof.com>
Content-Type: multipart/signed;
boundary="Apple-Mail=_3F31F3BC-24A3-4B3D-A12D-CA4E69785925";
protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <C90BC633-9BB0-4886-B818-02980ED3D6C4@bitsofproof.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Date: Tue, 16 Dec 2014 13:30:04 +0100
References: <54876653.4020403@certimix.com> <548769FA.5040406@bluematt.me>
<CA+s+GJAe9MeO+Sr0+2BRwu3q-Be5JQt_s_xdnBBEcquXqOyxcA@mail.gmail.com>
<417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
In-Reply-To: <417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com>
X-Mailer: Apple Mail (2.1878.6)
X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1418733013;
cbd51ad8;
X-Spam-Score: 2.1 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.237.132.66 listed in list.dnswl.org]
1.1 TRACKER_ID BODY: Incorporates a tracking ID number
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Y0rGX-0001QH-M5
Subject: Re: [Bitcoin-development] Merged mining a side chain with proof of
burn on parent chain
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 16 Dec 2014 12:30:16 -0000
--Apple-Mail=_3F31F3BC-24A3-4B3D-A12D-CA4E69785925
Content-Type: multipart/alternative;
boundary="Apple-Mail=_18E02D29-AA29-4EB6-BAF1-57F2558051B9"
--Apple-Mail=_18E02D29-AA29-4EB6-BAF1-57F2558051B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Let me be more concrete in implementation details:=20
1) burn transaction sends at least n satoshis to an OP_RETURN h,=20
2) h mod m matches the bitcoin block hash mod m, for the block the burn =
transaction was mined into.
3) The side chain block header hashes to h and also contains the bitcoin =
block hight.
4) a side chain block releases x new side coins
Since the burn hash does not reveal in advance which side chain it will =
be used for, the Bitcoin miner can not selectively block burn mining. =
They will include loosing bets for the Bitcoin fee. Bitcoin miner have =
no advantage over independent burn miner of the side chain.
Anyone who issues a burn transaction that complies the rules 1-3 has 1/m =
the chance to win the next block on the side chain. This implies a fair =
exchange rate of n*m satoshis =3D x side coins (at the margin).
Should two burn transactions fulfill the mod m lottery criteria, then we =
have a competing fork on the side chain. Just as for Bitcoin, the next =
block(s) will pick the winner.=20
To contain fork rate, the parameter m would have to be adjusted =
dynamically, similar to Bitcoins difficulty. It needs to increase if =
fork rate increases and decrease if no valid block is burned with =
Bitcoin blocks. Unfortunately SPV can only prove the existence of a =
transaction, but not the non-existence of an alternative. Therefore the =
fork rate within a block cycle can not be evaluated with SPV proofs.=20
Rational burn miner who frequently faces and loses head-to-head runs =
with a competing forks would increase his bet for the next burn cycle, =
as increasing the individual bet amount has the advantage that if he =
wins his victory is more stable. Remember the side chain trunk is =
selected as the one with highest cumulative burn.
Consequently cumulative burn within an adjustment period (measured in =
Bitcoin blocks) is expected to rise in face of high fork rate. If the =
sample period burn exceeds a target, then it would trigger a rise to the =
lottery criteria m, reducing the fork rate and vs.
Tamas Blummer
Bits of Proof
On Dec 10, 2014, at 8:35 AM, Tamas Blummer <tamas@bitsofproof.com> =
wrote:
>=20
> We spend scarce resources external to the digital realm to create =
Bitcoin. Real world sacrifice is needed to avoid =93nothing at stake=94 =
and sybil attacks. With Bitcoin we now have a scarce resource within the =
digital realm, so it appeals my intuition to re-use it for sacrifice =
instead of linking again an external, real world resource.=20
>=20
> In following I outline a new mining algorithm for side chains, that =
burn Bitcoins to secure them.
>=20
> The side chain block validity rules would require that a transaction =
on the Bitcoin block chain provably destroys Bitcoins with an OP_RET =
output, that contains the hash of the block header of the side chain. To =
also introduce a lottery, the burn transaction=92s hash is required to =
satisfy some function of the block hash it was included in on the =
Bitcoin block chain. For example modulo m of the burn transaction hash =
must match modulo m of the block hash, that is not known in advance.
>=20
> Those who want to mine the side chain will assemble side chain block =
candidates that comply the rules of the side chain, then a Bitcoin =
transaction burning to the hash of the block candidate and submit it to =
the Bitcoin network. Should he burn transaction be included into the =
Bitcoin block chain and the Bitcoin block=92s hash satisfy the lottery =
criteria, then the block candidate can be submitted to extend the side =
chain.
>=20
> A side chain block header sequence would be accepted as side chain =
trunk if a sequence of Bitcoin SPV proofs for burn transactions prove, =
that linked blocks have the highest cumulative burn, if compared to =
alternative sequences.=20
>=20
> The Bitcoin miner will include burn transactions because they offer =
Bitcoin fees. Bitcoin miner can not selectively block side chains since =
the hashes associated with the burn do not disclose which side chain or =
other project they are for. Here you have a =93merged mining=94 that =
does not need Bitcoin miner support or even consent.
>=20
> Mining difficulty of the side chain could be adjusted by stepping up =
the required burn and/or hardening the criteria that links a burn proof =
transaction with the bitcoin block hash it is included in.
>=20
> The difficulty to mine with burn would be dynamic and would also imply =
a floating exchange rate between Bitcoin and the side coin.
>=20
> Tamas Blummer
> Bits of Proof
>=20
> 00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85edd
--Apple-Mail=_18E02D29-AA29-4EB6-BAF1-57F2558051B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>Let me be more concrete in implementation =
details: </div><div><br></div><div>1) burn transaction sends at =
least n satoshis to an OP_RETURN h, </div><div>2) h mod m matches =
the bitcoin block hash mod m, for the block the burn transaction was =
mined into.</div><div>3) The side chain block header hashes to h and =
also contains the bitcoin block hight.</div><div>4) a side chain block =
releases x new side coins</div><div><br></div><div>Since the burn hash =
does not reveal in advance which side chain it will be used for, the =
Bitcoin miner can not selectively block burn mining. They will include =
loosing bets for the Bitcoin fee. Bitcoin miner have no advantage over =
independent burn miner of the side =
chain.</div><div><br></div><div>Anyone who issues a burn transaction =
that complies the rules 1-3 has 1/m the chance to win the next block on =
the side chain. This implies a fair exchange rate of n*m satoshis =3D x =
side coins (at the margin).</div><div><br></div><div>Should two burn =
transactions fulfill the mod m lottery criteria, then we have a =
competing fork on the side chain. Just as for Bitcoin, the next block(s) =
will pick the winner. </div><div><br></div><div>To contain fork =
rate, the parameter m would have to be adjusted dynamically, similar to =
Bitcoins difficulty. It needs to increase if fork rate increases and =
decrease if no valid block is burned with Bitcoin blocks. Unfortunately =
SPV can only prove the existence of a transaction, but not the =
non-existence of an alternative. Therefore the fork rate within a block =
cycle can not be evaluated with SPV =
proofs. </div><div><br></div><div>Rational burn miner who =
frequently faces and loses head-to-head runs with a competing forks =
would increase his bet for the next burn cycle, as increasing the =
individual bet amount has the advantage that if he wins his victory is =
more stable. Remember the side chain trunk is selected as the one with =
highest cumulative burn.</div><div><br></div><div>Consequently =
cumulative burn within an adjustment period (measured in Bitcoin blocks) =
is expected to rise in face of high fork rate. If the sample period burn =
exceeds a target, then it would trigger a rise to the lottery criteria =
m, reducing the fork rate and vs.</div><div><br></div><div =
apple-content-edited=3D"true">
<div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Tamas =
Blummer</div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;">Bits of Proof</div></div>
<br><div><div>On Dec 10, 2014, at 8:35 AM, Tamas Blummer <<a =
href=3D"mailto:tamas@bitsofproof.com">tamas@bitsofproof.com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><br>We spend scarce resources external to the digital =
realm to create Bitcoin. Real world sacrifice is needed to avoid =
=93nothing at stake=94 and sybil attacks. With Bitcoin we now have =
a scarce resource within the digital realm, so it appeals my intuition =
to re-use it for sacrifice instead of linking again an external, real =
world resource. <br><br>In following I outline a new mining algorithm =
for side chains, that burn Bitcoins to secure them.<br><br>The side =
chain block validity rules would require that a transaction on the =
Bitcoin block chain provably destroys Bitcoins with an OP_RET output, =
that contains the hash of the block header of the side chain. To also =
introduce a lottery, the burn transaction=92s hash is required to =
satisfy some function of the block hash it was included in on the =
Bitcoin block chain. For example modulo m of the burn transaction hash =
must match modulo m of the block hash, that is not known in =
advance.<br><br>Those who want to mine the side chain will assemble =
side chain block candidates that comply the rules of the side =
chain, then a Bitcoin transaction burning to the hash of the block =
candidate and submit it to the Bitcoin network. Should he burn =
transaction be included into the Bitcoin block chain and the Bitcoin =
block=92s hash satisfy the lottery criteria, then the block candidate =
can be submitted to extend the side chain.<br><br>A side chain block =
header sequence would be accepted as side chain trunk if a sequence of =
Bitcoin SPV proofs for burn transactions prove, that linked blocks have =
the highest cumulative burn, if compared to alternative sequences. =
<br><br>The Bitcoin miner will include burn transactions because they =
offer Bitcoin fees. Bitcoin miner can not selectively block side chains =
since the hashes associated with the burn do not disclose which side =
chain or other project they are for. Here you have a =93merged mining=94 =
that does not need Bitcoin miner support or even consent.<br><br>Mining =
difficulty of the side chain could be adjusted by stepping up the =
required burn and/or hardening the criteria that links a burn proof =
transaction with the bitcoin block hash it is included in.<br><br>The =
difficulty to mine with burn would be dynamic and would also imply a =
floating exchange rate between Bitcoin and the side coin.<br><br>Tamas =
Blummer<br>Bits of =
Proof<br><br>00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85=
edd<br></blockquote></div><br></body></html>=
--Apple-Mail=_18E02D29-AA29-4EB6-BAF1-57F2558051B9--
--Apple-Mail=_3F31F3BC-24A3-4B3D-A12D-CA4E69785925
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJUkCXMAAoJEPZykcUXcTkcj4oIALrQ22bNJ8fbE47zvr06QRoR
bUF/4G8QELCV8gUBEaqLhrLeSwJvAFZWjMUWFqVWnhOW/ElIPRWFFXYqhfWJ+ibp
GKyHCGspM4jnKCJY3p/9r83ghEgxuDqMlGU+X6mFCzXhbf10Am+BvDC0Sd5ndUQI
ofyNuZx89D++7AESp54gpCvPb4TaRe3bG9sRSVbdH+F/w5k1l8Kiw8k1rf3AJQa3
E5EmK6RXjA7QQfIAIfNoHF3Dw8rPqmUiY+0vR0gNO1nmNqWOH5a633XQle1EpntZ
Rc7MU5xB3N/mw1x0QGj462ovmVa1jjXi1plRAmo7nNDpmtTQZsaLCM1n/2LYZsg=
=pU3A
-----END PGP SIGNATURE-----
--Apple-Mail=_3F31F3BC-24A3-4B3D-A12D-CA4E69785925--
|
