goatpig (OP)
Moderator
Legendary

Activity: 4144
Merit: 1410
Armory Developer
|
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.
|