Skip to content

Commit c73bd00

Browse files
committed
Merge #18861: Do not answer GETDATA for to-be-announced tx
2896c41 Do not answer GETDATA for to-be-announced tx (Pieter Wuille) f2f32a3 Push down use of cs_main into FindTxForGetData (Pieter Wuille) c6131bf Abstract logic to determine whether to answer tx GETDATA (Pieter Wuille) Pull request description: This PR intends to improve transaction-origin privacy. In general, we should try to not leak information about what transactions we have (recently) learned about before deciding to announce them to our peers. There is a controlled transaction dissemination process that reveals our transactions to peers that has various safeguards for privacy (it's rate-limited, delayed & batched, deterministically sorted, ...), and ideally there is no way to test which transactions we have before that controlled process reveals them. The handling of the `mempool` BIP35 message has protections in this regard as well, as it would be an obvious way to bypass these protections (handled asynchronously after a delay, also deterministically sorted). However, currently, if we receive a GETDATA for a transaction that we have not yet announced to the requester, we will still respond to it if it was announced to *some* other peer already (because it needs to be in `mapRelay`, which only happens on the first announcement). This is a slight privacy leak. Thankfully, this seems easy to solve: `setInventontoryTxToSend` keeps track of the txids we have yet to announce to a peer - which almost(*) exactly corresponds to the transactions we know of that we haven't revealed to that peer. By checking whether a txid is in that set before responding to a GETDATA, we can filter these out. (*) Locally resubmitted or rebroadcasted transactions may end up in setInventoryTxToSend while the peer already knows we have them, which could result in us incorrectly claiming we don't have such transactions if coincidentally requested right after we schedule reannouncing them, but before they're actually INVed. This is made even harder by the fact that filterInventoryKnown will generally keep known reannouncements out of setInventoryTxToSend unless it overflows (which needs 50000 INVs in either direction before it happens). The condition for responding now becomes: ``` (not in setInventoryTxToSend) AND ( (in relay map) OR ( (in mempool) AND (old enough that it could have expired from relay map) AND (older than our last getmempool response) ) ) ``` ACKs for top commit: naumenkogs: utACK 2896c41 ajtowns: ACK 2896c41 amitiuttarwar: code review ACK 2896c41 jonatack: ACK 2896c41 per `git diff 2b3f101 2896c41` only change since previous review is moving the recency check up to be verified first in `FindTxForGetData`, as it was originally in 353a391 (good catch), before looking up the transaction in the relay pool. jnewbery: code review ACK 2896c41 Tree-SHA512: e7d5bc006e626f60a2c108a9334f3bbb67205ace04a7450a1e4d4db1d85922a7589e0524500b7b4953762cf70554c4a08eec62c7b38b486cbca3d86321600868
2 parents 362f9c6 + 2896c41 commit c73bd00

File tree

1 file changed

+51
-47
lines changed

1 file changed

+51
-47
lines changed

src/net_processing.cpp

Lines changed: 51 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -1608,6 +1608,37 @@ void static ProcessGetBlockData(CNode* pfrom, const CChainParams& chainparams, c
16081608
}
16091609
}
16101610

