2

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.

2 Answers 2

2

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

2
  • 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. Oct 6, 2017 at 15:58
  • @RichApodaca: Sorry, didn't pay enough attention. I'll edit my answer.
    – Murch
    Oct 6, 2017 at 16:34
1

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.

3
  • 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, 2017 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, 2017 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, 2017 at 5:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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