Hardfork bit wipeout protection #46

jameshilliard · 2017-06-25T03:54:08Z

This should make wipeout protection SPV compatible.

luke-jr

You also need to make CBlock::nVersion unsigned (and add a check to reject blocks with it set before the hardfork).

luke-jr · 2017-06-25T04:45:48Z

src/primitives/block.h

@@ -10,6 +10,8 @@
 #include "serialize.h"
 #include "uint256.h"

+static const int HARDFORK_VERSION_BIT = 0x80000000;


int is only guaranteed to be 15-bit.

Yes, but you made this an int...

changed to int32_t

It needs to be uint32_t (and CBlock::nVersion as well)

luke-jr · 2017-06-25T04:47:11Z

src/validation.cpp

+    if (BIP102active(nHeight, fSegwitSeasoned)) {
+        if (block.nVersion & HARDFORK_VERSION_BIT)
+            return true;
+        return state.Invalid(false, REJECT_OBSOLETE, strprintf("bad-version(0x%08x)", block.nVersion),


The reject reason should be a fixed string.

Seems like it would be a good idea to know the block version that was rejected for debugging purposes.

The next argument is the debug string.

I copied that from here, guess that should be changed as well?

jgarzik · 2017-06-29T18:58:17Z

This PR appears to reduce compatibility with wallet software in the field which could otherwise continue functioning just fine. Several Wallet softwares were previously tested, and are being re-tested, with a block size increase. I'm not aware of any testing a high bit block version change.

Probably NAK, but will await further comments and responses and corrections.

jameshilliard · 2017-06-29T23:31:06Z

@jgarzik The main issue is that SPV wallet developers need a reliable way to determine which chain they are on, this PR makes it trivial for them to determine since the block version is in the header while using a mandatory large block would be much more difficult since they would not normally have enough information to reliably determine the chain they are on.

Polve · 2017-06-30T05:59:13Z

Isn't following the chain with the most PoW not enough?

jameshilliard · 2017-06-30T06:14:39Z

Isn't following the chain with the most PoW not enough?

No, that's the reason for wipeout protection as that is something that can change, it ensures that you don't get unexpected reorgs.

Polve · 2017-06-30T06:29:24Z

But what's the point in following a minority chain if most of the miners defect?

The S2X comes to fruition because the hypothesis is that it's backed by 80%+ of hash rate.

jameshilliard · 2017-06-30T06:34:21Z

But what's the point in following a minority chain if most of the miners defect?

Markets will determine which is more profitable to mine.

Polve · 2017-06-30T07:02:44Z

That's my point.

jameshilliard · 2017-06-30T08:15:50Z

That's my point.

But miners may take time to react to markets so there's a good chance there will be a need for SPV wallets to be able to follow a minority chain at least temporarially, it's also possible there will be 2 viable chains like ETH and ETC.

The issue with SPV wallets like bitcoinj and hard fork validation has been pointed out by bitsquare:

I think it is mandatory to give the user full control which chain he wants to support.

Using the hard fork bit means SPV wallets aren't left behind here and have the same decision capability as full nodes. It also means they aren't at risk of reorg.

jli225 · 2017-06-30T09:49:10Z

@jameshilliard Avoiding chain split by reorg is one advantage. You advocated it as an advantage when you promoted the fake UASF like crazy. Its written into Bitcoin Paper that by definition shall nodes follow the longest chain. Its anti-Bitcoin if you try to encourage chain split by supporting orphaned short chain against 90% hashrate.

After all, you can fork anytime and do anything to wipe-protect your new altcoin, and take the risk yourself. No one stops you. But don't expect the Bitcoin community to take the risk for your altcoin. We don't have such obligations. Sorry.

Anyway, this project is to make sure the success of SegWit2X, especially the 2X part, as the charter stated. We shall try our best to mitigate unintentional chain split. Yet if some malicious guys try to split the chain intentionally, we do not have the obligation to encourage them. They shall take the risk themselves. And Bitcoin will move forward.

kek-coin · 2017-06-30T09:51:02Z

@jli225

Its written into Bitcoin Paper that by definition shall nodes follow the longest chain.

Don't worry, that bug was later fixed to instead follow the most-work chain.

jli225 · 2017-06-30T09:59:43Z

@kek-coin If you see Bitcoin as a bug, you can fork anytime. What stopped you?

Let me guess what you altcoin will base on, maybe most-censorship chain?

Most-lies chain is even better, lol

jameshilliard · 2017-06-30T10:31:33Z

Its written into Bitcoin Paper that by definition shall nodes follow the longest chain.

Read the code, it's more clear, it's most work valid chain.

They shall take the risk themselves.

Reorg protection is something that protects both sides. Without this if the economy favors the original chain the 2X chain would be wiped out for SPV wallets.

kek-coin · 2017-06-30T10:39:03Z

@jli225 Thank you for trying to interpret my words, unfortunately it seems you have failed to grok. I do not see Bitcoin as a bug, I was merely pointing out that the bug of using the longest valid chain rather than the most-work valid chain was already fixed a long time ago. Quoting bugs in the whitepaper does not strengthen your point (and neither does 👍ing your own comments).

jli225 · 2017-06-30T10:53:40Z

@kek-coin You have no clue how Bitcoin works. Go to read Bitcoin Paper and the talk of early Bitcoiners before you spam those ridiculous misinformation. If you see the work following consensus as 'invalid work', you can fork to your most-trolls altcoin anytime and create your own consensus and 'valid work'. 😊

kek-coin · 2017-06-30T10:59:23Z

Assuming that the most important chain is the one that most trolls will be active on I have no problem with that idea.

jgarzik · 2017-06-30T16:44:37Z

Two comments:

Closing this due to risk of breaking existing SPV wallets that would otherwise work unhindered through a base block size increase.
In order for a minority chain to survive, a hard fork is likely needed to fix diff or PoW etc. If that is the case, the minority chain should add a hardfork bit to ensure that SPV wallets can detect this.

jameshilliard · 2017-07-13T10:58:56Z

Closing this due to risk of breaking existing SPV wallets that would otherwise work unhindered through a base block size increase.

SPV wallets will need to be updated regardless(DNS seeds at a minimum), HF bit support is trivial for SPV wallet developers to support.

In order for a minority chain to survive, a hard fork is likely needed to fix diff or PoW etc. If that is the case, the minority chain should add a hardfork bit to ensure that SPV wallets can detect this.

Then why is there wipeout protection at all, why leave SPV wallets vulnerable and not full nodes? Clearly there's a very realistic chance that the minority chain would not be the minority for long if it has more economic support.

christophebiocca · 2017-07-13T12:05:28Z

Then why is there wipeout protection at all, why leave SPV wallets vulnerable and not full nodes? Clearly there's a very realistic chance that the minority chain would not be the minority for long.

Forcing SPV wallets onto the 1MB branch unless they upgrade also makes users vulnerable to funds theft in some scenarios. The tradeoffs need to be understood or this discussion will simply go in circles forever.

In the following I'm assuming that hashpower and % of bitcoin economy will converge to similar values over time (except in PoW-change scenarios), and I only cover standard SPV clients (using a trusted node would completely change the behaviour), and I assume the user only receives and cares about coins received on their local branch.

Scenario 1: ~80% forever.

The minority chain continues to exist without a POW hardfork.
Block-size wipeout protection: Does nothing.
Hard-fork-bit protection, non-upgraded wallet: would accept payments on the minority chain, which, if the user isn't aware of the ongoing fork, will lead to accepting 1MB-coins at multiples of what they're actually worth. Impact: lost funds in value terms.
Hard-fork-bit protection, upgraded-wallet: Does nothing.

Scenario 2: ~20% forever.

Block-size wipeout protection: Allows the fork to happen at all instead of constantly getting re-orged away. SPV wallets all end up on the majority chain instead.
Hard-fork-bit protection, non-upgraded-wallet: Follows the majority chain.
Hard-fork-bit protection, upgraded wallet: Follows the minority chain (which hopefully is understood by the user as less valuable, otherwise see above).

Scenario 3: ~80% -> ~20% steady state after a few months.

Block-size wipeout protection: User receives coins on majority branch which then becomes the minority branch. Impact: Loss funds in value terms, requires manual intervention to actually access the coins (they're not actually gone, just hard to see from an SPV wallet).
Hard-fork bit protection, non-upgraded wallets: User receives coins on minority branch which becomes majority branch. Impact: Gained funds in value terms.
Hard-fork bit protection, upgraded wallets: User receives coins on majority branch which becomes minority branch. Impact: Loss funds in value terms.

Scenario 3: ~20% -> ~80% steady state after a few months.

Block-size wipeout protection: User receives coins on majority branch which then becomes the minority branch. Impact: Loss funds in value terms, requires manual intervention to actually access the coins (they're not actually gone, just hard to see from an SPV wallet).
Hard-fork bit protection, non-upgraded wallets: User receives coins on majority branch which becomes minority branch. Impact: Loss funds in value terms.
Hard-fork bit protection, upgraded wallets: User receives coins on minority branch which becomes majority branch. Impact: Gained funds in value terms.

Scenario 4: ~80% -> 0 over some timescale (no PoW change)

Block-size wipeout protection: Total loss of received funds.
Hard-fork bit protection, non-upgraded wallets: Unaffected.
Hard-fork bit protection, upgraded wallets: Total loss of received funds.

Scenario 5: ~80% -> 100% over some timescale (no PoW change)

Block-size wipeout protection: Unaffected.
Hard-fork bit protection, non-upgraded wallets: Total loss of received funds.
Hard-fork bit protection, upgraded wallets: Unaffected.

Scenario 6: ~20% -> 0 over some timescale (no PoW change)

Block-size wipeout protection: Unaffected.
Hard-fork bit protection, non-upgraded wallets: Unaffected.
Hard-fork bit protection, upgraded wallets: Total loss of received funds.

Scenario 7: ~20% -> 100% over some timescale (no PoW change)

Block-size wipeout protection: Total loss of received funds.
Hard-fork bit protection, non-upgraded wallets: Total loss of received funds.
Hard-fork bit protection, upgraded wallets: Unaffected.

Scenarios 8, 9, 10, 11: Same as 4, 5, 6, 7 except a PoW change happens afterwards

Replace "Total loss of received funds" with "Requires wallet upgrade/new wallet to follow minority branch" instead.

Scenario 12: Chaos (alternating most-work branches for an extended duration):

Block-size wipeout protection: Will end up with coins on both sides, will need a subsequent wallet upgrade to manage them.
Hard-fork bit protection, non-upgraded wallets: Unaffected.
Hard-fork bit protection, upgraded wallets: Unaffected.

So the main advantage of the HF-bit protection is the avoidance of chain switching behaviour and the associated technical headaches. The main advantage of Block-size wipeout protection is that the SPV client is always tracking funds from the "most likely to survive" branch (assuming that hashrate % positively correlates with survival chance, even weakly).

Note that in no case does the user find themselves with lost coins in the block-size wipeout protection case but not in (one of the) HF-bit protection cases.

Contrast with no wipeout protection at all which results in truly lost funds every time the >1MB chain stops being the most-work chain (and subsequently falls to 0 hashrate). So there's a big requirement to give mining nodes wipeout protection, but the benefits to other nodes are less critical (given that the 2 chains continue to exist).

In addition, should we find ourselves in one of the scenarios where, in retrospect, the HF-bit protection would have been better (12, mostly) a retrospective handling of splits is pretty trivial to achieve by checkpointing.

spinza · 2017-07-13T15:01:40Z

@jgarzik

Several Wallet softwares were previously tested, and are being re-tested, with a block size increase. I'm not aware of any testing a high bit block version change.

Has SPV wallets been tested with two chains running?

SergioDemianLerner · 2017-07-27T16:10:24Z

src/validation.cpp

@@ -3001,6 +3003,13 @@ bool ContextualCheckBlockHeader(const CBlockHeader& block, CValidationState& sta
    if (block.GetBlockTime() > nAdjustedTime + 2 * 60 * 60)
        return state.Invalid(false, REJECT_INVALID, "time-too-new", "block timestamp too far in the future");

+    if (BIP102active(nHeight, fSegwitSeasoned)) {
+        if (block.nVersion & HARDFORK_VERSION_BIT)
+            return true;


This "return true" will re-enable block.nVersion < 4 for blocks after the HF, because that check is later . Is this really what you want?

Shouldn't any block with block.nVersion < 4 fail the if (block.nVersion & HARDFORK_VERSION_BIT) check?

jgarzik · 2017-11-08T20:22:13Z

Closing - not needed

This was referenced Jun 25, 2017

#29 - Mandatory block size increase validation #35

Closed

Hard fork on Block X #29

Closed

luke-jr suggested changes Jun 25, 2017

View reviewed changes

jameshilliard force-pushed the segwit2x-wipeout-protection branch 2 times, most recently from 517a48a to 2a6dfc9 Compare June 25, 2017 05:30

Hardfork bit wipeout protection

80e074d

jameshilliard force-pushed the segwit2x-wipeout-protection branch from 2a6dfc9 to 80e074d Compare June 25, 2017 05:33

Use uint32_t for nVersion

ad1fa37

btc1 deleted a comment from theslagter Jun 29, 2017

jgarzik closed this Jun 30, 2017

jgarzik reopened this Jul 24, 2017

SergioDemianLerner reviewed Jul 27, 2017

View reviewed changes

MrHash mentioned this pull request Aug 19, 2017

BTC1 with replay protection #113

Closed

jgarzik closed this Nov 8, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Hardfork bit wipeout protection #46

Hardfork bit wipeout protection #46

jameshilliard commented Jun 25, 2017

luke-jr left a comment

luke-jr Jun 25, 2017

jameshilliard Jun 25, 2017 •

edited

luke-jr Jun 25, 2017

jameshilliard Jun 25, 2017

luke-jr Jun 25, 2017

luke-jr Jun 25, 2017

jameshilliard Jun 25, 2017

luke-jr Jun 25, 2017

jameshilliard Jun 25, 2017

jgarzik commented Jun 29, 2017

jameshilliard commented Jun 29, 2017

Polve commented Jun 30, 2017

jameshilliard commented Jun 30, 2017

Polve commented Jun 30, 2017

jameshilliard commented Jun 30, 2017

Polve commented Jun 30, 2017

jameshilliard commented Jun 30, 2017

jli225 commented Jun 30, 2017 •

edited

kek-coin commented Jun 30, 2017

jli225 commented Jun 30, 2017 •

edited

jameshilliard commented Jun 30, 2017

kek-coin commented Jun 30, 2017

jli225 commented Jun 30, 2017 •

edited

kek-coin commented Jun 30, 2017

jgarzik commented Jun 30, 2017

jameshilliard commented Jul 13, 2017

christophebiocca commented Jul 13, 2017 •

edited

spinza commented Jul 13, 2017

SergioDemianLerner Jul 27, 2017

jameshilliard Aug 6, 2017

jgarzik commented Nov 8, 2017

Hardfork bit wipeout protection #46

Hardfork bit wipeout protection #46

Conversation

jameshilliard commented Jun 25, 2017

luke-jr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jameshilliard Jun 25, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgarzik commented Jun 29, 2017

jameshilliard commented Jun 29, 2017

Polve commented Jun 30, 2017

jameshilliard commented Jun 30, 2017

Polve commented Jun 30, 2017

jameshilliard commented Jun 30, 2017

Polve commented Jun 30, 2017

jameshilliard commented Jun 30, 2017

jli225 commented Jun 30, 2017 • edited

kek-coin commented Jun 30, 2017

jli225 commented Jun 30, 2017 • edited

jameshilliard commented Jun 30, 2017

kek-coin commented Jun 30, 2017

jli225 commented Jun 30, 2017 • edited

kek-coin commented Jun 30, 2017

jgarzik commented Jun 30, 2017

jameshilliard commented Jul 13, 2017

christophebiocca commented Jul 13, 2017 • edited

Scenario 1: ~80% forever.

Scenario 2: ~20% forever.

Scenario 3: ~80% -> ~20% steady state after a few months.

Scenario 3: ~20% -> ~80% steady state after a few months.

Scenario 4: ~80% -> 0 over some timescale (no PoW change)

Scenario 5: ~80% -> 100% over some timescale (no PoW change)

Scenario 6: ~20% -> 0 over some timescale (no PoW change)

Scenario 7: ~20% -> 100% over some timescale (no PoW change)

Scenarios 8, 9, 10, 11: Same as 4, 5, 6, 7 except a PoW change happens afterwards

Scenario 12: Chaos (alternating most-work branches for an extended duration):

spinza commented Jul 13, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgarzik commented Nov 8, 2017

jameshilliard Jun 25, 2017 •

edited

jli225 commented Jun 30, 2017 •

edited

jli225 commented Jun 30, 2017 •

edited

jli225 commented Jun 30, 2017 •

edited

christophebiocca commented Jul 13, 2017 •

edited