0.97 RC1

[goatpig]

0.97 RC1 is ready. You can find the *one* binary on the github release page.

There's a ton that's changed and no changelog yet. The purpose of this release is to get some testing and bug reports. Do not expect something plug and play.
This phase is to provide a stable and solid baseline of Armory features on modern operating systems. Fancy features will be reintroduced via minor versions of 0.97.
New stuff will come in 0.98.

Here's a quick summary of what's going on in this release candidate:

- Startup -

There's a new settings manager that pops before the lobby. It will help you navigate your setup before starting Armory.
It comes with 3 tabs, the features should be self explanatory:

. wallets: lets you manage your wallets before loading them into the lobby. For now this mostly helps with migrations, but it will also be needed to unlock wallets later. That's a new feature, you can ignore it for now.

. database: this helps you with managing your connection to the db. You can let it automate the db for you or try to connect to an existing instance, either local or remote. All modes encrypt the traffic, nothing is in clear text.

Recommendation for now is to let it automate. If that fails, you can run the db manually then connect to it through this tab, before starting the lobby. UI is still a bit wonky and mileage may vary.

. core: disabled for now, nothing implemented yet.

- Wallets -

There is a new wallet format with a requirement to migrate your old wallets to it. Setup manager will help you with that but you can also skip that step and import from the wallet menu in the lobby.

Old wallets cannot be loaded as is, you have to either import them from the respective files, or restore from the backup string. Migration does not affect the old files, it only creates new files.

New wallets have a .lmdb extention and do not carry the same wallet id as the old ones. This is a quirk of the new format and does not affect what keys the wallet carries.

When migrating from a wallet file, you will be asked to unlock to private keys (if it has any). You can choose not to, at which point you'll receive a watching only version of the wallet. Migration is preferable to restoring from seed, as it will carry over chain length, comments and timestamps, which a string backup cannot provide.

New wallets are fully encrypted. That means both public and private data. There are 2 passwords as a result, one for the private keys, and one for the public keys. There is currently no GUI implemented to set public data passwords. The feature is transparent to users for now. Eventually I'll add the GUI.

New wallets can also carry much more than just key data. There's a plan to let them carry block data, so that wallet balance and history can be viewed while offline, and that data can be carried over across wallets as well, meaning you could eventually check your history up to the last known block on your offline machine, as well as generate transactions in a purely offline setup, with no db.

BIP32/39/44 support has been added, but there is once again no GUI for it. I hate GUI development and end up doing other stuff everytime I'm faced with it. I had a guy helping me with that for a while but he dissapeared a couple months ago, so here we are.

- Signer -

There's of course a new signer format, but there's also a compability mode. If you're spending from a legacy format address, i.e. anything generated by 0.96.5 and prior, there's an option to generate a legacy unsigned tx. This means you can test this stuff out without messing with your offline setup, for the most part.

- database -

Entirely new design, leaner and meaner, you will have to let it build from scratch. Simplest thing is to delete your old 0.96.5 database, or copy it to some other place, or point to a new db path via the setup manager. Eventually I'll add version detection and fail safes, but this isn't for this cycle IMO.

DB_BARE has been reintroduced. This is now the default mode. It builds the whole thing in about 20min on my desktop (5950x, 32GB RAM, gen4 nmve). The final db is ~1GB in size. RAM usage should be a lot lower, it idles around 2GB for me atm. The goal is to get this mode to setup on my laptop (5700U, 16GB RAM, gen3 nvme) in under 2 hours.

DB_FULL is still there, it comes with full tx resolution. I'm still working on that and while it is functional, I highly recommend you stay away from this for now. It needs a lot of optimizations yet. It isn't useful for day to day Bitcoin operations at any rate, this is more of a mode for Lightning support. I'll get to that eventually (TM).

DB_SUPER is disabled, will rework as well at some point.

- builds -

. Linux: there is no build for linux in this cycle. IDK what distro to target nor do I have the time to generate packages. I'll get around to that eventually, but for now, Linux testers will have to build from source. Pull the tag and read the build instructions. As far as my own testing goes, I dev on arch and have moved coins on the mainnet with this code multiple times.

