Are there any current plans for segwit2x/btc1 to change the block header in a backward-incompatible way, either permanently or with a signal block (e.g., "hard fork bit"), before it goes live? This is sometimes referred to as "wipeout protection."

AFAIK, btc1 will require a large signaling block. The problem is that SPV nodes won't be able to detect it because by definition they avoid downloading entire blocks. In other words, an SPV node knows nothing about block size (and can know very little about block bodies in general).

I have found nothing about this and want to confirm that the plan is really to leave the block header untouched.

If so, it looks like SPV nodes will have no way to distinguish s2x and Bitcoin chains. They will follow whichever chain has the most proof-of-work - even if that chain contains invalid block bodies. This would have serious implications for the security of funds controlled by SPV wallets.

From following most of what has been going on in the btc1 repository, it is S2x's express plan to take along SPV wallets with their hard fork. Therefore, they are limiting wipeout protection to anything that doesn't break SPV wallet compatibility. Most notably they don't plan on using the proposed hardfork bit. I believe they are going to require a block with a base size greater than one megabyte (srsly!) for the block at fork height: ISSUE/PR

  • Replay protection is an important, but separate issue. I'm specifically interested in what is sometimes called "wipeout protection." Wipeouts can degrade the security of SPV users of either chain, and so there aught to be more of an incentive to adopt it in btc1. Still, the discussion you linked does suggest that neither wipeout protection nor replay protection will be part of s2x. I've updated my question to make it more specific. – Rich Apodaca Oct 6 '17 at 15:58
  • @RichApodaca: Sorry, didn't pay enough attention. I'll edit my answer. – Murch Oct 6 '17 at 16:34

Segwit2x/btc1 does not contain any wipeout protection for SPV wallets. Their only wipeout protection is that the block at their forking height must have a block weight greater than 4 million weight units. This means that SPV wallets will not be able to easily distinguish which chain that they are using. This will cause a situation similar to that of Bitcoin Cash's before their emergency difficulty adjustment went into effect.

  • 2
    Are you sure about the weight? I think they're actually tying it to "base block size": if (::GetSerializeSize(block, SER_NETWORK, PROTOCOL_VERSION | SERIALIZE_TRANSACTION_NO_WITNESS) <= MAX_LEGACY_BLOCK_SIZE) – Murch Oct 6 '17 at 16:41
  • "Base block size" is directly tied to block weight, although if they are implementing it with "base block size", they may have behavior that is different from what they intend. – Andrew Chow Oct 6 '17 at 17:02
  • 1
    I'm confused by your statement that "base block size is directly tied to block weight". There's quite some range on the ratio of stripped size vs vsize of transactions. – Murch Oct 9 '17 at 5:00

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.