[bitcoin] TheBlueMatt opened pull request #16856: Do not allow descendants of BLOCK_FAILED_VALID blocks to be BLOCK_FAILED_VALID (master...2019-09-invalidate-block-child-invalid) https://github.com/bitcoin/bitcoin/pull/16856
[bitcoin] TheBlueMatt opened pull request #16825: Default to 2 additional blocks-only connections over Tor (+ bump default max conns to 150) (master...2019-09-tor-blocksonly) https://github.com/bitcoin/bitcoin/pull/16825
instagibbs: I've seen a very large Bitcoin exchange in Asia that had suffered for years with a single wallet.dat for all customer wallets. It got to the point where ordinary RPC queries against that wallet would take several minutes. As a workaround for faster queries I told them to setup many parallel servers with bitcoind -txindex and watch-only wallets so that they could parallelize their lookups. I also warned that they check for block
I have picked up Pieter Wuille's proposal from 2017 to use a rolling hash for the UTXO set hash. It deals with the problem of a long computation time of the UTXO set hash which results in a slow RPC call gettxoutsetinfo (can take several minutes depending on hardware). I investigated three hash functions: MuHash, ECMH and LtHash and started implementing them in Bitcoin Core for comparison. However only MuHash
has a rolling hash implementation so far and my LtHash code is not as optimized as MuHash and ECMH. I am looking for feedback on concept, which choice to make for the hash function and implementation details before filing a PR to Bitcoin Core.