. Windows: the RC comes with a Windows build. This was built on baremetal win11 (i shoved a ssd into my desktop and installed win11 there). It starts, loads wallets and whatnot, but I have not tried mainnet with it (the ssd is too small). Looking to feedback on this platform.

The build is a stand alone zip. Check the hash/signature, then unzip it and browse into it. Run ArmoryQt.exe and pray. This is built with mingw now instead of msvc.

Note that one Windows, there is some quirk where file operation may hang for up to a couple minutes. I have an idea of what's going on but have yet to debug it.

. OSX: I do not own a Mac nor have an the faintest idea how to build on that platform. Open to contributions!

- Notes -

I have to go away for at least 5 weeks for personal matters. I wont have access to my windows setup as well as my offline signer for that period of time. I'm taking a second SSD with me and I'll try to setup windows on it for my laptop, but no guarantees. I've pushed the RC hoping to get feedback and bug reports, which I'll try to fix in the 5 weeks window, at which point I'll be able to deliver RC2 once I get back home.

[nc50lc]

. Windows: the RC comes with a Windows build. This was built on baremetal win11 (i shoved a ssd into my desktop and installed win11 there). It starts, loads wallets and whatnot, but I have not tried mainnet with it (the ssd is too small).
Looking to feedback on this platform.

Leaving the default "automate" settings in RegTest, it's stuck on the welcome page on my W11 machine if I proceed too early.
Here's the related log:

Code:

2026-05-21 12:55:14 (INFO) -- Settings.py:204 - Using Language: en
2026-05-21 12:56:01 (INFO) -- DlgSetupManager.py:179 - No tested connection - attempting connection on accept
2026-05-21 12:56:01 (INFO) -- DlgSetupManager.py:484 - Initiating DB connection: scenario=Automate ArmoryDB
2026-05-21 12:56:01 (INFO) -- DlgSetupManager.py:504 - Calling automateDb: satoshiPath=C:\Users\<username>\AppData\Roaming\Bitcoin\regtest, dbPath=C:\Users\<username>\AppData\Roaming\Armory\regtest\databases
2026-05-21 12:56:01 (ERROR) -- Traceback (most recent call last):
  File "C:/msys64/home/goat/Code/BitcoinArmory/qtdialogs/setupmanager/DlgSetupManager.py", line 185, in accept
  File "C:/msys64/home/goat/Code/BitcoinArmory/qtdialogs/setupmanager/DlgSetupManager.py", line 491, in initiateDbConnection
  File "C:/msys64/home/goat/Code/BitcoinArmory/qtdialogs/setupmanager/DlgSetupManager.py", line 508, in _connectLocalDb
  File "C:/msys64/home/goat/Code/BitcoinArmory/armoryengine/CppBridge.py", line 417, in automateDb
  File "C:/msys64/home/goat/Code/BitcoinArmory/armoryengine/CppBridge.py", line 376, in send
  File "C:/msys64/home/goat/Code/BitcoinArmory/armoryengine/CppBridge.py", line 183, in sendToBridgeProto
  File "C:/msys64/home/goat/Code/BitcoinArmory/armoryengine/CppBridge.py", line 211, in sendToBridgeBinary
  File "C:/msys64/home/goat/Code/BitcoinArmory/armoryengine/CppBridge.py", line 166, in encryptPayload
armoryengine.BIP15x.AEAD_Error: channel is not encrypted

While if I wait for the wallets to populate, it'll continue but but the main Window wont load with error related to your "execution dir".
I can't find a way to set it to a valid directory.
Here's the log:

Code:

