Segwit2X HF and UAHF have no Reorg Protection for Light-Clients

[MoinCoin]

I just recently realized, that Segwit2X and UAHF offer no wipeout reorg protection for Lite-Clients like mobile wallets, when they Hard Fork with a block size increase and split the chain.

The wipeout protection for the block size Hard Fork is based on a "Must-Be-Big" rule.
However light clients do not check the block size (because it is not in the block header) and therefore cannot check this rule.

How do current light wallets guard their users from reorgs and hops between chains and the results:
Unintended double-sent transactions - vanished Bitcoins or suddenly again unconfirmed transactions, that may not even be valid on the current chain, because a utxo-entry may have already been spent etc.

How can this be intended design?
Hope this didn't came up in a prominent place already.

[achow101]

Unfortunately neither of those two forks currently have any sort of reorg protection for lite clients. They both lack any actual specification and have been ignoring the advice of several Core developers (e.g set one of the BIP 9 hard fork bits in the version number so lite clients know that the chain is a hard fork).

The only way to protect yourself from reorg is to make sure that you always connect to nodes which you know will be following the chain that you want to follow.

How can this be intended design?

Both hard forks are designed by people who actively ignore those who have safely deployed consensus changes in the past; both are extremely rushed; both lack specification as to what they are doing;

[MoinCoin]

Thank you for your reply.

So essentially, because the developers rushed their code / did not care about consequences the average user now has to fix the mess they created.
This seems to me like it is bound to fail, especially for Bitcoin beginners.

Though i was aware of that theoretic solution - is that really possible with most wallets?
I saw some announcements recently from wallet providers, but i suspect not all wallets do even support this yet.

Doesn't connecting to a "prefered" node open new attack vectors, like sybil and MITM attacks?

[alani123]

It's not just carelessness in my opinion. It's likely that this detail was willfully ignored by the developers behind said forks.

[adaseb]

Is Electrum considered a light-client wallet?

[MoinCoin]

Is Electrum considered a light-client wallet?

AFAIK Electrum has a Client-Server architecture - so yes, the client is a light-client.
Be careful, which server you select.
There is a splitting guide for electrum:
http://docs.electrum.org/en/latest/hardfork.html

Basically all Clients, which are not full nodes, are light clients and will have severe problems with said hard forks.


Edit:
Because this is the development subforum:
Using the Hard Fork bit would fix this problem? (At least for 2 distinct chains)

[achow101]

Though i was aware of that theoretic solution - is that really possible with most wallets?
I saw some announcements recently from wallet providers, but i suspect not all wallets do even support this yet.

No, unfortunately many wallets do not give you the option to choose which nodes to use so you can't choose the blockchain that you want to use.

Doesn't connecting to a "prefered" node open new attack vectors, like sybil and MITM attacks?

Yes.

Because this is the development subforum:
Using the Hard Fork bit would fix this problem? (At least for 2 distinct chains)

Yes, although some software may need to upgrade to understand what to do if the hardfork bits are set.

[adaseb]

So this will become an issue mostly if either the BTC chain splits in 2 weeks or after the 2MB hard fork at the end of the year correct?

In 2 weeks if there is no splits, segwit gets activated we don't have to worry yet correct?

[achow101]

So this will become an issue mostly if either the BTC chain splits in 2 weeks or after the 2MB hard fork at the end of the year correct?

In 2 weeks if there is no splits, segwit gets activated we don't have to worry yet correct?

Yes.