You should empty the "databases" folder before running 0.96.5. You can install 0.96.5 over 0.96, it will replace the older binary. Wallet and databases data will be left untouched.

That sweet, sweet race to the bottom...

1. Run bitcoind manually, you're behind some 100k blocks as far as Armory is concerned
2. Make sure there are no zombie ArmoryDB instances
3. Make sure nothing is listening on 9001

Once bitcoind is caught up, start ArmoryDB from the terminal, let it catch up, post the log file back here if it doesn't get beyond block 700k. If ArmoryDB gets as far as "enabling zero conf parser", you can start ArmoryQt.

Hard to help you without logs.

0.22 should work with 0.96.5. There are no changes to the P2P layer nor block/tx serialization. Armory will simply ignore the taproot scripts.

On a side note, 0.96.5 ArmoryDB chokes on the testnet now. Someone mined malformed multisig scripts.

RPC is the broadcast fallback mechanism. Armory tries to broadcast via the p2p layer first, but that one throws a lot of false negatives.

Don't really know what's going on there. The RPC connection should be available regardless of Core's p2p connection count. You could try to automate bitcoind from Armory to make sure the connection is grabbed early. In doubt, I would try to monitor the Core RPC port, see what's trying to connect through that.

This isn't a WAN connection. This is ArmoryQt (the GUI) connecting to ArmoryDB (the blockchain service) on 127.0.0.1:50559


Getting the raw tx

A. If a transaction fails to broadcast, it should dump the tx in hex in your logs.

B. Or, go through the unsigned tx flow instead of signing and broadcasting from the send dialog (on an online node). You would:

a) Create the transaction as unsigned. This will give you a text blob you can save to a file or copy paste around.
b) Load this blob via the offline transaction dialog (the sign/broadcast option). This stuff is available to both offline and online nodes, just make sure you've set the user mode to expert.
c) From this dialog, you will first sign the transaction. This will update the blob with the signatures.
d) From this same dialog (if you're doing this from an online wallet), or after loading the blob on your online instance, you can either broadcast the transaction, or copy the raw hex tx. Choose the latter.

Broadcasting the raw tx

You can broadcast transactions in hex format from the Core RPC using the sendrawtransaction command. There are 2 ways to do this:

A. If you're using the bitcoin-core-qt (the GUI), this is as simple as going to the console tab, writing sendrawtransaciton then pasting the hex tx in quotes. If you can't see that tab in the GUI, restart it with -disablewallet.

B. You can also do this from any terminal/command line prompt by sending the same command within a JSON packet to Core's RPC. This is a somewhat involved process, so I'll let you search for a guide to walk you through the steps (they're not that hard to find).

This is really weird. Armory does not access the WAN at all. It only talks to your node on localhost. If your node is seeing Armory, broadcast should work. Maybe your settings prevent tx relay? Or "onlynet=onion" is rejecting the connection from localhost, which is not correctly reflected in the node count. At any rate, you can copy the raw tx from Armory and broadcast it directly with Core.

Latest commit in dev should be able to create & sign unsigned transactions. It may choke while converting wallets, checking that next.

Core signaling is unrelated, that's Taproot activation. While this doesn't affect Armory, you should consider updating Core.

With regards to Armory and signing your transactions, please elaborate on the step by step process. I don't want to assume anything you are doing or I'll be drawing false conclusions.

Starting Ubuntu 19, py2 was not installed by default anymore. You could however install it, as well as qt4, and all the necessary dependencies for Armory. That accelerated quickly however and the whole thing was dumped unceremoniously in Ubuntu 21. I don't blame them however. I've lost track of that tbh, I use Manjaro these days. I may just bite the bullet and go full Arch and never look back.

Python is now just a runtime for the GUI. The blockchain service and wallet manager/signer are now fully headless C++ processes. The GUI is a dumb interface that implements as little mechanisms as possible. Every minute operation in the GUI is deferred to the wallet manager, from converting scripts to address strings to coin selection. The wallet manager interfaces with the blockchain service to keep track of balance and transaction history.

I stuck to Python cause all of Armory's legacy UI is hardcoded as qt4 dialogs and widgets. I intent to use QML to implement new UI elements going forward, and then maybe dump the Python/Qt dependency altogether and migrate the QML to something more modern like Flutter.

0.92.x can only spend from older address types. If you picked a more recent address type, 0.92 won't be able to make sense of it. You'd have to update Armory on your offline signer.


The change address is where your coins go back to. If all the recipients in a transaction are spending to modern address types (SegWit) and there is only one legacy type address (P2PKH), blockchain crawlers will look at the address type of the origin coins, and deduce the legacy type recipient is your change. Armory detects this and recommends you modify the change address type to obfuscate it.

PySide2. It's an officially maintained version of Qt5 for Python, but with a less restrictive license than PyQt5.


It doesn't, I'd have to use PySide6 for Qt6 (there's no PySide 3-4-5, they just went from 2 to 6)


You can build qt4 from source and install locally (look up qt-everywhere). Maybe there's a pyqt4 version on pip that statically links to qt4 and you wouldn't even need to install qt4.

Got rid of that dependency in the py3 version entirely. It's used to spawn processes and watch over the PIDs for what its worth.


Unlock wallet flow is a bit busted atm, have to fix it. I suspect the offline signing will throw some exceptions along the way. Nothing design related though, most likely syntax issues (Qt4 doesn't translate 100% into PySide2) and missing imports (I've been refactoring the massive qtdialogs file into a collection of smaller files, in part to get rid of the circular imports). I've signed offline transactions on testnet before but went through some more refactoring lately so I expect some cleanup ahead of me. Could be fixed sometimes in the coming week. That aside, the wallet creation dialogs are probably busted, same with comments (doesn't map over to the new wallet format yet), and the migration dialog from old to new wallets is thread bare.

Be warned, the build system isn't super user friendly right now.

You can't really do this with current Armory. You'd have to manually manipulate the unsigned transaction or import the priv keys from one wallet to the other. I'll make a not of adding this functionality to the next version.

It would be easier if you presented full logs, it's hard to go off with just this. For now, the line suggests something went wrong when registering addresses with the DB, which is to say that never started scanning in the first place.

0.96.5 won't be able to spend to native taproot addresses. I'm working to add full support for that address format among other things.

Armory's KDF is particularly resource intensive. Unless you can remember most of your password, you are unlikely to crack the wallet within your lifetime.

The chaincode is an integral part of how the addresses are generated, you cant skip it.


The chaincode is unique and static for the lifetime of a wallet. 1.35c derives the chaincode from the root key, older versions pull 32 random bytes and use that instead. The chaincode is then used to generate key pairs on the chain.

Im not gonna delve in the math but basically to get the privkey N+1, you multiply privkey N by the chaincode. You do the same operation with the public keys. EC maths makes it so that pubkey N will match privkey N, even if you generated pubkey N without ever having knowledge of any private key (that's how we can have deterministic watching only wallets).

You cannot divide public keys because that operation does not exist in EC math, so you can't reveal the chaincode by looking at pubkey N and N+1. You can however do that with 2 consecutive private keys, since they are only scalars:



Unless you have private keys, no. The chaincode for your wallet is a random number, it has no relation to your rootkey, you're going to have to remember it or find an old wallet file with some private keys in it.