path: root/0e/1b5799c3da36ad2d9120bdda14feb544383150

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--