public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Johnson Lau <jl2012@xbt.hk>
To: Christopher Jeffrey <chjj@purse.io>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
Date: Mon, 10 Apr 2017 18:14:36 +0800	[thread overview]
Message-ID: <F322F899-8748-407D-884F-95EFBD3C7F99@xbt.hk> (raw)
In-Reply-To: <20170405174343.GA7180@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6457 bytes --]


> 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’t 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’d 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’t 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’s not confirmed. Have you paid enough fees?
Alice: ok, I’ll RBF/CPFP it

2 hours later:

Carol: it’s still not confirmed.
Alice: I have already paid double fees. Maybe the network is congested and I need to pay more…..

Repeat until the lock up period ends.

So this so-called “softfork” 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>


> 
> 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”, 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’s 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’d 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’s 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:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html>
> 
>> 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’s 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.




[-- Attachment #2: Type: text/html, Size: 9109 bytes --]

  reply	other threads:[~2017-04-10 10:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-04 18:03 [bitcoin-dev] Extension block proposal by Jeffrey et al Luke Dashjr
2017-04-04 18:35 ` Johnson Lau
2017-04-05 14:05   ` Olaoluwa Osuntokun
2017-04-05 15:37     ` Greg Sanders
2017-04-05 16:25       ` Joseph Poon
2017-04-05 17:04     ` Johnson Lau
2017-04-05 17:43   ` Christopher Jeffrey
2017-04-10 10:14     ` Johnson Lau [this message]
2017-05-09  0:56       ` Christopher Jeffrey
2017-05-09 17:56         ` Johnson Lau
2017-05-10  1:19           ` Christopher Jeffrey
2017-04-05 16:54 ` Christopher Jeffrey
2017-04-06 17:18   ` Luke Dashjr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F322F899-8748-407D-884F-95EFBD3C7F99@xbt.hk \
    --to=jl2012@xbt.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=chjj@purse.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox