<p>It seems that the transaction hash and the merkle root are both serialized in the gettxoutproof, but byte-wise reverse.
As stated in the <a href="https://bitcoin.org/en/developer-reference#hash-byte-order" rel="nofollow noreferrer">bitcoin developer reference</a>, </p>

<blockquote>
  <p>Bitcoin Core RPCs accept and return the byte-wise reverse of computed SHA-256 hash values.</p>
</blockquote>

<p>So regarding your example, the hash (byte-wise)</p>

<pre><code>81 48 74 0e ... 24 3c c4 a8
</code></pre>

<p>is contained twice in reverse in the gettxoutproof as:</p>

<pre><code>a8 c4 3c 24 ... 0e 74 48 81
</code></pre>

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

CC BY-SA 3.0
2018-02-14T15:32:37.057Z
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
CC BY-SA 3.0
2018-02-14T15:17:33.073Z
2018-02-14T15:17:33.073Z
Hardliner
<p>If you can run <code>gettxoutproof</code> then you might just be able to use <code>verifytxoutproof</code> and then pass back that the transaction is/isn't verified? - I honestly have no idea how the data is serialized.</p>

<p>Information on using gettxoutproof/verifytxoutproof is available on <a href="https://bitcoin.stackexchange.com/questions/70370/can-somebody-show-me-a-working-gettxoutproof-verifytxoutproof-pair">this question</a>.</p>

CC BY-SA 3.0
2018-02-12T09:28:09.483Z
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
CC BY-SA 3.0
2018-02-12T12:29:10.000Z
I have pinged a couple of users, I have seen thier informed answers on another question about Merkle Trees. We will see.
Willtech
CC BY-SA 3.0
2018-02-11T05:56:08.703Z
2018-02-11T05:56:08.703Z
Willtech
<p>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).</p>

<p>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. </p>

<p>Example:
This is the block im looking at: <a href="https://www.blocktrail.com/tBTC/block/00000000c98082481a458fdc837935d12c2922f6576a02a290316099e2205d22" rel="nofollow noreferrer">Testnet Block</a></p>

<p>it only contains one tx: <code>8148740e33df53073f55089f195c327f40e2a9c374dcc05643c60671243cc4a8</code></p>

<p>When I run the gettxoutproof command I get the following output:</p>

<pre><code>0000002024ea1b7676f6ae9f2a3b639ec43e15c509a661d33d123deb3d00000000000000a8c43c247106c64356c0dc74c3a9e2407f325c199f08553f0753df330e744881f4d6715affff001d00cecafd0100000001a8c43c247106c64356c0dc74c3a9e2407f325c199f08553f0753df330e7448810101
</code></pre>

<p>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.</p>

<p>Would be very happy if someone could help me out!</p>

CC BY-SA 3.0
2018-02-11T05:47:16.177Z
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
<bitcoin-core><merkle-tree><spv>
Deserializing merkleblock message
Paul Etscheit
# Deserializing merkleblock message

(Asked by: username_0 on 2018-02-09)

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:
0000002024ea1b7676f6ae9f2a3b639ec43e15c509a661d33d123deb3d00000000000000a8c43c247106c64356c0dc74c3a9e2407f325c199f08553f0753df330e744881f4d6715affff001d00cecafd0100000001a8c43c247106c64356c0dc74c3a9e2407f325c199f08553f0753df330e7448810101

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!

**Tags:** bitcoin-core, merkle-tree, spv

> **Comments:**
> **username_1**: 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.  

---

## 2 answers

### Answer by username_2 on 2018-02-14. Score: 1 | Accepted answer

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.

> **Comments:**
> **username_0**: I see, must have missed that part of the docs. Made that a lot more complicated then it had to be, thanks a lot!  

---

### Answer by username_1 on 2018-02-11. Score: 0

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](https://bitcoin.stackexchange.com/questions/70370/can-somebody-show-me-a-working-gettxoutproof-verifytxoutproof-pair).

> **Comments:**
> **username_0**: 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.  
> **username_1**: I have pinged a couple of users, I have seen thier informed answers on another question about Merkle Trees. We will see.  

---