1611+
//! Determine whether or not a peer can request a transaction, and return it (or nullptr if not found or not allowed).
1612+
CTransactionRef static FindTxForGetData(CNode* peer, const uint256& txid, const std::chrono::seconds mempool_req, const std::chrono::seconds longlived_mempool_time) LOCKS_EXCLUDED(cs_main)
1613+
{
1614+
// Check if the requested transaction is so recent that we're just
1615+
// about to announce it to the peer; if so, they certainly shouldn't
1616+
// know we already have it.
1617+
{
1618+
LOCK(peer->m_tx_relay->cs_tx_inventory);
1619+
if (peer->m_tx_relay->setInventoryTxToSend.count(txid)) return {};
1620+
}
1621+
1622+
{
1623+
LOCK(cs_main);
1624+
// Look up transaction in relay pool
1625+
auto mi = mapRelay.find(txid);
1626+
if (mi != mapRelay.end()) return mi->second;
1627+
}
1628+
1629+
auto txinfo = mempool.info(txid);
1630+
if (txinfo.tx) {
1631+
// To protect privacy, do not answer getdata using the mempool when
1632+
// that TX couldn't have been INVed in reply to a MEMPOOL request,
1633+
// or when it's too recent to have expired from mapRelay.
1634+
if ((mempool_req.count() && txinfo.m_time <= mempool_req) || txinfo.m_time <= longlived_mempool_time) {
1635+
return txinfo.tx;
1636+
}
1637+
}
1638+
1639+
return {};
1640+
}
1641+
16111642
void static ProcessGetData(CNode* pfrom, const CChainParams& chainparams, CConnman* connman, CTxMemPool& mempool, const std::atomic<bool>& interruptMsgProc) LOCKS_EXCLUDED(cs_main)
16121643
{
16131644
AssertLockNotHeld(cs_main);
@@ -1622,58 +1653,31 @@ void static ProcessGetData(CNode* pfrom, const CChainParams& chainparams, CConnm
16221653
const std::chrono::seconds mempool_req = pfrom->m_tx_relay != nullptr ? pfrom->m_tx_relay->m_last_mempool_req.load()
16231654
: std::chrono::seconds::min();
16241655

1625-
{
1626-
LOCK(cs_main);
1656+
// Process as many TX items from the front of the getdata queue as
1657+
// possible, since they're common and it's efficient to batch process
1658+
// them.
1659+
while (it != pfrom->vRecvGetData.end() && (it->type == MSG_TX || it->type == MSG_WITNESS_TX)) {
1660+
if (interruptMsgProc) return;
1661+
// The send buffer provides backpressure. If there's no space in
1662+
// the buffer, pause processing until the next call.
1663+
if (pfrom->fPauseSend) break;
16271664

1628-
// Process as many TX items from the front of the getdata queue as
1629-
// possible, since they're common and it's efficient to batch process
1630-
// them.
1631-
while (it != pfrom->vRecvGetData.end() && (it->type == MSG_TX || it->type == MSG_WITNESS_TX)) {
1632-
if (interruptMsgProc)
1633-
return;
1634-
// The send buffer provides backpressure. If there's no space in
1635-
// the buffer, pause processing until the next call.
1636-
if (pfrom->fPauseSend)
1637-
break;
1638-
1639-
const CInv &inv = *it++;
1665+
const CInv &inv = *it++;
16401666

1641-
if (pfrom->m_tx_relay == nullptr) {
1642-
// Ignore GETDATA requests for transactions from blocks-only peers.
1643-
continue;
1644-
}
1667+
if (pfrom->m_tx_relay == nullptr) {
1668+
// Ignore GETDATA requests for transactions from blocks-only peers.
1669+
continue;
1670+
}
16451671

1646-
// Send stream from relay memory
1647-
bool push = false;
1648-
auto mi = mapRelay.find(inv.hash);
1672+
CTransactionRef tx = FindTxForGetData(pfrom, inv.hash, mempool_req, longlived_mempool_time);
1673+
if (tx) {
16491674
int nSendFlags = (inv.type == MSG_TX ? SERIALIZE_TRANSACTION_NO_WITNESS : 0);
1650-
if (mi != mapRelay.end()) {
1651-
connman->PushMessage(pfrom, msgMaker.Make(nSendFlags, NetMsgType::TX, *mi->second));
1652-
push = true;
1653-
} else {
1654-
auto txinfo = mempool.info(inv.hash);
1655-
// To protect privacy, do not answer getdata using the mempool when
1656-
// that TX couldn't have been INVed in reply to a MEMPOOL request,
1657-
// or when it's too recent to have expired from mapRelay.
1658-
if (txinfo.tx && (
1659-
(mempool_req.count() && txinfo.m_time <= mempool_req)
1660-
|| (txinfo.m_time <= longlived_mempool_time)))
1661-
{
1662-
connman->PushMessage(pfrom, msgMaker.Make(nSendFlags, NetMsgType::TX, *txinfo.tx));
1663-
push = true;
1664-
}
1665-
}
1666-
1667-
if (push) {
1668-
// We interpret fulfilling a GETDATA for a transaction as a
1669-
// successful initial broadcast and remove it from our
1670-
// unbroadcast set.
1671-
mempool.RemoveUnbroadcastTx(inv.hash);
1672-
} else {
1673-
vNotFound.push_back(inv);
1674-
}
1675+
connman->PushMessage(pfrom, msgMaker.Make(nSendFlags, NetMsgType::TX, *tx));
1676+
mempool.RemoveUnbroadcastTx(inv.hash);
1677+
} else {
1678+
vNotFound.push_back(inv);
16751679
}
1676-
} // release cs_main
1680+
}
16771681

16781682
// Only process one BLOCK item per call, since they're uncommon and can be
16791683
// expensive to process.

0 commit comments

Comments
 (0)