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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tamas@bitsofproof.com>) id 1Y0VMI-0004aK-NI
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Dec 2014 13:06:42 +0000
X-ACL-Warn:
Received: from wp059.webpack.hosteurope.de ([80.237.132.66])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Y0VMG-0004Vx-IF
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Dec 2014 13:06:42 +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 1Y0VM9-0005xl-Pi; Mon, 15 Dec 2014 14:06:33 +0100
Content-Type: multipart/signed;
boundary="Apple-Mail=_FB760CE6-E0E4-4E53-B917-6B6144B0B6CF";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Tamas Blummer <tamas@bitsofproof.com>
In-Reply-To: <20141215123942.GA28381@savin.petertodd.org>
Date: Mon, 15 Dec 2014 14:06:32 +0100
Message-Id: <709AAA00-A40A-42EF-A17D-9B3E07FE902A@bitsofproof.com>
References: <417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com>
<CA+s+GJAe9MeO+Sr0+2BRwu3q-Be5JQt_s_xdnBBEcquXqOyxcA@mail.gmail.com>
<20141211120916.E912EE22B92@quidecco.de>
<B8D7AE7E-567E-4656-9231-17EEAD6ED603@bitsofproof.com>
<AEDF060A-17E7-4519-950A-30974D1520E3@bitsofproof.com>
<20141215123942.GA28381@savin.petertodd.org>
To: Peter Todd <pete@petertodd.org>
X-Mailer: Apple Mail (2.1878.6)
X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1418648800;
e44f5a56;
X-Spam-Score: 1.0 (+)
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.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Y0VMG-0004Vx-IF
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: Mon, 15 Dec 2014 13:06:42 -0000
--Apple-Mail=_FB760CE6-E0E4-4E53-B917-6B6144B0B6CF
Content-Type: multipart/alternative;
boundary="Apple-Mail=_5F22290B-0424-492B-867E-BE02C7840005"
--Apple-Mail=_5F22290B-0424-492B-867E-BE02C7840005
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Peter,
Thanks for the research, I am glad that the idea, that proof-of-burn can =
=93transfer" proof-of-work=20
was discussed earlier, as those discussions give some attack vectors =
that I can reevaluate in=20
a new context, that is side chains.=20
I think that the lottery component I suggested, makes it much more =
resilient to =93outspend=94 attack, since
the attacker not only needs to outspend but win the lottery for a reorg. =
This raises the cost of the attack
by magnitudes above the regular miner burn cost.
In addition, I suggest the burn transaction to include the Bitcoin block =
height, thereby disabling re-use of a burn,
for a later reorg.
Tamas Blummer
Bits of Proof
On Dec 15, 2014, at 1:39 PM, Peter Todd <pete@petertodd.org> wrote:
> On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer wrote:
>> Burn mining side chains might be one of the foundation ideas for that =
ecosystem, enabling permission-less merge mining for
>> anyone with interest in a side chain.
>>=20
>> I am puzzled by the lack of feedback on the idea.
>=20
> It's not a new idea actually - I outlined a system I eventually called
> "zookeyv"=B9 based on the notion of sacrificing Bitcoins to achieve
> consensus a year and a half ago on #bitcoin-wizards. The discussion
> started here and continued for a few days:
>=20
> https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.log
>=20
> I later wrote up the idea in the context of adding Zerocoin to =
Bitcoin:
>=20
> =
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg0=
2472.html
>=20
> For key-value mapping I eventually decided that the system didn't
> necessarily need to be a strict linear blockchain - a directed acyclic
> graph of commitments had advantages as there needed to be less
> syncronization between transactions. This also means that the graph
> doesn't necessarily need to be revealed directly in the blockchain,
> exposing it to miner censorship. OTOH revealing it makes it easy to
> determine if an attacker larger than you exists. These days I'd =
suggest
> using timelock crypto to defeat miner censorship, while ensuring that =
in
> principle consensus over all possible parts of the chain can =
eventually
> be reached.=B2
>=20
> Proof-of-sacrifice for consensus has a few weird properties. For
> instance you can defeat attackers after the fact by simply sacrificing
> more than the attacker. Not unlike having a infinite amount of mining
> equipment available with the only constraint being funds to pay for =
the
> electricity. (which *is* semi-true with altcoins!)
>=20
> As for your specific example, you can improve it's censorship =
resistance
> by having the transactions commit to a nonce in advance in some way
> indistinguishable from normal transactions, and then making the
> selection criteria be some function of H(nonce | blockhash) - for
> instance highest wins. So long as the chain selection is based on
> cumulative difficulty based on a fixed target - as is the case in
> Bitcoin proper - you should get a proper incentive to publish blocks, =
as
> well as the "total work information rachet" effect Bitcoin has against
> attackers.
>=20
>=20
> 1) In honor of Zooko's triangle.
>=20
> 2) This doesn't necessarily take as much work as you might expect: you
> can work backwards from the most recent block(s) if the scheme
> requires block B_i to include the decryption key for block B_{i-1}.
>=20
> --=20
> 'peter'[:-1]@petertodd.org
> 000000000000000018d439a78581d2a9ecd762a2b37dd5b403a82beb58dcbc7c
--Apple-Mail=_5F22290B-0424-492B-867E-BE02C7840005
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>Peter,</div><div><br></div><div>Thanks for the =
research, I am glad that the idea, that proof-of-burn can =93transfer" =
proof-of-work </div><div>was discussed earlier, as those =
discussions give some attack vectors that I can reevaluate =
in </div><div>a new context, that is side =
chains. </div><div><br></div><div>I think that the lottery =
component I suggested, makes it much more resilient to =93outspend=94 =
attack, since</div><div>the attacker not only needs to outspend but win =
the lottery for a reorg. This raises the cost of the attack</div><div>by =
magnitudes above the regular miner burn =
cost.</div><div><br></div><div>In addition, I suggest the burn =
transaction to include the Bitcoin block height, thereby disabling =
re-use of a burn,</div><div>for a later reorg.</div><br><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 15, 2014, at 1:39 PM, Peter Todd <<a =
href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer =
wrote:<br><blockquote type=3D"cite">Burn mining side chains might be one =
of the foundation ideas for that ecosystem, enabling permission-less =
merge mining for<br>anyone with interest in a side chain.<br><br>I am =
puzzled by the lack of feedback on the idea.<br></blockquote><br>It's =
not a new idea actually - I outlined a system I eventually =
called<br>"zookeyv"=B9 based on the notion of sacrificing Bitcoins to =
achieve<br>consensus a year and a half ago on #bitcoin-wizards. The =
discussion<br>started here and continued for a few days:<br><br><a =
href=3D"https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.l=
og">https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.log</=
a><br><br>I later wrote up the idea in the context of adding Zerocoin to =
Bitcoin:<br><br>http://www.mail-archive.com/bitcoin-development@lists.sour=
ceforge.net/msg02472.html<br><br>For key-value mapping I eventually =
decided that the system didn't<br>necessarily need to be a strict linear =
blockchain - a directed acyclic<br>graph of commitments had advantages =
as there needed to be less<br>syncronization between transactions. This =
also means that the graph<br>doesn't necessarily need to be revealed =
directly in the blockchain,<br>exposing it to miner censorship. OTOH =
revealing it makes it easy to<br>determine if an attacker larger than =
you exists. These days I'd suggest<br>using timelock crypto to defeat =
miner censorship, while ensuring that in<br>principle consensus over all =
possible parts of the chain can eventually<br>be =
reached.=B2<br><br>Proof-of-sacrifice for consensus has a few weird =
properties. For<br>instance you can defeat attackers after the fact by =
simply sacrificing<br>more than the attacker. Not unlike having a =
infinite amount of mining<br>equipment available with the only =
constraint being funds to pay for the<br>electricity. (which *is* =
semi-true with altcoins!)<br><br>As for your specific example, you can =
improve it's censorship resistance<br>by having the transactions commit =
to a nonce in advance in some way<br>indistinguishable from normal =
transactions, and then making the<br>selection criteria be some function =
of H(nonce | blockhash) - for<br>instance highest wins. So long as the =
chain selection is based on<br>cumulative difficulty based on a fixed =
target - as is the case in<br>Bitcoin proper - you should get a proper =
incentive to publish blocks, as<br>well as the "total work information =
rachet" effect Bitcoin has against<br>attackers.<br><br><br>1) In honor =
of Zooko's triangle.<br><br>2) This doesn't necessarily take as much =
work as you might expect: you<br> can work backwards from =
the most recent block(s) if the scheme<br> requires block =
B_i to include the decryption key for block B_{i-1}.<br><br>-- =
<br>'peter'[:-1]@petertodd.org<br>000000000000000018d439a78581d2a9ecd762a2=
b37dd5b403a82beb58dcbc7c<br></blockquote></div><br></body></html>=
--Apple-Mail=_5F22290B-0424-492B-867E-BE02C7840005--
--Apple-Mail=_FB760CE6-E0E4-4E53-B917-6B6144B0B6CF
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
iQEcBAEBCgAGBQJUjtzYAAoJEPZykcUXcTkcspQH/iIohpunKCq2JMdI9RCjehHy
7YA+TMliFl25beX5AOum0TiXS1j4xnKKYeEkOoff0CnlvFqO95Ii0UgT6wW9iBU8
l77RiHd4tF+loEvlYs7KfhfRBJ4VkxTvJBH7cJ1bOJtrmlgC1MAV3P8Bj+BI+sv3
CHn7+OkoJkviuvIwZOJYiPXXLM2zp1P7EUJ3yb/QS7ye1NovvHQzOo6VEnH+HwqQ
iKsyEqK2X4me41ahjlqtUcZi577PERsjGtv1P4G7fV+ZTVYiQ7k9FkWoz6mhndqp
XrySeS2kw8vPkN+v6W6G8lkEwXG1kj19LtkLqzC9e7qcj4PYJ7+Ec2/Z4MAyXyE=
=74tg
-----END PGP SIGNATURE-----
--Apple-Mail=_FB760CE6-E0E4-4E53-B917-6B6144B0B6CF--
|
