Bitcoin Forum

 Because this can be (and most probably is, most ppl just dont have so much patience to wait, when it will be finished, while watching to hdd usage indicator and enjoy highly unresponsible os) the main problem why bitcoin isn't popular. It's totally insane to download all this cache crap for >20 hours even for modern pc with fast hdd. It's so big problem to include the damn cache to the installer and update it at least once a week?

I think it is against the decentralisation principe.

Idea:

1. Include a snapshot of the blockchain in the dowload installer (updated on a regular basis)
2. Add a peer request to get the checksum of a block.
3. Have the newly installed client request checksums from peers for all blocks in the pre-loaded blockchain.
4. The checksum for each block has to be provided by at least X peers, and it has to match the checksum for the block in the pre-loaded chain.

This would simply be a way to verify with peers that the pre-loaded blockchain is valid. It would still comply with the idea of keeping things decentralized, since you wouldn't be trusting the installer, you would be trusting your peers (the same ones you would be getting the blocks from anyway).

Is there any reason why this wouldn't work?

Afaik there are anyways already "checkpoint blocks" hardcoded in the satoshi client.

After the chain gets downloaded, it needs to be checked anyways - a monthly or so updated "official" torrent of a blockchain file would be really nice however, like something "official" every 4000 blocks? Anyone with an existing blockchain anyways can verify the hash of that file.

The real issue however is still that one needs to download + verify a looot of data. This (I think) takes much longer than downloading that one gig or the other.

I agree however that the "out of the box" experience is really bad - after all you very often need a full blockchain to start things and it takes quite some time until then... which makes the first impression one of the worst ones

it's much faster if you put the data directory on a RAM disk. maybe the dev team should consider caching blockchain parts in memory?

I would agree that this would be a sensible thing to do.

Most people download the client from a central place anyway so I don't see much added risk including an up to date block chain.

People can, and do, audit the software— even the binaries due to the use of a deterministic build process— so any replacement with a compromised version has the risk of detection.  At least as things are currently constructed, an opaque blockchain wouldn't have this property.

Discussions of including the blockchain are ignoring the real issue too— initial syncup is slow because the chain validation is slow. The validation is slow due to IO related implementation issues.

Once this is fixed there will be a lot less cause for concern. Beyond that, the software should eventually make validation and downloading decoupled so that it could go on in the background— making the client usable even while downloading/validation is going on. This would be much better than making the install file a gigabyte.

In any case, it's easy to propose things— and the idea that the package could include a copy of some blockchain, with the according loss of zero-trust hasn't failed to occur to pretty much anyone— why not sit down and spend some time trying to improve it?

Will gladly help if you could teach me to program better (only know some php, rest is scripting and markup languages) and provide with extensive documentation of the source code.   :D

Not joking.