summaryrefslogtreecommitdiff
path: root/0e/1b5799c3da36ad2d9120bdda14feb544383150
blob: 3e2f6fdc722ce96df5340c9b288ff24dc67954dd (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
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B7B7E7A8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Apr 2017 10:14:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E313156
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Apr 2017 10:14:43 +0000 (UTC)
Received: from [192.168.1.111] (137.189.135.19 [137.189.135.19]) by
	mx.zohomail.com with SMTPS id 14918192803341021.1129005954127;
	Mon, 10 Apr 2017 03:14:40 -0700 (PDT)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <F322F899-8748-407D-884F-95EFBD3C7F99@xbt.hk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E0DAA63D-FD2A-4DBE-BBB1-04206D346AD1"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Mon, 10 Apr 2017 18:14:36 +0800
In-Reply-To: <20170405174343.GA7180@gmail.com>
To: Christopher Jeffrey <chjj@purse.io>
References: <20170405174343.GA7180@gmail.com>
X-Mailer: Apple Mail (2.3259)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
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: Mon, 10 Apr 2017 10:14:44 -0000


--Apple-Mail=_E0DAA63D-FD2A-4DBE-BBB1-04206D346AD1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 6 Apr 2017, at 01:43, Christopher Jeffrey <chjj@purse.io> wrote:
>=20
>=20
>> This hits the biggest question I asked in my January post: do you =
want
>> to allow direct exit payment to legacy addresses? As a block reorg
>> will almost guarantee changing txid of the resolution tx, that will
>> permanently invalidate all the child txs based on the resolution tx.
>> This is a significant change to the current tx model. To fix this, =
you
>> need to make exit outputs unspendable for up to 100 blocks. Doing
>> this, however, will make legacy wallet users very confused as they do
>> not anticipate funding being locked up for a long period of time. So
>> you can=E2=80=99t let the money sent back to a legacy address =
directly, but
>> sent to a new format address that only recognized by new wallet, =
which
>> understands the lock up requirement. This way, however, introduces
>> friction and some fungibility issues, and I=E2=80=99d expect people =
using
>> cross chain atomic swap to exchange bitcoin and xbitcoin
>=20
> Yes, this issue is probably the biggest edge case in the proposal.
>=20
> I think there's two possible solutions:
>=20
> First solution:
>=20
> Like you said, add a maturity requirement for exiting outputs. Likely
> lower than coinbase's 100 block requirement. To solve the issue of
> non-upgraded wallets not being aware of this rule and spending early,
> have upgraded mempool implementations accept/relay txs that contain
> early spends of exits, but not mine them until they are mature. This =
way
> non-upgraded wallets do not end up broadcasting transactions that are
> considered invalid to the rest of the network.

This won=E2=80=99t solve the problem. Think about the following =
conversation:

Alice (not upgraded): Please pay 1 BTC to my address 1ALicExyz
Bob (upgraded): ok, paid, please check

10 minutes later

Alice: received and confirmed, thanks!

5 minutes later:

Carol (not upgraded): Please pay 0.5BTC to my address 3CaroLXXX
Alice: paid, please check

1 hour later:

Carol: it=E2=80=99s not confirmed. Have you paid enough fees?
Alice: ok, I=E2=80=99ll RBF/CPFP it

2 hours later:

Carol: it=E2=80=99s still not confirmed.
Alice: I have already paid double fees. Maybe the network is congested =
and I need to pay more=E2=80=A6..

Repeat until the lock up period ends.

So this so-called =E2=80=9Csoftfork=E2=80=9D actually made non-upgraded =
wallet totally unusable. If failed to meet the very important =
requirement of a softfork: backward compatibility

More discussion:
=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013985.=
html =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013985=
.html>


>=20
> Depending on how wallets handle reorgs, a non-upgraded wallet may put
> reorg'd spend chains from exits back into an unconfirmed state, when =
in
> reality they should probably delete them or mark them conflicted in =
some
> way. This may be an acceptable compromise as the wallet will still see
> the funds as unconfirmed when they really don't exist anymore, but =
maybe
> unconfirmed is good enough. Users are pretty used to dropping
> non-confirming txs from their wallet, and this is much better than
> legacy wallets seeing there funds as confirmed when they could be
> permanently reorged out at any moment.
>=20
> Second solution:
>=20
> Move all exiting outputs to the coinbase. This will enforce a 100 =
block
> maturity requirement and non-upgraded wallets will be aware of this.

This is also unacceptable.

When someone says "Please pay 1 BTC to my address 1ALicExyz=E2=80=9D, no =
one anticipates being paid by a coinbase output. Some exchanges like =
btc-e explicitly reject coinbase payment.

Such deterioration in user experience is unacceptable. It basically =
forces everyone to upgrade, i.e. a hardfork with soft fork=E2=80=99s =
skin



>=20
> The first solution might require more implementation, but allows more
> flexibility with the maturity requirement. The second solution is
> possibly simpler, but sticks to a hard 100 block limit.
>=20
>> 1. Is it acceptable to have massive txid malleability and transaction
>> chain invalidation for every natural happening reorg?  Yes: the
>> current spec is ok; No: next question (I=E2=80=99d say no)
>=20
> Answered above.
>=20
>> 2. Is locking up exit outputs the best way to deal with the problem?
>> (I tried really hard to find a better solution but failed)
>=20
> You've probably thought about this more than anyone, so I'd say yes, =
it
> may be the only way. Painful, but necessary.
>=20
>> 3. How long the lock-up period should be? Answer could be anywhere
>> from 1 to 100
>=20
> I imagine having something lower than 100 would be preferable to =
users,
> maybe somewhere in the 5 to 15 range. A 15 block reorg on mainnet is
> seriously unlikely unless something strange is happening. A 5 block
> reorg is still pretty unlikely, but possible. The coinbase solution =
only
> allows for 100 blocks though.
>=20
>> 4. With a lock-up period, should it allow direct exit to legacy
>> address? (I think it=E2=80=99s ok if the lock-up is short, like 1-2 =
block. But
>> is that safe enough?)
>=20
> I think so. Adding a kind of special address probably creates more
> issues than it solves.


As I explained above, no legacy wallet would anticipate a lock up. If =
you want to make a softfork, all burden of incompatibility must be taken =
by the upgraded system. Only allow exit to a new address guarantees that =
only upgraded wallet will see the locked-up tx:

=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/01349=
0.html =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/0134=
90.html>
>=20
>> 5. Due to the fungibility issues, it may need a new name for the
>> tokens in the ext-block
>=20
> I suppose the market will decide whether that's the case.
>=20
> It's worth noting, if segwit is not activated on the mainchain, it
> creates a much bigger incentive to use the extension block, and
> potentially ensures that users will have less of a reason to exit.
>=20

I think it=E2=80=99s unacceptable if malleability is not fixed in main =
chain, for 3 reasons:=20

1. a solution is *already* available and tested for > 1 year.

2. the deactivation design (which I think is an interesting idea) makes =
the ext block unsuitable for long-term storage of value.

3. LN over main chain allows instant exchange of main coin and xcoin =
without going through the ugly 2-way-peg process.




--Apple-Mail=_E0DAA63D-FD2A-4DBE-BBB1-04206D346AD1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 6 Apr 2017, at 01:43, Christopher Jeffrey &lt;<a =
href=3D"mailto:chjj@purse.io" class=3D"">chjj@purse.io</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">This hits =
the biggest question I asked in my January post: do you want<br =
class=3D"">to allow direct exit payment to legacy addresses? As a block =
reorg<br class=3D"">will almost guarantee changing txid of the =
resolution tx, that will<br class=3D"">permanently invalidate all the =
child txs based on the resolution tx.<br class=3D"">This is a =
significant change to the current tx model. To fix this, you<br =
class=3D"">need to make exit outputs unspendable for up to 100 blocks. =
Doing<br class=3D"">this, however, will make legacy wallet users very =
confused as they do<br class=3D"">not anticipate funding being locked up =
for a long period of time. So<br class=3D"">you can=E2=80=99t let the =
money sent back to a legacy address directly, but<br class=3D"">sent to =
a new format address that only recognized by new wallet, which<br =
class=3D"">understands the lock up requirement. This way, however, =
introduces<br class=3D"">friction and some fungibility issues, and I=E2=80=
=99d expect people using<br class=3D"">cross chain atomic swap to =
exchange bitcoin and xbitcoin<br class=3D""></blockquote><br =
class=3D"">Yes, this issue is probably the biggest edge case in the =
proposal.<br class=3D""><br class=3D"">I think there's two possible =
solutions:<br class=3D""><br class=3D"">First solution:<br class=3D""><br =
class=3D"">Like you said, add a maturity requirement for exiting =
outputs. Likely<br class=3D"">lower than coinbase's 100 block =
requirement. To solve the issue of<br class=3D"">non-upgraded wallets =
not being aware of this rule and spending early,<br class=3D"">have =
upgraded mempool implementations accept/relay txs that contain<br =
class=3D"">early spends of exits, but not mine them until they are =
mature. This way<br class=3D"">non-upgraded wallets do not end up =
broadcasting transactions that are<br class=3D"">considered invalid to =
the rest of the network.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>This won=E2=80=99t solve the problem. Think about =
the following conversation:</div><div><br class=3D""></div><div>Alice =
(not upgraded): Please pay 1 BTC to my address 1ALicExyz</div><div>Bob =
(upgraded): ok, paid, please check</div><div><br class=3D""></div><div>10 =
minutes later</div><div><br class=3D""></div><div>Alice: received and =
confirmed, thanks!</div><div><br class=3D""></div><div>5 minutes =
later:</div><div><br class=3D""></div><div>Carol (not upgraded): Please =
pay 0.5BTC to my address 3CaroLXXX</div><div>Alice: paid, please =
check</div><div><br class=3D""></div><div>1 hour later:</div><div><br =
class=3D""></div><div>Carol: it=E2=80=99s not confirmed. Have you paid =
enough fees?</div><div>Alice: ok, I=E2=80=99ll RBF/CPFP it</div><div><br =
class=3D""></div><div>2 hours later:</div><div><br =
class=3D""></div><div>Carol: it=E2=80=99s still not =
confirmed.</div><div>Alice: I have already paid double fees. Maybe the =
network is congested and I need to pay more=E2=80=A6..</div><div><br =
class=3D""></div><div>Repeat until the lock up period =
ends.</div><div><br class=3D""></div><div>So this so-called =
=E2=80=9Csoftfork=E2=80=9D actually made non-upgraded wallet totally =
unusable. If failed to meet the very important requirement of a =
softfork: backward compatibility</div><div><br class=3D""></div><div>More =
discussion:</div><div><a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April=
/013985.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ap=
ril/013985.html</a></div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""><br class=3D"">Depending on how wallets handle reorgs, a =
non-upgraded wallet may put<br class=3D"">reorg'd spend chains from =
exits back into an unconfirmed state, when in<br class=3D"">reality they =
should probably delete them or mark them conflicted in some<br =
class=3D"">way. This may be an acceptable compromise as the wallet will =
still see<br class=3D"">the funds as unconfirmed when they really don't =
exist anymore, but maybe<br class=3D"">unconfirmed is good enough. Users =
are pretty used to dropping<br class=3D"">non-confirming txs from their =
wallet, and this is much better than<br class=3D"">legacy wallets seeing =
there funds as confirmed when they could be<br class=3D"">permanently =
reorged out at any moment.<br class=3D""><br class=3D"">Second =
solution:<br class=3D""><br class=3D"">Move all exiting outputs to the =
coinbase. This will enforce a 100 block<br class=3D"">maturity =
requirement and non-upgraded wallets will be aware of this.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>This =
is also unacceptable.</div><div><br class=3D""></div><div>When someone =
says "Please pay 1 BTC to my address 1ALicExyz=E2=80=9D, no one =
anticipates being paid by a coinbase output. Some exchanges like btc-e =
explicitly reject coinbase payment.</div><div><br =
class=3D""></div><div>Such deterioration in user experience is =
unacceptable. It basically forces everyone to upgrade, i.e. a hardfork =
with soft fork=E2=80=99s skin</div><div><br class=3D""></div><div><br =
class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div class=3D""><br class=3D"">The first solution might =
require more implementation, but allows more<br class=3D"">flexibility =
with the maturity requirement. The second solution is<br =
class=3D"">possibly simpler, but sticks to a hard 100 block limit.<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">1. Is it =
acceptable to have massive txid malleability and transaction<br =
class=3D"">chain invalidation for every natural happening reorg? =
&nbsp;Yes: the<br class=3D"">current spec is ok; No: next question =
(I=E2=80=99d say no)<br class=3D""></blockquote><br class=3D"">Answered =
above.<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">2. Is locking up exit outputs the best way to deal with the =
problem?<br class=3D"">(I tried really hard to find a better solution =
but failed)<br class=3D""></blockquote><br class=3D"">You've probably =
thought about this more than anyone, so I'd say yes, it<br class=3D"">may =
be the only way. Painful, but necessary.<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">3. How long the lock-up =
period should be? Answer could be anywhere<br class=3D"">from 1 to =
100<br class=3D""></blockquote><br class=3D"">I imagine having something =
lower than 100 would be preferable to users,<br class=3D"">maybe =
somewhere in the 5 to 15 range. A 15 block reorg on mainnet is<br =
class=3D"">seriously unlikely unless something strange is happening. A 5 =
block<br class=3D"">reorg is still pretty unlikely, but possible. The =
coinbase solution only<br class=3D"">allows for 100 blocks though.<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">4. With a =
lock-up period, should it allow direct exit to legacy<br =
class=3D"">address? (I think it=E2=80=99s ok if the lock-up is short, =
like 1-2 block. But<br class=3D"">is that safe enough?)<br =
class=3D""></blockquote><br class=3D"">I think so. Adding a kind of =
special address probably creates more<br class=3D"">issues than it =
solves.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div><br class=3D""></div><div>As I explained above, no =
legacy wallet would anticipate a lock up. If you want to make a =
softfork, all burden of incompatibility must be taken by the upgraded =
system. Only allow exit to a new address guarantees that only upgraded =
wallet will see the locked-up tx:</div><div><br class=3D""></div><div><a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Janua=
ry/013490.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ja=
nuary/013490.html</a></div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D"">5. Due to the fungibility issues, it may need a =
new name for the<br class=3D"">tokens in the ext-block<br =
class=3D""></blockquote><br class=3D"">I suppose the market will decide =
whether that's the case.<br class=3D""><br class=3D"">It's worth noting, =
if segwit is not activated on the mainchain, it<br class=3D"">creates a =
much bigger incentive to use the extension block, and<br =
class=3D"">potentially ensures that users will have less of a reason to =
exit.<br class=3D""><br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>I think it=E2=80=99s unacceptable if malleability =
is not fixed in main chain, for 3 reasons:&nbsp;</div><div><br =
class=3D""></div><div>1. a solution is *already* available and tested =
for &gt; 1 year.</div><div><br class=3D""></div><div>2. the deactivation =
design (which I think is an interesting idea) makes the ext block =
unsuitable for long-term storage of value.</div><div><br =
class=3D""></div><div>3. LN over main chain allows instant exchange of =
main coin and xcoin without going through the ugly 2-way-peg =
process.</div></div><div><br class=3D""></div><div><br =
class=3D""></div><br class=3D""></body></html>=

--Apple-Mail=_E0DAA63D-FD2A-4DBE-BBB1-04206D346AD1--