search

Kixunil / btc-rpc-proxy

Finer-grained permission management for bitcoind.
MIT License
63 stars 18 forks source link

Make more efficient Block Serving strategy #7

Closed ProofOfKeags closed 3 years ago

ProofOfKeags commented 3 years ago

Currently we race archive peers to fetch blocks that have been pruned. We should either cap the number of peers we do this for, or we should scale logarithmically or abandon parallel fetches altogether for an in-series fetch approach.

Kixunil commented 3 years ago

You mean if there's 1000 requests in a batch, 1000 peers are contacted an the idea is to make it lower?

ProofOfKeags commented 3 years ago

If a block is requested and it is pruned by the underlying instance of Core, the proxy will reach out to all archive peers for the block simultaneously. This consumes network bandwidth that scales with the number of peers that your node has.

Kixunil commented 3 years ago

Ah, I see, this is really not good. I'd suggest make it configurable, with a small default (around 5). If none of those attempts succeeds, try another batch.

Kixunil commented 3 years ago

As far as I understand, #6 fixed this.