Thin Client and OP_RETURN

0

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

gatb27

Posted 2017-01-30T16:38:25.940

Reputation: 5

Answers

0

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

Nick ODell

Posted 2017-01-30T16:38:25.940

Reputation: 26 536

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 – 2017-01-30T19:58:12.983

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 – 2017-01-30T20:43:21.127

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 – 2017-01-30T21:15:10.967

Right. You need all of the blocks to enforce rules like not letting the same output be spent twice. – Nick ODell – 2017-01-30T21:25:57.580

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 – 2017-02-01T14:17:51.037

@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 – 2017-02-01T17:28:09.080

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 – 2017-02-03T07:01:22.887

Asked: 2017-01-30T16:38:25.940

Viewed: 166 times

Active: 2017-01-30T19:37:54.667