Source-Code
為什麼比特幣客戶端在“inv”過程中發送交易的 txid 和 wtxid？
我正在閱讀 Bitcoin Core 的原始碼，我發現在這個
inv過程中，節點會將 txid 和 wtxid 中繼到其他對等節點。我有以下問題：
- 為什麼節點發送這兩個id，有什麼好處？
- 假設一個事務的 txid 是 A，它的 wtxid 是 B。節點會將 A 和 B inv 中繼給對等點。客戶端先收到A後，以後收到B的時候會不會把這個事務標記為“fAlreadyHave”？
Wtxid 繼電器是在 BIP339 中引入的，您可以在其中找到有關基本原理和設計的更多詳細資訊。
每當一個節點支持 BIP339 時，它都會通過
wtxidrelay協商消息將其通告給它的對等方。當這些對等點也支持 BIP339 時，他們可能會選擇通過他們的 wtxid 而不是他們的 txid 來宣傳交易。每個交易只在每個連接上發布一次（對普通對等點使用 txid，對 BIP339 對等點使用 wtxid）。那不是您發布的程式碼；該程式碼用於填充中繼池：一組最近的事務，用於
getdata響應為響應 s 通告的事務而發送的請求inv。因為一些對等點可能使用 txid 請求，而一些可能使用 wtxid 請求（大部分匹配它們的 BIP339 支持，但即使 BIP339 對等點在某些情況下也會使用 txids 請求），兩者都被添加到中繼池中。
- 為什麼節點發送這兩個id，有什麼好處？
基於 Wtxid 的中繼更好，但對 BIP339 之前的對等方不可用，因此兩者都必須保持支持。
- 假設一個事務的 txid 是 A，它的 wtxid 是 B。節點會將 A 和 B inv 中繼給對等點。客戶端先收到A後，以後收到B的時候會不會把這個事務標記為“fAlreadyHave”？
通常，同一事務在每個連接中只通告一次，但有可能一個節點先聽到 txid A，然後再從另一個對等點聽到 wtxid B。如果實際交易已經收到（通過使用 txid A 獲取 tx），那麼 tzid A 和 wtxid B 都將被視為“AlreadyHave”。
在收到實際交易之前，節點不知道 A 和 B 的廣告指的是同一交易。為了避免重複請求，Bitcoin Core 在獲取使用 txids 通告的交易之前引入了 2 秒的延遲，以便讓 wtxid 對等點有機會首先通告它。