比特幣中的交易中繼和涓涓細流
如果一個節點與其他節點有 100 個連接並使用 getData 請求接收到一個新事務，它會向它的 100 個連接對等方發送一條 inv 消息，對嗎？
它是否還會將 inv 消息發送到它剛剛收到交易的對等方，因為它仍然是正在連接的對等方之一？
‘消息，一般來說，大約每 100 毫秒定期刷新一次。但是，事務中繼是通過“涓涓”消息進行的。比特幣以 1/4 的機率隨機選擇 inv 消息的交易並停止剩餘的交易。每個鄰居都會獲得一組不同的隨機選擇的交易，每個交易大約是目前可用交易的 1/4。只有隨機選擇的“滴流節點”（參見 addr 消息中繼）立即獲得所有交易。其他鄰居要麼稍後得到它，要麼已經從另一個鄰居那裡得到它。涓流減少了成本，同時使流量分析更加困難，其方式類似於混合網路中的混合。
我有點難以理解涓涓細流在交易方面的工作原理。我相信這個過程是在交易發生時，負責交易的節點將向其對等方發送 INV 消息，如果對等方使用 getData 響應，則發送 tx。
如果一個節點與其他節點有 100 個連接並使用 getData 請求接收到一個新事務，它會向它的 100 個連接對等方發送一條 inv 消息，對嗎？
不，這取決於哪些節點發送了
inv他們有該交易的聲明。當inv收到 an 時，節點將記住該節點已inv發送給他們的內容，以便它不會嘗試向其發送它已經擁有的內容。最多inv發送 99 條消息。由於我們已經知道向我們發送交易的對等方已經擁有它，所以我們不會向他們發送inv. 至少，不會inv發送任何消息，因為所有節點可能已經向我們發送inv了同一事務的消息。它是否還會將 inv 消息發送到它剛剛收到交易的對等方，因為它仍然是正在連接的對等方之一？
如上所述，它沒有。雖然沒有明確禁止這種情況的規則，但明智的做法是不要向
inv已經inv向您發送同一件事的人發送。這節省了頻寬成本。我有點難以理解涓涓細流在交易方面的工作原理。
對於每個對等點，該節點都保留了一個將要發送給它的事務列表
inv。它inv定期發送事務處理，每個事務之間有一個隨機延遲inv。inv根據一些涉及費率的指標，選擇交易以稍微隨機地進入消息。它選擇有限數量的交易inv。我相信這個過程是在交易發生時，負責交易的節點將向其對等方發送 INV 消息，如果對等方使用 getData 響應，則發送 tx。
創建交易的節點將該交易視為通過網路接收到的任何其他交易。對於該節點連接到的每個對等方，它將該事務添加到最終將發送到該節點的事務列表中。然後其他一切都照常進行。下次它要
inv為特定對等方發送消息時，它會選擇交易到inv，並且它創建的交易可能是也可能不是其中之一。一旦inv發送了，另一個節點將響應getdata它想要的東西，這可能包括也可能不包括它創建的事務。getdata然後你的節點用交易本身來響應。