The immediate plans are simply to have the reference client support peers that request filtered blocks. BitcoinJ and derived SPV clients would be candidates for requesting filtering. We're not making the reference client SPV, or making it request filtered blocks.
Something related is switching the synchronisation mechanism in the reference client to be "headers first". This is different from "headers only" - it simply means we're first going to request only headers, so that the client knows what the best chains are its peers knows about, and then in a second (mostly parallel) step, fetch the actual blocks along the best known chain. This makes it much easier to make the initial synchronization parallellized. I believe most core developers agree this is the way to go, but it requires a lot of delicate implementation and testing.
However, once that is done, the step to making the program headers-only, where the step to download the actual blocks is skipped altogether, becomes quite small. Some believe a good way forward is to make the program start in such a headers-only mode (effectively SPV mode), and when resources (cpu/bandwidth/storage) allow it, suggest upgrading itself to becoming a full node by downloading and verifying all blocks in history. This will not be for very soon, though.
Topic: BIP0037 - Bloom Filter - Bitcoin Reference Client to be SPV by default? (Read 2714 times)
November 24, 2012, 08:39:42 AM
November 24, 2012, 07:50:07 AM
As we all know the major problem with the reference client for new users is the initial 3gig/24 hour++ blockchain download.
Is it the developers medium term intention to change the default setting for the Reference client to be SPV? (see http://bitcoin.org/bitcoin.pdf - section 8 if you do not know what SPV is).
You could even set it to only download headers after the last checkpoint block, and even include those headers in the standard download so only a few thousand headers were required (guessing this would only take minutes to catch up given the time the initial 50,000 blocks of the full chain download take).
My opinion is that this would be a good thing. Then once users understood the system more and wanted to use bitcoins for paying large amount of money they could then go to the options page and "untick SPV mode" and so then download the 3gig, support the network etc...
Obviously the default should not be changed till there are 1000+ clients that accept bloom filter requests and the whole bloom filter process has proved to be stable. But having SPV as the default should be the objective.
Is this agreed or still a controversial topic?
Is it the developers medium term intention to change the default setting for the Reference client to be SPV? (see http://bitcoin.org/bitcoin.pdf - section 8 if you do not know what SPV is).
You could even set it to only download headers after the last checkpoint block, and even include those headers in the standard download so only a few thousand headers were required (guessing this would only take minutes to catch up given the time the initial 50,000 blocks of the full chain download take).
My opinion is that this would be a good thing. Then once users understood the system more and wanted to use bitcoins for paying large amount of money they could then go to the options page and "untick SPV mode" and so then download the 3gig, support the network etc...
Obviously the default should not be changed till there are 1000+ clients that accept bloom filter requests and the whole bloom filter process has proved to be stable. But having SPV as the default should be the objective.
Is this agreed or still a controversial topic?
Jump to: