Bitcoin Forum
May 06, 2024, 11:23:12 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Segwit2X HF and UAHF have no Reorg Protection for Light-Clients  (Read 959 times)
MoinCoin (OP)
Sr. Member
****
Offline Offline

Activity: 286
Merit: 251


Extension Blocks <3 Rootstock <3


View Profile
July 16, 2017, 01:31:18 AM
Last edit: July 16, 2017, 01:51:27 AM by MoinCoin
Merited by ABCbits (1)
 #1

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.

Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
1715037792
Hero Member
*
Offline Offline

Posts: 1715037792

View Profile Personal Message (Offline)

Ignore
1715037792
Reply with quote  #2

1715037792
Report to moderator
1715037792
Hero Member
*
Offline Offline

Posts: 1715037792

View Profile Personal Message (Offline)

Ignore
1715037792
Reply with quote  #2

1715037792
Report to moderator
1715037792
Hero Member
*
Offline Offline

Posts: 1715037792

View Profile Personal Message (Offline)

Ignore
1715037792
Reply with quote  #2

1715037792
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715037792
Hero Member
*
Offline Offline

Posts: 1715037792

View Profile Personal Message (Offline)

Ignore
1715037792
Reply with quote  #2

1715037792
Report to moderator
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3388
Merit: 6587


Just writing some code


View Profile WWW
July 16, 2017, 06:42:22 AM
 #2

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 (OP)
Sr. Member
****
Offline Offline

Activity: 286
Merit: 251


Extension Blocks <3 Rootstock <3


View Profile
July 16, 2017, 09:19:41 AM
 #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?

Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
alani123
Legendary
*
Offline Offline

Activity: 2394
Merit: 1412


Leading Crypto Sports Betting & Casino Platform


View Profile
July 16, 2017, 09:22:18 AM
 #4

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

..Stake.com..   ▄████████████████████████████████████▄
   ██ ▄▄▄▄▄▄▄▄▄▄            ▄▄▄▄▄▄▄▄▄▄ ██  ▄████▄
   ██ ▀▀▀▀▀▀▀▀▀▀ ██████████ ▀▀▀▀▀▀▀▀▀▀ ██  ██████
   ██ ██████████ ██      ██ ██████████ ██   ▀██▀
   ██ ██      ██ ██████  ██ ██      ██ ██    ██
   ██ ██████  ██ █████  ███ ██████  ██ ████▄ ██
   ██ █████  ███ ████  ████ █████  ███ ████████
   ██ ████  ████ ██████████ ████  ████ ████▀
   ██ ██████████ ▄▄▄▄▄▄▄▄▄▄ ██████████ ██
   ██            ▀▀▀▀▀▀▀▀▀▀            ██ 
   ▀█████████▀ ▄████████████▄ ▀█████████▀
  ▄▄▄▄▄▄▄▄▄▄▄▄███  ██  ██  ███▄▄▄▄▄▄▄▄▄▄▄▄
 ██████████████████████████████████████████
▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄
█  ▄▀▄             █▀▀█▀▄▄
█  █▀█             █  ▐  ▐▌
█       ▄██▄       █  ▌  █
█     ▄██████▄     █  ▌ ▐▌
█    ██████████    █ ▐  █
█   ▐██████████▌   █ ▐ ▐▌
█    ▀▀██████▀▀    █ ▌ █
█     ▄▄▄██▄▄▄     █ ▌▐▌
█                  █▐ █
█                  █▐▐▌
█                  █▐█
▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀█
▄▄█████████▄▄
▄██▀▀▀▀█████▀▀▀▀██▄
▄█▀       ▐█▌       ▀█▄
██         ▐█▌         ██
████▄     ▄█████▄     ▄████
████████▄███████████▄████████
███▀    █████████████    ▀███
██       ███████████       ██
▀█▄       █████████       ▄█▀
▀█▄    ▄██▀▀▀▀▀▀▀██▄  ▄▄▄█▀
▀███████         ███████▀
▀█████▄       ▄█████▀
▀▀▀███▄▄▄███▀▀▀
..PLAY NOW..
adaseb
Legendary
*
Offline Offline

Activity: 3752
Merit: 1710



View Profile
July 16, 2017, 09:26:33 AM
 #5

Is Electrum considered a light-client wallet?

.BEST..CHANGE.███████████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
███████████████
..BUY/ SELL CRYPTO..
MoinCoin (OP)
Sr. Member
****
Offline Offline

Activity: 286
Merit: 251


Extension Blocks <3 Rootstock <3


View Profile
July 16, 2017, 10:09:56 AM
 #6

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)

Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3388
Merit: 6587


Just writing some code


View Profile WWW
July 16, 2017, 05:59:36 PM
 #7

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
Legendary
*
Offline Offline

Activity: 3752
Merit: 1710



View Profile
July 16, 2017, 07:26:03 PM
 #8

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?


.BEST..CHANGE.███████████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
███████████████
..BUY/ SELL CRYPTO..
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3388
Merit: 6587


Just writing some code


View Profile WWW
July 16, 2017, 08:55:25 PM
 #9

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.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!