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

As for the python versions:
- 3.13 doesnt work cause capnp chokes
- 3.12 I target using pyenv and a venv
- I can target 3.11 and just work off of that tbf. Python will be frozen for the Windows release but I don't know if that's kosher for Linux packages.

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?

Updated


This is a false negative error. ArmoryQt will always try to grab extra entropy from sources to mix with the PRNG pull at wallet creation. One of them is a screenshot of the desktop, and I guess the syntax has changed in qtpy to accommodate for various Qt versions, which is what you're running into. You can look at the code here:

https://github.com/goatpig/BitcoinArmory/blob/loading_wallets/ArmoryQt.py#L1053

Extra entropy through cards is an optional source, manually provided by the user, to assuage the more paranoid types.


This is another false negative. You're running into this: https://github.com/goatpig/BitcoinArmory/blob/loading_wallets/cppForSwig/Wallets/WalletFileInterface.cpp#L431

The wallet code has lived in ArmoryQt.py all the way to 0.96.5. When migrating from py2 to py3 for 0.97, all the mission critical cryptography has been removed from python and reimplemented CppBridge. The legacy wallet format has been discarded in the process. CppBridge can read the legacy format but uses a brand new format.

The new format comes with 2 layers of encryption:
 - the usual direct encryption of private assets (private keys, seed/root). This uses the passphrase you're familiar with.
 - encryption of all assets in the wallet. This is called the control encryption layer and uses a secondary passphrase: the control passphrase. You can choose to set it at wallet creation. You can also change it throughout the wallet's lifetime. There is currently no GUI to set/provide this passphrase, but that's in the tubes.

Control and private passphrases are different. You have to provide the private passphrase every time you sign a tx or reveal private keys/seed/root. Control passphrase is provided once at wallet load (once per ArmoryQt run). At wallet creation time, the private passphrase is mandatory, the control passphrase is optional. This is enforced in GUI, not in the actual wallet code. The control encryption is always applied however. If you do not provide a control passphrase, the wallet uses a default key written in clear text on file instead. This prevents code divergence.

The control encryption layer has 2 uses: it acts as an implicit file integrity check, and if you provide a passphrase, hides all wallet public data from interlopers.
At the moment, you can toy with this feature via ArmoryDB. It uses a special wallet to track client public keys. This wallet only has a control passphrase. You can toy with that wallet by running ArmoryDB manually, or via the BIP150KeyManager cli tool. ArmoryDB uses this special wallet as its key store for client authentication.

Most likely you are running into this issue: https://github.com/goatpig/BitcoinArmory/issues/720

Long story short, Core 0.28+ went from JSON 1.0 to JSON 2.0 and that bricks the RPC code in ArmoryDB. Simplest solution is to downgrade to Core 0.27, hard solution is to try and build your own DB binary following the updated instructions from that issue's contributor.

Long term solution is 0.97. Build system is too busted to generate a new release for 0.96.x

What's the content of your bitcoin.conf?

Pushed some changes that should fix issue #4. I don't think I can come up with a fix for the rest before I have to leave. Stay tuned in April I guess =D

1 & 2: LWS is building both static and dynamic libs, or only dynamic, and libtool is picking that up when linking armory binaries. Try to set LWS to only build static libs, or delete the .so from the LWS build folder (assuming the .a is present), and try to link again.

3: figures it would fail aggressively there of all places...

4. this is a SNAFU from one of my recent big commits, haven't caught everywhere this code gets replaced

5. that's what I was working on before I got side tracked by DB issues. Next set of commits should address this. I've implemented the progress callback for wallet creation, was about to write tests for it then got side tracked again. I'm going to visit my brother for a week this sunday, hopefully I can push that stuff before I leave.

Ah right, I completely ignored the digital backups part. Still working the db fix, should be done before the weekend, then I'll get to this.


Means the WO was migrated correctly but the load sequence blow up.


It's very helpful and very welcomed. Thank you.

I've fixed a few things, it should run a bit smoother on your end. I've ran into a db issue along the way so i gotta focus that for now.


This feature needs the full capnp and bridge support, will take a bit longer to address.

I've reviewed some of those call and there are many instances where they're already casted to int. I'll go over all this stuff over the weekend.


Ah figures, I didn't try with extra entropy. Thanks for the report. I have yet to figure out why pictures aren't loading, will get around to it.


Haven't tried restore from the wizard, will check.


Process is a bit wonky atm, it doesn't correctly detect whether it's offline or not. You have to explicitly feed it the --offline arg for now.

This is super weird. Looking at the pyside6 documentation, resizeSection only accepts int, so casting down to int is correct, but this code is almost 10y old and has never failed, be it in py2 or py3, across windows, mac and linux. I don't quite understand why it would start failing now. I'm going to assume it has something to do with your system locale? That's the only thing I can think of.

There are only 2 instances of resizeSection in the source, so I've added the int cast and it seems to work just fine.


Looks like you're installing these package as system libs via pacman. I'd suggest setting up a venv and installing python packages via pip, this lets you isolate the python environment from your actual system.

You do not need python-lmdb, it isn't used on the python side at all. I'm going to assume that helped you cause it most likely depends on system lmdb, which was installed along.

1. You should try the current bleeding edge branch: https://github.com/goatpig/BitcoinArmory/tree/loading_wallets
A lot easier for me to help you there, also a much better base if you want to PR fixes.

2. There are "up to date" build instructions for linux: https://github.com/goatpig/BitcoinArmory/blob/loading_wallets/build_instructions/linux/linux.md
My system runs py3.13.2, for which pycapnp fails to build, so I use a venv with py3.12.8 to run Armory

3. I'm not sure what you mean by the type cast. I have not run any of this on python <3.10, I don't think I've run into the issue you mention ever. Also what version of qt are you using? ArmoryQt uses qtpy now, so it can run against pyqt/pysides somewhat seamlessly. I do my development vs pysides6.