<p>Segwit nodes can recognise legacy transaction types and will handle them in the traditional way.</p>
<p>A legacy node would create a transaction that omits the optional segwit flag. When this transaction data is received by a segwit node, it can see that the segwit flag is not present and therefore knows to treat it using the old rules.</p>
<p>See <a href="https://bitcoin.stackexchange.com/q/113697/13866">What are the parts of a Bitcoin transaction in segwit format?</a> for details of Segwit flag.</p>

CC BY-SA 4.0
2022-06-24T18:50:07.277Z
Ok so Segwit nodes are not capable of fighting against transaction malleability in this case, as they are still judging by the old rules ?
nourou4them
CC BY-SA 4.0
2022-06-25T03:22:17.537Z
Yes, only transactions that solely spend segwit outputs are covered by segwit's malleability protections. Inputs which spend legacy outputs do not have their behavior modified.
Pieter Wuille
CC BY-SA 4.0
2022-06-27T02:44:08.180Z
But it seems like wtxids are also malleable before the transaction confirmation, according to this: https://bitcoin.stackexchange.com/questions/83677/why-is-the-wtxid-considered-malleable.
nourou4them
CC BY-SA 4.0
2022-06-24T09:56:34.013Z
2022-06-24T10:12:04.853Z
2022-06-24T10:12:04.853Z
RedGrittyBrick
<p>Segwit did not change the rules for existing output types. The non-segwit standard output types P2PKH (Pay to Public Key Hash) and P2SH (Pay to Script Hash) still work exactly as they always have. Legacy nodes that don't understand segwit will only create addresses for non-segwit output types, and thus any transactions created by legacy nodes will never include any witness data.</p>
<p>Naturally, the more modern segwit nodes are backwards-compatible and can read non-segwit transactions just fine. Only transactions that spend segwit outputs include witness data.</p>

CC BY-SA 4.0
2022-06-25T01:55:08.787Z
2022-06-25T01:55:08.787Z
Murch
<p>Segwit nodes know about the move of the witnesses to another part of the transaction block.</p>
<p>What would happen when they receive a transaction between two legacy nodes, knowing that they will build it following the &quot;old&quot; format, with a txid.</p>
<p>While segwit nodes are looking for a wtxid and witnesses (scriptsig and redeem script) being on another place.</p>
<p>Also, how would the miners consider this particular transaction, currently ?</p>

<transactions><segregated-witness><full-node>
How do segwit nodes behave when they receive a transaction between two legacy nodes?
nourou4them
# How do segwit nodes behave when they receive a transaction between two legacy nodes?

(Asked by: username_0 on 2022-06-24)

Segwit nodes know about the move of the witnesses to another part of the transaction block.

What would happen when they receive a transaction between two legacy nodes, knowing that they will build it following the "old" format, with a txid.

While segwit nodes are looking for a wtxid and witnesses (scriptsig and redeem script) being on another place.

Also, how would the miners consider this particular transaction, currently ?

**Tags:** transactions, segregated-witness, full-node


---

## 2 answers

### Answer by username_3 on 2022-06-25. Score: 5 | Accepted answer

Segwit did not change the rules for existing output types. The non-segwit standard output types P2PKH (Pay to Public Key Hash) and P2SH (Pay to Script Hash) still work exactly as they always have. Legacy nodes that don't understand segwit will only create addresses for non-segwit output types, and thus any transactions created by legacy nodes will never include any witness data.

Naturally, the more modern segwit nodes are backwards-compatible and can read non-segwit transactions just fine. Only transactions that spend segwit outputs include witness data.


---

### Answer by username_1 on 2022-06-24. Score: 4

Segwit nodes can recognise legacy transaction types and will handle them in the traditional way.

A legacy node would create a transaction that omits the optional segwit flag. When this transaction data is received by a segwit node, it can see that the segwit flag is not present and therefore knows to treat it using the old rules.

See [What are the parts of a Bitcoin transaction in segwit format?](https://bitcoin.stackexchange.com/q/113697/13866) for details of Segwit flag.

> **Comments:**
> **username_0**: Ok so Segwit nodes are not capable of fighting against transaction malleability in this case, as they are still judging by the old rules ?  
> **username_2**: Yes, only transactions that solely spend segwit outputs are covered by segwit's malleability protections. Inputs which spend legacy outputs do not have their behavior modified.  
> **username_0**: But it seems like wtxids are also malleable before the transaction confirmation, according to this: https://bitcoin.stackexchange.com/questions/83677/why-is-the-wtxid-considered-malleable.  

---

