<blockquote>
<p>this limit implies and allows</p>
<blockquote>
<p>&quot;[...] spreading the load and ensuring that it doesn't overwhelm any peer with requests.&quot;</p>
</blockquote>
<p>and</p>
<blockquote>
<p>&quot;[...] allowing the peers to control the pace of updates and not
overwhelm the networks.&quot;</p>
</blockquote>
</blockquote>
<p>That's incorrect. The sole reason for the <code>MAX_BLOCKS_IN_TRANSIT_PER_PEER</code> constant and associated logic in the Bitcoin Core P2P block fetching code to exist is to speed up initial download <em>for them</em>. 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.</p>
<p>Source: I wrote that code.</p>
<blockquote>
<p>But what would happen if someone removes this limit or sets it very high? Could it end in a DoS attack?</p>
</blockquote>
<p>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.</p>

CC BY-SA 4.0
2023-03-08T15:23:21.183Z
Thanks you very much, so removing the limit could cause other nodes flooding me of blocks, so like dossing myself?
Paro
CC BY-SA 4.0
2023-03-08T15:27:40.723Z
@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.
Pieter Wuille
CC BY-SA 4.0
2023-03-07T14:46:16.967Z
2023-03-07T14:52:37.180Z
2023-03-07T14:52:37.180Z
Pieter Wuille
<p>I was reading Mastering Bitcoin and I found, in the section <em>Exchanging &quot;Inventory&quot;</em>, this:</p>
<blockquote>
<p>&quot;The node keeps track of how many blocks are &quot;in transit&quot; 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)&quot;</p>
</blockquote>
<p>this limit implies and allows</p>
<blockquote>
<p>&quot;[...] spreading the load and ensuring that it doesn't overwhelm any peer with requests.&quot;</p>
</blockquote>
<p>and</p>
<blockquote>
<p>&quot;[...] allowing the peers to control the pace of updates and not
overwhelm the networks.&quot;</p>
</blockquote>
<p>But what would happen if someone removes this limit or sets it very high? Could it end in a DoS attack?</p>

<network><nodes><attack><mastering-bitcoin>
DoS attack and MAX_BLOCKS_IN_TRANSIT_PER_PEER
Paro
# DoS attack and MAX_BLOCKS_IN_TRANSIT_PER_PEER

(Asked by: username_0 on 2023-03-07)

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?

**Tags:** network, nodes, attack, mastering-bitcoin


---

## 1 answers

### Answer by username_1 on 2023-03-07. Score: 4 | Accepted answer

> 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.

> **Comments:**
> **username_0**: Thanks you very much, so removing the limit could cause other nodes flooding me of blocks, so like dossing myself?  
> **username_1**: @username_0 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.  

---

