<p>Downloading the blockchain is several orders of magnitude <em>easier</em> than mining. Validating is just taking the blocks, hashing them and verifying that the proposed solution a) matches such hash and b) at the specified difficulty level. If a received block passes these validations, it's accepted as valid an the next one is requested, and so on.</p>

<p>Per comparison, downloading a movie or software implies no validation until the very end, when you check the archive is not corrupted. In case it indeed is, you have to download the whole big mess again .</p>

<p>As you correctly assume, most of the time is spent in verifying blocks. That's why even if a friend lends you a DVD with the blockchain, loading it for the 1st time won't be instantaneous but will take (depending on your PC's speed) from half an hour to several hours.</p>

<p>Your idea of creating a "resume" block at the end of the day (why not weekly/monthly/annually as well?) looks promising, I've heard of no coin implementing any such idea. It's not without potential problems, but it could be.</p>

CC BY-SA 3.0
2014-03-27T16:57:14.423Z
2014-03-27T16:57:14.423Z
Joe Pineda
<p>Your premise is wrong. The work required to download and validate the blockchain has nothing at all to do with the work required to mine it.</p>

<p>As far as the block hash goes, validating it requires just one hash while mining the block requires quintillions of hash calculations.</p>

<p>Validating the block also requires computing the hashes of the Merkle tree but the main work is validating ECDSA signatures. Your method is not going to help with that.</p>

<p>(On a meta note, it's rude to offer "improvements" when you don't understand well enough what currently exists.)</p>

CC BY-SA 3.0
2014-03-27T14:23:25.913Z
Could you please clarify than, why downloading of blockchain ( 16GB ) in 24x more slower than downloading the same blob file, like avi movie?
Anomalous Awe
CC BY-SA 3.0
2014-03-27T16:45:18.420Z
@AnomalousAwe:

1. Verifying all the ECDSA signatures (CPU)
2. Looking up previous outputs for each transaction input (Hard drive)

Having an SSD can greatly help with #2.
Meni Rosenfeld
CC BY-SA 3.0
2014-03-27T16:59:57.823Z
Once read at bitcointalk a proposal to integrate the code to hash in the GPU (e.g. taken from cgminer) into the QT client and have the GPU run the validations in parallel with the CPU, potentially yielding a big speed boost but to day there's no implementation. But then if the biggest speed block is #2 (is it? sounds reasonable to me) then accelerating #1 to almost zero won't do much to improve times.
Joe Pineda
CC BY-SA 3.0
2014-03-27T18:44:27.780Z
@JoePineda
Hash != ECDSA verification.
Possibly GPU is suitable for ECDSA verification as well but it wouldn't be related to any of the existing mining software.
Meni Rosenfeld
CC BY-SA 3.0
2014-03-27T20:25:40.130Z
@Meni Rosenfeld, cascade of sha(sha(..(sha(text))..) for super-blocks - day + ultra blocks - months， will allow to skip ESDSA verification. Each block contain hash of prevision. Super block contain hashs of 144 prevision, etc... There would be only O(number of blocks) sha calculations. Ordinary CPU give you at least kh ~ 1000 per sec, 8-7 days per sec. 480-420 days per minute (months). 12 minutes = years. 24 minutes = 2 years. 2-3 hours - all of current life time
Anomalous Awe
CC BY-SA 3.0
2014-03-27T21:09:01.440Z
@AnomalousAwe: If you want to skip ECDSA verification, you can do so already (but then you're trusting others to do the verification for you). It has nothing to do with hashes, computing all hashes in the Merkle trees of all blocks is cheap.
Meni Rosenfeld
CC BY-SA 3.0
2014-03-27T13:39:24.600Z
2014-03-27T13:39:24.600Z
Meni Rosenfeld
<p>Let me introduce my idea.</p>

<p>Given:</p>

<ul>
<li>sizeof( Blockchain ) = 16Gb</li>
<li>Downloading of one avi film 16GB from the pirate bay ( 5mb/s ) = 2-3 hours</li>
<li>Downloading of bitcoin's blockchain ( 5mb/s ) = 2-3 days</li>
<li>One day = 6 * 24 = 144 blocks.</li>
<li>Drag - cryptography. </li>
</ul>

<p>Task:</p>

<ul>
<li>Accelerate boot of fresh client to the torrent speed. Similar to <strong>Bootstrap</strong>.</li>
</ul>

<hr>

<p>As I can see, downloading of blockchain is the same hard as mining, because there is every time recalculation of hash, comparing, checking of signs, etc...</p>

<p>What if client will only download this 144 blocks for a day and one super block with 144 hashs of the last valid blocks, thereafter only compare current wallet's addresses with addresses in this 144 blocks without any calculation of its hash.</p>

<p>Is there any alt-coin with such accelerator? </p>

<p><hr>
E.g. this super blocks might be archived into another ultra-block for a month. Than we have similar to sha(sha(text)) cascade shield against bruteforce attack. </p>

<p>Downloading of blockchain should takes at max the same time as downloading of 16GB avi from the pirate bay. Say, 5mb/s internet channel + p2p / 16 Gb = 2, may be 3 hours ( in the <code>no peers case</code> ), but I spent 2 - 3 days, and I see that this is no internet speed reason, it is CPU + harddisk very very hard job.</p>

CC BY-SA 3.0
2014-03-26T11:52:12.117Z
I think I understand your question now: Do you mean that there should be two parallel blockchains, one with single blocks and one with consolidated large blocks that are compatible to each other, so that for synchronization one can only validate the chain of consolidated blocks, but end up being compatible to the single block blockchain?
Murch
CC BY-SA 3.0
2014-03-26T12:22:20.620Z
Methinks, I have meet such alt-coins, there was a super blocks. This block must be in the blockchain like any other. Ofcouse, this is hard fork from current blockchain.
Anomalous Awe
CC BY-SA 3.0
2014-03-27T03:39:11.250Z
I don't think there is such an altcoin although a neat idea.
John T
CC BY-SA 3.0
2014-03-27T17:03:46.760Z
Another potential improvement: merge a QT client with bittorrent so no machine had the obligation to store the whole blockchain if undesired, rather requesting different parts of it from the network and paying the storers as they consume. And of course, receiving payments in the coin for the "service" of storing copies of the blockchain when it fulfills such a request. It could even be expanded to a DAC that provides anonymous cloud data storage, and you get paid for renting an amount of your hard disk space to it. My 2 satoshis.
Joe Pineda
<blockchain><synchronization><altcoin><bootstrap.dat>
Is there any altcoin with improvements in blockchain download time?
Anomalous Awe
# Is there any altcoin with improvements in blockchain download time?

(Asked by: username_0 on 2014-03-26)

Let me introduce my idea.

Given:

* sizeof( Blockchain ) = 16Gb
* Downloading of one avi film 16GB from the pirate bay ( 5mb/s ) = 2-3 hours
* Downloading of bitcoin's blockchain ( 5mb/s ) = 2-3 days
* One day = 6 \* 24 = 144 blocks.
* Drag - cryptography.

Task:

* Accelerate boot of fresh client to the torrent speed. Similar to **Bootstrap**.

---

As I can see, downloading of blockchain is the same hard as mining, because there is every time recalculation of hash, comparing, checking of signs, etc...

What if client will only download this 144 blocks for a day and one super block with 144 hashs of the last valid blocks, thereafter only compare current wallet's addresses with addresses in this 144 blocks without any calculation of its hash.

Is there any alt-coin with such accelerator?

---

E.g. this super blocks might be archived into another ultra-block for a month. Than we have similar to sha(sha(text)) cascade shield against bruteforce attack.

Downloading of blockchain should takes at max the same time as downloading of 16GB avi from the pirate bay. Say, 5mb/s internet channel + p2p / 16 Gb = 2, may be 3 hours ( in the `no peers case` ), but I spent 2 - 3 days, and I see that this is no internet speed reason, it is CPU + harddisk very very hard job.

**Tags:** blockchain, synchronization, altcoin, bootstrap.dat

> **Comments:**
> **username_1**: I think I understand your question now: Do you mean that there should be two parallel blockchains, one with single blocks and one with consolidated large blocks that are compatible to each other, so that for synchronization one can only validate the chain of consolidated blocks, but end up being compatible to the single block blockchain?  
> **username_0**: Methinks, I have meet such alt-coins, there was a super blocks. This block must be in the blockchain like any other. Ofcouse, this is hard fork from current blockchain.  
> **username_2**: I don't think there is such an altcoin although a neat idea.  
> **username_3**: Another potential improvement: merge a QT client with bittorrent so no machine had the obligation to store the whole blockchain if undesired, rather requesting different parts of it from the network and paying the storers as they consume. And of course, receiving payments in the coin for the "service" of storing copies of the blockchain when it fulfills such a request. It could even be expanded to a DAC that provides anonymous cloud data storage, and you get paid for renting an amount of your hard disk space to it. My 2 satoshis.  

---

## 2 answers

### Answer by username_3 on 2014-03-27. Score: 1

Downloading the blockchain is several orders of magnitude *easier* than mining. Validating is just taking the blocks, hashing them and verifying that the proposed solution a) matches such hash and b) at the specified difficulty level. If a received block passes these validations, it's accepted as valid an the next one is requested, and so on.

Per comparison, downloading a movie or software implies no validation until the very end, when you check the archive is not corrupted. In case it indeed is, you have to download the whole big mess again .

As you correctly assume, most of the time is spent in verifying blocks. That's why even if a friend lends you a DVD with the blockchain, loading it for the 1st time won't be instantaneous but will take (depending on your PC's speed) from half an hour to several hours.

Your idea of creating a "resume" block at the end of the day (why not weekly/monthly/annually as well?) looks promising, I've heard of no coin implementing any such idea. It's not without potential problems, but it could be.


---

### Answer by username_4 on 2014-03-27. Score: 1

Your premise is wrong. The work required to download and validate the blockchain has nothing at all to do with the work required to mine it.

As far as the block hash goes, validating it requires just one hash while mining the block requires quintillions of hash calculations.

Validating the block also requires computing the hashes of the Merkle tree but the main work is validating ECDSA signatures. Your method is not going to help with that.

(On a meta note, it's rude to offer "improvements" when you don't understand well enough what currently exists.)

> **Comments:**
> **username_0**: Could you please clarify than, why downloading of blockchain ( 16GB ) in 24x more slower than downloading the same blob file, like avi movie?  
> **username_4**: @username_0:  1. Verifying all the ECDSA signatures (CPU) 2. Looking up previous outputs for each transaction input (Hard drive)  Having an SSD can greatly help with #2.  
> **username_3**: Once read at bitcointalk a proposal to integrate the code to hash in the GPU (e.g. taken from cgminer) into the QT client and have the GPU run the validations in parallel with the CPU, potentially yielding a big speed boost but to day there's no implementation. But then if the biggest speed block is #2 (is it? sounds reasonable to me) then accelerating #1 to almost zero won't do much to improve times.  
> **username_4**: @username_3 Hash != ECDSA verification. Possibly GPU is suitable for ECDSA verification as well but it wouldn't be related to any of the existing mining software.  
> **username_0**: @username_4, cascade of sha(sha(..(sha(text))..) for super-blocks - day + ultra blocks - months， will allow to skip ESDSA verification. Each block contain hash of prevision. Super block contain hashs of 144 prevision, etc... There would be only O(number of blocks) sha calculations. Ordinary CPU give you at least kh ~ 1000 per sec, 8-7 days per sec. 480-420 days per minute (months). 12 minutes = years. 24 minutes = 2 years. 2-3 hours - all of current life time  
> **username_4**: @username_0: If you want to skip ECDSA verification, you can do so already (but then you're trusting others to do the verification for you). It has nothing to do with hashes, computing all hashes in the Merkle trees of all blocks is cheap.  

---

