<blockquote>
<p>Not upgraded nodes will accept the block (since nSequence does not have meaning) and all other (upgraded) nodes will not?</p>
</blockquote>
<p>Yes, that is what happens.</p>
<blockquote>
<p>How is that solved?</p>
</blockquote>
<p>The answer is the same for every soft fork: the consensus change is only safe to old nodes as long as a majority of the hashrate enforces it. If not, it is possible that a chain split between old and new nodes appears.</p>
<p>Imagine that there is a percentage of the hashrate that produces blocks that violate BIP68. As long as a majority of the hashrate refuses to build on top of such blocks, the chain without BIP68-invalid blocks will be extended faster, and whenever that chain overtakes a BIP68-invalid chain, even pre-BIP68 nodes will switch over to it (because to them, both are valid).</p>
<p>Thus, as long as the majority of the hashrate enforces BIP68 (and thus refuses to build on top of BIP68-invalid blocks or chains), old and new nodes will eventually agree on what the active chain is.</p>

CC BY-SA 4.0
2023-11-03T19:30:13.223Z
2023-11-03T19:58:52.713Z
2023-11-03T19:58:52.713Z
Pieter Wuille
<p>What would happen if the node not upgraded to BIP68 and relative lock time meaning of <code>nSequence</code> get a block with the transaction where one of its <code>nSequence</code> is not set to <code>0xffffffff</code>, but to value which relative time still did not pass? (<strong>Assume that the <code>nLocktime</code> is 0x00000000 or some value that already pass - for example 3 blocks</strong>). Not upgraded nodes will accept the block (since nSequence does not have meaning) and all other (upgraded) nodes will not? How is that solved?</p>

<soft-fork><sequence><checksequenceverify>
What would happen if the non-upgraded node to BIP68 receives block with the transaction where one of its nSequence is different than 0xffffffff?
LeaBit
# What would happen if the non-upgraded node to BIP68 receives block with the transaction where one of its nSequence is different than 0xffffffff?

(Asked by: username_0 on 2023-11-03)

What would happen if the node not upgraded to BIP68 and relative lock time meaning of `nSequence` get a block with the transaction where one of its `nSequence` is not set to `0xffffffff`, but to value which relative time still did not pass? (**Assume that the `nLocktime` is 0x00000000 or some value that already pass - for example 3 blocks**). Not upgraded nodes will accept the block (since nSequence does not have meaning) and all other (upgraded) nodes will not? How is that solved?

**Tags:** soft-fork, sequence, checksequenceverify


---

## 1 answers

### Answer by username_1 on 2023-11-03. Score: 3 | Accepted answer

> Not upgraded nodes will accept the block (since nSequence does not have meaning) and all other (upgraded) nodes will not?

Yes, that is what happens.

> How is that solved?

The answer is the same for every soft fork: the consensus change is only safe to old nodes as long as a majority of the hashrate enforces it. If not, it is possible that a chain split between old and new nodes appears.

Imagine that there is a percentage of the hashrate that produces blocks that violate BIP68. As long as a majority of the hashrate refuses to build on top of such blocks, the chain without BIP68-invalid blocks will be extended faster, and whenever that chain overtakes a BIP68-invalid chain, even pre-BIP68 nodes will switch over to it (because to them, both are valid).

Thus, as long as the majority of the hashrate enforces BIP68 (and thus refuses to build on top of BIP68-invalid blocks or chains), old and new nodes will eventually agree on what the active chain is.


---

