I can't get armory online and I am having difficulty migrating to another platfo

[nc50lc]

And to nc50lc's point, I guess maybe not necessary if I were to restore from seed on a fresh system with a new full node. I will wait and see.

Yeah, that's for existing Bitcoin Core and Armory setup.

Since it's a fresh setup anyways, it might be better to setup a proven working combination of Bitcoin Core and Armory versions.
So, in that new system, install Bitcoin Core v27.2 and Armory v0.96.5 for compatibility. (Windows11 shouldn't have issue with those versions)
You can download old versions of Core from here: bitcoincore.org/en/releases

That way, you don't have to wait for updates, those should work with their default settings (considering the system disk's space is enough)
Of course, do not enable pruning as mentioned by goatpig.

[newnube]

Excellent. Thanks for the info, I should have asked what version to go with. I will also use an external SSD rather than HDD. Once I get a spare system to run it on.

And yip, I will keep pruning off 👍


In relation to my current node:

You should check Bitcoin Core's logs if this is really necessary.
Find the "debug.log" file inside your bitcoin datadir in your '/appdata/roaming' or '/appdata/local' folder. (if you're using the default paths)
There should be an error line indicating a corrupted file or non-matching hash if it needs to be reindexed.
That'll also tell if you need to reindex the full block database or just the chainstate or just a simpler command to proceed.
[/quote]



There is no 'corrupted file' or 'non-matching hash' when searching the debug.log. so, I hope my current node is fine at least.

Maybe I could try a copy and paste to SSD, and then run this node with the more proven versions?

Or maybe even with my current system doing a rebuild rescan of databases in armory, if that does more than deleting the content in the databases folder?

[nc50lc]

There is no 'corrupted file' or 'non-matching hash' when searching the debug.log. so, I hope my current node is fine at least.

Great, then may just be a setup issue with the current RC
And you can still use your Bitcoin data directory once Armory v0.97 is stable.

If you're worried on Core's reliability, you can start Bitcoin Core without Armory and see if it'll return with an error since it auto-detects such issues.
Or to absolutely make sure, use verifychain command with "checklevel" 1 to 3 on the entire blockchain. (in Bitcoin Core)
e.g.:

Code:

verifychain 3 0

If it returns with "true", it's safe to assume that the blockchain isn't corrupted.

[newnube]

I often ran bitcoin core without armory, to keep the chain up-to-date, it synced fine. And with the trouble I was having with armory 96.5, I generally ran core until it was uptodate and synced, then I would run armory along side.


I will try the command in bitcoin core later today or tomorrow. Thanks

[newnube]

Ok it looks like I need to reindex 😣

'Verifychain 3 0' is coming back false.

The debug says:

2026-06-25T03:54:12Z Verifying last 955271 blocks at level 3
2026-06-25T03:54:12Z [0%]...ERROR: ReadBlockFromDisk: Errors in block header at FlatFilePos(nFile=4580, nPos=81813786)
2026-06-25T05:52:00Z ERROR: VerifyDB(): *** ReadBlockFromDisk failed at 860036, hash=000000000000000000002d7250815b8d194c6f4574bde61a0564607f61c621eb
2026-06-25T05:52:00Z Potential stale tip detected, will try using extra outbound peer (last tip update: 7688 seconds ago)
2026-06-25T05:52:02Z New outbound peer connected: version: 70016, blocks=955288, peer=101 (outbound-full-relay)

[nc50lc]

2026-06-25T03:54:12Z [0%]...ERROR: ReadBlockFromDisk: Errors in block header at FlatFilePos(nFile=4580, nPos=81813786)
2026-06-25T05:52:00Z ERROR: VerifyDB(): *** ReadBlockFromDisk failed at 860036, hash=000000000000000000002d7250815b8d194c6f4574bde61a0564607f61c621eb

Yeah, this is bad; there's an actual block file that's is corrupted, not just block index or chainstate.
Specifically "blk04580.dat"

At least you now know the underlying issue.

Since it's a corrupted block, your node will likely re-download and verify that block and everything above it.
It's good that it's near the current tip so it wont consume that much bandwidth, but --reindex will still take a while.

The hash and the message in the next line are concerning though.
It indicates that it may just be a case of "stuck in a fork" issue which can be solved by reconsiderblock command.
It's apparent if you see a lot of peers getting banned by your node.

[newnube]

So looking at the log previously it seemed to pick up peers ok, with the instance above it did 101,102,103,104 and moved on. As far as I can remember. And, it seemed to occasionally pick up a new peer now and then.
I didn't see any specific peer rejection, but it may have been there. The log is overwritten with reindexing at the moment so I can't check. I tried the shortcut method to reindex; adding ' -reindex' to the Target field of my desktop bitcoin core shortcut's properties. Then double clicked.


I hope this is all that's wrong. I am starting to lose faith in my node I am getting 'ERROR: AcceptBlock: bad-witness-nonce-size, ContextualCheckBlock: invalid witness reserved value size'
Early on in the chain, for maybe 50 different blocks ( around 900 to 1100) but then it moves on ok and gets new tips. And haven't had errors since. And weirdly I have had numerous confirmed transactions well beyond those early blocks, through armory, with this node. So hopefully those errors are negligible...

Additionally the headers sync stops at the same block that is corrupted, 8600036. The reindexing continues with the blocks. I will let the reindex do it's thing maybe it will automatically re-sync beyond that block as you say, or I guess I will have to delete blocks beyond the  "blk04580.dat". And then the node will have to download from there...


Please let me know if I should move this reindexing to another question stream, or bitcoin core form perhaps. However, the orphan chain maybe be involved at this specific position also.

2026-06-25T03:54:12Z [0%]...ERROR: ReadBlockFromDisk: Errors in block header at FlatFilePos(nFile=4580, nPos=81813786)
2026-06-25T05:52:00Z ERROR: VerifyDB(): *** ReadBlockFromDisk failed at 860036, hash=000000000000000000002d7250815b8d194c6f4574bde61a0564607f61c621eb

The hash and the message in the next line are concerning though.
It indicates that it may just be a case of "stuck in a fork" issue which can be solved by reconsiderblock command.
It's apparent if you see a lot of peers getting banned by your node.

Is this a major concern? Or would the reindexing possibly fix that loop. Not that I has seen peers getting banned.

Thank you both for your time, patience, and advice. I know this wears me out.

[goatpig]

Core downloads blocks, checks the content then commits it to disk. The commit part is what failed. There are various causes for this, from a freak accident at write time (very unlikely), to your drive have dead/damaged sectors (possible), to some OS event messing with the write (like the system going into sleep/suspend as the data is being pushed to the drive).

Reindexing is a long process, but it will fix the symptom. It's worth checking your drive's health prior to that. If it is in fact a bad drive issue and not just bad luck, you'll want to fix the drive or copy the data to another one before reindexing.