<p>Yes, <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Transaction_ID" rel="nofollow noreferrer">all <code>txid</code>s are calculated only from non-witness data</a>. While many nodes have a complete copy of the blockchain (which does contain all transactions), most nodes do not have a full transaction index. <strong>It is generally not possible to request a transaction per its <code>txid</code> via the P2P protocol.</strong></p>
<p><a href="https://i.sstatic.net/bzboG.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/bzboG.png" alt="enter image description here" /></a><br />
<sup>via <a href="https://developer.bitcoin.org/reference/p2p_networking.html" rel="nofollow noreferrer">https://developer.bitcoin.org/reference/p2p_networking.html</a></sup></p>
<p>Nodes will advertise new transactions to their peers once per <code>inv</code> (inventory) messages. Only the notified peers can then request announced transactions per <code>getdata</code> messages, which prompts <code>tx</code> message responses. Nodes will not serve <code>getdata</code> requests unless they recently announced the transaction to the requesting peer for privacy reasons.</p>
<p>In absence of a prior announcement, a node can only learn about a transaction from a peer by requesting the block it was included in.</p>
<p>You can read more about the P2P messages for example here: <a href="https://developer.bitcoin.org/reference/p2p_networking.html" rel="nofollow noreferrer">https://developer.bitcoin.org/reference/p2p_networking.html</a></p>

CC BY-SA 4.0
2022-05-14T14:23:06.080Z
Maybe a clarification: there is no generic way in the P2P protocol to request a transaction by its txid. The `getdata`/`tx` approach only works for recently announced transactions. Beyond that, the only way of getting transactions is by fetching the blocks they are in.
Pieter Wuille
CC BY-SA 4.0
2022-05-14T14:33:55.970Z
I revised my answer to clarify that confirmed transactions cannot be requested outside of the context of the block they're in.
Murch
CC BY-SA 4.0
2022-05-14T15:42:09.463Z
That's not exactly right. The criterion for being able to fetch a transaction is solely "has it been announced recently". If that's the case, it can be requested (even if it has since confirmed). If that's not the case, it's not guaranteed to be requestable (even if it is still unconfirmed); e.g. if a transaction was relayed by node X before you connected to X, you generally can't `getdata` it (for privacy reasons).
Pieter Wuille
CC BY-SA 4.0
2022-05-14T18:32:44.357Z
Thanks for the correction, I hope I got it right now.
Murch
CC BY-SA 4.0
2022-05-14T01:58:43.963Z
2022-05-14T18:32:32.573Z
2022-05-14T18:32:32.573Z
Murch
<p>If I'm right, segwit TxIDs are composed of the SHA^2(256) hash of the non-segwit data of a transaction. But, how does another node use the TxID to obtain information about the transaction such as the address information.</p>
<p>Am I right in saying that the node with the TxID will send it to a full-node which matches the desired TxID with the TxIDs that it stores with the relevant information which is then sent back to the node? If so, does that mean full nodes store the TxID and the transaction information?</p>

<segregated-witness><p2p><transaction-id>
How does a node get information from the TxID?
Jamo
# How does a node get information from the TxID?

(Asked by: username_0 on 2022-05-14)

If I'm right, segwit TxIDs are composed of the SHA^2(256) hash of the non-segwit data of a transaction. But, how does another node use the TxID to obtain information about the transaction such as the address information.

Am I right in saying that the node with the TxID will send it to a full-node which matches the desired TxID with the TxIDs that it stores with the relevant information which is then sent back to the node? If so, does that mean full nodes store the TxID and the transaction information?

**Tags:** segregated-witness, p2p, transaction-id


---

## 1 answers

### Answer by username_1 on 2022-05-14. Score: 4 | Accepted answer

Yes, [all `txid`s are calculated only from non-witness data](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Transaction_ID). While many nodes have a complete copy of the blockchain (which does contain all transactions), most nodes do not have a full transaction index. **It is generally not possible to request a transaction per its `txid` via the P2P protocol.**

[![enter image description here](https://i.sstatic.net/bzboG.png)](https://i.sstatic.net/bzboG.png)  
via <https://developer.bitcoin.org/reference/p2p_networking.html>

Nodes will advertise new transactions to their peers once per `inv` (inventory) messages. Only the notified peers can then request announced transactions per `getdata` messages, which prompts `tx` message responses. Nodes will not serve `getdata` requests unless they recently announced the transaction to the requesting peer for privacy reasons.

In absence of a prior announcement, a node can only learn about a transaction from a peer by requesting the block it was included in.

You can read more about the P2P messages for example here: <https://developer.bitcoin.org/reference/p2p_networking.html>

> **Comments:**
> **username_2**: Maybe a clarification: there is no generic way in the P2P protocol to request a transaction by its txid. The `getdata`/`tx` approach only works for recently announced transactions. Beyond that, the only way of getting transactions is by fetching the blocks they are in.  
> **username_1**: I revised my answer to clarify that confirmed transactions cannot be requested outside of the context of the block they're in.  
> **username_2**: That's not exactly right. The criterion for being able to fetch a transaction is solely "has it been announced recently". If that's the case, it can be requested (even if it has since confirmed). If that's not the case, it's not guaranteed to be requestable (even if it is still unconfirmed); e.g. if a transaction was relayed by node X before you connected to X, you generally can't `getdata` it (for privacy reasons).  
> **username_1**: Thanks for the correction, I hope I got it right now.  

---

