Every block index entry currently requires a separately-allocated CBigNum. By replacing them with uint256, it's just 32 bytes extra in CBlockIndex itself.
This should save us a few megabytes in RAM (around 32 bytes per block), and less allocation overhead.
Are these numbers always guaranteed to fit in a uint256?
A more general solution may be to change CBigNum to store numbers <2^256 inline, and only allocate for larger ones, like with some optimized string implementations.
Our current work (printed as a uint256 with this patch) is 00000000000000000000000000000000000000000000003256b810087da1a920, assuming every 600MH card on the network is replaced with a 60GH ASIC and then we multiply that by 1000 for network growth, we get a network rate of 100,000x current, we are safe for another 92 septillion*time since genesis, so...I think we are safe.
ACK
ok, ACK
When 2^256 hashes are exceeded, it's quite likely we'll have found a preimage for double-SHA256, and Bitcoin is broken in the first place.
@BitcoinPullTester @TheBlueMatt I believe this will require a different pulltest, as I presume it tries to modify the global BigNums.
Yea, this tries to modify the mindiff stuff so breaks on this pull. Ignore pulltester output for now and ping me before merge so I can update the patch.
Rebased.
Added a commit that prints the 2-log of nChainWork instead, which is somewhat more useful for human eyes.
ACK. (Needs pulltester)
Rebased. This will need manual pulltester changes before it will succeed.
Every block index entry currently requires a separately-allocated
CBigNum. By replacing them with uint256, it's just 32 bytes extra
in CBlockIndex itself.
This should save us a few megabytes in RAM, and less allocation
overhead.
@TheBlueMatt I've added a patch to your patch in this pullreq. If you update pulltester to use the tests in contrib, this should apply cleanly.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/1657c4bc495815febc2137972c3c63b99d2b0189 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
Would it be of any use to display a delta work (work since the last block) instead?
The work since last block is also called "difficulty".
Doesn't seem like a very useful thing to display on every UpdateTip message.. Why not just output one debug line when the difficulty changes, and remove log2_work= altogether from the UpdateTip debug message?