@sipa I assumed HexStr(pblock->nBits) was going to be equivalent to uint256().SetCompact(pblock->nBits).GetHex() but I didn't tested the output. I can leave as it was.

@laanwj using strprintf("%08x", nBits) to replace HexBits instead of defining the new specialized HexStr seems better (less additions, the same deletions) if the outputs are equivalent. Would this serve for the case sipa is discussing too? Either way seems better to remove HexBits, which is just too specific.

@jtimon No, it wouldn't address sipa's problem. Let's leave the line in CheckWork as it is, as I see it it doesn't even use hexbits?

No, it doesn't, I thought that could be a use outside of the rpc stuff, but yeah, I'll just leave it as it was.
Replace HexBits( with strprintf("%08x", it is.

OK!
We indeed still have to check that the output is the same, but looking at the source code the intention is the same. Ie, write the bytes of 0xAABBCCDD as AA BB CC DD in memory using htonl then print them as hex bytes, resulting in AABBCCDD.

Untested ACK.

Yep, this won't show up on the automatic tests so it will need to be tested manually.

u-t ACK

Tested both functions in an independent program and they produce the same results.

ACK

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4422_645d497aa0010525441ce409e8e6d327a157ab39/ 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.