Fix for endianness of contract hash

[Randy808]

Fixes #118

[louisinger]

ACK, nice catch & thanks for the contribution

EDIT: however it seems that blockstream.info is using little endian for the contract hash. I think that's why we originally reversed the bytes while encoded as hex string.

[louisinger]

could you remove also the slice() method ? we used it to reverse the bytes safely but now it's not useful anymore.

[louisinger]

looks like blocktream explorer is using little endian encoding: https://blockstream.info/liquid/asset/0c5d451941f37b801d04c46920f2bc5bbd3986e5f56cb56c6b17bedc655e9fc6

now I'm doubting 🤔

[Randy808]

It should display in little-endian, but the hash should be using big-endian when the entropy is calculated.

In issue Blockstream/asset_registry#51, the referenced asset id is a9d52b02348a097d4f780644064c437e364a41d6299290fef1c49e7d1fbbf665

This is the code used to issue the asset in the issue above. It uses liquidjs: https://github.com/baset-btc/liquid-test/blob/main/test.js

If we look at the asset from the issue using esplora we'll see the contract_hash is ed90ec2399bbcca8b38378a1bef6db81127a749ba84b791bacd028183a5faa95. This is the big-endian value of the contract hash. This happens because the little-endian value was used to generate the entropy. Esplora was expecting the value used to generate the entropy to be in big-endian and thus reversed the bytes attempting to display it in little-endian (just as it was entered in the elements rpc command), but since the little-endian value was used for entropy generation, this ended up converting little-endian to big-endian instead.

Sidenote: To verify the contract data yielded the big-endian value of the contract hash we see on esplora, we can change the values of this script, deleting everything after contract_hash = hashlib.sha256(contract_json.encode("ascii")).hexdigest() and printing out the value for contract_hash (contract_hash is the big-endian hex value and contract_hash_reversed is the little-endian hex value).

In the elements code, ParseHashV performs length and hex validation. The string hex is then passed into uint256S(strHex). The constructor for uint256S then calls SetHex on a newly initialized uint256. SetHex converts the string to a char* and calls another SetHex where the decoding happens. The variable digits is set to the last valid hex character and the digits are read in reverse order into p1 which points to the start of m_data (the data of the uint256)

Edit: Rephrased and formatted for clarity

[louisinger]

ok right 👍

however, I would revert the changes to the fixtures because they are coming from esplora API (let's keep the string encoded hash reversed). Instead, could you reverse the contractHash in the test file?

[Randy808]

Yeah, will do 👍

[Randy808]

Updated

[altafan]

Thank you @Randy808 for spotting this out and providing a fix for it.