<p>Wtxid relay was introduced in BIP339, where you'll find more details on the rationale and design.</p>
<p>Whenever a node supports BIP339, it will advertize that to its peers, through the <code>wtxidrelay</code> negotiations message. When those peers support BIP339 as well, they may choose to advertize transactions through their wtxid instead of their txid.</p>
<p>Every transaction is only advertized once (using the txid for normal peers, and using the wtxid for BIP339 peers) on each connection. That's not the code you posted though; that code is for populating the relay pool: the set of recent transactions which is used to answer <code>getdata</code> requests sent in response to transactions advertized by <code>inv</code>s. Because some peers may request using the txid, and some may requests using the wtxid (mostly matching their BIP339 support, but even BIP339 peers will in some cases request using txids), both are added to the relay pool.</p>
<blockquote>
<ol>
<li>Why the node send these two ids, what are the benefits?</li>
</ol>
</blockquote>
<p>Wtxid based relay is better, but is not available to pre-BIP339 peers, so both have to remain supported.</p>
<blockquote>
<ol start="2">
<li>Suppose a transaction's txid is A, and its wtxid is B. Nodes will relay A and B inv to peers. After a client received A first, will the client mark this transaction &quot;fAlreadyHave&quot; when receiving B later?</li>
</ol>
</blockquote>
<p>Generally the same transaction is only advertized once per connection, but it is possible that a node hears a txid A first, and the wtxid B later from another peer. If the actual transaction was received already (by fetching tx using txid A), then both txid A and wtxid B will be considered &quot;AlreadyHave&quot;.</p>
<p>Before the actual transaction is received, the node has no idea that advertisements for A and for B refer to the same transaction. To avoid duplicate requests, Bitcoin Core introduces a 2s delay before fetching transactions advertised using txids, to give wtxid peers a chance to advertize it first.</p>

CC BY-SA 4.0
2022-11-08T03:21:42.483Z
2022-11-21T19:45:45.907Z
2022-11-21T19:45:45.907Z
Pieter Wuille
<p>I'm reading the source code of Bitcoin Core, and I found that in the <code>inv</code> process, nodes will relay both txid and wtxid to other peer nodes. I have the following questions:</p>
<ol>
<li>Why does the node send these two ids, what are the benefits?</li>
<li>Suppose a transaction's txid is A, and its wtxid is B. Nodes will relay A and B <code>inv</code> announcements to peers. After a client received A first, will the client mark this transaction &quot;fAlreadyHave&quot; when receiving B later?</li>
</ol>
<p><a href="https://i.sstatic.net/GhbZD.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/GhbZD.png" alt="enter image description here" /></a></p>

<bitcoin-core-development><p2p><source-code><transaction-propagation>
Why does the bitcoin client send transaction's txid and wtxid in 'inv' process?
noob
# Why does the bitcoin client send transaction's txid and wtxid in 'inv' process?

(Asked by: username_0 on 2022-11-08)

I'm reading the source code of Bitcoin Core, and I found that in the `inv` process, nodes will relay both txid and wtxid to other peer nodes. I have the following questions:

1. Why does the node send these two ids, what are the benefits?
2. Suppose a transaction's txid is A, and its wtxid is B. Nodes will relay A and B `inv` announcements to peers. After a client received A first, will the client mark this transaction "fAlreadyHave" when receiving B later?

[![enter image description here](https://i.sstatic.net/GhbZD.png)](https://i.sstatic.net/GhbZD.png)

**Tags:** bitcoin-core-development, p2p, source-code, transaction-propagation


---

## 1 answers

### Answer by username_1 on 2022-11-08. Score: 6 | Accepted answer

Wtxid relay was introduced in BIP339, where you'll find more details on the rationale and design.

Whenever a node supports BIP339, it will advertize that to its peers, through the `wtxidrelay` negotiations message. When those peers support BIP339 as well, they may choose to advertize transactions through their wtxid instead of their txid.

Every transaction is only advertized once (using the txid for normal peers, and using the wtxid for BIP339 peers) on each connection. That's not the code you posted though; that code is for populating the relay pool: the set of recent transactions which is used to answer `getdata` requests sent in response to transactions advertized by `inv`s. Because some peers may request using the txid, and some may requests using the wtxid (mostly matching their BIP339 support, but even BIP339 peers will in some cases request using txids), both are added to the relay pool.

> 1. Why the node send these two ids, what are the benefits?

Wtxid based relay is better, but is not available to pre-BIP339 peers, so both have to remain supported.

> 2. Suppose a transaction's txid is A, and its wtxid is B. Nodes will relay A and B inv to peers. After a client received A first, will the client mark this transaction "fAlreadyHave" when receiving B later?

Generally the same transaction is only advertized once per connection, but it is possible that a node hears a txid A first, and the wtxid B later from another peer. If the actual transaction was received already (by fetching tx using txid A), then both txid A and wtxid B will be considered "AlreadyHave".

Before the actual transaction is received, the node has no idea that advertisements for A and for B refer to the same transaction. To avoid duplicate requests, Bitcoin Core introduces a 2s delay before fetching transactions advertised using txids, to give wtxid peers a chance to advertize it first.


---

