Byte-order of chain_hash in messages

[cdecker]

We did not specify the byte-order of the chain_hash field
in the open_channel and the channel_announcement messages. While
testing integration I noticed that the three implementations disagree
about the ordering:

• c-lightning and eclair both use the reversed order that bitcoin
  uses internally, i.e., interpreting the hash as a little-endian
  number.
• lnd uses the non-reversed byte-order that is directly produced by
  the hashing function.

I think both have their merits, however we need to agree on which
order to use, otherwise we'll be unable to open a channel, or exchange
gossip.

[rustyrussell]

Crap. BOLT #1:

All data fields are big-endian unless otherwise specified.

But I was pretty sure that {0x00, 0x00, 0x00, 0x00, 0x00, 0x19, 0xd6, 0x68, 0x9c, 0x08, 0x5a, 0xe1, 0x65, 0x83, 0x1e, 0x93, 0x4f, 0xf7, 0x63, 0xae, 0x46, 0xa2, 0xa6, 0xc1, 0x72, 0xb3, 0xf1, 0xb6, 0x0a, 0x8c, 0xe2, 0x6f } which we send is big endian. No?

Erk, no. Block explorers mislead me. MY LIFE HAS BEEN A LIE!

The sha256(sha256(genesis header)) is:
$ 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000

We will change.

[Roasbeef]

The genesis hash is a hash, why is it subject to the endian rules governing byte ordering for integers?

The output from Bitcoin related RPC calls always reverse the bytes of any hashed items such as txid's etc. If one were to take the txid outputted and attempt to craft a transaction using the hash raw without reversing it, then that transaction would be invalid.

The non-reversed byte-order is the correct value as this ordering is what Bitcoin uses on the wire protocol to refer to header hashes, txids, etc.