mirror of
https://github.com/bitcoin/bitcoin.git
synced 2026-01-19 14:53:43 +01:00
51c050787f
d7f359b35eAdd tests for parallel compact block downloads (Greg Sanders)03423f8bd1Support up to 3 parallel compact block txn fetchings (Greg Sanders)13f9b20b4cOnly request full blocks from the peer we thought had the block in-flight (Greg Sanders)cce96182baConvert mapBlocksInFlight to a multimap (Greg Sanders)a90595478dRemove nBlocksInFlight (Greg Sanders)86cff8bf18alias BlockDownloadMap for mapBlocksInFlight (Greg Sanders) Pull request description: This is an attempt at mitigating https://github.com/bitcoin/bitcoin/issues/25258 , which is a revival of https://github.com/bitcoin/bitcoin/pull/10984, which is a revival of https://github.com/bitcoin/bitcoin/pull/9447. This PR attempts to mitigate a single case, where high bandwidth peers can bail us out of a flakey peer not completing blocks for us. We allow up to 2 additional getblocktxns requests per unique block. This would hopefully allow the chance for an honest high bandwidth peer to hand us the transactions even if the first in flight peer stalls out. In contrast to previous effort: 1) it will not help if subsequent peers send block headers only, so only high-bandwidth peers this time. See: https://github.com/bitcoin/bitcoin/pull/10984/files#diff-6875de769e90cec84d2e8a9c1b962cdbcda44d870d42e4215827e599e11e90e3R1411 2) `MAX_GETBLOCKTXN_TXN_AFTER_FIRST_IN_FLIGHT` is removed, in favor of aiding recovery during turbulent mempools 3) We require one of the 3 block fetching slots to be an outbound peer. This can be the original offering peer, or subsequent compact blocks given by high bandwidth peers. ACKs for top commit: sdaftuar: ACKd7f359b35emzumsande: Code Review ACKd7f359b35eTree-SHA512: 54980eac179e30f12a0bd49df147b2c3d63cd8f9401abb23c7baf02f76eeb59f2cfaaa155227990d0d39384de9fa38663f88774e891600a3837ae927f04f0db3