fix(electrum): query block count in sequential manner#2666
Conversation
as in, perfrom them in series instead of in parallel (and label the connection as not_needed once done with the request). this makes it so we won't break the max_connected threshold (this is a lie as we can break it by at most one extra connection due to the running background task that also manages connections aside from us forcefully instantiating connections in get_servers_with_latest_block_count)
since any forceful request will always call not_needed() at the end (check ElectrumClient::electurm_request_to())
|
In this PR we select servers returning max height. Are we sure this is a correct way to do this? |
I would address that in another PR (if it's a problem), but let's have a discussion here about that nonetheless. You here mean that there might be a longer chain but with less work right? |
yes exactly, a forked node can longer chain with less work |
|
@dimxy aha got you. we def need to compare chain works instead of max height. i will create an issue for that. |
3 participants
This PR makes it so we query electrums latest blocks in sequential manner instead of in parallel. This guarantees that we don't break out of
max_connected + 1(note the+1here is because such a query is a forced connection and background task used for managing connections might already havemax_connectedconnections that are different from the forced connection).This call was only used in
block_header_utxo_loopwhich is only performed for lightning withspv_conf(but i cant find it in coins file).This makes querying latest block a bit slower, but we don't need it to be fast anyway.