From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B7B7E7A8 for ; 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 ; 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 Message-Id: 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 = >=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 = >=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
On 6 Apr 2017, at 01:43, Christopher Jeffrey <chjj@purse.io> = wrote:


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

Yes, this issue is probably the biggest edge case in the = proposal.

I think there's two possible = solutions:

First solution:

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:



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.

Second = solution:

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




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.

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)

Answered = above.

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)

You've probably = thought about this more than anyone, so I'd say yes, it
may = be the only way. Painful, but necessary.

3. How long the lock-up = period should be? Answer could be anywhere
from 1 to = 100

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.

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

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:



5. Due to the fungibility issues, it may need a = new name for the
tokens in the ext-block

I suppose the market will decide = whether that's the case.

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.


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

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