Calling getrawmempool with true is slow because the node needs to pull all tx mempool details before returning anything. This change instead calls getrawmempool with false, followed by individual requests for tx mempool entries which we submit in parallel up to the configured concurrency limit. This provides some safety against running into the RPC timeout that was previously common (when calling getrawmempool(true)) with large mempools. In addition to greater reliability in large-mempool scenarios, this change significantly improves the performance of the /unconfirmed-tx page in particular - because that page only cares about 20 tx mempool entries at a time; previously we were waiting for the node to query all mempool tx entries and throwing away the vast majority of the returned data.
Fixes#127
Move closer to the original vision of supporting any address-querying implementation desired. Current options include ElectrumX (as before) and now blockchain.com and blockcypher.com since they were easy to support and are publicly/easily available (though ridiculously neither is yet to support bc1 addresses).
- new env var option BTCEXP_ADDRESS_API, value can be electrumx, blockchain.com, blockcypher.com
- update ElectrumX client connect to request v1.4 of API as all clients are now supposed to do
- misc frontend improvements/cleanup for addresses
- support for configurable RPC concurrency level (default 10, to be under bitcoind default "rpcworkqueue=16")
- queue up requests to prevent overloading RPC work queue of bitcoind
- simplify / cleanup rpcApi
Dan Janosik
pendingbot