2

I was reading Mastering Bitcoin and I found, in the section Exchanging "Inventory", this:

"The node keeps track of how many blocks are "in transit" per peer connection, meaning blocks that it has requested but not received, checking that it does not exceed a limit (MAX_BLOCKS_IN_TRANSIT_PER_PEER)"

this limit implies and allows

"[...] spreading the load and ensuring that it doesn't overwhelm any peer with requests."

and

"[...] allowing the peers to control the pace of updates and not overwhelm the networks."

But what would happen if someone removes this limit or sets it very high? Could it end in a DoS attack?

1 Answer 1

4

this limit implies and allows

"[...] spreading the load and ensuring that it doesn't overwhelm any peer with requests."

and

"[...] allowing the peers to control the pace of updates and not overwhelm the networks."

That's incorrect. The sole reason for the MAX_BLOCKS_IN_TRANSIT_PER_PEER constant and associated logic in the Bitcoin Core P2P block fetching code to exist is to speed up initial download for them. It causes block fetches to be spread out over multiple peers, so that if one or a few of the peers are slow, it doesn't slow down block download overall. There is an associated mechanism that causes peers which are noticeably slower than other peers to be disconnected and replaced with other ones too.

Source: I wrote that code.

But what would happen if someone removes this limit or sets it very high? Could it end in a DoS attack?

No, removing it wouldn't hurt anyone but the person running without it. Other nodes aren't bound to use the same code anyway, so whether or not this mechanism exists in Bitcoin Core has no bearing on people not using Bitcoin Core, and thus we can't rely on it as a DoS protection mechanism.

2
  • Thanks you very much, so removing the limit could cause other nodes flooding me of blocks, so like dossing myself?
    – Paro
    Commented Mar 8, 2023 at 15:23
  • 1
    @Paro No, the result wouldn't flood you any more or less with or without the limit ("flooding" implies it's undesirable, but during initial block download you want to get the blocks as quickly as possible). The only point of having a limit it to prevent requesting all blocks from the same peer (as opposed to spread out over many peers), because if you're only downloading from one peer, and that peer is slow, your synchronization will be slow. Commented Mar 8, 2023 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.