<p>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 <a href="https://github.com/btc1/bitcoin/pull/46#issuecomment-312067571" rel="nofollow noreferrer">doesn't break SPV wallet compatibility</a>. Most notably they don't plan on using the proposed hardfork bit. I believe they are going to require a block <em>with a base size greater than one megabyte</em> (srsly!) for the block at fork height: <a href="https://github.com/btc1/bitcoin/issues/29" rel="nofollow noreferrer">ISSUE</a>/<a href="https://github.com/btc1/bitcoin/commit/b368c9bfbbea8161a719ac6fda89bcb9909ea83e" rel="nofollow noreferrer">PR</a></p>

CC BY-SA 3.0
2017-10-06T15:58:05.707Z
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
CC BY-SA 3.0
2017-10-06T16:34:55.570Z
@RichApodaca: Sorry, didn't pay enough attention. I'll edit my answer.
Murch
CC BY-SA 3.0
2017-10-06T15:42:35.917Z
2017-10-06T16:40:25.533Z
2017-10-06T16:40:25.533Z
Murch
<p>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.</p>

CC BY-SA 3.0
2017-10-06T16:41:35.903Z
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
CC BY-SA 3.0
2017-10-06T17:02:49.753Z
"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.
Ava Chow
CC BY-SA 3.0
2017-10-09T05:00:36.727Z
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
CC BY-SA 3.0
2017-10-06T16:35:26.383Z
2017-10-06T16:35:26.383Z
Ava Chow
<p>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."</p>

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

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

<p>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.</p>

<security><spv><segwit2x>
Segwit2x/btc1 block header changes: wipeout protection for SPV nodes?
Rich Apodaca
# Segwit2x/btc1 block header changes: wipeout protection for SPV nodes?

(Asked by: username_0 on 2017-10-06)

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.

**Tags:** security, spv, segwit2x


---

## 2 answers

### Answer by username_1 on 2017-10-06. Score: 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](https://github.com/btc1/bitcoin/pull/46#issuecomment-312067571). 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](https://github.com/btc1/bitcoin/issues/29)/[PR](https://github.com/btc1/bitcoin/commit/b368c9bfbbea8161a719ac6fda89bcb9909ea83e)

> **Comments:**
> **username_0**: 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.  
> **username_1**: @username_0: Sorry, didn't pay enough attention. I'll edit my answer.  

---

### Answer by username_2 on 2017-10-06. Score: 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.

> **Comments:**
> **username_1**: 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)`  
> **username_2**: "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.  
> **username_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.  

---

