Topic: Armory & Headers first (Read 1991 times)
What about pruning? I'm assuming armory won't support pruning, but would love to be wrong.
the current dev branch supports headers first, it is being tested. The next release of armory will officially support headersfirst. Nothing to worry about!
Well I am testing the headers first node. Might try to run armory against those blk files.
and being able to use a single trusted Core instance on a network for a bunch of Armory instances).
Or being able to use alternatives to Bitcoin Core. 
I'm sure it can be handled. Will armory work as is or do you know it won't?
For reference, when I did the upgrade from RAM-only to LevelDB-backed databases, I designed the DB build&scan operations to accommodate out of order blocks in the blk*.dat files. Basically because I heard murmurings of this change coming more than a year ago.
However, I never actually tested it and there might be something stupid preventing it from working, but it should be a very short upgrade path to make it work.
In the future, I'd like to get away from blk*.dat files altogether and just pull things over P2P from your localhost Core instance. If you do that, you can guarantee you get them in order, though there other nice benefits (like no longer even having to specify a --satoshi-datadir, and being able to use a single trusted Core instance on a network for a bunch of Armory instances).
I'm sure it can be handled. Will armory work as is or do you know it won't?
Not sure the current version can handle it. I'd say there is a 80% chance it can. We'll purposefully test this in the upcoming version to make sure the code can handle both ordered and out of order/header only blk files.
I'm sure it can be handled. Will armory work as is or do you know it won't?
We've been discussing the patch. Long story short, we're not worried. Some code changes may be necessary. The basic architecture of Armory should be pretty sound, though.
How compatible would Armory be with headers first sync? I read about it and saw the following issues:
Might the out of order blocks on disk be an issue for Armory? I'm setting up the headers first sync to see if it will work.
Quote
Known issues:
* At the very start of the sync, especially before all headers are
processed, downloading is very slow due to a limited number of blocks
that are requested per peer simultaneously. The policies around this
will need some experimentation can certainly be improved.
* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support. If you are fully
synced, it may still be possible to go back to an earlier version.
* At the very start of the sync, especially before all headers are
processed, downloading is very slow due to a limited number of blocks
that are requested per peer simultaneously. The policies around this
will need some experimentation can certainly be improved.
* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support. If you are fully
synced, it may still be possible to go back to an earlier version.
Might the out of order blocks on disk be an issue for Armory? I'm setting up the headers first sync to see if it will work.
Jump to: