Deserializing merkleblock message


I've been struggling the past couple of days to deserialize a merkleblock message. I'm writing a go app that uses the bitcoin rpc client to call gettxoutproof, but only need the merkle proof (array of required tx hashes needed to hash merkle root) of given transaction (want to verify the transaction in an ethereum smart contract).

So I've looked at how the serialization is defined in merkleblock.h which looks pretty straight forward. The problem i'm having is figuring out how CDataStream serializes the CMerkleBlock object, and finding the transaction hashes in the hex string.

Example: This is the block im looking at: Testnet Block

it only contains one tx: 8148740e33df53073f55089f195c327f40e2a9c374dcc05643c60671243cc4a8

When I run the gettxoutproof command I get the following output:


Initially I expected to find the tx hash somewhere in that hex string, since its the only tx in the block and has to be included, but its no where to be found. Since the docs say that gettxoutproof returns a serialized, hex encoded string I thought maybe the tx hash has been hex encoded, but it isn't. I've tried figuring this out with other blocks, that for example contain 2 transactions but have had no luck. I've looked at how CDataStream serializes the data but fail to understand it.

Would be very happy if someone could help me out!

Paul Etscheit

Posted 2018-02-09T13:50:11.700

Reputation: 13

Welcome to Bitcoin.SE! I am sure that the answer I am about to post will not answer your question completely but, hopefully, you will get a few more answers not too far away. – Willtech – 2018-02-11T05:47:16.177



It seems that the transaction hash and the merkle root are both serialized in the gettxoutproof, but byte-wise reverse. As stated in the bitcoin developer reference,

Bitcoin Core RPCs accept and return the byte-wise reverse of computed SHA-256 hash values.

So regarding your example, the hash (byte-wise)

81 48 74 0e ... 24 3c c4 a8

is contained twice in reverse in the gettxoutproof as:

a8 c4 3c 24 ... 0e 74 48 81

In this special case it is contained twice, of course, because with only one transaction the merkle root equals the according transaction hash.


Posted 2018-02-09T13:50:11.700

Reputation: 26

I see, must have missed that part of the docs. Made that a lot more complicated then it had to be, thanks a lot! – Paul Etscheit – 2018-02-14T15:32:37.057


If you can run gettxoutproof then you might just be able to use verifytxoutproof and then pass back that the transaction is/isn't verified? - I honestly have no idea how the data is serialized.

Information on using gettxoutproof/verifytxoutproof is available on this question.


Posted 2018-02-09T13:50:11.700

Reputation: 2 878

The problem is that I have to prove the transaction in a smart contract, so I cant use verifytxoutproof. I know how to use the methods and it all works as expected, but im not able to extract the merkle path (not sure if that the proper name for the array of tx's needed to prove a transaction). There was another answer on friday but its (been deleted for some reason) about the net socket object that is being used to return the data, will take a stab at that and post the answer once I figured it out. – Paul Etscheit – 2018-02-12T09:28:09.483

I have pinged a couple of users, I have seen thier informed answers on another question about Merkle Trees. We will see. – Willtech – 2018-02-12T12:29:10.000