I'd like to see this, but I'm not sure it's worth breaking the RPC interface for (something we generally try hard to avoid).

Is the PRC designed for human (readable) consumption anyway? Converting these numbers to hex is often a 1-liner.
This would also break a lot of code.

Yes, these two RPCs have a verbose version (the default) that returns JSON. It's pretty useful to look something up quick via the debug window CLI in bitcoin-qt. The version makes more sense to me quickly when it's in hex, that's all.
For example:

And yes, the type changes from number to string because in JSON, "the octal and hexadecimal formats are not used" [http://www.json.org/].

Actually, I suppose that just adding this as "version_hex" would be just as well. I might do that later.

@mruddy did you change bits in the example above?

In any case, I'm for it (without the 0x though), but it would break code.

@dcousens no, but that was from a node running -regtest.

Yes, for that reason I'll probably put up a different commit that just has another field for the hex encoding. I think I'll stick with the 0x because then it's visually obvious that it's not base 10. I'm thinking about only including this new field for versions other than 1-4, but I haven't decided yet.

Maybe versionBits: 'ffff0000' instead of replacing version

That sounds pretty good although I'm hesitant to use the terminology that overlaps with BIP9. For example, there are two more possible future mechanisms where a hex encoding might also be helpful (and I think some BIP101 blocks used something very close or similar to BIP9 IIRC). So, how about versionHex: 'ffff0000'. That is obvious enough to drop the 0x and still generic enough that I don't have to apply BIP specific logic to it or create another field in the far future. The only decision is whether to show this field for versions 1-4. I'm leaning towards not showing it for versions 1-4.

versionHex: 'ffff0000' 👍

Cool, yeah that works for me. Thanks for the help!

RPC isn't meant for human consumption. Do this in the client.

I agree with @luke-jr.
This is a number, keep passing it as a number. Client software can format it to the user however they want.
(we do this consistently in other places too; e.g. we even report timestamps as numbers, and don't bother formatting them as date-times)

It's certainly not worth breaking the interface for. Also realize that a client may need this value to process further, not to show to the user: e.g. bitwise-AND operations should be done on a number, not a string, so this change may mean doing an extra conversion from hex to int on the client side.

No strong opposition to adding it as extra field, though I'd still say adding a field to avoid an extra hex conversion on the client side is too much hand-holding. This shouldn't set a precedent to add hex, octal, binary for every field.

@laanwj Updated to use the VERSIONBITS_LAST_OLD_BLOCK_VERSION constant and added help text. I opted to not always add the new hex formatted field to avoid redundancy when the version is visually obvious.

BTW we should probably add the bit number to bip9_softforks in getblockchaininfo. It would provide some context to these bits.
(doesn't necessarily have to be in this pull, but it's another idea to make BIP9 more visible and transparent, and allowing clients to interpret this)

Or add some command to list the defined bip9 softforks with their starttime, timeout and bit.

@laanwj You could only decode the BIP9 deployments your version understands, so earlier versions are just going to return "unknown" and it's also conceivable that Bitcoin Core would not necessarily have the definitions for all softforks (because it doesnt support them). For a full "decode", we should better rely on a file BIPs which lists all known deployments, and it would also serve to help the community co-ordinate on free bits.

I went ahead and added the extra data to bip9_softforks in getblockchaininfo.

The first thing to decide was if/when to show the bit information.
Since the relevant bit information for a given block version changes over time, it would be confusing to always show the bit info for every soft fork that was ever defined with this mechanism.
It's actually not quite as straightforward as I guessed it would be.
For example, BIP9 gives the guidance:

"Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on consensus rules."

"There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the other one simultaneously transitions to STARTED, which would mean both would demand setting the bit."

"Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes."

Although the plan is to have a fallow period, due to consensus allowing a locked in bit to be immediately reused, it might not really be safe for a miner to continue setting the bit.
EDIT: this is also feedback to @sipa about ComputeBlockVersion continuing to set the version bit during LOCKED_IN, assuming my understanding of BIP9 is correct.
Thus, it might not make sense to show the info for a locked in soft fork even though during normal operations, the fallow period is observed and it would make sense to give a user the info.

So, I took the conservative approach and decided to only show the bit info during an active voting period, that is when the soft fork is in state STARTED.
This gives an indication to users that if the hex block version is other than 20000000 and no info is shown in bip9_softforks, then either everything is locked in, or there is fork voting going on for something the node software being used does not know about.

I left the condition as a separate block in-case we decide to change it to THRESHOLD_STARTED == thresholdState || THRESHOLD_LOCKED_IN == thresholdState. I figured I'd throw this out there and see what other people thought.

it's also conceivable that Bitcoin Core would not necessarily have the definitions for all softforks (because it doesnt support them)

@btcdrak I agree. It can't be complete, but it can show the known ones. Tons of options for the unknown ones, one would be to show them as 'unknownXX' where XX is the bit. E.g. in UpdateTip logging we issue a warning per block, see #7795.

IMO where to coordinate the bits is completely offtopic here :) It shouldn't happen in our repository at all, but indeed in BIPs.

@mruddy Sounds good to me.

@laanwj Yes. I like the patch as it is now.

ok, i pushed up a commit that simplifies and always shows the versionHex for getblock and getblockheader instead of only showing it when version > 4.

post humus ACK

Tested ACK 92107d5