Topic: Great news! blockchain initial downloading are much faster now. (Read 2361 times)
Great! Now people who first get the software and get a payment won't be wondering what's wrong when the only problem is they haven't got the whole chain yet!
Thank you for the clarifications and thoughts, guys! Nice!
Ente
Ente
This is the kind of headlines that will drive people to help test the pre-releases. Everybody loves massive performance improvements. Fingersnappin' good work!
excellent. looking forward to the next release guys 
nice, thanks 
顶！
That factor is determined exactly by difficulty*4295032833.
That is how much harder it is to find a block nonce at a given difficulty vs. verifying it.
That is how much harder it is to find a block nonce at a given difficulty vs. verifying it.
Thanks for quantifying it.
That's great news.
Thanks sipa.
Thanks sipa.
I just did some testing for good parameters. Tweaking them was Gavin's idea.
Of course (can't believe I missed that). So yeah it is more like a million fold (maybe billion fold) easier to verify than produce.
That factor is determined exactly by difficulty*4295032833.
That is how much harder it is to find a block nonce at a given difficulty vs. verifying it.
That's great news.
Thanks sipa.
Thanks sipa.
Of course (can't believe I missed that). So yeah it is more like a million fold (maybe billion fold) easier to verify than produce.
But then: The point in cryptographic tools (like hashing the block to verify) is that the verify is quick, the reverse (brute-force) painfully slow?
It was fast. The block chain took over 1000 days to create. If you downloaded and verified it in a day it was ~1000x faster to verify than create. With things like ramdisk (or improved client which keep portion of chain in ram) and the improvements the developers made to 0.6 it likely is 10,000x faster under optimal conditions.
No doubt. And it took 1000 days for a very substantial amount of resources. And it could be done in 2 days (now hours?!) by one weak machine.
But then: The point in cryptographic tools (like hashing the block to verify) is that the verify is quick, the reverse (brute-force) painfully slow?
It was fast. The block chain took over 1000 days to create. If you downloaded and verified it in a day it was ~1000x faster to verify than create. With things like ramdisk (or improved client which keep portion of chain in ram) and the improvements the developers made to 0.6 it likely is 10,000x faster under optimal conditions.
No:
verification: CPU is the bottleneck
indexing: HDD latency is the bottleneck
download: network/p2p is the bottleneck
Indexing almost always outweighed the other two, unless you were running on a ramdrive.
Yes, sorry I confused verification with indexing. verification: CPU is the bottleneck
indexing: HDD latency is the bottleneck
download: network/p2p is the bottleneck
Indexing almost always outweighed the other two, unless you were running on a ramdrive.
No:
verification: CPU is the bottleneck
indexing: HDD latency is the bottleneck
download: network/p2p is the bottleneck
Indexing almost always outweighed the other two, unless you were running on a ramdrive.
verification: CPU is the bottleneck
indexing: HDD latency is the bottleneck
download: network/p2p is the bottleneck
Indexing almost always outweighed the other two, unless you were running on a ramdrive.
Verification. Later blocks were larger and had more transactions and spam, causing them to be slower. Running the initial download in a ramdisk has always been speedy, because the disk throughput was the bottleneck. Sounds like that has either been made more efficient or removed.
Verification -> CPU is the bottleneck
Download -> HDD is the bottleneck
So, which one of the two then? :-P
Defragmenting the local (large) blockchain doesnt help, in my tests.
I cant believe its a HDD throughput problem.. Sure, many thousand blocks, but its just a few gigs data?
So I guess "verification/CPU" is the problem. My CPU was at 100% while loading the chain, too..
But then: The point in cryptographic tools (like hashing the block to verify) is that the verify is quick, the reverse (brute-force) painfully slow?
Ente
Verification. Later blocks were larger and had more transactions and spam, causing them to be slower. Running the initial download in a ramdisk has always been speedy, because the disk throughput was the bottleneck. Sounds like that has either been made more efficient or removed.
Verification -> CPU is the bottleneck
Download -> HDD is the bottleneck
So, which one of the two then? :-P
Defragmenting the local (large) blockchain doesnt help, in my tests.
I cant believe its a HDD throughput problem.. Sure, many thousand blocks, but its just a few gigs data?
So I guess "verification/CPU" is the problem. My CPU was at 100% while loading the chain, too..
But then: The point in cryptographic tools (like hashing the block to verify) is that the verify is quick, the reverse (brute-force) painfully slow?
Ente
And today it was merged into mainline, so it will be part of 0.6.0 final.
Oh yeah, great! :-)
It really was a pain to wait one, two days for the whole chain..
Out of historical curiosity: What made it took so long? Downloading the blocks from other peers, or verifying the blocks when they got there?
Also, at the beginning of the downloading they came in by the thousands, at the end you can watch the blocks come in one after another per second?
Ente
Verification. Later blocks were larger and had more transactions and spam, causing them to be slower. Running the initial download in a ramdisk has always been speedy, because the disk throughput was the bottleneck. Sounds like that has either been made more efficient or removed. It really was a pain to wait one, two days for the whole chain..
Out of historical curiosity: What made it took so long? Downloading the blocks from other peers, or verifying the blocks when they got there?
Also, at the beginning of the downloading they came in by the thousands, at the end you can watch the blocks come in one after another per second?
Ente
Oh yeah, great! :-)
It really was a pain to wait one, two days for the whole chain..
Out of historical curiosity: What made it took so long? Downloading the blocks from other peers, or verifying the blocks when they got there?
Also, at the beginning of the downloading they came in by the thousands, at the end you can watch the blocks come in one after another per second?
Ente
It really was a pain to wait one, two days for the whole chain..
Out of historical curiosity: What made it took so long? Downloading the blocks from other peers, or verifying the blocks when they got there?
Also, at the beginning of the downloading they came in by the thousands, at the end you can watch the blocks come in one after another per second?
Ente
Jump to: