Processing of new blocks slower than necessary due to overly selective peer selection

rebroad commented at 8:13 am on April 29, 2021: contributor

From the debug.log below, 12 seconds was saved by slightly changing the code to allow the first cmpctblock received to be used instead of the cmpctblock requested from the first node that announced the block (via headers).

I realise perhaps most miners will be using the backbone and so perhaps a 12 second delay between nodes might be uncommon - it could be useful to see what are typical delays in situations where the backbone is used.

2021-04-29T08:02:12.411 recv new best header 0000000000000000000acc7acbceda74c626835d58c2e31c1fe58b2ca7fa1645 (681070) age=19s peer=51 2021-04-29T08:02:12.412 Requesting cmpctblock 0000000000000000000acc7acbceda74c626835d58c2e31c1fe58b2ca7fa1645 (681070) age=19s peer=51 2021-04-29T08:02:12.414 recv best cmpctblock 0000000000000000000acc7acbceda74c626835d58c2e31c1fe58b2ca7fa1645 (681070) age=19s size=6587 peer=62 2021-04-29T08:02:12.414 Rather than wait for peer=51 we’ll use this one peer=62 2021-04-29T08:02:12.437 Calling ProcessMessage(BLOCKTXN) peer=62 2021-04-29T08:02:12.437 recv blocktxn 0000000000000000000acc7acbceda74c626835d58c2e31c1fe58b2ca7fa1645 (681070) age=19s indexes=0 size=33 peer=62 2021-04-29T08:02:12.463 made block 0000000000000000000acc7acbceda74c626835d58c2e31c1fe58b2ca7fa1645 with 1 txn prefilled, 1022 txn from mempool (incl at least 0 from extra pool) and 0 txn requested 2021-04-29T08:02:12.880 UpdateTip: new best=0000000000000000000acc7acbceda74c626835d58c2e31c1fe58b2ca7fa1645 height=681070 version=0x3fffe000 log2_work=92.841074 tx=637848335 date=‘2021-04-29T08:01:50Z’ progress=1.000000 cache=91.7MiB(692788txo) 2021-04-29T08:02:24.280 recv tip cmpctblock 0000000000000000000acc7acbceda74c626835d58c2e31c1fe58b2ca7fa1645 (681070) age=31s size=6587 peer=51

rebroad added the label Bug on Apr 29, 2021

practicalswift commented at 4:02 pm on April 29, 2021: contributor

I realise perhaps most miners will be using the backbone […]

With “backbone” do you mean the FIBRE public network? It’s no longer running AFAIK.

pinheadmz commented at 3:28 pm on March 20, 2023: member

slightly changing the code

Do you still have this patch available?

Is it the case that > first cmpctblock received is from a high-bandwidth CB peer but > first node that announced the block (via headers). is a low-bandwidth peer? And you’re seeing bitcoin ignore the block message because it received the headers first and is requesting the block from the low-bandwidth peer?

rebroad commented at 9:14 am on March 21, 2023: contributor

The first node that announced the block with the existing code (well, at the time I raised this issue) generally gets designated as a high-bandwidth peer once the blocktxn has been received from it, and the block that provided the cmpctblock first often gets redesignated as a low-bandwidth peer (with the existing code). With my code changes, the node that provided the cmpctblock first is less likely to lose it’s high-bandwidth designation, and yet the node that provided the header first does get added to the list of high-bandwidth nodes (as is currently the case).

fb2e43d1318b0099b7fd62100bc45b549561e2f0 is the patch to allow announce cmpctblocks to be processed.

84984274b3310be4cda30861cfc6217ef769ed3d and d4f7b724508038b2e3fd6fc6b8aa868fc6cdf397 are patches to request and to process more than one cmpctblock at a time 97af00349eeca55c1a4d74a6016aa897fe24f07c is a minor change that allows smaller blocktxns to be requested. 3d104ec0537e3f9bb2ac5267eae7468220559dc2 is a change that caches the last cmpctblock received rather than redownloading it from another peer, should the peer we’re fetching the blocktxn from fail.

pinheadmz assigned pinheadmz on Jun 2, 2023

pinheadmz commented at 3:00 pm on June 2, 2023: member

@rebroad is this issue closed by #27626 ?

instagibbs commented at 3:07 pm on June 2, 2023: member

I believe so. A headers peer announcing first doesn’t preclude follow-on compact block messages anymore, within some limits of peer type.

pinheadmz commented at 3:12 pm on June 2, 2023: member

Sweet thanks. @rebroad feel free to comment if you think this is still an issue on master now, we can reopen if need be.

pinheadmz closed this on Jun 2, 2023

bitcoin locked this on Jun 1, 2024

Processing of new blocks slower than necessary due to overly selective peer selection #21803