Armory & Headers first

[spin]

How compatible would Armory be with headers first sync?  I read about it and saw the following issues:

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.

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.

[doug_armory]

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.

[spin]

I'm sure it can be handled.  Will armory work as is or do you know it won't?

[goatpig]

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.

[etotheipi]

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).

[justusranvier]

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.

[spin]

Well I am testing the headers first node.  Might try to run armory against those blk files.

[njaard]

the current dev branch supports headers first, it is being tested. The next release of armory will officially support headersfirst. Nothing to worry about!

[PRab]

What about pruning? I'm assuming armory won't support pruning, but would love to be wrong.