Actually, wouldn't it more directly be related to the number of signatures? And if so, isn't the ratio of blockchain bytes to signature bytes fairly constant? In other words, wouldn't it be even more accurate to measure/predict the number of TxIn's? Or probably just total blockchain bytes...
Also, sipa just pointed out that verification is diabled for the initial download up to about blk 216,000. This is because there's a hard-coded checkpoint there, so verification isn't necessary. This would explain why it all slows down pretty dramatically at the very end.
I guess it is just coincidence that it fits the N8 curve pretty cleanly...
Topic: Predicting Time to Finish Downloading Chain (Read 783 times)
The download time is linear in the number of transactions ...
Imagine that...
The download time is linear in the number of transactions. 0.8.1 (current git) uses that for its progress indicator.
This is scary because I would like to think that no part of Bitcoin has an order of growth of O(N8).
It won't last forever; just until we move past the inflection point of the S curve.
Okay, well I just did an experiment with Bitcoin-Qt 0.8, and what I found is kind of scary...
Plotting percentage-of-blocks-downloaded vs percentage-of-total-download-time yielded a rather extreme relationship:
It can be linearized by plotting (% of blocks)8 vs (% of total time). The linearity of the result is surprisingly... good.
This is scary because I would like to think that no part of Bitcoin has an order of growth of O(N8). Of course, that was probably the trajectory of the relationship before we hit the [artificial] block-size limits.
The moral of this story is that if you predict the current top block you are synchronizing to (say from asking peers, or just projecting out at 10min/blk from your last estimate), then you can create a fairly accurate "Percent Complete: ..." meter by simply computing (currentBlock/maxBlock)8. This seems to be accurate for at least the first 225k blocks...
Plotting percentage-of-blocks-downloaded vs percentage-of-total-download-time yielded a rather extreme relationship:
It can be linearized by plotting (% of blocks)8 vs (% of total time). The linearity of the result is surprisingly... good.
This is scary because I would like to think that no part of Bitcoin has an order of growth of O(N8). Of course, that was probably the trajectory of the relationship before we hit the [artificial] block-size limits.
The moral of this story is that if you predict the current top block you are synchronizing to (say from asking peers, or just projecting out at 10min/blk from your last estimate), then you can create a fairly accurate "Percent Complete: ..." meter by simply computing (currentBlock/maxBlock)8. This seems to be accurate for at least the first 225k blocks...
I want to put this in Armory, but maybe Bitcoin-Qt would do the same thing: roughly predict the time to finish downloading and verifying the chain in Bitcoin-Qt. It doesn't need to be exact by any means, but it shouldn't be like the Windows copy dialog.
Anyone have any empirical data on this? Sure, I could do some experiments myself, but why if someone else already has it? I expect it would be some linear combination of the number of blocks remaining and the number MB remaining. I expect to be able to approximate both, along with rates of download/verification, and come up with something accurate to within 15 minutes. Perhaps only the MB-remaining-to-download is the important metric. Or maybe as simple as a reverse-lookup table based on previous measurements, that says 'if you are up to block 178k that's 50%, 202k is 75%", etc. I just want to set expectations appropriately for the first-time user.
Anyone have any empirical data on this? Sure, I could do some experiments myself, but why if someone else already has it? I expect it would be some linear combination of the number of blocks remaining and the number MB remaining. I expect to be able to approximate both, along with rates of download/verification, and come up with something accurate to within 15 minutes. Perhaps only the MB-remaining-to-download is the important metric. Or maybe as simple as a reverse-lookup table based on previous measurements, that says 'if you are up to block 178k that's 50%, 202k is 75%", etc. I just want to set expectations appropriately for the first-time user.
Jump to: