Conversation
Signed-off-by: barrystyle <baz@tiltpool.com>
Cache powhashes in a persistent database. Test purposes.
|
@barrystyle have you obtained a successful build of this version on your machine? |
Rationel: Convience libraries built by bitcoin contain logically separated code, which allows for modularity. Introducing powcache -> dbwrapper dependecy breaks this modularity by making consensus dependant on server/wallet functionality. Apart from that it breaks builds for libconsesnsus shared library, and bruteforce fixing by satisfying every symbol is incorrect. It is designed to be stand-alone and lightweight for a reason. Thus this commit relinks powcache.* files to server library, and implements cache lookup outside of primitives.
1. Adds a wrapper around PoW cache database, which allows for easy substitution of any heavy block.GetHash() encounter. 2. Removes redundant calls. Consideration: Performing a database lookup with 160 bit long buffer instead of 256 bit blob. Due to the fact that SHA1 output is 160 bits long 256 - 160 = 96 bits are zeros simply taking up space. It is not a big issue, but may result in extra 1 MB of data every week.
|
This should conclude a round of development. Currently merging to @barrystyle thank you for the initiative! |
Ensure you're building with latest g++, not 5 series which dates back to 2015. |
|
Thank you for the update.
|
|
Issues shown and resolved in #17
2 and 3) Builds fine, and from memory had issues unless they were added. As for leveldb, that is neither here nor there - Bitcoin is not at the point where someone can use whichever key/value store database they please. The point remains that the hashing functions are defined and used from within the consensus library (which requires the crypto primitives library too by the way), and whilst they are used in there - they require linking against leveldb. |
2 participants
Reopening PR #17, as the old branch was deleted.
(by @barrystyle)
Rational:
Obtc node is extremely inefficient on the start-up due. As the blocks retrieved from the disk, they are put in the runtime structures, which require calling heavy-hash many times. Heavy-hash is clock cycle intensive, thus at the current chain height starting a node takes roughly 8 mins on average, which is really annoying.
@barrystyle suggests storing previously encountered hashes to a db, indexing each with a lightweight SHA1 hash, thereby bringing the start-up time back to almost instant.