summaryrefslogtreecommitdiff
path: root/82/8bf3fcfdd52484b3625c8a6d5f2d87b28828c9
blob: 5415e1523107435005bdb708855db43e4fdc8782 (plain)
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
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9E3F49E8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Aug 2017 13:38:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com
	[209.85.218.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 77DA7443
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Aug 2017 13:38:28 +0000 (UTC)
Received: by mail-oi0-f52.google.com with SMTP id g131so66295869oic.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Aug 2017 06:38:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=Jj/tX6nzlkspvA8fQAbGqet5MJjHYEyJwBWgMGymsoU=;
	b=tXzsNm+9TYwDEuCp73czJgbELn+yvlAMsMwyCewBTK952arBJhDS2Gw5IF9ljbxptg
	iZbhsSqtSeb43xBjwZ6MIJIjkzfrmHBQf6SbS0i1npiRJFltA2POpsNT3awwHwH5TPfO
	HLo2MjjYby0xh8fqVStL1ljsoOjcFety623g9Gtz4fVGg+JO271lkUggSlwzKgq7EWIj
	5NePe0IDKe6BuHVmsXY/S1sJ9IMAs6F27pI9YHjUjW85gxYuGHgYYvyn/icNwevVO5GP
	5Y4TFwDLfOt+Bn2UaGBMlNYj8miSOzPSjN7ytxAqxTBt3wrmMsXO02Q6zk5Gfx5sUxBC
	zMWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=Jj/tX6nzlkspvA8fQAbGqet5MJjHYEyJwBWgMGymsoU=;
	b=JhUbbkS+An6skzFq/P2XQDEuXbKbI1J+eHC2cSkHCVz6UvuPELogWuVnMwKNJep4ki
	GlgSO2wQ4E7AiXxt/WJSanbbYHsuGixJknyLdpjbvA06dyfU8ZK62kgyEAvStd/Qu3OY
	wP2ugjEDj5VrnNh27uTlYJ6QAyPaA435LYpjsVf9VaxmLZEleMjpv2OGDHQVP6+L5rdU
	pSFvQ28P5bILT5q18jizQdaQ4JV40YmuLEhAMjFmQ3e04iVnupjBB4EQdF3k3ewELRM0
	AxNb9KFtRS7y35zd7NjvwvSrmmEOMYT/LL/2n1nOu4xFem8O06BeiaM6Jb6jl4nvsIZP
	Cgxg==
X-Gm-Message-State: AHYfb5hBPgIG93HZoVYeIVE7kaJHbtKvwEDGLZGfTotuJgDvyXStlCfi
	lfR1QO3YV5B2pUXZmcLLzyk5OT0ciw==
X-Received: by 10.202.214.145 with SMTP id n139mr7209288oig.48.1502977107526; 
	Thu, 17 Aug 2017 06:38:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.18.227 with HTTP; Thu, 17 Aug 2017 06:38:26 -0700 (PDT)
Received: by 10.58.18.227 with HTTP; Thu, 17 Aug 2017 06:38:26 -0700 (PDT)
In-Reply-To: <CADc9zGCr127JPn_hHO+==PZUEVUFvF2a66M+BY9i78xciqX8+w@mail.gmail.com>
References: <CAKhySQxKvR+1g8Y-OeDjAZj2jDgHub2iJceu_y44t0b+prKYXQ@mail.gmail.com>
	<CALxbBHU-_sC7Qr=U5TMtB_Gs6fe1QnskAaYrLhp1_7Zqc-m8cg@mail.gmail.com>
	<CABaSBaxNc2rSPBhqicBakpCkVtg8YOhLs7ecC2XwKfV4fM34iw@mail.gmail.com>
	<CADc9zGCr127JPn_hHO+==PZUEVUFvF2a66M+BY9i78xciqX8+w@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 17 Aug 2017 15:38:26 +0200
Message-ID: <CAAt2M186D-FSOXr15Y+UoBKwzuH14y5XArfg3Toq=TCwzDiZVg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>, 
	Conrad Burchert <conrad.burchert@googlemail.com>
Content-Type: multipart/alternative; boundary="001a113dda34998d250556f32099"
Subject: Re: [bitcoin-dev] Fwd: [Lightning-dev] Lightning in the setting of
 blockchain hardforks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 17 Aug 2017 13:38:28 -0000

--001a113dda34998d250556f32099
Content-Type: text/plain; charset="UTF-8"

Couldn't scripts like this have a standardized "hardfork unroll" mechanism,
where if a hardfork is activated and signaled to its clients, then those
commitments that are only meant for their original chain can be reversed
and undone just on the hardfork? Then the users involved would just send an
unroll transaction which is only valid on the hardfork.

- Sent from my phone

Den 17 aug. 2017 14:52 skrev "Conrad Burchert via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:

> Some notes:
>
> Hardforks like Bitcoin ABC without a malleability fix are very unlikely to
> have payment channels, so the problem does not exist for those.
>
> The designers of a hardfork which does have a malleability fix will
> probably know about payment channels, so they can just build a replay
> protection that allows the execution of old commitments. That needs some
> kind of timestamping of commitments, which would have to be integrated in
> the channel design. The easiest way would be to just write the time of
> signing the commitment in the transaction and the replay protection accepts
> old commitments, but rejects one's which were signed after the hardfork.
> These timestamps can essentially be one bit (before or after a hardfork)
> and if the replay protection in the hardfork only accepts old commitments
> for something like a year, then it can be reused for more hardforks later
> on. Maybe someone comes up with an interesting way of doing this without
> using space.
>
> Nevertheless hardforking while having channels open will always be a mess
> as an open channel requires you to watch the blockchain. Anybody who is
> just not aware of the hardfork or is updating his client a few days too
> late, can get his money stolen by an old commitment transaction where he
> forgets to retaliate on the new chain. As other's can likely figure out
> your client version the risk of retaliation is not too big for an attacker.
>
>
>
> 2017-08-17 13:31 GMT+02:00 Bryan Bishop via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>>
>> ---------- Forwarded message ----------
>> From: Christian Decker <decker.christian@gmail.com>
>> Date: Thu, Aug 17, 2017 at 5:39 AM
>> Subject: Re: [Lightning-dev] Lightning in the setting of blockchain
>> hardforks
>> To: Martin Schwarz <martin.schwarz@gmail.com>,
>> lightning-dev@lists.linuxfoundation.org
>>
>>
>> Hi Martin,
>>
>> this is the perfect venue to discuss this, welcome to the mailing list :-)
>> Like you I think that using the first forked block as the forkchain's
>> genesis block is the way to go, keeping the non-forked blockchain on the
>> original genesis hash, to avoid disruption. It may become more difficult in
>> the case one chain doesn't declare itself to be the forked chain.
>>
>> Even more interesting are channels that are open during the fork. In
>> these cases we open a single channel, and will have to settle two. If no
>> replay protection was implemented on the fork, then we can use the last
>> commitment to close the channel (updates should be avoided since they now
>> double any intended effect), if replay protection was implemented then
>> commitments become invalid on the fork, and people will lose money.
>>
>> Fun times ahead :-)
>>
>> Cheers,
>> Christian
>>
>> On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz <martin.schwarz@gmail.com>
>> wrote:
>>
>>> Dear all,
>>>
>>> currently the chain_id allows to distinguish blockchains by the hash of
>>> their genesis block.
>>>
>>> With hardforks branching off of the Bitcoin blockchain, how can
>>> Lightning work on (or across)
>>> distinct, permanent forks of a parent blockchain that share the same
>>> genesis block?
>>>
>>> I suppose changing the definition of chain_id to the hash of the first
>>> block of the new
>>> branch and requiring replay and wipe-out protection should be
>>> sufficient. But can we
>>> relax these requirements? Are slow block times an issue? Can we use
>>> Lightning to transact
>>> on "almost frozen" block chains suffering from a sudden loss of
>>> hashpower?
>>>
>>> Has there been any previous discussion or study of Lightning in the
>>> setting of hardforks?
>>> (Is this the right place to discuss this? If not, where would be the
>>> right place?)
>>>
>>> thanks,
>>> Martin
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>>
>>
>> --
>> - Bryan
>> http://heybryan.org/
>> 1 512 203 0507 <(512)%20203-0507>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"auto">Couldn&#39;t scripts like this have a standardized &quot;=
hardfork unroll&quot; mechanism, where if a hardfork is activated and signa=
led to its clients, then those commitments that are only meant for their or=
iginal chain can be reversed and undone just on the hardfork? Then the user=
s involved would just send an unroll transaction which is only valid on the=
 hardfork.=C2=A0<br><br><div data-smartmail=3D"gmail_signature">- Sent from=
 my phone</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">Den 17 aug. 2017 14:52 skrev &quot;Conrad Burchert via bitcoin-dev&quot=
; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt;:<br type=3D"attribution"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>Some notes:<br></div><div><br></div><d=
iv>Hardforks like Bitcoin ABC without a malleability fix are very unlikely =
to have payment channels, so the problem does not exist for those.</div><di=
v><br></div><div>The designers of a hardfork which does have a malleability=
 fix will probably know about payment channels, so they can just build a re=
play protection that allows the execution of old commitments. That needs so=
me kind of timestamping of commitments, which would have to be integrated i=
n the channel design. The easiest way would be to just write the time of si=
gning the commitment in the transaction and the replay protection accepts o=
ld commitments, but rejects one&#39;s which were signed after the hardfork.=
 These timestamps can essentially be one bit (before or after a hardfork) a=
nd if the replay protection in the hardfork only accepts old commitments fo=
r something like a year, then it can be reused for more hardforks later on.=
 Maybe someone comes up with an interesting way of doing this without using=
 space.</div><div><br></div><div>Nevertheless hardforking while having chan=
nels open will always be a mess as an open channel requires you to watch th=
e blockchain. Anybody who is just not aware of the hardfork or is updating =
his client a few days too late, can get his money stolen by an old commitme=
nt transaction where he forgets to retaliate on the new chain. As other&#39=
;s can likely figure out your client version the risk of retaliation is not=
 too big for an attacker.</div><div><br></div><div><br></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-08-17 13:31 GMT+02:0=
0 Bryan Bishop via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr=
>linuxfoundation.org</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><div class=3D"m_-8170959235983589267h5"><br><div class=3D=
"gmail_quote">---------- Forwarded message ----------<br>From: <b class=3D"=
gmail_sendername">Christian Decker</b> <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:decker.christian@gmail.com" target=3D"_blank">decker.christian@gmail.co=
m</a>&gt;</span><br>Date: Thu, Aug 17, 2017 at 5:39 AM<br>Subject: Re: [Lig=
htning-dev] Lightning in the setting of blockchain hardforks<br>To: Martin =
Schwarz &lt;<a href=3D"mailto:martin.schwarz@gmail.com" target=3D"_blank">m=
artin.schwarz@gmail.com</a>&gt;, <a href=3D"mailto:lightning-dev@lists.linu=
xfoundation.org" target=3D"_blank">lightning-dev@lists.linuxfound<wbr>ation=
.org</a><br><br><br><div dir=3D"ltr">Hi Martin,<div><br></div><div>this is =
the perfect venue to discuss this, welcome to the mailing list :-)</div><di=
v>Like you I think that using the first forked block as the forkchain&#39;s=
 genesis block is the way to go, keeping the non-forked blockchain on the o=
riginal genesis hash, to avoid disruption. It may become more difficult in =
the case one chain doesn&#39;t declare itself to be the forked chain.</div>=
<div><br></div><div>Even more interesting are channels that are open during=
 the fork. In these cases we open a single channel, and will have to settle=
 two. If no replay protection was implemented on the fork, then we can use =
the last commitment to close the channel (updates should be avoided since t=
hey now double any intended effect), if replay protection was implemented t=
hen commitments become invalid on the fork, and people will lose money.</di=
v><div><br></div><div>Fun times ahead :-)</div><div><br></div><div>Cheers,<=
/div><div>Christian</div></div><br><div class=3D"gmail_quote"><div><div cla=
ss=3D"m_-8170959235983589267m_8531517743362604424h5"><div dir=3D"ltr">On Th=
u, Aug 17, 2017 at 10:53 AM Martin Schwarz &lt;<a href=3D"mailto:martin.sch=
warz@gmail.com" target=3D"_blank">martin.schwarz@gmail.com</a>&gt; wrote:<b=
r></div></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"m_-81=
70959235983589267m_8531517743362604424h5"><div dir=3D"ltr"><div>Dear all,</=
div><div><br></div><div>currently the chain_id allows to distinguish blockc=
hains by the hash of their genesis block.</div><div><br></div><div>With har=
dforks branching off of the Bitcoin blockchain, how can Lightning work on (=
or across)</div><div>distinct, permanent forks of a parent blockchain that =
share the same genesis block?</div><div><br></div><div>I suppose changing t=
he definition of chain_id to the hash of the first block of the new</div><d=
iv>branch and requiring replay and wipe-out protection should be sufficient=
. But can we=C2=A0</div><div>relax these requirements? Are slow block times=
 an issue? Can we use Lightning to transact</div><div>on &quot;almost froze=
n&quot; block chains suffering from a sudden loss of hashpower?</div><div><=
br></div><div>Has there been any previous discussion or study of Lightning =
in the setting of hardforks?</div><div>(Is this the right place to discuss =
this? If not, where would be the right place?)</div><div><br></div><div>tha=
nks,</div><div>Martin</div></div></div></div>
______________________________<wbr>_________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfound<wbr>ation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>o=
rg/mailman/listinfo/lightning<wbr>-dev</a><br>
</blockquote></div>
<br>______________________________<wbr>_________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfound<wbr>ation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>o=
rg/mailman/listinfo/lightning<wbr>-dev</a><br>
<br></div><br><br clear=3D"all"><div><br></div></div></div>-- <br><div clas=
s=3D"m_-8170959235983589267m_8531517743362604424gmail_signature" data-smart=
mail=3D"gmail_signature">- Bryan<br><a href=3D"http://heybryan.org/" target=
=3D"_blank">http://heybryan.org/</a><br><a href=3D"tel:(512)%20203-0507" va=
lue=3D"+15122030507" target=3D"_blank">1 512 203 0507</a></div>
</div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div></div>

--001a113dda34998d250556f32099--