SmartSPV – A better Simplified Payment Verification for Smartphones

[Sergio_Demian_Lerner]

Smart-SPV is a variation of the standard SPV headers-only mode that allows a smartphone to keep a fairly accurate state of the wallet balance without downloading all the missing headers and without sacrificing battery life and time.
The idea is to detect transactions and account them in the client wallet even if the branch where they come is still orphaned.

Here is the description of the protocol: http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/

Best regards!
Sergio.

[1714165222]

1714165222

[1714165222]

1714165222

[1714165222]

1714165222

[1714165222]

1714165222

[1714165222]

1714165222

[1714165222]

1714165222

[TierNolan]

So, for receiving payment

- When on battery, your client doesn't bother downloading the header chain
-- maybe it updates when connected to a charger and/or with a Wifi connection

- You ask your (full) peers to send you any new transactions (via Bloom filter)

- A new transaction has to be in a block timestamped near "now"

- If you receive a transactions, you ask your peers to send you all the new headers, until the tx is confirmed

- A tx is confirmed as long as it is built on by N blocks
-- N determined by comparing POW to POW of last known block

- If the block height of the block is to far away, then new headers are requested

To fake a transaction, you have to build a chain with the required POW of 6 blocks.  Doing that on a disconnected fork it to expensive.

It is also not any cheaper than forking the main chain.

I think N should be determined based on actual work.  You can estimate the cost of a hash in coins, based on the most recent header.

You could require that the transaction is built on by blocks worth at least 100X the total value of the transaction.

Have you considered allowing "skips" in the header chain?

For example, you could point to the previous header and also point to the most recent header that has more than 1024X the required difficulty (hash(header) < target / 1024).

This generates 2 chains, but one of them is 1024X smaller.  This would allow an SPV client to keep up with the main chain, but with much less data.

In fact, you could have an hierarchy, prev, prev(32X) and prev(1024X).

The SPV client stays locked to the main chain using the 1024X chain.  Once a tx comes in, it can use the 32X chain to get within 32 of the end of the main chain and then just download (on average) 16 headers.