2026-05-21 13:11:08 (INFO) -- Settings.py:204 - Using Language: en
2026-05-21 13:11:15 (INFO) -- DlgSetupManager.py:179 - No tested connection - attempting connection on accept
2026-05-21 13:11:15 (INFO) -- DlgSetupManager.py:484 - Initiating DB connection: scenario=Automate ArmoryDB
2026-05-21 13:11:15 (INFO) -- DlgSetupManager.py:504 - Calling automateDb: satoshiPath=C:\Users\<username>\AppData\Roaming\Bitcoin\regtest, dbPath=C:\Users\<username>\AppData\Roaming\Armory\regtest\databases
2026-05-21 13:11:19 (INFO) -- DlgSetupManager.py:514 - automateDb succeeded
2026-05-21 13:11:19 (INFO) -- DlgSetupManager.py:190 - Connection established on accept
2026-05-21 13:11:19 (INFO) -- WalletUtils.py:111 - Loading wallets...
2026-05-21 13:11:19 (INFO) -- WalletUtils.py:120 - Number of wallets read in: 3
2026-05-21 13:11:19 (INFO) -- WalletUtils.py:125 -    Wallet (5S45dFin):    "Cold-Storage_test (Watch)       "   (No Encryption)
2026-05-21 13:11:19 (INFO) -- WalletUtils.py:125 -    Wallet (4bYgV4yc):    "Restored - 4bYgV4yc             "   (Encrypted)
2026-05-21 13:11:19 (INFO) -- WalletUtils.py:125 -    Wallet (Kd88RdHp):    "Kd88RdHp (Watch)                "   (No Encryption)
2026-05-21 13:11:19 (INFO) -- ArmoryQt.py:275 - First load of new version: v0.96.99
2026-05-21 13:11:19 (INFO) -- ArmoryQt.py:1589 - acquiring process mutex...
2026-05-21 13:11:19 (INFO) -- ArmoryQt.py:1785 - Loading settings...
2026-05-21 13:11:19 (INFO) -- ArmoryUtils.py:1127 - Determined that execution dir is: C:\msys64\home\goat\Code\BitcoinArmory
2026-05-21 13:11:19 (ERROR) -- ArmoryUtils.py:1129 - Exec dir C:\msys64\home\goat\Code\BitcoinArmory does not exist!
2026-05-21 13:11:19 (ERROR) -- Traceback (most recent call last):
  File "C:/msys64/mingw64/lib/python3.14/site-packages/freeze_core/initscripts/__startup__.py", line 137, in run
  File "C:/msys64/mingw64/lib/python3.14/site-packages/freeze_core/initscripts/console.py", line 27, in run
  File "ArmoryQt.py", line 5125, in <module>
  File "ArmoryQt.py", line 474, in __init__
  File "ArmoryQt.py", line 815, in loadArmoryModulesNoZip
  File "C:/msys64/home/goat/Code/BitcoinArmory/armoryengine/ArmoryUtils.py", line 1130, in GetExecDir
TypeError: not all arguments converted during string formatting

It's using a fresh database since I've deleted it as suggested (it's just RegTest)
I've also tested manually running Core v 29.0 or letting Armory launch it.

BTW, Bitcoin Core's latest versions (starting v28.0) now default to "local appdata" in Windows if there's no existing datadir in roaming.
It's probably best to check both locations or follow the same method as Core.
Reference: github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-28.0.md

[goatpig]

Please try the following and report back:

1. Try with the offline db option, or spawn ArmoryQt with the explicit --offline flag. You can do that either by starting ArmoryQt.exe from the command line, or by creating a shortcut of ArmoryQt.exe, and adding your cli args to the target field. Do you manage to load/migrate wallets and make it to the lobby? I'm interested in that AEAD error.

2. Try running the db manually. In the "bin" folder of the zip archive, you will find ArmoryDB.exe. Run this manually from the command line, make sure to pass it the necessary arguments. Of note for your setup:

Code:

--regtest (so that it picks the correct network)
--public (so that you can talk to it without setting up a key share)
--satoshi-datadir=*path/to/your/block/data*
--dbdir=*path/to/where/the/db/files/will/build*

Start ArmoryQt, go to the database tab and pick connect to remote. Use the default settings and click connect. It should show you a public key in the "AR1..." format. Check this matches with the public key ArmoryDB displays at startup. Click "Ok" if they match and then accept the settings.

3. Unfortunately, to modify the pathing issue for autodb ill have to start working on the Core tab. FML

[nc50lc]

Please try the following and report back:

1. Try with the offline db option, or spawn ArmoryQt with the explicit --offline flag. You can do that either by starting ArmoryQt.exe from the command line, or by creating a shortcut of ArmoryQt.exe, and adding your cli args to the target field. Do you manage to load/migrate wallets and make it to the lobby? I'm interested in that AEAD error.

Same errors in offline mode.
It's trying to execute in "C:\msys64\home\goat\Code\BitcoinArmory" instead of the directory where I extracted the binary.

2. Try running the db manually. In the "bin" folder of the zip archive, you will find ArmoryDB.exe.

I've tried this yesterday and I can't spawn ArmoryDB, no logs generated in dbLog.txt as well.
It's in "build" folder by the way, or is it hidden somewhere else in lib?

I have no issue doing this in v0.96.5 where armorydb can be spawned via terminal.

[goatpig]

The lib stuff is the frozen python environment, i.e. what let's you run a python script from a .exe. Basically, the .exe is the python runtime (or a wrapper around python.dll) plus a manifest that tells it where to look for the .py scripts. The lib stuff is all the associated python packages needed to run. In Armory's case, it's mostly the pyqt stuff.

It's trying to execute in "C:\msys64\home\goat\Code\BitcoinArmory" instead of the directory where I extracted the binary.

Maybe it has hardcoded that folder to key exchange... Check your Armory datadir, is there a bunch of a files named "keyFile_XXXXXXX"?

It's in "build" folder by the way,

It's in a folder along with CppBridge.exe, on its own. I can't remember if it's bin or build o.o"

I'll setup Windows on my laptop after the weekend and try it out directly.

[nc50lc]

Maybe it has hardcoded that folder to key exchange... Check your Armory datadir, is there a bunch of a files named "keyFile_XXXXXXX"?

Yes but not a bunch, there are only two "keyfile" files inside "/Armory/regtest" folder.
Both sharing the same name and the other one has "-lock" appended to the file name.

Additionally, Armory works after I manually created that path "C:\msys64\home\goat\Code\BitcoinArmory", moved the binaries there and launched it from that dir.
But it's just a workaround.

[goatpig]

This is why 3rd party testing is important. It doesn't matter how often I test stuff on my systems, they're dev environments that are not representative of user setups.

[lunarflash]

Armory crashes when attempting to click Send Bitcoin. Running the 0.97 RC1 - I needed this version as I'm running the latest BitcoinCore and was getting the JSON crash issue running an earlier version of Armory.

I was able to import my wallet from a paper backup successfully and Armory is Online.

Here are my latest logs from armorylog.txt:

2026-05-24 20:57:24 (INFO) -- ArmoryQt.py:4194 - Dashboard switched to "Scanning" mode
2026-05-24 20:57:25 (INFO) -- BDM.py:214 - BDM is ready!
2026-05-24 20:57:27 (ERROR) -- Traceback (most recent call last):
  File "C:/msys64/home/goat/Code/BitcoinArmory/ui/QtExecuteSignal.py", line 44, in methodSlot
  File "ArmoryQt.py", line 4412, in handleCppNotification
  File "ArmoryQt.py", line 2069, in finishLoadBlockchainGUI
  File "ArmoryQt.py", line 2161, in createCombinedLedger
  File "C:/msys64/home/goat/Code/BitcoinArmory/armorymodels.py", line 454, in reset
  File "C:/msys64/home/goat/Code/BitcoinArmory/armoryengine/CppBridge.py", line 631, in getHistoryPageForDelegate
  File "C:/msys64/home/goat/Code/BitcoinArmory/armoryengine/CppBridge.py", line 79, in getVal
Exception: map::at

2026-05-24 20:57:29 (WARNING) -- FeeSelectUI.py:333 - [getFeeByteFromNode] failed with error: generic core RPC error


I also noticed this log error further up:
PermissionError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions


dblog.txt is empty.

Thanks! Let me know if you need anymore info.

[goatpig]

Exception: map::at

It's expecting a transaction in the local db cache that is absent. I'm guessing you managed to sign a tx and tried to broadcast it? In such case, it's possible the tx was broadcasted, the error you're seeing is GUI only.

If you indeed signed a tx, you can extract the raw binary version and feed it to your core instance to broadcast as well. You'll have to use the built in command tab from bitcoin-qt and the "sendrawtransaction" command.

If it's happening earlier, it's failing to build the UTXO set for a specific wallet. If you have multiple of them loaded, try them one at a time. You can uncheck wallets in the setup manager prior to loading the lobby. Check the wallet balance and if the wallet doesn't have too much history, check the individual addresses and double click rows in the main lobby to display individual tx details. Maybe it will crash on the one tx it's missing that way too.

I also noticed this log error further up:
PermissionError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions

Did Windows ask for network permissions for either CppBridge.exe, ArmoryQt.exe or ArmoryDB.exe?

[lunarflash]

Exception: map::at

It's expecting a transaction in the local db cache that is absent. I'm guessing you managed to sign a tx and tried to broadcast it? In such case, it's possible the tx was broadcasted, the error you're seeing is GUI only.

If you indeed signed a tx, you can extract the raw binary version and feed it to your core instance to broadcast as well. You'll have to use the built in command tab from bitcoin-qt and the "sendrawtransaction" command.

If it's happening earlier, it's failing to build the UTXO set for a specific wallet. If you have multiple of them loaded, try them one at a time. You can uncheck wallets in the setup manager prior to loading the lobby. Check the wallet balance and if the wallet doesn't have too much history, check the individual addresses and double click rows in the main lobby to display individual tx details. Maybe it will crash on the one tx it's missing that way too.

I also noticed this log error further up:
PermissionError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions

Did Windows ask for network permissions for either CppBridge.exe, ArmoryQt.exe or ArmoryDB.exe?

So it never loads my transaction history. I have a balance from the super old wallet I'm trying to recover. But the transactions tab shows nothing, and I haven't done any transactions in 7+ years. Restoring from a paper backup.

Windows never asked for any network permissions. I created an empty wallet, and the Send Bitcoin didn't crash the program.

For now I'm re-downloading bitcoin core on an old version (27.1.0) on a spare machine to hopefully recover my wallet and be able to send BTC out.

[nc50lc]

In my attempt to reproduce his Send tab crash issue (which I can't), I stumbled upon these log error lines when sending,
Seem benign but might be important:

Code:

2026-05-26 15:42:09 (ERROR) -- Traceback (most recent call last):
  File "C:/msys64/home/goat/Code/BitcoinArmory/qtdialogs/DlgSettings.py", line 658, in accept
TypeError: '>' not supported between instances of 'str' and 'int'
.
.
.
2026-05-26 15:42:35 (ERROR) -- Traceback (most recent call last):
  File "C:/msys64/home/goat/Code/BitcoinArmory/qtdialogs/DlgSettings.py", line 658, in accept
TypeError: '>' not supported between instances of 'str' and 'int'

8 repeats in total.

The transaction went through though.

Windows never asked for any network permissions.

In my case, it asked for network permission during the first time it's launched.
But I doubt that it's the cause of the crash.

[goatpig]

So it never loads my transaction history. I have a balance from the super old wallet I'm trying to recover. But the transactions tab shows nothing, and I haven't done any transactions in 7+ years. Restoring from a paper backup.

Windows never asked for any network permissions. I created an empty wallet, and the Send Bitcoin didn't crash the program.

Did you try with the automated db or a manual setup? When ArmoryQt.exe is running, before you press send, is there an instance CppBridge.exe running? ArmoryDB.exe?

For now I'm re-downloading bitcoin core on an old version (27.1.0) on a spare machine to hopefully recover my wallet and be able to send BTC out.

New code can handle blockxor, you shouldn't have to downgrade. You have to make sure pruning is off however.

[goatpig]

In my attempt to reproduce his Send tab crash issue (which I can't), I stumbled upon these log error lines when sending,
Seem benign but might be important:

Code:

2026-05-26 15:42:09 (ERROR) -- Traceback (most recent call last):
  File "C:/msys64/home/goat/Code/BitcoinArmory/qtdialogs/DlgSettings.py", line 658, in accept
TypeError: '>' not supported between instances of 'str' and 'int'
.
.
.
2026-05-26 15:42:35 (ERROR) -- Traceback (most recent call last):
  File "C:/msys64/home/goat/Code/BitcoinArmory/qtdialogs/DlgSettings.py", line 658, in accept
TypeError: '>' not supported between instances of 'str' and 'int'

8 repeats in total.

That's the old bitcoind path detection code, it's going to get replaced wholesale once I'm done with the Core tab in setup manager.