:: [Libbitcoin] Un-reverse bitcoin_has…
Página Inicial
Delete this message
Reply to this message
Autor: William Swanson
Data:  
Para: libbitcoin@lists.dyne.org
Assunto: [Libbitcoin] Un-reverse bitcoin_hash in memory
Hello,
I have just pushed another big pull request to the libbitcoin repos
(https://github.com/libbitcoin/libbitcoin/pull/144). This one fixes
the way bitcoin_hashes are stored in memory.

A bitcoin_hash is just a double-round of sha256 hashing. However, if
you ever ask the Satoshi client to display one of these things, it
prints the bytes in the opposite of the expected order. To match this,
the old bitcoin_hash function in libbitcoin also returned its bytes in
reverse order.

The problem with this approach is that now the hash is sitting
backwards in memory, so we have to un-reverse it just about everywhere
it's used, including signatures, scripts, block difficulty,
serialization, and checksums. Plus, now we have backwards data leaking
out of the library and into outside software like AirBitz wallet. All
the AirBitz database entries are stored backwards now (oops), and this
adds a layer of confusion whenever we want to interface with external
software.

So, storing bitcoin hashes backwards is a bad idea. If we want to
display them the same way the Satoshi client does, we should just
reverse them in the display code instead of the whole system. That's
what the pull request achieves.

With the pull request in place, all hashes are now stored the right
way round in memory. To display or parse a bitcoin_hash, use the
following new functions:

* encode_hash
* decode_hash

These two functions include the necessary reversing code. In fact,
these are the *only* functions in the library that include reversing
code now. This is much simpler.

This pull request changes the API of the decode_hash function, and
gets rid of the decode_short_hash function, so bx will break. Both
fixes should be easy, since those functions are each used in only a
single location. BX will also have to use the new encode_hash instead
of encode_hex when dealing with hashes.

-William