diff options
author | fanquake <fanquake@gmail.com> | 2022-05-19 09:09:59 +0100 |
---|---|---|
committer | fanquake <fanquake@gmail.com> | 2022-05-19 09:27:24 +0100 |
commit | 986bae8e72481a46744e299432beeb4dffb64a9a (patch) | |
tree | 7291f23eff7d0712c26e3b10e8ab85620bd5f51d /test | |
parent | bb83aba6c98b948c1715b26237980a4ddc87a547 (diff) | |
parent | 9db82f1bca0bb51c2180ca4a4ad63ba490e79da4 (diff) | |
download | bitcoin-986bae8e72481a46744e299432beeb4dffb64a9a.tar.xz |
Merge bitcoin/bitcoin#22778: net processing: Reduce resource usage for inbound block-relay-only connections
9db82f1bca0bb51c2180ca4a4ad63ba490e79da4 [net processing] Don't initialize TxRelay for non-tx-relay peers. (John Newbery)
b0a4ac9c26f60fd4993d89f45cafffaa389db2d4 [net processing] Add m_tx_relay_mutex to protect m_tx_relay ptr (John Newbery)
290a8dab0288344fa5731ec2ffd09478e9420a2f [net processing] Comment all TxRelay members (John Newbery)
42e3250497b03478d61cd6bfe6cd904de73d57b1 [net processing] [refactor] Move m_next_send_feefilter and m_fee_filter_sent (John Newbery)
Pull request description:
block-relay-only connections are additional outbound connections that bitcoind makes since v0.19. They participate in block relay, but do not propagate transactions or addresses. They were introduced in #15759.
When creating an outbound block-relay-only connection, since we know that we're never going to announce transactions over that connection, we can save on memory usage by not a `TxRelay` data structure for that connection. When receiving an inbound connection, we don't know whether the connection was opened by the peer as block-relay-only or not, and therefore we always construct a `TxRelay` data structure for inbound connections.
However, it is possible to tell whether an inbound connection will ever request that we start announcing transactions to it. The `fRelay` field in the `version` message may be set to `0` to indicate that the peer does not wish to receive transaction announcements. The peer may later request that we start announcing transactions to it by sending a `filterload` or `filterclear` message, **but only if we have offered `NODE_BLOOM` services to that peer**. `NODE_BLOOM` services are disabled by default, and it has been recommended for some time that users not enable `NODE_BLOOM` services on public connections, for privacy and anti-DoS reasons.
Therefore, if we have not offered `NODE_BLOOM` to the peer _and_ it has set `fRelay` to `0`, then we know that it will never request transaction announcements, and that we can save resources by not initializing the `TxRelay` data structure.
ACKs for top commit:
MarcoFalke:
review ACK 9db82f1bca0bb51c2180ca4a4ad63ba490e79da4 🖖
dergoegge:
Code review ACK 9db82f1bca0bb51c2180ca4a4ad63ba490e79da4
naumenkogs:
ACK 9db82f1bca0bb51c2180ca4a4ad63ba490e79da4
Tree-SHA512: 83a449a56cd6bf6ad05369f5ab91516e51b8c471c07ae38c886d51461e942d492ca34ae63d329c46e56d96d0baf59a3e34233e4289868f911db3b567072bdc41
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions