After much discussion with William I agree that we should take this
change. Now that the pull request is down to one simple commit that
isolates this issue, it's a simple change. The outcome of the change is
definitely an improvement. Instead of reversals all over the code base
we will have them isolated to two lines of code, the encode and decode
functions. This ensures that proper textual serializations will match
expectations.

The only downside is the subtleness of the break. However this follows
some significant breaks in the version2 branch, such as complete removal
of the blockchain and node implementations, as well as more subtle
changes. So in our opinion this is the time to do it. If there are no
objections by the end of the day I'll merge this then.

e

On 12/02/2014 02:42 PM, William Swanson wrote:
> 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
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>