Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Hash Cache #8259
Some notes about the implementation:
This commit is only for having a cache that is simple to review and understand. It is probably possible to fix the two first points above, but the code overhead is not worth it when our goal is only to fix the O(n²) issue.
(rebased version of sipa#70)
referenced this pull request
Jul 28, 2016
Assume a transaction has many signatures. One is SIGHASH_SINGLE, all the others are SIGHASH_ALL | SIGHASH_ANYONECANPAY.
The first computes and stores hashPrevouts. All the others will compute hashOutputs. However, after the first call, all TrySets will not do anything, as there is already a result in the cache, so it gets computed over and over again.
I think CachedHashes needs a Merge method like this:
which can then be called from TrySet (instead of insert, use
That's not true, I would be calculating the three hashes at the same time during the SIGHASH_SINGLE.
I prefer not doing a merge. Without a merge my lock only have to protect the internal map as CachedHashes instances are read only. If we calculate the mid states lazily, I also need to be careful about locking at the CachedHashes instance level.
@sipa The Merge function as you did here can't grab the lock, because the lock is at the cache map level, not at the CachedHashes instance level.
But basically, if doing that way, I would need to grab the lock of the map around the Merge, as well as around any hash read of the HashedCaches instance. (so one can't read and call merge on the HashedCaches at the same time)