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?

1 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.
  • 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
    Commented Sep 7, 2023 at 12:26
  • 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. Commented Sep 7, 2023 at 12:27
  • 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
    Commented Sep 7, 2023 at 12:30
  • 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. Commented Sep 7, 2023 at 12:33
  • 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. :) Commented Sep 7, 2023 at 13:53

Your Answer

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

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