Please don't listen to bullshit from non-technical people. Bitcoin Core does initial download faster only in certain conditions, that nowadays could be considered laboratory-like. With the real user environments (especially technical newbies or people outside USA) it is much more reliable and oftentimes faster to do this using Bittorrent or cloud file storage.
This is simply untrue.
Unless your internet connection is very slow the vast majority of time is spent in validation and data handling even on a 24 core host.
If you download separately you cannot overlap the download and validation. So unless your download is nearly infinitely fast it must be slower.
This experiment is conducted regularly in real conditions at least with every release (since we benchmark for synchronization performance regressions).
Dude, you are so disconnected from reality that it isn't funny anymore.
Your "real conditions" consist of:
1) Not running Windows natively on the hardware as a matter of core dev team policy, but on virtualized high-end hardware.
2) Using well tested hardware, probably with ECC RAM and SSD storage.
3) Using static (or nearly static) IPv4 address that isn't shared with other users of the ISP providing cabled/fixed service.
The real users' conditions are vastly different:
1) Windows running natively, frequently on cheap computers or external drives connected with USB.
2) Untested hardware that had never run any sort of database application, only web browsers and games. Most users will try to put Bitcoin on a mechanical drive and to compound problems will run various online anti-virus and other lame security applications.
3) Outside of the USA static IPv4 are quite rare commodity, most users have either forcibly changed dynamic IPv4, shared IPv4 through CG-NAT or dual-stack-lite IPv6 deployments where only IPv6 is static and IPv4 is shared. Large fraction of Bitcoin users use various non-cabled ISPs either radio-line or cellular. Bittorrent deals with those much better than Bitcoin Core.
4) In practice the beginning users have to attempt initial synchronization several times until their resolve problems with their configuration following the usual recipe: blow away everything except wallet.dat and restart from scratch, very much in the days of MS-DOS on a PC-compatible. Downloading the data separately at least allows them to start cleanly in an reproducible configuration that allows sensible troubleshooting.
5) For many users the proper metric to optimize is not "minimum total time" but "minimum total costs". Especially those users on non-cabled ISPs have non-metered, well-performing connections only through 8 to 12 hours during night time. For them separating download (via Bittorrent or cloud file locker) and local synchronization makes obvious sense.
created with multiple restarts of the Bitcoin client, needlessly keep track of orphaned blocks, keep track of transactions in somebody's wallet, etc.
Orphaned blocks are about 1% -- who cares if there is 1% of overhead in the files? The linearize tool in the contribs directory will create block files without them-- sure, but they're not a big deal. The main reason to exclude them is to get a reproducible file. The wallet _never_ has any effect on the content of the block files.
The risk with copying a chainstate, beyond the risk of being tricked onto a fork where the attacker has created a bunch of coins out of thin air is that the leveldb database files are not a safe external interface and it may well be possible to get remote code execution with a specially crafted database. BDB (used for the wallets) can easily be caused to crash with out of bounds memory accesses from crafted database files, for example.
I'm pretty sure that that a UTXO assume-valid type sync will be supported (even a default) in the future-- but that doesn't mean that copying database files from third parties is safe-- personally I'd never do it.
It isn't the 1% waste that is the problem. It is lack of reproducibility and lack of possibility of making sensible incremental backups and incremental synchronization amongst multiple machines.
Your paranoia is largely unfounded for two reasons:
1) even if you (or your friends stateside) don't know the providers of pre-initialized state directories, those people are frequently quite well-known outside of the USA and can be reasonably trusted.
2) most of the users desiring shortcuts to initialize don't have any coins in their wallet and don't plan on putting any just yet. They are planning on learning or demonstrating the technology.
3) the "crafted leveldb exploit to put user on a fake fork" is largely theoretical so far, whereas the practical exploits were social engineering related to fraudulent technical help with extremely fragile and problematic Bitcoin Core that has almost no internal RAS features (reliability - availability - serviceability) and laughable error messages like "there was checksum error, aborting".
Don't even get me started on using sensible storage architecture for Bitcoin Core. I tried to explain the benefits of storage layer abstraction to etotheipi in 2013:
https://bitcointalksearch.org/topic/new-blockchain-management-in-armory-144015His position was that he rather have his company fail than use a database engine that is more than an educational toy. By the time they tried to switch to LightningDB he was out of money and out of patience from the prospective enterprise customers.
