<p>1) The easiest way within the protocol is probably to add that transaction hash to a bloom filter, send the bloom filter to a remote node with <code>filterload</code>, and request each filtered block. This will send you only the transaction you're interested in. (It will also send some extra transactions that match the bloom filter because they're false positives.) <a href="https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki" rel="nofollow noreferrer">See BIP37</a> for more details about how this feature works. This is how BitcoinJ based light clients find transactions relevant to them.</p>

<p>Knowing the block height that this is included at would simplify this enormously, as you will only need to look at one block, instead of the entire chain.</p>

<p>2) No. They get the block headers for the entire best chain. This goes from the genesis block to the current tip. (This is currently <code>450000*80=36MB</code>) They then check that the relevant block is somewhere in that chain.</p>

CC BY-SA 3.0
2017-01-30T19:58:12.983Z
thank you for the explanation! Can I also ask you what are the minimum requirements for a thin client in term of RAM and CPU ?
gatb27
CC BY-SA 3.0
2017-01-30T20:43:21.127Z
Pretty much nothing. Strictly speaking, you don't even need to keep all of the block headers once you've checked that they connect to the genesis block. You could keep only the chain tip, and the ones you're interested in. The primary issue with thin clients is not the resources they use, but their inability to check whether a blockchain is valid.
Nick ODell
CC BY-SA 3.0
2017-01-30T21:15:10.967Z
Ok, now I've got it. To be sure the blockchain is a valid one, we need the complete blocks with all the transaction, so a full node right?
gatb27
CC BY-SA 3.0
2017-01-30T21:25:57.580Z
Right. You need all of the blocks to enforce rules like not letting the same output be spent twice.
Nick ODell
CC BY-SA 3.0
2017-02-01T14:17:51.037Z
Hi @nick , if I am a thin client (bitcoinj) and I know both the `tx_hash` and the `block_number`, what kind of message do I need to send to my peers to get back the complete transaction?
gatb27
CC BY-SA 3.0
2017-02-01T17:28:09.080Z
@gatb27 Once you know `block_hash`, and `tx_hash`, you send the bloom filter with `filterload`. Then you send `getdata`, with an inv type of `MSG_FILTERED_BLOCK`, and the block hash. This documents the low-level details. https://en.bitcoin.it/wiki/Protocol_documentation#Inventory_Vectors Let me see if I can work up some example code for you.
Nick ODell
CC BY-SA 3.0
2017-02-03T07:01:22.887Z
I've just studied the different kind of messages on the developer guide :) 
I'd like to ask for the last favour: I'm interested in a snippet of code in python (jython for bitcoinj) that given a `tx_hash` and `block_number`, it returns the hex after OP_RETURN in the tx_hash output. Where can I find a guide for learning how to do it? :)
gatb27
CC BY-SA 3.0
2017-01-30T19:37:54.667Z
2017-01-30T19:37:54.667Z
Nick ODell
<p>I'd like to better understand how a light client works. As far as I know, a light client stores locally only the block headers (80 bytes each) and it receives a new block header on average each 10 minutes. </p>

<p>I've essentially two questions:</p>

<p>1) How can a light client retrieve a transaction given its hash? I'd like to get back the complete transaction so to read out the data after the OP_RETURN code.</p>

<p>2) How can the light client be sure that the retrieved transaction is really the one in the longest blockchain? Does it simply check if there are 5 blocks already confirmed after the transaction's block?</p>

<p>Thank you very much</p>

<transactions><hash><op-return><thin-clients>
Thin Client and OP_RETURN
gatb27
# Thin Client and OP_RETURN

(Asked by: username_0 on 2017-01-30)

I'd like to better understand how a light client works. As far as I know, a light client stores locally only the block headers (80 bytes each) and it receives a new block header on average each 10 minutes.

I've essentially two questions:

1) How can a light client retrieve a transaction given its hash? I'd like to get back the complete transaction so to read out the data after the OP\_RETURN code.

2) How can the light client be sure that the retrieved transaction is really the one in the longest blockchain? Does it simply check if there are 5 blocks already confirmed after the transaction's block?

Thank you very much

**Tags:** transactions, hash, op-return, thin-clients


---

## 1 answers

### Answer by username_1 on 2017-01-30. Score: 0 | Accepted answer

1) The easiest way within the protocol is probably to add that transaction hash to a bloom filter, send the bloom filter to a remote node with `filterload`, and request each filtered block. This will send you only the transaction you're interested in. (It will also send some extra transactions that match the bloom filter because they're false positives.) [See BIP37](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki) for more details about how this feature works. This is how BitcoinJ based light clients find transactions relevant to them.

Knowing the block height that this is included at would simplify this enormously, as you will only need to look at one block, instead of the entire chain.

2) No. They get the block headers for the entire best chain. This goes from the genesis block to the current tip. (This is currently `450000*80=36MB`) They then check that the relevant block is somewhere in that chain.

> **Comments:**
> **username_0**: thank you for the explanation! Can I also ask you what are the minimum requirements for a thin client in term of RAM and CPU ?  
> **username_1**: Pretty much nothing. Strictly speaking, you don't even need to keep all of the block headers once you've checked that they connect to the genesis block. You could keep only the chain tip, and the ones you're interested in. The primary issue with thin clients is not the resources they use, but their inability to check whether a blockchain is valid.  
> **username_0**: Ok, now I've got it. To be sure the blockchain is a valid one, we need the complete blocks with all the transaction, so a full node right?  
> **username_1**: Right. You need all of the blocks to enforce rules like not letting the same output be spent twice.  
> **username_0**: Hi @username_1 , if I am a thin client (bitcoinj) and I know both the `tx_hash` and the `block_number`, what kind of message do I need to send to my peers to get back the complete transaction?  
> **username_1**: @username_0 Once you know `block_hash`, and `tx_hash`, you send the bloom filter with `filterload`. Then you send `getdata`, with an inv type of `MSG_FILTERED_BLOCK`, and the block hash. This documents the low-level details. https://en.bitcoin.it/wiki/Protocol_documentation#Inventory_Vectors Let me see if I can work up some example code for you.  
> **username_0**: I've just studied the different kind of messages on the developer guide :)  I'd like to ask for the last favour: I'm interested in a snippet of code in python (jython for bitcoinj) that given a `tx_hash` and `block_number`, it returns the hex after OP_RETURN in the tx_hash output. Where can I find a guide for learning how to do it? :)  

---

