|
Title: Armory on RPI5 Post by: Aethereal on March 19, 2025, 08:48:44 PM Hello again @goatpig,
just because I can, I tried compiling the loading_wallet branch on a Raspberry Pi 5, default Raspi-OS aarch_64. There I could even use a venv to limit the python modules to the development environment. The compile phase went fine, and it actually runs. I was unable to try further at the moment, later I'll try if I can also create a wallet. Due to the size of the SD card I'm using, I can't run bitcoind on it, so I'm limited to --offline testing It's very interesting, if the final release will also work I might consider the option to keep my signing wallet on an SD card (self-contained with OS and Armory) and put it into my Raspberry just when needed, while the Raspberry itself will be used for other purposes (retrogaming mostly) the rest of the time. Now, while I compiled Armory in this other environment, I noticed a couple things that initially I thought were specific of my first environment, but actually happened here too: 1. I used the suggested layout (the three directories on the same tree level) as written in the build instructions, but both times I had to include the explicit path for libbtc and libwebsockets for it to work. It's not a big deal but not consistant with the instructions. 2. Armory asks for libbtc.so.0 at runtime. It is built under libbtc/.libs/libbtc.so.0.0.0 and I have to manually copy it on the BitcoinArmory folder (unless I want to have to put it in some system-wide directory). I wonder how this would work in the final release and if it's correct to move it, since there's no mention of that in the build instructions. 3. There is an error when starting Armory and in the home folder of the user there isn't a .bitcoin folder. A simple empty directory is enough to skip it, but I was wondering if this exception should be handled better, since in offline environments that's very likely to happen. Code: (ERROR) ArmoryUtils.py:1060 - Error getting system details: 4. At first run, there's an error probably due to the wallet list being empty: Code: (ERROR) Traceback (most recent call last): This seems to not happen again on subsequents runs 5. In the wallet creation, after step 3 (validate the password a third time) and step 4 (create backup, that is still not working by the way) some time passes (creating the actual wallet keys I assume) but there's no visual hint about Armory doing anything and it just look freezed until the step 4 dialog appears. I would suggest at least changing the cursor to a "busy" icon to signal the user that the "next" button click was received. Regards Title: Re: Armory on RPI5 Post by: goatpig on March 20, 2025, 09:15:09 AM 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. Title: Re: Armory on RPI5 Post by: goatpig on March 21, 2025, 05:00:44 PM 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
Title: Re: Armory on RPI5 Post by: Aethereal on March 23, 2025, 04:56:33 PM Hello
I tried again, removig the .armory folder to emulate a first run, and this time the error was not present, so maybe it's good now About points 1&2, it was the libbtc that needed to be built as static only, so to be statically linked when creating the cffi pyton library Rather than deleting the files, I preferred to add the --disable-shared So in libbtc build instructions, Code: CFLAGS="-fPIC -g" ./configure --disable-wallet --disable-tools --disable-net Code: CFLAGS="-fPIC -g" ./configure --disable-wallet --disable-tools --disable-net --disable-shared I tried creating a wallet without adding the "extra entropy" trough cards, and this error shown up (the wallet was created ayway) Code: (ERROR) ArmoryQt.py:1114 - Third source of entropy (desktop screenshot) failed I am still having some errors about passphrase not being present when creating the password but the interface marking the wallet as protected. I will wait until the "Click to Test" link in the Wallet Properties dialog will work again to check if it actually used my passphrase or some other value. Have a nice time and hear about you again when you are back Title: Re: Armory on RPI5 Post by: goatpig on March 31, 2025, 09:35:29 AM Quote Maybe it would be useful to update the BitcoinArmory/build_instructions/linux/linux.md file so other would not have the same issue. Updated Quote 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#L1053 Extra entropy through cards is an optional source, manually provided by the user, to assuage the more paranoid types. Quote 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#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. |