Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Use a uint256 for bnChainWork #2418

Merged
merged 1 commit into from Apr 12, 2013

Conversation

Projects
None yet
7 participants
Owner

sipa commented Mar 28, 2013

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.

Owner

laanwj commented Mar 30, 2013

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.

Contributor

TheBlueMatt commented Mar 30, 2013

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.

Contributor

TheBlueMatt commented Mar 30, 2013

ACK

Owner

laanwj commented Mar 30, 2013

ok, ACK

Owner

sipa commented Mar 30, 2013

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.

Owner

sipa commented Mar 30, 2013

@BitcoinPullTester @TheBlueMatt I believe this will require a different pulltest, as I presume it tries to modify the global BigNums.

Contributor

TheBlueMatt commented Mar 30, 2013

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.

@sipa sipa referenced this pull request Apr 2, 2013

Merged

Limited mapAlreadyAskedFor #2423

Owner

sipa commented Apr 4, 2013

Rebased.

Owner

sipa commented Apr 7, 2013

Added a commit that prints the 2-log of nChainWork instead, which is somewhat more useful for human eyes.

Member

gmaxwell commented Apr 8, 2013

ACK. (Needs pulltester)

Owner

sipa commented Apr 9, 2013

Rebased. This will need manual pulltester changes before it will succeed.

@sipa sipa + Pieter Wuille Use a uint256 for bnChainWork
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.
1657c4b
Owner

sipa commented Apr 12, 2013

@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.

@sipa sipa closed this Apr 12, 2013

@sipa sipa reopened this Apr 12, 2013

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.

@gavinandresen gavinandresen added a commit that referenced this pull request Apr 12, 2013

@gavinandresen gavinandresen Merge pull request #2418 from sipa/uintwork
Use a uint256 for bnChainWork
1b4b463

@gavinandresen gavinandresen merged commit 1b4b463 into bitcoin:master Apr 12, 2013

@sipa sipa deleted the sipa:uintwork branch May 3, 2013

@laudney laudney pushed a commit to reddcoin-project/reddcoin that referenced this pull request Mar 19, 2014

@gavinandresen gavinandresen Merge pull request #2418 from sipa/uintwork
Use a uint256 for bnChainWork
633486f
Contributor

rebroad commented Jun 25, 2015

Would it be of any use to display a delta work (work since the last block) instead?

Owner

sipa commented Jun 25, 2015

Contributor

rebroad commented Jun 25, 2015

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment