1

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.

Improve this question
2
  • 1
    Does this answer your question? How is SegWit a soft fork?
    – Pieter Wuille
    Sep 10 at 18:31
  • 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 at 18:35

1 Answer 1

Reset to default
2

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

Improve this answer
29
  • 1
    @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).
    – Pieter Wuille
    Sep 10 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.
    – Pieter Wuille
    Sep 10 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.
    – RedGrittyBrick
    Sep 10 at 20:07
  • 1
    @joke Yes, exactly. New nodes use the flag/marker serialization (which includes witness data) for transactions that have non-empty witnesses, while old nodes always use the old serialization format. To me however, serialization is just an implementation detail - the question is which data they have, as it can always be converted to another format. And in terms of data, they have exactly the same data, just without witness data.
    – Pieter Wuille
    Sep 10 at 20:53
  • 1
    Yes, that's my point, nodes can use whatever format they want to store the data, the only thing that matters is what data they have available and which protocol they speak. Bitcoin Core stores blocks in the same format on disk as it'd sent on the network, packed together with multiple blocks in a files with some metadata before each block, and a separate database that contains an index of all those blocks.
    – Pieter Wuille
    Sep 10 at 22:05

Your Answer

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

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