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).
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.
