New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardfork bit wipeout protection #46

Closed
wants to merge 2 commits into
base: segwit2x
from

Conversation

Projects
None yet
9 participants
@jameshilliard

jameshilliard commented Jun 25, 2017

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).

Show outdated Hide outdated src/primitives/block.h Outdated
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),

This comment has been minimized.

@luke-jr

luke-jr Jun 25, 2017

The reject reason should be a fixed string.

@luke-jr

luke-jr Jun 25, 2017

The reject reason should be a fixed string.

This comment has been minimized.

@jameshilliard

jameshilliard Jun 25, 2017

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

@jameshilliard

jameshilliard Jun 25, 2017

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

This comment has been minimized.

@luke-jr

luke-jr Jun 25, 2017

The next argument is the debug string.

@luke-jr

luke-jr Jun 25, 2017

The next argument is the debug string.

This comment has been minimized.

@jameshilliard

jameshilliard Jun 25, 2017

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

@jameshilliard

jameshilliard Jun 25, 2017

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

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Jun 29, 2017

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.

jgarzik commented Jun 29, 2017

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.

@btc1 btc1 deleted a comment from theslagter Jun 29, 2017

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 29, 2017

@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.

jameshilliard commented Jun 29, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@Polve

Polve Jun 30, 2017

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

Polve commented Jun 30, 2017

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

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 30, 2017

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.

jameshilliard commented Jun 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Polve

Polve Jun 30, 2017

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.

Polve commented Jun 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 30, 2017

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.

jameshilliard commented Jun 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Polve

Polve Jun 30, 2017

That's my point.

Polve commented Jun 30, 2017

That's my point.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 30, 2017

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.

jameshilliard commented Jun 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jli225

jli225 Jun 30, 2017

@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.

jli225 commented Jun 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kek-coin

kek-coin Jun 30, 2017

@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.

kek-coin commented Jun 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jli225

jli225 Jun 30, 2017

@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

jli225 commented Jun 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jun 30, 2017

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.

jameshilliard commented Jun 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kek-coin

kek-coin Jun 30, 2017

@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).

kek-coin commented Jun 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jli225

jli225 Jun 30, 2017

@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'. 😊

jli225 commented Jun 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kek-coin

kek-coin Jun 30, 2017

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

kek-coin commented Jun 30, 2017

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

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Jun 30, 2017

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.

jgarzik commented Jun 30, 2017

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.

@jgarzik jgarzik closed this Jun 30, 2017

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jul 13, 2017

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.

jameshilliard commented Jul 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@christophebiocca

christophebiocca Jul 13, 2017

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.

christophebiocca commented Jul 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@spinza

spinza Jul 13, 2017

@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?

spinza commented Jul 13, 2017

@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?

@jgarzik jgarzik reopened this Jul 24, 2017

@@ -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 comment has been minimized.

@SergioDemianLerner

SergioDemianLerner Jul 27, 2017

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?

@SergioDemianLerner

SergioDemianLerner Jul 27, 2017

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?

This comment has been minimized.

@jameshilliard

jameshilliard Aug 6, 2017

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

@jameshilliard

jameshilliard Aug 6, 2017

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

@MrHash MrHash referenced this pull request Aug 19, 2017

Closed

BTC1 with replay protection #113

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Nov 8, 2017

Closing - not needed

jgarzik commented Nov 8, 2017

Closing - not needed

@jgarzik jgarzik closed this Nov 8, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment