I don't think any of the LTS ubuntu's come with pyqt4 preinstalled. You can either grab it via pip (or download the wheel and install it offline) or via apt, but you'll probably need to add the backport repo to your apt sources file.


The CPU on your machine doesn't carry SSE3/4 silicon, you have to use the noasm build.

ubuntu 20.04LTS and older, debian 8, anything based on debian 8 and apt/dpkg

Is ArmoryDB maxing a thread once it gets to "Organizing Chain"?

You have to flag wallets as yours for each wallet. You can find it in the wallet details dialog (double click a wallet from the lobby to get there). You need to set your user to "expert" first, from the User File menu.

You likely have a long orphan, i.e. a block deep into the chain is missing, triggering 100k+ block reorgs over and over. I don't know how these happen, but I've ran into them myself recently however.

This isn't an Armory issue per se, your copy of the chain is corrupted somehow. You will need to reindex Core first to fix the issue, Armory cannot help you here.

Call bitcoind/bitcoin-qt with -reindex and let it do its thing. Once it succeeds, you can wipe Armory's database folder and try again.

Is the most recent transaction in the ledger showing coins moving out of your wallet? What wallet filter did you select (in bottom left corner)?

Does the number of blocks in Armory match that of Core? Are there any transactions showing in the ledger? You should create your own thread and we can troubleshoot from there.

Delete the databases folder in your Armory appdata then update to 0.96.5:

https://github.com/goatpig/BitcoinArmory/releases

This sounds very slow. It shouldn't take over 2h for full DB build. Can you try with a fresh Armory databases folder and post logs?

The JSON version was updated starting Core 0.28, likely a benign update of the underlying library. This broke Armory's handling.

In the previous JSON version, the "error" field is mandatory, regardless of whether the request was successful or not. Armory 0.96.x treats replies as malformed if the field is missing, which the new JSON version can omit.

Regarding your options with 0.96.5, you can either apply a patch yourself to 0.96.5, stick to Core 0.27.x, or run Armory without Core RPC support. If you're more patient, 0.97. I'm hoping to release it before the end of summer.

autodb is a side branch I started working on while waiting for replies to my comments on the migration UI wizard. You check the progress for that here:

https://github.com/goatpig/BitcoinArmory/pull/725

autodb is unstable for now, but since I have to travel a bunch until late July, I had to push stuff to swap to a laptop. The branch is meant to get rebased once the migration UI PR is good enough to merge in.

Also please note that 0.96.5 cannot talk to Core RPC starting 0.28.x

Does knots do anything besides blacklisting a few known nodes from peer discovery? It does not affect how blocks are stored on disk nor strip anything out of the p2p layer, it ought to work.

1. Check the txhash in a block explorer, if it cannot find it, your tx is probably evicted from mempools across the network.
2. You can now delete Armory's mempool and restart it.
3. At this point you can respend the coins as if they never moved.

I'm writing tests for the migration code as we speak, then I'll slap the new migration wizard on top. I should have something by the weekend.

With regards to py3.11, I will do a run on 3.11 but I expect I won't find the issues until I spawn the related dialog, so keep reporting those as you find them, that helps. I did another blind pass with a wider heuristic, hopefully this is enough to get you through for now.

Tried a blind fix, should be doing better regardless. The error is kinda obvious.


Are you saying it's failing to read from .lmdb files (new cpp wallets) or from .wallet files (old python wallets)?

Are you using different versions of Qt across systems? That's the first thing that comes to mind, qtpy wraps "silently" around anything from pyqt4 to pysides6.

This is a regression. Old armory (python wallets) did not have you submit the password to generate the backup after creation. The password does live in memory for the whole wizard lifetime, just as before, but decryption happens in the cppbridge now.

New Armory unlocks via a callback process: encrypted assets list their encryption key id, the code tries to resolve that. If it finds no key, it prompts the caller for candidates. I can force feed the passphrase by hijacking the prompt, I was just lazy to.

Updated the verbose to be more specific about what's happening.


The private keys are encrypted nonetheless. You're running into a GUI quirk. It parses the used address data to determine encryption state and a fresh wallet that never went online has no provable used addresses, so there is nothing to parse, hence the issue on fresh wallets. Get one address from the wallet, reload Armory and it should show as encrypted. I have to use a better heuristic for this...

As for the new wallets you made showing as encrypted, I've had the creation process put the first address in use to avoid the quirk. Again, I have to think of something better.


Will fix.


This is really wonky atm, made somehow even worse on Hyprland. Probably something to do with qtpy and/or qt5/6, I'll get to it eventually.


Ah, I completely ignored that, we'll see what I can do.


Next commit will add unlock testing, should be within the hour of writing this.

What version of Armory are you using?