Improve performance of p2p inv to send queues #27610

ajtowns · 2023-05-10T00:11:48Z

Couple of performance improvements when draining the inventory-to-send queue:

drop txs that have already been evicted from the mempool (or included in a block) immediately, rather than at the end of processing
marginally increase outgoing trickle rate during spikes in tx volume

DrahtBot · 2023-05-10T00:11:51Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	darosior, willcl-ark, instagibbs, glozow, dergoegge
Concept ACK	0xB10C, pinheadmz

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

We use CompareDepthAndScore to choose an order of txs to inv. Rather than sorting txs that have been evicted from the mempool at the end of the list, sort them at the beginning so they are removed from the queue immediately.

If transactions are being added to the mempool at a rate faster than 7tx/s (INVENTORY_BROADCAST_PER_SECOND) then peers' inventory_to_send queue can become relatively large. If this happens, increase the number of txids we include in an INV message (normally capped at 35) by 5 for each 1000 txids in the queue. This will tend to clear a temporary excess out reasonably quickly; an excess of 4000 invs to send will be cleared down to 1000 in about 30 minutes, while an excess of 20000 invs would be cleared down to 1000 in about 60 minutes.

darosior

utACK 5b34060

0xB10C · 2023-05-10T13:04:52Z

Concept ACK

willcl-ark · 2023-05-10T13:05:50Z

ACK 5b34060

Currently running this cherry-picked on top of v24.0.1 on mainnet and seeing reduced resource usage.

instagibbs · 2023-05-10T13:19:49Z

ACK 5b34060

Significant reduction in CPU usage when influx of transactions is high and sustained. Allows an additional INV to trickle per additional 200 INV backlog, capped at 1k.

0xB10C · 2023-05-10T14:48:29Z

Compared where the time is spent in the b-msghand thread on a mainnet master and a mainnet 5b34060 node that were both running for a while. Followed eklitzke's flamegraph.md to create the flamegraphs below. This seems to be indeed a nice performance improvement. The second flamegraph looks healthier.

master:

5b34060:

glozow · 2023-05-10T15:28:31Z

src/net_processing.cpp

@@ -5666,7 +5666,9 @@ bool PeerManagerImpl::SendMessages(CNode* pto)
                    // especially since we have many peers and some will draw much shorter delays.
                    unsigned int nRelayedTransactions = 0;
                    LOCK(tx_relay->m_bloom_filter_mutex);
-                    while (!vInvTx.empty() && nRelayedTransactions < INVENTORY_BROADCAST_MAX) {
+                    size_t broadcast_max{INVENTORY_BROADCAST_MAX + (tx_relay->m_tx_inventory_to_send.size()/1000)*5};


Could this increase the number of transactions we're announcing beyond INVENTORY_MAX_RECENT_RELAY = 3500 so things fall out of m_recently_announced_invs (essentially what you said in #27602 (comment))?

Maybe we want to increase INVENTORY_MAX_RECENT_RELAY, e.g. equal to MAX_PEER_TX_ANNOUNCEMENTS = 5000 (the max requesting coming from the receiver end if they're Bitcoin Core - imo it could make sense for these to be symmetrical)?

The 3500 figure is calculated based on outbound peers, which already have 2.5x the INV rate of inbound peers. An inbound peer would need to be at 65 or 70 txids per INV message to have the same 1-in-a-million chance of a problem, implying a tx rate of 13 or 14 tx/s. To get to a 1-in-100 chance of a problem, you'd need to hit 90-to-95 txids per INV (and sustain that for ~40 INVs, and hit the 1-in-100 chance of sending those 40 INVs in a 2 minute period). Those seem okay to me.

Note to others: we may send outbound peers 7 * 2.5 * 60 * 2 ~= 2100 transaction ids per 2 minutes. Depending on random variation it can be more. UNCONDITIONAL_RELAY_DELAY = 2min; is the period of time that we have to remember what we sent to a specific peer. For privacy reason we don't want to reveal these transactions to other (spy) peers yet. We do this tracking with a bloom filter m_recently_announced_invs that has a 1 in a million chance of messing up. I forgot if it's false positive (we give the spy a transaction we shouldn't have) or negative (we deny them a transaction we just announced).

Now my question:
This change increases the max rate for outbound rate too, so I'm still confused why we don't have to increase the 3500. This PR increases the maximum rate to outbound peers from 7 * 2.5 = 17.5 tx/s to 1000 / 2 = 500 tx/s (in theory, presumably not in practice), so a 4 second burst would fill it up.

From below:

(Could make sense to limit it to 90 for inbounds and 45 for outbounds as (if sustained for two minutes) those values would hit roughly a 1-in-100 chance of overflowing INVENTORY_MAX_RECENT_RELAY)

That would make more sense to me as well, plus:

static asserts or something would be even better

pinheadmz

Concept ACK

A few questions below.

I have a non-debug mainnet node with a 100% b-msghandler thread. I'm going to deploy this branch today and monitor

pinheadmz · 2023-05-10T15:05:20Z

src/net_processing.cpp

@@ -5666,7 +5666,9 @@ bool PeerManagerImpl::SendMessages(CNode* pto)
                    // especially since we have many peers and some will draw much shorter delays.
                    unsigned int nRelayedTransactions = 0;
                    LOCK(tx_relay->m_bloom_filter_mutex);
-                    while (!vInvTx.empty() && nRelayedTransactions < INVENTORY_BROADCAST_MAX) {
+                    size_t broadcast_max{INVENTORY_BROADCAST_MAX + (tx_relay->m_tx_inventory_to_send.size()/1000)*5};
+                    broadcast_max = std::min<size_t>(1000, broadcast_max);


Why stop at 1000? If it's the same rationale could you use this constant?

bitcoin/src/net_processing.cpp

Lines 109 to 110 in 104eed1

/** Limit to avoid sending big packets. Not used in processing incoming GETDATA for compatibility */

static const unsigned int MAX_GETDATA_SZ = 1000;

It's more related to MAX_PEER_TX_ANNOUNCEMENTS=5000 (we don't want to send more than we would be willing to receive) and INVENTORY_MAX_RECENT_RELAY=3500 (we don't want to advertise txids and then refuse to relay them because we've forgotten that we advertised them).

(Could make sense to limit it to 90 for inbounds and 45 for outbounds as (if sustained for two minutes) those values would hit roughly a 1-in-100 chance of overflowing INVENTORY_MAX_RECENT_RELAY)

Explaining that in a comment would be nice

static asserts or something would be even better

src/txmempool.cpp

glozow

code review ACK 5b34060

dergoegge

utACK 5b34060

The code and approach looks good to me.

(my comments can be addressed in a follow-up)

dergoegge · 2023-05-11T11:20:01Z

src/net_processing.cpp

@@ -5666,7 +5666,9 @@ bool PeerManagerImpl::SendMessages(CNode* pto)
                    // especially since we have many peers and some will draw much shorter delays.
                    unsigned int nRelayedTransactions = 0;
                    LOCK(tx_relay->m_bloom_filter_mutex);
-                    while (!vInvTx.empty() && nRelayedTransactions < INVENTORY_BROADCAST_MAX) {
+                    size_t broadcast_max{INVENTORY_BROADCAST_MAX + (tx_relay->m_tx_inventory_to_send.size()/1000)*5};


INVENTORY_BROADCAST_MAX should be renamed or have its comment amended

clang-format?

Maybe add the commit description as a comment here

@dergoegge INVENTORY_BROADCAST_MAX has been poorly named for a while. It applies to inbound peers, but to outbounds we send 5 / 2 more.

dergoegge · 2023-05-11T11:20:53Z

src/net_processing.cpp

@@ -5666,7 +5666,9 @@ bool PeerManagerImpl::SendMessages(CNode* pto)
                    // especially since we have many peers and some will draw much shorter delays.
                    unsigned int nRelayedTransactions = 0;
                    LOCK(tx_relay->m_bloom_filter_mutex);
-                    while (!vInvTx.empty() && nRelayedTransactions < INVENTORY_BROADCAST_MAX) {
+                    size_t broadcast_max{INVENTORY_BROADCAST_MAX + (tx_relay->m_tx_inventory_to_send.size()/1000)*5};
+                    broadcast_max = std::min<size_t>(1000, broadcast_max);


Explaining that in a comment would be nice

dergoegge · 2023-05-11T12:54:12Z

src/net_processing.cpp

@@ -5666,7 +5666,9 @@ bool PeerManagerImpl::SendMessages(CNode* pto)
                    // especially since we have many peers and some will draw much shorter delays.
                    unsigned int nRelayedTransactions = 0;
                    LOCK(tx_relay->m_bloom_filter_mutex);
-                    while (!vInvTx.empty() && nRelayedTransactions < INVENTORY_BROADCAST_MAX) {
+                    size_t broadcast_max{INVENTORY_BROADCAST_MAX + (tx_relay->m_tx_inventory_to_send.size()/1000)*5};


Suggested change

size_t broadcast_max{INVENTORY_BROADCAST_MAX + (tx_relay->m_tx_inventory_to_send.size()/1000)*5};

size_t broadcast_max{INVENTORY_BROADCAST_MAX + (tx_relay->m_tx_inventory_to_send.size() / 1000) * count_seconds(INBOUND_INVENTORY_BROADCAST_INTERVAL)};

brunoerg

post-merge crACK 5b34060

brunoerg · 2023-05-11T13:23:11Z

src/txmempool.cpp

@@ -755,11 +755,16 @@ void CTxMemPool::check(const CCoinsViewCache& active_coins_tip, int64_t spendhei

 bool CTxMemPool::CompareDepthAndScore(const uint256& hasha, const uint256& hashb, bool wtxid)
 {
+    /* Return `true` if hasha should be considered sooner than hashb. Namely when:
+     *   a is not in the mempool, but b is


Could we have these cases covered by a unit test?

I've written a unit test here: https://github.com/glozow/bitcoin/commits/2023-05-comparedepthandscore-test

Cool, @glozow.

We use CompareDepthAndScore to choose an order of txs to inv. Rather than sorting txs that have been evicted from the mempool at the end of the list, sort them at the beginning so they are removed from the queue immediately. Github-Pull: bitcoin#27610 Rebased-From: 228e920

If transactions are being added to the mempool at a rate faster than 7tx/s (INVENTORY_BROADCAST_PER_SECOND) then peers' inventory_to_send queue can become relatively large. If this happens, increase the number of txids we include in an INV message (normally capped at 35) by 5 for each 1000 txids in the queue. This will tend to clear a temporary excess out reasonably quickly; an excess of 4000 invs to send will be cleared down to 1000 in about 30 minutes, while an excess of 20000 invs would be cleared down to 1000 in about 60 minutes. Github-Pull: bitcoin#27610 Rebased-From: 5b34060

We use CompareDepthAndScore to choose an order of txs to inv. Rather than sorting txs that have been evicted from the mempool at the end of the list, sort them at the beginning so they are removed from the queue immediately. Github-Pull: bitcoin#27610 Rebased-From: 228e920

If transactions are being added to the mempool at a rate faster than 7tx/s (INVENTORY_BROADCAST_PER_SECOND) then peers' inventory_to_send queue can become relatively large. If this happens, increase the number of txids we include in an INV message (normally capped at 35) by 5 for each 1000 txids in the queue. This will tend to clear a temporary excess out reasonably quickly; an excess of 4000 invs to send will be cleared down to 1000 in about 30 minutes, while an excess of 20000 invs would be cleared down to 1000 in about 60 minutes. Github-Pull: bitcoin#27610 Rebased-From: 5b34060

maflcko

first commit lgtm. Left one question. Didn't look too long at the second commit.

maflcko · 2023-05-11T10:03:08Z

src/txmempool.cpp

    indexed_transaction_set::const_iterator j = wtxid ? get_iter_from_wtxid(hashb) : mapTx.find(hashb);
-    if (j == mapTx.end()) return true;
+    if (j == mapTx.end()) return false;
+    indexed_transaction_set::const_iterator i = wtxid ? get_iter_from_wtxid(hasha) : mapTx.find(hasha);


question (feel free to ignore): I tried to figure out if there was a reason why this was re-ordered, but couldn't find one. An equivalent patch of simply changing the literals false to true and true to false in this function should have achieved the same, right?

The CompareTxMemPoolEntryByScore comparator returns false on equality (ie, it's "less than" not "less than or equal"), so this preserves that behaviour.

Thanks, I should have just read the documentation: https://en.cppreference.com/w/cpp/named_req/Compare , which would have answered this.

97f5e28 doc: update release notes for 24.1rc3 (fanquake) 7e9c7ae doc: update manual pages for v24.1rc3 (fanquake) abb9fa0 build: bump version to v24.1rc3 (fanquake) 128da6e net_processing: Boost inv trickle rate (Anthony Towns) a9a861a txmempool: have CompareDepthAndScore sort missing txs first (Anthony Towns) ec7cd33 p2p: Avoid prematurely clearing download state for other peers (Suhas Daftuar) Pull request description: Backports for rc3. Currently: * #27608 * #27610 ACKs for top commit: josibake: ACK 97f5e28 dergoegge: ACK 97f5e28 achow101: ACK 97f5e28 glozow: ACK 97f5e28 brunoerg: ACK 97f5e28 hebasto: ACK 97f5e28, commits were backported locally, got zero diff. Tree-SHA512: 09572285ed1e8169d7e77d12ec438586dab54c86064de85d0e743564e601686f884bf74f2bf8ed1be73bddcd7db6da4277c6dd6b9732e7eca383e108f8f37d58

mzumsande

Post-Merge ACK.

I've been running this patch (plus added reporting in getpeerinfo, mzumsande@6932997) for a few days, and have neither seen extremely high backlogs > 5000 in m_tx_inventory_to_send nor enhanced CPU use.

In order to better monitor the efficacy of this, it might make sense to expose the size of m_tx_inventory_to_send via RPC permanently?

We use CompareDepthAndScore to choose an order of txs to inv. Rather than sorting txs that have been evicted from the mempool at the end of the list, sort them at the beginning so they are removed from the queue immediately. Github-Pull: bitcoin#27610 Rebased-From: 228e920

If transactions are being added to the mempool at a rate faster than 7tx/s (INVENTORY_BROADCAST_PER_SECOND) then peers' inventory_to_send queue can become relatively large. If this happens, increase the number of txids we include in an INV message (normally capped at 35) by 5 for each 1000 txids in the queue. This will tend to clear a temporary excess out reasonably quickly; an excess of 4000 invs to send will be cleared down to 1000 in about 30 minutes, while an excess of 20000 invs would be cleared down to 1000 in about 60 minutes. Github-Pull: bitcoin#27610 Rebased-From: 5b34060

49a2d66 doc: update manual pages for v25.0rc2 (fanquake) 3ea4a11 build: bump version to v25.0rc2 (fanquake) 7ef71e3 net_processing: Boost inv trickle rate (Anthony Towns) 1adbcd3 txmempool: have CompareDepthAndScore sort missing txs first (Anthony Towns) 9a23079 p2p: Avoid prematurely clearing download state for other peers (Suhas Daftuar) Pull request description: Backports for rc2. Currently: * #27608 * #27610 ACKs for top commit: achow101: ACK 49a2d66 Tree-SHA512: a1a7678e16136636ec8a232d12630529639bae3b577769b5a5fd204dda234a5e588f3d4dfebf4d7abe7111d13cc0714f9ccdea0a858fe821a7146e6a697308d3

5b34060 net_processing: Boost inv trickle rate (Anthony Towns) 228e920 txmempool: have CompareDepthAndScore sort missing txs first (Anthony Towns) Pull request description: Couple of performance improvements when draining the inventory-to-send queue: * drop txs that have already been evicted from the mempool (or included in a block) immediately, rather than at the end of processing * marginally increase outgoing trickle rate during spikes in tx volume ACKs for top commit: willcl-ark: ACK 5b34060 instagibbs: ACK bitcoin@5b34060 darosior: utACK 5b34060 glozow: code review ACK 5b34060 dergoegge: utACK 5b34060 Tree-SHA512: 155cd3b5d150ba3417c1cd126f2be734497742e85358a19c9d365f4f97c555ff9e846405bbeada13c3575b3713c3a7eb2f780879a828cbbf032ad9a6e5416b30

Sjors · 2023-05-12T09:04:10Z

src/txmempool.cpp

@@ -755,11 +755,16 @@ void CTxMemPool::check(const CCoinsViewCache& active_coins_tip, int64_t spendhei

 bool CTxMemPool::CompareDepthAndScore(const uint256& hasha, const uint256& hashb, bool wtxid)
 {
+    /* Return `true` if hasha should be considered sooner than hashb. Namely when:


For a followup it would be could to clarify "should be considered" for what. It's somewhat confusing to reason about because the call site reverses a and b.

The first case in the comment is "a is not in the mempool, but b is", but the line of code checks if b is not in the mempool.

The first case in the comment is "a is not in the mempool, but b is", but the line of code checks if b is not in the mempool.

If b is not in the mempool, the function must return false, see #27610 (comment)

If b is in the mempool, the function will continue over the early return false, and checks to see if a is missing, in which case it should be considered sooner.

"should be considered" for what

For processing, which begins by dropping a transaction from m_tx_inventory_to_send before deciding whether to send it. Since we stop processing after having sent broadcast_max transactions, it makes sense to do the cleaning first.

A return value of true means hasha is lower, i.e. would be at the bottom of the (max)heap and processed last. But because we swap a and b when calling this, it works. That was introduced in the second commit of #7840.

We could prune non-mempool transactions even before making a heap, but that would double the mempool lookups, and the flame graph suggests that make_heap is plenty fast already now.

a26ff20 doc: add initial release notes for v23.2 (fanquake) 60edfd5 doc: update manual pages for v23.2rc1 (fanquake) b93814b doc: update version in bips.md to v23.2 (fanquake) 67bbe6d build: bump version to v23.2rc1 (fanquake) 06731d1 net_processing: Boost inv trickle rate (Anthony Towns) d0a2c87 txmempool: have CompareDepthAndScore sort missing txs first (Anthony Towns) ce8f812 p2p: Avoid prematurely clearing download state for other peers (Suhas Daftuar) Pull request description: Final backports for `rc1`. Currently: * #27608 (not a clean cherry-pick) * #27610 (second commit is not clean) ACKs for top commit: achow101: ACK a26ff20 dergoegge: ACK a26ff20 ajtowns: utACK a26ff20 Tree-SHA512: 59e43ec4d5004b3543d5c0366c9dc8c5f8a6a777b147628ebc0c03aeb0846312a7780376ebf40f389e3403e4501ba2b70bb97925479670bee13c89e5b6925137

Sjors · 2023-05-12T13:21:24Z

Partial utACK, for 228e920 (i.e. the changes in CompareDepthAndScore). Took me a while to wrap my head around it.

pinheadmz · 2023-05-17T14:10:54Z

I've been running this branch for 7 days on a VPS and noticed this morning the CPU on b-msghand is back up to 100%. It was about that high running v24 release but dropped to 30% or so when I first switched to this branch and restarted.

willcl-ark · 2023-05-17T15:12:34Z

@pinheadmz I am also still running this patch, but I still see pretty stable utilisation in the range of ~2-12%, currently with 88 inbound peers.

0xB10C · 2023-05-18T17:19:59Z

I've been running this branch for 7 days on a VPS and noticed this morning the CPU on b-msghand is back up to 100%. It was about that high running v24 release but dropped to 30% or so when I first switched to this branch and restarted.

@pinheadmz I've been running the patch on multiple nodes for a week now and haven't seen 100% CPU usage in the b-msghand thread again. If you haven't restarted or if it happens again, it would be helpful to see which functions are slow. perf top -p $(pidof bitcoind) should do the trick.

maflcko · 2023-05-18T17:30:00Z

Could also make sense to double check the debug.log to ensure you restarted bitcoind after compiling? 😅

pinheadmz · 2023-05-18T17:35:53Z

Could also make sense to double check the debug.log to ensure you restarted bitcoind after compiling? 😅

Phew! That would've been embarassing

2023-05-10T15:39:40Z Bitcoin Core version v25.99.0-5b3406094f26 (debug build)

perf top -p $(pidof bitcoind) should do the trick.

Not familiar with this tool but it looks cool! This is at the top. Every other line in the output is < 0.10%

  99.56%  bitcoind             [.] boost::multi_index::detail::safe_iterator_base::detach

maflcko · 2023-05-18T17:47:32Z

(debug build)

See #27700 (comment) ?

pinheadmz · 2023-05-18T17:50:24Z

ah thanks I forgot I configured that way, will follow the other threads

…in#27610" This reverts commit 3270c6c.

For all release notes since 0.21.2, see [1]. This commit also: - removes the package patches, all included in this release, - removes the patch entry in ".checkpackageignore", - adds a comment about pgp signature check in the hash file, - updates the license hash, due to year update, - adds the requirement on gcc >= 9, see [2], - removes the dependency on !BR2_TOOLCHAIN_HAS_GCC_BUG_64735 which is no longer needed, due to the gcc version requirement. Fixes: - [3] Note: this CVE-2023-33297 is not explicitly mentioned in the Bitcoin core release notes. It is not either appearing in CVE list at [4]. The change corresponding to this vulnerability is "#27610 Improve performance of p2p inv to send queues" in the version 24.1 release note. See [5] and [6]. [1] https://github.com/bitcoin/bitcoin/tree/v26.0/doc/release-notes [2] https://github.com/bitcoin/bitcoin/blob/v26.0/doc/dependencies.md [3] https://nvd.nist.gov/vuln/detail/CVE-2023-33297 [4] https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures [5] https://github.com/bitcoin/bitcoin/blob/v26.0/doc/release-notes/release-notes-24.1.md?plain=1#L45 [6] bitcoin/bitcoin#27610 Signed-off-by: Julien Olivain <ju.o@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

For all release notes since 0.21.2, see [1]. This commit also: - removes the package patches, all included in this release, - removes the patch entry in ".checkpackageignore", - adds a comment about pgp signature check in the hash file, - updates the license hash, due to year update, - adds the requirement on gcc >= 9, see [2], - removes the dependency on !BR2_TOOLCHAIN_HAS_GCC_BUG_64735 which is no longer needed, due to the gcc version requirement. Fixes: - [3] Note: this CVE-2023-33297 is not explicitly mentioned in the Bitcoin core release notes. It is not either appearing in CVE list at [4]. The change corresponding to this vulnerability is "#27610 Improve performance of p2p inv to send queues" in the version 24.1 release note. See [5] and [6]. [1] https://github.com/bitcoin/bitcoin/tree/v26.0/doc/release-notes [2] https://github.com/bitcoin/bitcoin/blob/v26.0/doc/dependencies.md [3] https://nvd.nist.gov/vuln/detail/CVE-2023-33297 [4] https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures [5] https://github.com/bitcoin/bitcoin/blob/v26.0/doc/release-notes/release-notes-24.1.md?plain=1#L45 [6] bitcoin/bitcoin#27610 Signed-off-by: Julien Olivain <ju.o@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> (cherry picked from commit a3a88ff) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

ajtowns added 2 commits May 10, 2023 10:51

txmempool: have CompareDepthAndScore sort missing txs first

228e920

We use CompareDepthAndScore to choose an order of txs to inv. Rather than sorting txs that have been evicted from the mempool at the end of the list, sort them at the beginning so they are removed from the queue immediately.

ajtowns force-pushed the 202305-invtosend branch from 95dcd1a to 5b34060 Compare May 10, 2023 00:52

ajtowns mentioned this pull request May 10, 2023

CPU DoS on mainnet in debug mode #27586

Closed

darosior reviewed May 10, 2023

View reviewed changes

glozow reviewed May 10, 2023

View reviewed changes

pinheadmz reviewed May 10, 2023

View reviewed changes

willcl-ark mentioned this pull request May 11, 2023

One core in CPU usage rate remains at 100% for a long time, causing serious delays in new blocks and forks #27623

Closed

1 task

glozow reviewed May 11, 2023

View reviewed changes

dergoegge approved these changes May 11, 2023

View reviewed changes

fanquake merged commit 137a98c into bitcoin:master May 11, 2023

brunoerg approved these changes May 11, 2023

View reviewed changes

brunoerg reviewed May 11, 2023

View reviewed changes

fanquake mentioned this pull request May 11, 2023

[24.1] Backports for rc3 #27614

Merged

fanquake mentioned this pull request May 11, 2023

[25.0] Backports for rc2 #27613

Merged

maflcko reviewed May 11, 2023

View reviewed changes

dergoegge mentioned this pull request May 11, 2023

[23.2] Backports for rc1 #27624

Merged

mzumsande reviewed May 11, 2023

View reviewed changes

Sjors reviewed May 12, 2023

View reviewed changes

dergoegge mentioned this pull request May 12, 2023

p2p: Increase tx relay rate #27630

Closed

ajtowns mentioned this pull request May 15, 2023

net processing: avoid serving non-announced txs as a result of a MEMPOOL message #27602

Closed

ajtowns mentioned this pull request Oct 5, 2023

p2p: Increase tx relay rate #28592

Open

losh11 mentioned this pull request Feb 18, 2024

Vulnerability in 24.0.1 bitcoin upstream: CVE-2023-33297 (ONLY affects the unmerged .24 branches) litecoin-project/litecoin#913

Closed

losh11 added a commit to litecoin-project/litecoin that referenced this pull request Mar 3, 2024

backport: Improve performance of p2p inv to send queues bitcoin#27610

2170c24

losh11 added a commit to litecoin-project/litecoin that referenced this pull request Mar 6, 2024

backport: Improve performance of p2p inv to send queues bitcoin#27610

3270c6c

losh11 added a commit to litecoin-project/litecoin that referenced this pull request Mar 6, 2024

Revert "backport: Improve performance of p2p inv to send queues bitco…

b0f96bc

…in#27610" This reverts commit 3270c6c.

digirayc added a commit to digirayc/cyberyen that referenced this pull request Apr 1, 2024

Backport: Improve performance of p2p inv to send queues bitcoin#27610

cce321a

koh-gt mentioned this pull request Apr 25, 2024

fecv-3.2.0 koh-gt/ferrite-core#62

Merged

bitcoin locked and limited conversation to collaborators May 17, 2024

	/** Limit to avoid sending big packets. Not used in processing incoming GETDATA for compatibility */
	static const unsigned int MAX_GETDATA_SZ = 1000;

	size_t broadcast_max{INVENTORY_BROADCAST_MAX + (tx_relay->m_tx_inventory_to_send.size()/1000)*5};
	size_t broadcast_max{INVENTORY_BROADCAST_MAX + (tx_relay->m_tx_inventory_to_send.size() / 1000) * count_seconds(INBOUND_INVENTORY_BROADCAST_INTERVAL)};

Improve performance of p2p inv to send queues #27610

Improve performance of p2p inv to send queues #27610

Uh oh!

Conversation

ajtowns commented May 10, 2023

Uh oh!

DrahtBot commented May 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviews

Uh oh!

darosior left a comment

Choose a reason for hiding this comment

Uh oh!

0xB10C commented May 10, 2023

Uh oh!

willcl-ark commented May 10, 2023

Uh oh!

instagibbs commented May 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0xB10C commented May 10, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sjors May 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pinheadmz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

glozow left a comment

Choose a reason for hiding this comment

Uh oh!

dergoegge left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brunoerg left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maflcko left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mzumsande left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DrahtBot commented May 10, 2023 •

edited

Loading

instagibbs commented May 10, 2023 •

edited

Loading

Sjors May 15, 2023 •

edited

Loading

brunoerg left a comment •

edited

Loading

Sjors May 12, 2023 •

edited

Loading

Sjors commented May 12, 2023 •

edited

Loading