Does adding OP_1 to scriptSig create a fork between non-segWit and segWit nodes?

Question

According to this, 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?

Answer 1

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" a post from Pieter Wuille which examines the failure modes of a soft fork activation.
• A tiny Python script 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.