<p>For any soft fork, it's possible for a block to contain a transaction violating the new consensus rules. Old nodes would accept this block and new nodes would refuse it.</p>
<p>However as long as more than half of the network hashrate updated to the new rules the fork would only be temporary. This is because updated miners would not mine on top of an invalid block. If the majority of the hashrate does so they would eventually create a chain with more work  than the one with the invalid block, which old nodes would therefore drop.</p>
<p>The lower the percentage of updated hashrate on the network, the higher the probability of a long chain containing an invalid block being created. This is why historically care has been taken to wait for miners to upgrade their nodes before full nodes started enforcing the new rules. You want to minimize the probability of an unsuspecting user receiving a payment on their non-updated node with a decent number of confirmations which eventually gets wiped as the invalid chain gets reorg'd out!</p>
<p>To go further:</p>
<ul>
<li>&quot;<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html" rel="nofollow noreferrer">On the security of soft forks</a>&quot; a post from Pieter Wuille which examines the failure modes of a soft fork activation.</li>
<li>A <a href="https://github.com/jonasnick/bip8-tester#thresholdpy" rel="nofollow noreferrer">tiny Python script</a> by Jonas Nick which computes the probability of an old node seeing a chain longer than N blocks given the % of the network hashrate which updated to the new rules.</li>
</ul>

CC BY-SA 4.0
2023-09-07T12:26:53.413Z
How will the old nodes know when to switch to the new chain? Also, won't the fork happen again when the old nodes switch to a "valid" chain because they will again have a similar problem with validation? Is the switch to a "valid" fork done only when they are updated?
dassd
CC BY-SA 4.0
2023-09-07T12:27:45.337Z
Because it has more work. Bitcoin nodes follow the (valid) chain with the most work. By definition of a soft fork, the chain valid according to the new nodes is also valid according to the old nodes. If the valid chain gets longer (loosely speaking), old nodes will start following it.
Antoine Poinsot
CC BY-SA 4.0
2023-09-07T12:30:03.440Z
Yes, but will the old node run into the problem again when validating those blocks? Is the switch to right chain only done after they are "updated"?
dassd
CC BY-SA 4.0
2023-09-07T12:33:31.563Z
No, the valid blocks are valid in their view. They switch even without being updated, that's the beauty of a soft fork (combined with a majority hashrate). You should checkout the mailing list post i link above.
Antoine Poinsot
CC BY-SA 4.0
2023-09-07T13:27:46.450Z
Oh sorry, I got confused. If I understand, the point of a soft fork is that the old nodes always accept "something" , while updated nodes have some additional rules. So, it may happen that some transaction is accepted by the old nodes but not by the new one (due to new rules), so a fork is created. The old nodes will at some point move to the right fork and accept all these block and their transactions because they are valid for them (the problem was that some of transactions were not valid for updated nodes, but they are not even part of the block). Is this correct?
dassd
CC BY-SA 4.0
2023-09-07T13:37:36.040Z
The problem would occur if some transaction was accepted by the updated nodes while the old nodes reject it. In this case it would be imposible for the old and updated nodes to "synchronize" (to be on a same fork) since the old nodes will never accept these transaction as valid. In this case the fork is permanent, until the old nodes decide to move on a new rules. This is called hard fork. Is this correct?
dassd
CC BY-SA 4.0
2023-09-07T13:53:48.540Z
Yes, exactly. One way of looking at it is that a soft fork *tightens* the validation rules whereas a hardfork *loosens* them. It doesn't make a soft fork necessarily safe or necessarily "compatible" though, as you could do many things by simply tightening the validation rules, but i guess it's a discussion for a different question. :)
Antoine Poinsot
CC BY-SA 4.0
2023-09-07T11:52:49.950Z
2023-09-07T12:03:33.047Z
2023-09-07T12:03:33.047Z
Antoine Poinsot
<p>According to <a href="https://bitcoin.stackexchange.com/a/101146/144381">this</a>, when the scriptPubKey equals to:</p>
<p><code>OP_n (with n between 0 and 16, inclusive) followed by a direct push of exactly 2 to 40 bytes inclusive</code></p>
<p>... it denotes the start of SegWit validating process. SegWit validation process include the checking whether the scriptSig is an empty field. If it is, old nodes (non-segWit) will automatically accept this as a valid script since after the &quot;concatenation&quot; (I know it's not a real concatenation) the top-most element in the stack will be non-zero, while the segWit nodes will go into further checking.</p>
<p>So, my question is: <strong>what will happen if someone just add <code>OP_1</code> in scriptSig?</strong> I mean, for non-segWit nodes it would still be accepted as
a valid script since top-most element in the stack is non-zero, and for segWit nodes it will considered as invalid since scriptSig is not an empty field. <strong>Will this make some kind of fork? How is this resolved?</strong></p>
<p>Additional question is what will happen if non-segWit nodes accept some &quot;segWit&quot; transaction as valid since top-most item is non-zero, and segWit on the other hand do not accept that transaction since something in its witness data is not okay? <strong>What is happening in this case, how is this resolved?</strong></p>

<segregated-witness><blockchain-fork>
Does adding OP_1 to scriptSig create a fork between non-segWit and segWit nodes?
dassd
# Does adding OP_1 to scriptSig create a fork between non-segWit and segWit nodes?

(Asked by: username_0 on 2023-09-07)

According to [this](https://bitcoin.stackexchange.com/a/101146/144381), when the scriptPubKey equals to:

`OP_n (with n between 0 and 16, inclusive) followed by a direct push of exactly 2 to 40 bytes inclusive`

... it denotes the start of SegWit validating process. SegWit validation process include the checking whether the scriptSig is an empty field. If it is, old nodes (non-segWit) will automatically accept this as a valid script since after the "concatenation" (I know it's not a real concatenation) the top-most element in the stack will be non-zero, while the segWit nodes will go into further checking.

So, my question is: **what will happen if someone just add `OP_1` in scriptSig?** I mean, for non-segWit nodes it would still be accepted as
a valid script since top-most element in the stack is non-zero, and for segWit nodes it will considered as invalid since scriptSig is not an empty field. **Will this make some kind of fork? How is this resolved?**

Additional question is what will happen if non-segWit nodes accept some "segWit" transaction as valid since top-most item is non-zero, and segWit on the other hand do not accept that transaction since something in its witness data is not okay? **What is happening in this case, how is this resolved?**

**Tags:** segregated-witness, blockchain-fork


---

## 1 answers

### Answer by username_1 on 2023-09-07. Score: 3 | Accepted answer

For any soft fork, it's possible for a block to contain a transaction violating the new consensus rules. Old nodes would accept this block and new nodes would refuse it.

However as long as more than half of the network hashrate updated to the new rules the fork would only be temporary. This is because updated miners would not mine on top of an invalid block. If the majority of the hashrate does so they would eventually create a chain with more work than the one with the invalid block, which old nodes would therefore drop.

The lower the percentage of updated hashrate on the network, the higher the probability of a long chain containing an invalid block being created. This is why historically care has been taken to wait for miners to upgrade their nodes before full nodes started enforcing the new rules. You want to minimize the probability of an unsuspecting user receiving a payment on their non-updated node with a decent number of confirmations which eventually gets wiped as the invalid chain gets reorg'd out!

To go further:

* "[On the security of soft forks](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html)" a post from Pieter Wuille which examines the failure modes of a soft fork activation.
* A [tiny Python script](https://github.com/jonasnick/bip8-tester#thresholdpy) by Jonas Nick which computes the probability of an old node seeing a chain longer than N blocks given the % of the network hashrate which updated to the new rules.

> **Comments:**
> **username_0**: How will the old nodes know when to switch to the new chain? Also, won't the fork happen again when the old nodes switch to a "valid" chain because they will again have a similar problem with validation? Is the switch to a "valid" fork done only when they are updated?  
> **username_1**: Because it has more work. Bitcoin nodes follow the (valid) chain with the most work. By definition of a soft fork, the chain valid according to the new nodes is also valid according to the old nodes. If the valid chain gets longer (loosely speaking), old nodes will start following it.  
> **username_0**: Yes, but will the old node run into the problem again when validating those blocks? Is the switch to right chain only done after they are "updated"?  
> **username_1**: No, the valid blocks are valid in their view. They switch even without being updated, that's the beauty of a soft fork (combined with a majority hashrate). You should checkout the mailing list post i link above.  
> **username_0**: Oh sorry, I got confused. If I understand, the point of a soft fork is that the old nodes always accept "something" , while updated nodes have some additional rules. So, it may happen that some transaction is accepted by the old nodes but not by the new one (due to new rules), so a fork is created. The old nodes will at some point move to the right fork and accept all these block and their transactions because they are valid for them (the problem was that some of transactions were not valid for updated nodes, but they are not even part of the block). Is this correct?  
> **username_0**: The problem would occur if some transaction was accepted by the updated nodes while the old nodes reject it. In this case it would be imposible for the old and updated nodes to "synchronize" (to be on a same fork) since the old nodes will never accept these transaction as valid. In this case the fork is permanent, until the old nodes decide to move on a new rules. This is called hard fork. Is this correct?  
> **username_1**: Yes, exactly. One way of looking at it is that a soft fork *tightens* the validation rules whereas a hardfork *loosens* them. It doesn't make a soft fork necessarily safe or necessarily "compatible" though, as you could do many things by simply tightening the validation rules, but i guess it's a discussion for a different question. :)  

---

