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/725autodb 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.
|
|
|
Is there any way to do that in armory? If I right click on the transaction tab to bum fees and select bump fee from the menu just get a blank screen with my wallet ID. Thanks
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.
|
|
|
This is apparently due to the fact in Python 3.12 the parsing of nested quotes was changed (might even say "improved").
Tried a blind fix, should be doing better regardless. The error is kinda obvious. On a side note, I have a problem since your previous commit: If I launch Armory against an old .armory folder I had from a back-up, it doesn't recognize neither the wallet nor the watch-only wallet that there were inside. Since the load digital backup dialog is still not working, I can't try to see if they would work if manually imported. If possible I would like to load the binary backups as they pair the addresses I used with the description I gave them, while restoring a paper backup of course lacks the descriptions.
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.
|
|
|
Actually, that's not really wrong. Assuming at this point the wallet was already created and saved in encrypted form, it's totally legit Armory ask again the password to unlock it if the password was already discarded from memory. I suppose the on-demand "make backup" option will have to ask for the password anyway if done at a later time.
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.
|
|
|
The creation process still throws a warning about "No crontrol passphrase" for the global protection but now the single wallet created is correctly encrypted with the set password.
Updated the verbose to be more specific about what's happening. a- previously created wallet now are listed as not encrypted and the new ones are listed as encrypted in the Available Wallets grid
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. b- when asked to make a paper backup during the creation phase, I'm asked again (for a fouth time) the password to unlock it
Will fix. he wizard window is enlarged to accomodate the card pictures
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. When creating a new wallet, hitting the "print" button during the "print single sheer paper backup" phase throws an error
Ah, I completely ignored that, we'll see what I can do. Since the wallet property window buttons aren't yet working, I couldn't test if the error is specific to the creation flow or is present also on on-demand wallet backup.
Next commit will add unlock testing, should be within the hour of writing this.
|
|
|
What version of Armory are you using?
|
|
|
Maybe it would be useful to update the BitcoinArmory/build_instructions/linux/linux.md file so other would not have the same issue.
Updated I tried creating a wallet without adding the "extra entropy" trough cards, and this error shown up (the wallet was created ayway)
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#L1053Extra entropy through cards is an optional source, manually provided by the user, to assuage the more paranoid types. I am still having some errors about passphrase not being present when creating the password but the interface marking the wallet as protected.
This is another false negative. You're running into this: https://github.com/goatpig/BitcoinArmory/blob/loading_wallets/cppForSwig/Wallets/WalletFileInterface.cpp#L431The 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/720Long 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. But if I close it and then open it again, it doesn't throw errors anymore and instead the watch-only wallet appears correctly in the wallets window.
Means the WO was migrated correctly but the load sequence blow up. I hope to have been helpful.
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. Since the strange error, I wanted to try if the password I entered was correctly applied, so I opened the wallet properties page and clicked the "Click to Test" under "Unlock Time:" but I got the following error:
This feature needs the full capnp and bridge support, will take a bit longer to address.
|
|
|
setMinimumWidth setMinimumHeight setMinimumSize setMaximumWidth setMaximumHeight setMaximumSize QSize
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. First test, I tried to create a new wallet. I checked the flag for creating additional entropy, and got the dialog for the selection of the shuffled cards. All the boxes are black, so I just randomly clicked some until I got enough entropy and went on. I got this errror:
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. This might relatedto the previous though, since a wallet wan't actually created.
Haven't tried restore from the wizard, will check. Later, I tried restoring a paper backup I had. It's a 1.35c plain one. The restoring process was apparently successful, but even if I set a password on the walled when required (and confirmig it the third time) I got this error on console:
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. capnproto python-pycapnp python-distro python-cffi python-setuptools python-qtpy python-lmdb
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.
|
|
|
|