Returns nChainWork from the block index, the total work done by all blocks since the genesis block.
Worth exposing for pedagogical reasons at the very least.
Anyone who tries to bikeshed either the name or the format the value is returned in will regret it - I'm warning you.
Returns nChainWork from the block index, the total work done by all
blocks since the genesis block.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/1b3656d50bda646822fd954714a88dea1528548b 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.
Given that the only work-related RPC output is already measured in difficulty, perhaps use the same unit?
Another related and useful unit for transactions and blocks, is depth measured in "equivalent current blocks", namely the difference between chainwork of the tx/block under consideration and the chainwork of the tip, divided by the chainwork of the tip block.
I used the raw hex value as the units for chainwork so that alt-implementations could use it as a way of double-checking their calculations - right now if you write your own chainwork calculating implementation there isn't a convenient way of ensuring your results match the reference implementation binary form exactly. Having said that other than verbosity I don't mind creating a "chainwork" and "chainworkhex" or something if people feel it is important, similar to how we have "bits" and "difficulty"
re: "equivalent current blocks" Sounds reasonable for a subsequent pull-req, especially after headers first is merged.
The internal encoding of chainwork isn't relevant to implementations, just the relative measurement...
@petertodd You're exporting an integer as a hexified String, rather than a JSON Number, which I think is what @sipa was suggesting.
@luke-jr Right, but the problem there is that JSON numbers are kinda-sorta double-precision floats - matching Javascript semantics - and support for bigints is pretty spotty in libraries.
Also sipa was talking about making the number in "difficulty" units, with has a 2^32 factor, so you'd always wind up with floating point numbers. I haven't worked it out, but I wouldn't be surprised if double-precision floats aren't precise enough for consensus purposes.
Already some libraries have issues with bitcoind's output. I don't think trying to workaround bugs that might or might not exist in other software should be a concern...
It's not a bug, it's just a limitation of JSON - bigints just aren't standard JSON. Bitcoin internally uses a uint256, so I'm not worried about exporting exactly that even if it's in hex. (like uint256 digests...) Anyway, as I said above:
"Anyone who tries to bikeshed either the name or the format the value is returned in will regret it - I'm warning you."
...apparently I'm not threatening looking enough. Maybe I need a leather jacket and a motorcycle?
JSON doesn't place any precision limits on Numbers.
@petertodd Do you have an actual use case where the full-precision chainwork is useful?
@sipa Testing alt-implementations. chainwork is nasty, because subtle arithmetic mistakes in calculating it that only affect low-order bits are easy to not notice if any rounding is done anywhere, yet still can cause an (unlikely) fork. In addition it lets us easily compare different bitcoin versions to make sure we ourselves don't introduce any subtle mistakes.
ACK
ACK