Branch: refs/heads/master
Home: https://github.com/btcsuite/btcd
Commit: 23f59144c7755dd980b52dfaf40676e97d5905a7
https://github.com/btcsuite/btcd/commit/23f59144c7755dd980b52dfaf40676e97d5905a7
Author: Dave Collins <[email protected]>
Date: 2016-04-11 (Mon, 11 Apr 2016)
Changed paths:
M blockmanager.go
Log Message:
-----------
server: Optimize map limiting in block manager. (#658)
This optimizes the way in which the maps are limited by the block
manager.
Previously the code would read a cryptographically random value large
enough to construct a hash, find the first entry larger than that value,
and evict it.
That approach is quite inefficient and could easily become a bottleneck
when processing transactions due to the need to read from a source such
as /dev/urandom and all of the subsequent hash comparisons.
Luckily, strong cryptographic randomness is not needed here. The primary
intent of limiting the maps is to control memory usage with a secondary
concern of making it difficult for adversaries to force eviction of
specific entries.
Consequently, this changes the code to make use of the pseudorandom
iteration order of Go's maps along with the preimage resistance of the
hashing function to provide the desired functionality. It has
previously been discussed that the specific pseudorandom iteration order
is not guaranteed by the Go spec even though in practice that is how it
is implemented. This is not a concern however because even if the
specific compiler doesn't implement that, the preimage resistance of the
hashing function alone is enough.
Thanks to @Roasbeef for pointing out the efficiency concerns and the
fact that strong cryptographic randomness is not necessary.
