[Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening?

Sjors Provoost sjors at sprovoost.nl
Sun Oct 15 14:01:46 UTC 2017

There's a confusion about the term wipeout here.

A full node, or a modified SPV wallet which explicitly checks the forking block, can use the "must [not] be big" requirement. If the 1x chain overtakes the 2x chain and such a node becomes aware of the 1x chain again, it will stay on the 2x chain.

But an SPV wallet that doesn't check the block size and isn't behind a trusted node, would switch back to the 1x chain again. From the point of view of its user, their transaction history is wiped out. They could of course still export their private keys and use a full node wallet on either chain.

This second scenario is less bad than a "true" wipe-out, where neither a 1x or a 2x full node would recognize the transaction history as valid. We should probably call this phenomon something else, to make it clear the SPV wallet got broken, but the funds are fine (ignoring replay issues). Maybe chain-snapping?


> Op 15 okt. 2017, om 14:41 heeft Kekcoin via Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org> het volgende geschreven:
> > Bitcoin2x lacks wipe-out protection
> Incorrect, B2X has wipeout protection in the form of a "must be big" requirement on the hardfork-blockheight. See https://github.com/btc1/bitcoin/pull/50 <https://github.com/btc1/bitcoin/pull/50>
> Sent with ProtonMail <https://protonmail.com/> Secure Email.
>> -------- Original Message --------
>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening?
>> Local Time: October 15, 2017 12:20 PM
>> UTC Time: October 15, 2017 12:20 PM
>> From: bitcoin-segwit2x at lists.linuxfoundation.org
>> To: David A. Harding <dave at dtrt.org>
>> Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org>
>> My other point was as per breadwallet"s explanation of the
>> malfunctions they so far expect of their SPV wallet, which chain
>> followed is chaotic and dynamic because the Bitcoin nodes will ban
>> nodes that send them invalid blocks, and phone wallets select nodes
>> somewhat at random from peer caches and seeds.
>> It is a dynamic and high risk situation, and also existing wallets
>> will be changing in a rush to avert disaster so that there is not a
>> stationary behaviour to test with. (Most phone wallets have auto
>> upgrade features).
>> The node ban has bi-directional effect, but given Bitcoin2x lacks
>> wipe-out protection there is risk of full re-org incurring funds loss
>> for 2X users.
>> Greg Maxwell wrote about some other scenarios here
>> https://www.reddit.com/r/Bitcoin/comments/7465sd/btc1_just_merged_the_ability_for_segwit2x_to/dnw2djt/
>> The full matrix of what can fail in this dynamic situation not fully
>> understood and analysed (by anyone).
>> Ben Davenport and James Lopp (CTO and lead architect at BitGo), are
>> also warning about these kinds of issues.
>> Adam
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171015/6936e88a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171015/6936e88a/attachment-0001.sig>

More information about the Bitcoin-segwit2x mailing list