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

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: adaseb on July 16, 2017, 02:26:03 PM

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.

adaseb

legendary

Activity: 3808

Merit: 1723

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

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: MoinCoin on July 16, 2017, 04:19:41 AM

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.

Quote from: MoinCoin on July 16, 2017, 04:19:41 AM

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

Yes.

Quote from: MoinCoin on July 16, 2017, 05:09:56 AM

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.

MoinCoin

sr. member

Activity: 286

Merit: 251

Extension Blocks <3 Rootstock <3

Quote from: adaseb on July 16, 2017, 04:26:33 AM

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)

adaseb

legendary

Activity: 3808

Merit: 1723

Is Electrum considered a light-client wallet?

alani123

legendary

Activity: 2422

Merit: 1451

Leading Crypto Sports Betting & Casino Platform

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

MoinCoin

sr. member

Activity: 286

Merit: 251

Extension Blocks <3 Rootstock <3

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?

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

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.

Quote from: MoinCoin on July 15, 2017, 08:31:18 PM

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

sr. member

Activity: 286

Merit: 251

Extension Blocks <3 Rootstock <3

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.

Topic: Segwit2X HF and UAHF have no Reorg Protection for Light-Clients (Read 984 times)