2

I understand that SegWit is backward compatible (soft-fork) from this perspective.

So, for old nodes the following output script (scriptPubKey)

OP_n (where n from 0 to 16) <2-40 bytes>

... is considered as anyone-can-spend and in "concatenation" with the empty input script (scriptSig) it will be always valid.

For new (updated) nodes it will be considered as SegWit, so the special SegWit validation process, as Pieter Wuille described, will start.

Observing only this, everything is clear to me.

What is not clear to me is how all this will work when the structure of the transaction has been changed from SegWit.

Namely, according to bip144, the structure of the transaction has been changed by "expanding" the transaction with two bytes (marker (0x00) and flag (0x01)) after version field, and also adding witness data after tx_outs and before locktime.

For new (updated) nodes this is considered as a sign that there is witness data, however, for old nodes this is a transaction with 0 inputs and 1 output which is considered invalid so they will always discard this transaction (especially since there is also witness data that is not clear to them at all).

Even if we would consider that the old nodes would not relay these transactions to other peers, they would not even accept them in the blocks they receive from the miners, because for them these are completely invalid transactions (valid from the first perspective of inputs and outpus since they are anyone-can-spend, but invalid from this second, structure perspective).

Can someone explain to me how this works? I misunderstood something.

2
  • 1
    Does this answer your question? How is SegWit a soft fork? Sep 10, 2023 at 18:31
  • 1
    Yes, I read it, but I still don't understand 100%. I have additional questions. I've posted the questions below in a reply, but may as well post them here so RedGrittyBrick doesn't get too many notices.
    – dassd
    Sep 10, 2023 at 18:35

1 Answer 1

3

Old nodes never see the new serialisation format

When an old node asks a new node for data, the new node edits the data into the old serialisation format before sending it

29
  • 1
    Okay, but when a node just want to relay the transaction it got to all its peers, how will he know if the peer is old or new (updated) node?
    – dassd
    Sep 10, 2023 at 18:05
  • 1
    Part of the communications handshake distinguishes segwit nodes Sep 10, 2023 at 18:23
  • 2
    @RedGrittyBrick While that's true, the handshake just lets the other side know that the peer can offer witness. To actually get witness data, a node has to ask for a witness_tx or a witness_block, rather than tx or block (if you ask for those, even from a segwit node, you get the stripped version). Sep 10, 2023 at 18:35
  • 1
    1) Yes, unknown service flags are ignored by nodes that don't know them. 2) Yes, the marker/flag format is used for any transaction that has at least one non-empty witness (old format is still used for transactions without witnesses) 3) Yes, the witness block format is identical to telhe normal block format, but instead of normal transactions, witness transactions are included. Sep 10, 2023 at 19:13
  • 2
    @joke: It is probably clearer to think of it not as different blockchains but as the same blockchain with Segwit data stripped out. Just as we would say a pruning node and a non-pruning node have the same blockchain even though one node has more data than the other. Sep 10, 2023 at 20:07

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.