Show more significant bytes of block hashes. #1426

On Mon Aug 16 20:55:54 2010, Satoshi modified the client to display 20 bytes of the block hash (up from 16 bytes). This pull request increases the number of significant bytes by 5, and reduces the number of insignificant bytes (almost always zeros) by 10, resulting in saved space in debug.log and improved uniqueness of block hashes.

I'd like to keep one leading 0 on diff-1 blocks, instead of removing all the 0s, which would leave only 6 0s on current-diff blocks, which IMHO is acceptable, but ACK on the idea.

I like the at-least-one leading 0 on min-difficulty blocks idea; I've spent a lot of time staring at min difficulty testnet block hashes.

One downside of this change: it might break blockexplorer.com's block lookup (please test, I know it works with the existing lots-of-leading-zeroes format).

I see what you mean re testnet. Perhaps I should code it so that it's one leading zero whatever the situation...?

Solution: use the low bits of block hashes to identify them, instead of high bits which contain several zeroes?

I definitely prefer showing the low bits over high ones.

Agreed, as long as someone pings theymos et al to get bbe/blockchain.info updated to support low bit-searching implemented before release.

BBE doesn't care which bits you use. Blockchain.info doesn't accept partial matches/searches at all.

Ah, well then I guess we should just switch to low bits.

Using the 14 lowest hex characters of a block as identifier should suffice for 100 years (0.2% chance for a collision after 5.46 million blocks). So I'd say use the 16 lowest ones.

I'd somewhat prefer to show the full values, because thats what the getblock rpc needs. If we're concerned about space we should create rotation that doesn't stink.

@sipa it's just a debug.log. I doubt anyone will have a debug.log file as long as 100 years, so 14 characters would be an extreme overkill. @gmaxwell it doesn't currently show full values and never has. The current requirement seems to be that the numbers don't want to be duplicated within the entirity of the debug.log file. For that, the last 14 hex characters are more than sufficient (as sipa pointed out).

@rebroad Are you going to update this to show the least-significant (end/tail) N?

Yes, very likely, when i next get access to a computer (next week sometime).

@luke-jr can I ask your opinion - is it better to hardcode the substr numbers or instead do it in a way that uses the length of the string?

I'd just go with substr(504)

@luke-jr modified (not yet tested - compiling)

wth? 504? hex hashes are only 64 characters long.

@rebroad I prefer the reported hashes in the debug file to be globally and near-forever usable as unique identifiers. I'd just use the low 64 bits of the hash (i.e., the last 16 hex characters). .substr(48) i suppose.

... yeah, not sure how I got 504 (except I know I forgot to divide by 8)... long day :(

I meant .substr(56), but I don't mind 48

@rebroad I know it doesn't currently show full values. @sipa I still think it should show the full value. The partial values are almost useless because there is no way to getblock by them. I don't think carrying another index for partial block values names sense, nor do I think precluding hash tables that require exact lookups makes sense. Reducing them by 1/4th while breaking lookup with getblock isn't a worthwhile tradeoff.

(Of, course, I'll continue to patch my nodes to log the full value regardless, but I think its a reasonable default).

updated. now substr(48) (effectively). Next.. shall we shorten the work= field....?!

How about using the unit GHy? (gigahash year). We're currently at around 11874.5 GHy.

@sipa how do you turn the current value into GHy?

Divide the bnWork number by 31556926000000000 (1 billion times the number of seconds in a year).

@sipa Shall I add that change to this pull, or a separate pull (which would need to go in after this one?)

Currently there is no way for a user to go from the entries in the debug.log, using bitcoind calls only, to useful information. Is there no intention of correcting the api calls so they accept whatever it is we're dumping into debug.log? This way we can do investigation without writing our own extensive tools or being forced to visit a website? How is it that you guys debug problematic blocks? Do you maintain extensive patchsets of your own that don't depend on behaviour in the base client?

Weak ACK, mostly don't care.

BLOCKSUBSTR should be in a separate, zero-behavior-change commit.

BLOCKSUBSTR could take a little comment IMHO.

While we're fence-painting, it seems to me hash.ToString().substr(BLOCKSUBSTR).c_str() could be reduced to hash.BlockSubstr().c_str()

Automatic sanity-testing: FAILED MERGE, see http://jenkins.bluematt.me/pull-tester/7a2670692e7cf455899fdb3dafdff734ce2a794b for test log.

This pull does not merge cleanly onto current master

Closing this in favor of #1670