Very interesting, thanks. Now here's another question: when Armory loads up it always takes the same amount of time even if it has already been loaded and exited from! That is, if you load Armory, let it do "Initialization of Database Engine", "Build Database", "Scan Transactions", then exit Armory, then one second later reload Armory, it takes the same amount of time, like 10 minutes, before it goes online. This is a feature or bug? It should not take so long the second time it is loaded since the data downloaded is already in place?
BTW, below is something of interest that was mentioned earlier (new version of Core): I see that the chief scientist Gavin Andresen made his blog post Oct 6, 2014 yet it seems the "headers first" approach has in fact "won the endorsement" of the "Powers That Be" in less than three weeks--very interesting. I'd like to know why they picked this approach, perhaps it is the easiest to code (but I see Pieter Wuille was pushing for this, and he seems to be their main man, so that's probably why)? Regardless, how long before they come out with a stable version of Core using Headers First? It might be several months? Maybe a year? Time will tell but I bet this is not a trivial change to make in Core?
TonyT
A Scalability Roadmap
by Gavin Andresen, Chief Scientist, October 6, 2014
https://bitcoinfoundation.org/2014/10/a-scalability-roadmap/Pieter Wuille has been hard at work on a “headers first” approach – downloading the longest chain of 80-byte block headers, which is only 25 megabytes of data. The headers are sufficient to know whether or not you have the best chain, and once your node has the headers it can “back fill” by requesting complete blocks from multiple peers in any order it wants, similar to how BitTorrent downloads chunks of a large file from many different peers at once.
You might be surprised that old blocks aren’t needed to validate new transactions. Pieter Wuille re-architected Bitcoin Core a few releases ago so that all of the data needed to validate transactions is kept in a “UTXO” (unspent transaction output) database. The amount of historical data needed that absolutely must be stored depends on the plausible depth of a blockchain reorganization. The longest reorganization ever experienced on the main network was 24 blocks during the infamous March 11, 2013 chain fork.