Technical help article describing SPV within MultiBit

This would be useful to assist people with questions about SPV, Bloom filtering, checkpoints and restrictions on Account numbers.

Here is a guideline:

We start with thinking about what a full node knows. It knows:

• every transaction that is currently being broadcast around the network
• every transaction that has EVER been sent
• all the unspent tx outputs (the UTXO set aka the ledger)

SPV Explained

SPV (Simplified Payment Verification) is a way where you can determine that a particular tx was in a block (in the blockchain). It does this as follows:

• Every tx has a hash
• Every block has a hash
• You can connect the tx hash and the block hash using what is known as a Merkle tree proof.

A Merkle tree is a tree where the block is at the apex and all the tx get placed in a tree like structure. A Merkle tree proof is a list of all the hashes between the apex (block) and the leaf (tx). The point of a merkle tree proof is that you only need a small part of the block to prove the tx is in the block.

Thus when a wallet says it uses SPV it refers to the fact that it is checking that before it believes in a tx it checks:

• there is a merkle tree proof that the tx is in a block
• the block itself is in the main chain of the block chain

The tx is then "good" and it will put it in the wallet.

Bloom filtering and single HD account support

The main reason we only supprt one HD account (Account 1) is due to how we get our tx from the Bitcoin Core nodes. We use a technique called bloom filtering. We don't ask for the tx directly, instead we give the Bitcoin Core nodes a filter that we know will match all the tx we are interested in (plus some false positives to put anyone spying off the scent a little).

Supporting just one account means creating filters for a steadily increasing number of addresses for both the main addresses and the change addresses. This starts off as 'hundreds' and, as the wallets get used, will become 'thousands'.

Scaling this up to supporting any number of accounts means creating filters that match:

number of accounts x (main addresses + change addresses)

Thus we have to filter to match many more addresses to the point (we think) where we are pretty much getting the complete blocks. This makes us as slow as a Bitcoin Core node (slower actually as we are uploading very wide bloom filters).

We think this will be far too slow to be useful so we are restricting our usage to a single account.

We don't have the UTXO set

We don't have access to the UTXO set using bitcoinj thus we cannot check directly against it. Only implementations that have a full block store in their backend and can query it directly can use the UTXO set which would mean downloading the entire blockchain.

Bitcoinj only talks the Bitcoin network protocol which does not give you calls such as "give me all the UTXO for this address' or whatever.

Checkpoints

To reduce the amount of blocks that need to be downloaded we include a checkpoints file in the installer which gives the hash of roughly every 2000th block in the main chain.

This allows us to only sync from the checkpoint before the wallet birth date which saves a lot of time and is why we ask you to record the "datestamp" during wallet creation. Thus if the wallet datestamp is equivalent to block 200,050 and we have a checkpoint at block 200,000 then we can just sync 50 blocks.

come from https://github.com/bitcoin-solutions/multibit-website/issues/193

打赏地址：13dyX9hbF9d1VQsCYLN5KHmq3uaQEdqNMz