Quote from: keeshux on September 02, 2014, 09:50:49 AM

Quote from: zhouqi_cn on September 02, 2014, 05:42:09 AM

In this BIP, I want to improve the way to find the first block header we are going to store in the client. What you are saying is since which block we may want the transactions in it. In another word, I'm talking about which block to start header downloading. While you are talking about which block to start body downloading, which means header downloading should end in the mean time. We are not talking about the same problem here.

If you read carefully I moved the problem to the FCU simply because it's pointless to set a checkpoint without considering the FCU, unless you intend to support raw monitors that only observe upcoming blocks and transactions.

I don't see any advantage for SPV wallets with some history, whereas a protocol message providing a (timestamp -> checkpoint_hash) mapping would be much more useful for both monitors and wallets. By checkpoint_hash I don't mean "the first block with transactions", rather a checkpoint block the way you meant in your previous posts.

Example: "hey peer, I want to start syncing from 'Jan 01, 2012' (or from now on). I don't have any idea about what the hash of the first block to start sync from could be, can you give it to me?"

For now, FCU is only use for decide to use getblock message or getheader message which means download block's transaction or not. But we still need to know the first block's hash, and get the first block's block time to decide with FCU.

OK, may be you think why not peer direct give us a block hash that before a point time? I think it may be a future improve for Bitcoin, and may be another BIP.