|
I had a pretty awful 2022 so far, didn't have a lot of time to work on Armory. The dev branch is running on py3/qt5 but it's not really user friendly yet. I have to wrap that part up and it's ready for release.
|
|
|
|
I have paper backups and an encrypted wallet.dat file that I know the password to.
Unless you had coins in an bitcoin-core wallet, wallet.dat is not useful. Willing to pay a telegram buddy to walk me through buying the right type of machine, setting up, etc. I have tried several times over the last 12 months and cant get it.
Simplest OS to setup for Armory is Windows. Most reliable one is Linux. Stay away from Macs. For Windows, anything that runs Windows 7 and newer will work (please don't get something as old as Win7 though). For Linux, aim for Ubuntu 18.04 LTS. You will need a 1TB drive ideally, You may get away with only 500GB (will be tight). Laptops are fine if it's all you have access to. |
|
|
|
|
Armory reads block data from the files generated by Bitcoin Core. If you start Armory without Core running, it will see the blockchain up to the last time Core ran. To bootstrap your ArmoryDB, it's fine to start it without Core running, but for proper operations, Core will have to run too.
The PyQt issue you mentioned earlier is related to your Python install. That's where the Mac nastyness starts and my expertise ends.
As for the progress of chain scanning, you should run ArmoryDB manually and read progress in the terminal the first time around. That way you can figure out if it's the DB that's stuck or the GUI that's not picking up on progress updates. Once the database is ready, you can let ArmoryQt handle that in the background.
|
|
|
|
The only non-standard thing (that was a recommended solution) is I am using a sym link from /Users/billd/Library/Application Support/Bitcoin/ to an external SSD due to the space requirements of Bitcoin Core. The log error leads me to believe that Armory is seeing the blocks but for some reason can not create the BlockDataMap Huh
symlinks typically do not allow for mmap'ing the drive into memory, which is how Armory accesses the on-disk data. You should try point Armory to the drive directly instead. In your specific case, since ArmoryDB can't setup, you should work directly with it (it's a binary found in the build folder), instead of going through the GUI for automation. It will make the troubleshooting easier. In your case, I'd open the terminal and run something like this: ArmoryDB --satoshi-datadir=/path/to/bitcoind/blockchain/data --dbdir=/where/the/armory/db/is/written
Obvioulsy set the relevant paths, just don't use symlinks/ln, point ArmoryDB to the actual data. |
|
|
|
|
Armory backup codes carry 4 bytes of the hash256 per line. Basically, there's a tiny chance you will type in a backup code with an undetected typo. This doesn't mean the resulting wallet has funds in it (i.e. belongs to someone else). That will realistically never happen.
|
|
|
|
pub rsa4096 2015-11-22 [SC]
745D 707F BA53 968B DF63 AA8D 8C52 1176 4922 589A
uid [ unknown] goatpig (Offline signing key for Armory releases) <moothecowlord@gmail.com>
This is my offline signing key's fingerprint. The short hand fingerprints you are finding either show the last 2 or the last 4 hexit packets of the full fingerprint -----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBFZRUpgBEADN/akS+sMnPqG4VigcipiLUmdQIElf2Uj1KTIgR21ifR0xT1Ed
dPtUTIxxeHAYZQN1yanrmtBJmR6NeF7qkROJ4mAisLzrtW/UaIj868fnQv0y+mbc
VGg+NP947E8pRF368cN0RJELDOrKmY2lfyZ5ueq/gC04jFHBgjYfaqEIu8sd16nA
C5ir0ilNGV+FvXjP4BP3fZghTM4y2d69mA+VN4DKBbZce7BVl586ODKUU8flvrsA
N8uDmomIF+DVjPiH/+t0KOizLy8NxoLdzGpJOSktUQF0vhW9EwBkpGp9vVh8PUPU
WjI6orjyoAGQRQvD/oZu4iZCXXNRSHouMMClo9JoZlfbkplZ4EYXJZIlAYpUGolj
YoWf9I4GQHCn3nqcoG7E7u6u+2+thiTQG0QxTl7VE+cnlBAsPg1D86WhPzWzHueA
lvtwlChLCXlZifJFi7MlD3+ijg8o3V8qWMm+cwKJDR8gOvJ0AZ9t11TLPb15o63d
QKcDd++FAc1etCazZnvPH8pjo0+0FZtd870JRkCn9N8yqxlWccCmjaS1hbgYZd1W
8T8rtKDLCW0isZzzB74SpaHiMlcQOlIz2K6WGHqb6Fr2evpzX80LjqANaGXjjEJy
U7HYcT9ffOxm7Idisj6QbW5Y9s135YYg+LR55N/P3cm2FWg09IHVZjd/FwARAQAB
tEtnb2F0cGlnIChPZmZsaW5lIHNpZ25pbmcga2V5IGZvciBBcm1vcnkgcmVsZWFz
ZXMpIDxtb290aGVjb3dsb3JkQGdtYWlsLmNvbT6JAjgEEwECACIFAlZRUpgCGwMG
CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIxSEXZJIliadfIQAKsqhFZ3TyXs
u6M0iu6TMYzXcLhRclzxF3i6gsBk2QOn0/d4AOImuPj1lP2BwlH2WuMuej5ZcnJ7
s6xpDNi85AIO5ffq87P6PyX4uCp4mZKD/W9OGhHRBwwEwh3YeyN5nosDQS0kY2hR
Z8nidzIk2mtyeHBgV6jZlG+g3VkzXymmQ5TNMb1syL+MrNlZPnoFdaYW2xtwF8hB
CANry9JaN+F4sKLdewysegQBodkwQyepOsPlavJ+2I3bd0qqSKGmT3rrGmVGzm5g
h3TBHFJl6LAeqrxAegRnpcOnUrxphfnlT8pg7VLkj8lns2MmaZ9t8naQBAvOcGxp
LlXb7U+S04/fxde3TjFSd1WoK0c+XxBfc1p4w47pWaQ0pgQ4d13vuO8/XmqeUXxW
LnWR7Q9eNyPcEqwrRlI5RYAjHGJsYpWvkDx3WYLWMgCD57j9vU/40YX2BPxpKhbN
sngBMfToC49AHI4RDn9+Mc9PrhAjiB+DldTO3zFuJuBMd1EMUmr479i0y5/kzZFt
+Q2Kebyn8I1IVEXvrkQ4gfRiWKAhtOHQGvmviqGEyAhjrKYLRRJWWONbX6P1JC7/
l3L3cnu6PXMGS7XuaqhJqaslpmQrS1h9cMN4uCiUNmERgjQbbUOblzZhhGzeH5+Q
0zAMTm3hJr8ZYJXGRtrAiTAUSVhjJ/eXiQEcBBABCAAGBQJXICPTAAoJEL00DjdN
HMgQXncH/js8G6cqHau6XsZYVLi9hwvWVXuELss+CDjXW4EdiYQ9PHz/O7Zg/UHd
16rMuHNynS6+G144Ft3jqDWBLF27sziEAcOE9AN4kPEeNqw9la7ieyT9Bv6T39Z/
0Q9iZ/DPaZwNvm2CpE5R74o55cXKOFFqsMAkyANJ3DPcqedAWdllrPQvk2Y50bTd
3qoXLrSgUzuE9STXR47ulplF5SURMm9YEF2BCxkahgDSxpBOFNvMP/1QfAcm4Z7l
u2gvsPPCG9LCl0b6jWZTHdunpgvSEcH8I8cBBjHAWuHUKFvk/s+rJBCMQH6Oxs6f
YoF2HQYSQg68deNhTl6m70L8n9cxm+OJARwEEAEIAAYFAldU8XEACgkQo/9aebCR
iCTLoAgAl20DxjVIqxFfE0nXWmgk8l/N/VHmcWlt0nmwccTo3kll+/TlYyKwnDf2
u43jnZOJrJPFnqZ0Ycv8DjstsDdpxEZ5VfDi7FsRqcbQId9ADCprBZXP2KQuNu/c
jMF559V9DdJtBTpnRcUeZZZ2j8tcGpI08Ph6a5Tg3MP23N/ODrsv2CiCYZfbJpBc
jDijTp1Vk2MaUoiCT2tCcg35q+iWzLqu/iu5bzb1z+/72X0q8t8sarwvlsx0drWV
NbvnpDSNVe799GCpUxGJMfTGl2xmN/FuJJYyGJ3MpqPidh7vAszlD4iY1LN8dywg
tj8qC1WBBORDtCARI2XEkjWZY1hJlokCHAQQAQgABgUCV0SvqgAKCRACeCH/exz+
xpB4EACoyDmADNIMQJBbeYYey/aVtC1eyjXaA/kRVxpQWc8XX4pzbnDw0IBHicIt
L8oSyrf8Qf0di+x+BMD+0OKNN7OLQr3T2BPJEs73KRoUnUrjaT0ryBrp3jZ/05Xw
voNNekVtEe7oyOVBbkbGOwgneyMqUEGej4UC1eEcjkh4848ti0Wqkfc4gUzEc7wV
9qYz7kGhyDYUaqnIEMhNHebU1L3YW8OKDAFW90ihkTF6T6UIOrC+w1hgtT+GsECO
K1LAMTb4Uk/I1K6sVo9AbaFTr6S+P7936By0UE58y9fDmFQ0yyUFovuUoAkC7kpb
UBCUxYcGpQ9atezoce5mgoJls/2JQBRS8pFrnWxrCeMJINPzWItxDU4kMaHxtVV6
aqFEyc3j4h7ZdSjdAPidS+36NB9HF5nmtwcN+UaZ2I0x81XIpCSCl3be9uiDIrQQ
uqaXQv7NeWX6ruTpUaC3G8p/jtmg8B7ryD9uK8gW9mBHO9iGySu/NDh+ZY9Dlj4I
B0PquuNj6eRXgzGSiCytTqqaS0yRFUzJuxnVry+Dpx6Xc94Ujd482xBTBYz/VyzP
PPCT3eKILRPh7juM8PBv2NRe0g80gHIyZkGD3zZ1qCobwUJFOQWVMKX/wDCscJjF
Bzytv8AriryniaPw8nQ08ifsVsMgXXtx9IKr00L6am7rAUciD4kCHAQQAQgABgUC
V2M6hQAKCRBi2lJ29X08OhbAD/4zpHeex0ckxalhmJ7xEvHdOtCLWL220+fK6aEl
y6/ae9FE8DvtnWZpQaKeD0/znWU2ksnqVg6jHkh0OhgsE+ZxLwoGgIt2KOUkEccF
ETFX24rbVM/LR8vCL5SfI+muoyqcBCWiM8c+2W8BOxQV0K9w2dCChDwVVQU8TpgU
lOQGhgc9BBnxaO0JVDXD3YWXdVxI2gvGOtLRfZ7rFx7H7fPrjXNvT/Z/cNEtYM+1
C23O/rJW0x3Y+L1YUTu3FETQUq6GwKUs9XlQ6yhgluG4T2/RXZFGHf8G24qZpZl2
+k1wxtReplKRjN2kKH9D3CWlfxjxjzkl8tEjlXwT/K5EA5eNdY/Vu8CXmJ+gQLzb
FpQnljBBI9ttoQnH7FK1dXktxA2L7fdl9U9HUWKHPg8IrH8aA8TLlDIYMi1iJvWZ
piqDAH8ZUUP1N8UrzdtfK9lfXyV4+JYD5b/bvA1nxSJIsAxCdytKLGGYmhRK62qX
GJ2VKreocSA5pKTeQdz4/PLeaMj0EprmmEwu4f+JKD0HOWCHVKncrkpclDIsPbxB
yfcXnXOA2rkkH3EMOPvMGdiuQZnY3s+k2nfyVqSICHZaCQLFijdILIHncDDTvXjI
MP0WYZwFWukFRl0vwunKR1AbCv72HXZHKJKCXTMlwblb3ve+ErKxwrPFD4bU3Tm8
pideUYkBHAQQAQIABgUCWXs04QAKCRB/AiD48Q3xA69ACACaFHjl1us4S8PWs0aT
B3wuHacBbfLgO6sltpRnXYErHJzHZ14nK1pVGkMJjydddMLe++qI9b57qt4k3e7I
q64+M8ke5zKrHV3vr04xryVixS+4MgOz3FfiYY7RVzz6ZY/NgjCUeGQRIlGWIzmD
qVD4C42eCLYh4+/XchuhRYh5m4LMZfnL24dDAU6QD/4zQNmnSfd4GBmX5WRPmJOJ
vBPme5Ir0AS1DHw2FQ1XIH1lJcthkKA36V9tkyUXy4zN/m93ONCEM12BOrRu8l/k
gjBL6M4YjG7H6Ac2rlZFZbAJBOI7xRidkl+RCgfcaQOX2hLIC6n3uOCIUkO/TRuE
29aRiQIcBBABAgAGBQJam5eyAAoJEK0biQkblwbooBQP/1++zNtNOisaNsXkuGlQ
xtg2Oye6GUIEILBOZ09tcHkgl5UTCdmg5NeI3P5g+E5IJkgaOmagrUx/dCWFzVHX
Z5vS1Llyx0YFgyLqCCBjgSwon3qi9FWzvm6noTyY81ftmgxJS+0MUB8wttIO65Hr
vcD8d2XlFgB09rVsKWLZeMeP/kQI1oVspGYTeANO3xcLlDj3pXlSyZsoULstTLm6
8Kf+S+Qp95REFVFeqWCT1Tl04OppuyfCF9624LKhsja5EsUF1DzX13zkYmuljn0O
5Or5NBQwWUFQVPMet5OdvKydkzhw8lq9MCgHLKcv3nJLRPezEIRfwQDnZxrwvivw
kVU13F6WTPxvLc4l+TtsA7lagKjMUCDVnISpk6MFXyLry88dnT5RhREdWXgk9ry7
gHgsdxkQ564IQG1GgqblgzUB/4DhKSRqlTvSN5kg1Y6BtdVO+e2uxBLoGKnVWemt
MsgpAWHnmFUBtlwJzDISVeRlRMiJaTz2dbXFW0NSK7L1LQBjH4hbdBdFIQLUwIY4
fAJYkr6b1Dyf/172lXX5H+3ZwOAlEG6mnGZrVQWpXYSaTyn2yKosdK2wHCk0oGxV
9SRZRSi7L7aKMST6fJxc/uvF2kUgY1MKsWpa0XqOkkzw7hpRF1v/9pBfU1FSbmGb
EIA42p8eQRf7zvD0ExccgdLiiQEzBBABCAAdFiEEcDSnqhxCC9+KsldSIh4BWJIH
xdMFAlriC9cACgkQIh4BWJIHxdOuHwf/St38MSxYu70xfAUGFvjQWDuh4uenOMB5
EVBUxixJ3E1L3REGiu4dDJQqCZ+QIh7BZ5ZP7tsMbr5d/F+tziex66NgdoL6nIBl
Tv5ktubejdrwBUmVf/Fam1ep1fHU2NSPJUB9BZX4dE+BRQKSgJSPSoPZYrfSDFBh
S29ZPlukc0RlSlUF0VNtZGz4rdnBPZchkVGruEP5qcdTCIqzP1tKSsUm40rMs/YX
p/SObbABkKLd1PmGtut497yFLo+DogYxzeiR0UES0Q0/KuwqASRBJNGb2f0N7iV5
EtKYEthkEvfwdzsnhFMdSSrApYSS1rKTj90FIGrJonA56SLCjBXpI4kBSgQQAQgA
NBYhBDn4fkxfbpHorxzLznDPh0hJSdCABQJeBAGiFhSAAAAAAA0AAHJlbUBnbnVw
Zy5vcmcACgkQcM+HSElJ0ID11QgAvi5zMK3W50mGCLIgIlHvF4NOxkz0zWMdTyOL
aCmTmHf6FZ3FmGk3KPH8+8UmGZ797v94p92EBVcIRjX/GYiTmAC7ZtPFp04m2hgp
MQSx+LYeByBbDEKVYqi+pSEVbOzKHVqTunaW2kOZ7mXDuvdXYjwTbFS9H0K2JmAV
So7Zt4es0hFA2E20r8SKEL4b45B52ZG49MwoZEG9KD9ZY0pLEs+TAcOirzRnajHo
eNXTwWwa5NuoHSxZy6TMUm36T6dDkYbsiTxfAgxCnJzx1nIgBwGDUQYxgyQiPuAX
MGWoGui3z20CYHllwxGkSp1iIkMzHXvQ6W+o22pAl6DG0NFXnokBSgQQAQgANBYh
BDn4fkxfbpHorxzLznDPh0hJSdCABQJeBLJvFhSAAAAAAA0AAHJlbUBnbnVwZy5v
cmcACgkQcM+HSElJ0IBz1ggAjRw0Ap4dorO/wkMKx7qp0nyUKd4rI06PkVEmv/uQ
A1AQbNv8Boh9VdXprcWEYg8NAMa9QHpWXTmVaswQXpZtXCycpbk+U2M4wyteUR5R
RmUAt3D+b6buLyB4q/y0RjLUhf63M2JfVbaZDp236QdRJYVhhPeDg4IrXCLd6r2g
/qNSJHwZLNo2Cn8tMmf4dxoiuuDs1cNjagbf9gDqh0cJheN9LcQsdQARRjjdcHIi
LbMN6YENxwhEiIF6x+ZCu+y2wFSOid3LhVza6LoPmhS+bPRbvErmaIL2NwaaqsGT
WUFDmBk8qJbAzbhtw3qpnru3eo0D++rhDa7UfcZgekTcvYkBSgQQAQgANBYhBDn4
fkxfbpHorxzLznDPh0hJSdCABQJeBLKKFhSAAAAAAA0AAHJlbUBnbnVwZy5vcmcA
CgkQcM+HSElJ0IDoeQf/cUzd0Bgr3msVlc/FYBDPobWOYAwsTjTv95APDVvspcVR
gjz/bNoC/SolmDPs88AS1RqXkhSoO9jFokzqjwNeNDz/XfDtXNT7vWsPdLY0UpJx
glq/eYsWq+w+PJ5gGHEiafhbotQB9mh75SggWljjAURV+oaVn+AtUJsFYpfojZYK
BtbNUfJXvs57bzPJ25HQY0dTCbJ6dkiL0oDTNCWxzVWPBz+2Xii4GtyyVVxnf+9s
DLxmsHLWBKSMlZ9vjoay0MD0U4kZ2+2tcv4u1UqNdnTiuYKStmhUNe/memzcYSPg
MeVExGd09GdQsNwKtcFL9kzwZ0FpfbIvzMUWuc3+Gw==
=MOxo
-----END PGP PUBLIC KEY BLOCK-----
This is the key itself, with some sigs added |
|
|
|
|
You should really use GPG from the terminal instead of a GUI solution. The signature process for Armory is the same as Core: save the sha256sum for each package to a text file, then sign that file. Therefor to verify the package, you have to do things:
- Check the packages sha256sum matches the one in the hash file (for the same name). This is as simple as running `sha256sum *package filename*` in the terminal/powershell and comparing with the entry in the hash file for the same file name.
- Check the signature on the hash file is valid. For you can run `gpg verify *hash filename*`. If you have public key in your keystore, it should tell you the sig is valid.
|
|
|
|
Is there any way to run it on macOS Monterey 12.2.1 (21D62)?
Unlikely 0.96.5 would run on a recent macOS |
|
|
|
1. Haven't imported a wallet with private keys in a while, time to retest it I guess. 2. How old is your DB? Current code received a set of fixes for txfilters vs what 0.96.5 puts out. Did you setup from scratch or used an existing db state? 3. I forgot this button even existed o.o', will fix Thanks for the report. It seems like porting to a different Qt version/lib was pretty clean in terms of outcome, so that's something. The dashboard wallet scan animation was always a little "janky" under Xen, so some gui bugs are already fixed!
There are some minor syntax changes from Qt5 to Qt4, but its essentially the same lib. I was surprised how little impact the migration had on looks. I was expecting a struggle just to port it and then end up with botched dialogs. Py2 to Py3 was a lot more disruptive in the end. |
|
|
|
I can't see how it makes sense to scan the blocks for transactions in that case, but that happened, and all was well. Sadly, there was no surprise BTC   Failure on my part, "isNew" flag not being propagated correctly I expect. It seems there are methods in cppforswig/BridgeAPI/WalletManager to convert the 0.96.x format to the new one? Can I call them somehow, or is there no userspace interface yet?
CppBridge loads all wallets in the datadir and converts them to the new format on the fly. Old wallet files are ignored past that point. Those wallets that carry encrypted private keys will lead to a prompt in GUI to unlock them. The same password used to unlock them will be used to encrypt the new file. There is no client facing API to call the conversion code directly. It is all baked into loadWallets ( https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/BridgeAPI/WalletManager.cpp#L199). It will be part of the last major new piece of GUI I need to implement. I want to add a settings dialog that precedes ArmoryQt itself to do a few things: --------- - Wallets: need a tab that lists all wallets found in the data dir and offer users the choice to convert. I don't like the tacit conversion but it was a cheap solution at the time. I'm very bad at GUI development =D. Also need to offer the option to unlock wallets. The new wallet container encrypts public data with a different passphrase. This is set to a cleartext key by default, but with some minor GUI at wallet creation time, users can have the option to set a passphrase of their own choosing. With fully encrypted wallets, users need unlock the public data prior to loading Armory itself. I could have gone with a simple message box prompt but that would get very obnoxious with more than 2-3 wallets loading. --------- - AEAD key management: CppBridge couldn't talk to ArmoryDB because ArmoryDB wasn't set to --public. All sockets are encrypted now (this means from ArmoryDB to CppBridge and from CppBridge to ArmoryQt). The AEAD allows both 1-way auth (client authenticates the server) and 2-way auth (server authenticates the client back). It defaults to 2-way, meaning ArmoryDB's key vault needs to know of CppBridge's key prior to the connection. As for ArmoryDB's key, if it's missing from CppBridge's vault, the user should be prompted to accept the key, but since I'm lazy, I defaulted the accept to true instead of writing a prompt ( https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/BridgeAPI/CppBridge.cpp#L324). Since ArmoryQt spawns CppBridge, adhoc keys are setup every run, and discarded after use.I haven't looked at automating ArmoryDB yet, so you're left running it yourself. As it is missing the keys in its vault, it will reject all clients, unless you run it with --public (accept all clients). The 1-way and 2-way handshakes are incompatible on purpose, there is no downgrading of a 2-way handshake to 1-way for convenience purposes. There's a command prompt tool to manage keys, aptly dubbed "KeyManager" (I'm good with names 'n stuff) -> https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/KeyManager.cppThis needs some GUI around it, considering it isn't just for your local instances, but remote ones as well (considering running a supernode for those people who can't get fullnode Armory up locally, just so they can move their coins out). With 2-way auth, you can actually manage who gets in a WAN exposed DB and/or CppBridge. This tab will also be a good place to manage IPs for remote DB/Bridge. The bridge handles all things wallets, ArmoryQt is more or less a dumb interface now, so you could run CppBridge in say a Docker container and plug ArmoryQt to it from somewhere else. --------- - DB/Core management: Need some GUI for people to discover block/db paths to ease the pain around initial setup. Also a place to reintroduce the settings for Core and DB automation. It's a lot harder to make the bootstrap consistent if ArmoryQt starts before the DB or Core. It's simpler to assume these pieces of software have to run before ArmoryQt is up and handle the complexity in this new pre-start dialog. |
|
|
|
|
There is no official packages for pacman/pamac. I don't know who made the AUR package. I do know it wasn't anyone officially involved with Armory. Take that for what it's worth.
Since Armory 0.96.5 needs py2 and qt4, you are unlikely to get it to run on Manjaro without installing those old packages. Maybe there's a solution with pipenv? Otherwise you could try and build the py3/qt5 version. I recently added backwards compatible unsigned transactions, so you can create the tx with modern Armory and sign it with your old offline setup.
|
|
|
|
ok, so I finally have the dev branch in some kind of working state (real life + building problems intervened before) one problem persists, namely that I cannot get the CppBridge to launch ArmoryDB in latest dev branch. No clue whether this is because it's broken or just that I did something wrong. ArmoryDB works fine on it's own, but launching ArmoryQt.py once ArmoryDB is started/synced does not create the bridge connection. Yes, I re-ran the c20p1305_cffi.py script. And also make clean. Not in that order  Try running ArmoryDB with --public |
|
|
|
|
1. What version of Debian?
2. Do *NOT* run Armory with root privileges. You should not run it with sudo. Just dont.
3. What version of python is installed on your system?
|
|
|
|
To have a chance of running Armory 0.96.5 on a M1 mac, you'd have to build from source on your machine. This requires installing the build tools and dependencies, the most unstable of which ought to be SWIG 3.x. Even then, Armory uses Python2 and Qt4, both of which have been EOL for a few years now. Qt4 support notably has been dismal on macOS ever since 2015. Your best bet is to run a Ubuntu 18.04 VM on your mac and run Armory from within that. If you are nonetheless adventurous, you can try building the new Armory code from source in the dev branch ( https://github.com/goatpig/BitcoinArmory/tree/dev). This uses Py3 and Qt5 so it should run fairly easily on your mac as long as you find a M1 compatible version of clang or gcc to build the C++ code with. |
|
|
|
|
There are no versions of Armory built for the M1 processor. I don't think you can get it to work on these processors without A LOT of nix-fu.
|
|
|
|
|
Works for me. Thanks for the help.
|
|
|
|
Reviewed the full changeset, here are my comments: ######################
## review comments
ui/MultiSigDialogs.py:
HighPrioTODO and some commented lines are in infraction of python indent
rules. This code will not run as a result (intentional?)
qtdialogs/qtdefines.py:
STRETCH as seen in qtdialogs.py has been redefined in qtdefines.py.
Files importing STRETCH still look for it in qtdialogs.py (mostly). It
should be imported from qtdefines.py only and STRETCH should be removed
from qtdialogs.py (it makes more sense in qtdefines)
qtdialogs/ArmoryDialog.py:
qtdialogs/DlgHelpAbout.py:
qtdialogs/MsgBoxWithDNAA.py:
Hardcoded path to images in the root img folder is invalid
(i.e ./img/MsgBox_info48.pgn). These paths are probably invalid now that
the files live one folder deeper (should be ../img instead, I suspect)
qtdialogs/MsgBoxCustom.py:
Same image pathing issue as with MsgBoxWithDNAA.
Also, the file uses the old connect/SIGNAL syntax which is invalid in
pyside2, e.g:
self.connect(btnOk, SIGNAL('clicked()'), self.accept)
it should be
btnOk.clicked.connect(self.accept)
qtdialogs/DlgWltRecoverWallet.py:
qtdialogs/DlgCorruptWallet.py:
These dialogs are deprecated, new wallets do not make use of it. Shouldn't
spend time fixing these. There is no cause to remove them however, they're
not imported anywhere. May revive this stuff later but the whole functionality
is obsolete due to how the new wallet files work: they're fully encrypted,
with MACs, so file corruptions will always be detected natively instead of
potentially altering wallet data silently.
qtdialogs/DlgSettings.py:
This dialog is super broken and will take a lot of work to fix besides
the pyside2 migration stuff. I'm thinking of removing those features in
there that are broken and reimplementing them in the "manager" dialog
instead of fixing them in place. Shouldn't spend time on this code as
a result.
qtdialogs/RestoreWOData.py:
This dialog requires a decent amount of time to work with both Armory
legacy wallets and BIP32 wallets. The new wallet format also allows for
exporting the wallet structure and meta data (all data that isn't private
keys), as well as encrypt that data for transit, so all things related to
WO and meta data import/export will need a UX rework.
qtdialogs/DlgRestoreSingle.py:
The stuff that applies to RestoreWOData applies to wallet restore in
general. Put another way, time shouldn't be spent trying to simply fix
these dialogs, that effort will be lost when reworking the restore
dialogs to fit the new wallet functionalities.
qtdialogs/DlgRestoreFragged.py:
Same as above. The SSS code is dead atm anyways so this feature is nowhere
near funcitonal.
qtdialogs/DlgPasswd3.py:
Invalid img path.
Invalid connect/SIGNAL syntax.
qtdialogs/DlgInflatedQR.py:
Missing a few imports.
dynamicImport.py:
Depreacted file used to load plugins, a feature that was never really
fleshed out. Ignore.
jasvet.py:
Python implementation of the Bitcoin message signing protocol. Unsafe and
deprecated for signing, only used for verifying signatures. Should be fully
replaced with calls to CppBridge.
pytest/*.py:
The python tests are deprecated. A few of them can be revived but over
95% of what they cover has been moved to CppBridge. Coverage only
really make sense for CppBridge now. The python client is now a dumb UI
that does not implement any core logic, only GUI elements. CppBridge is
an API process that communicates via protobuf, so it's pretty easy to
flesh out a headless test suite for it instead.
qtdialogs/.pylintrc
This looks like some sort of linter dependency and/or a syntax helper.
These kind of files shouldn't be committed.
ui/toolsDialogs.py:
Minor indent infractions in the import section.
######################
## files with nothing to comment on:
ui/QrCodeMatrix.py
ui/Wizards.py
ui/CoinControlUI.py
ui/FeeSelectUI.py
ui/TxFramesOffline.py
qtdialogs/DlgWalletSelect.py
qtdialogs/DlgWalletDetails.py
qtdialogs/DlgUnlockWallet.py
qtdialogs/DlgShowKeyList.py
qtdialogs/DlgSetComment.py
qtdialogs/DlgSendBitcoins.py
qtdialogs/DlgRequestPayment.py
qtdialogs/DlgReplaceWallet.py
qtdialogs/DlgQRCodeDisplay.py
qtdialogs/DlgProgress.py
qtdialogs/DlgOfflineTx.py
qtdialogs/DlgNewAddress.py
qtdialogs/DlgMigrateWallet.py
qtdialogs/DlgKeypoolSettings.py
qtdialogs/DlgIntroMessage.py
qtdialogs/DlgExportTxHistory.py
qtdialogs/DlgEULA.py
qtdialogs/DlgDispTxInfo.py
qtdialogs/DlgConfirmSend.py
qtdialogs/DlgChangePassphrase.py
qtdialogs/DlgBrowserWarn.py
qtdialogs/DlgAddressBook.py
ArmoryQt.py
armorymodels.py
armoryengine/ArmoryUtils.py
I'm considering merging this stuff into the dev branch and moving to a file by file or feature by feature basis past this point. What do you think? Do you want to cleanup this PR some more or move on? |
|
|
|
I've gone over the change set, it's fairly straight forward. A few comments: - The indent issue still exists in ui/MultiSigDialogs.py and ui/Wizards.py. Could you please fix those and submit only these changes as a new commit on top of the attic_qtdialogs branch? The rest of the work is good, we can start fixing the minor issues on a step by step basis. - The patch introduced a lot of new and unnecessary white spaces, as well as deleting the new line at the end of several files, both of which are style infractions and tend to pollute changesets. Fortunately, git can fix a lot of this on its own (git am --whitespace=fix *path/to/patch*). It can't do anything about the missing new line at file end however, but can be addressed in a small commit. In the future, please try not to commit whitespace changes, possibly by having git ignore them when creating a patch. - Apparently, I've fucked up with the license header in the segregated dialog files. It looks like I've elected to set the header to "Armory Technologies Inc 2011-2021" when I'm not allowed to do this (I'm not ATI), and it's wrong (I've done the work, whereas ATI is defunct). You've copied that license header along in your work and that made me realize it needs fixed. The license itself is also wrong, ATI uses AGPLv3, whereas I use MIT (more permissive). I do not have the right to loosen ATI's license, therefor the new code has to be copyrighted to me so that it can benefit from the looser license, hence the double license header which is the correct formulation. I'll fix those as I go, feel free to do the same. - This syntax doesn't not carry over from PyQt4 to PySide2: self.connect(self.btnAccept, SIGNAL("clicked()"), self.verifyUserInput)
The correct syntax is: self.btnAccept.clicked.connect(self.verifyUserInput)
This stuff amounts for a lot of the syntax errors left. ------------------------ With regard to development, currently the following features are FUBAR and need a lot of attention. I don't intent to fix these in the near term: - fragmented backups - multisig/lockbox dialogs - message signing The following GUI elements are still broken but fairly easy to fix. I will likely give them attention: - Wallet creation/restore wizard - Changing the password on wallets - Some minor display issues such as wallet labels, security mode, ownership On top of that, there are obsolete features that are/will be replaced: - The settings menu - Wallet corruption checks and recovery There is a set of new features that I want to add in the scope of the next release: - A new "manager" dialog that will appear before the main lobby. It would have a few tabs with the purpose of walking the user through setting up Armory prior to start up. The tabs would be: . Wallets: load all wallet files in the datadir, help with migration from the old to the new format, assist with unlocking public data (new wallet format encrypts all wallet data, public data can be locked with a separate password that requires a one time unlock at load)
. ArmoryDB: prepare all things related to setting up ArmoryDB. The new DB enforces AEAD, and supports both 1-way and 2-way auth. While local ArmoryDB requires path settings, connecting to a remote DB requires key exchange. This tab would assist with that.
. bitcoind: This tab will be succinct for now, just help with detecting bitcoind and custom pathing, possibly automate the process. Something to flesh out in the future.
- Transaction export format: There is a new format for passing transactions around now. This format is not backwards compatible with previous Armory versions. The new signer code also handles PSBT, so the idea is to allow (when eligible) for users to choose between formats when exporting signed/unsigned transaction blobs. The formats would be legacy, with a cutoff at 0.92, one at 0.96.x, PSBT and the new format. - Support for paying to taproot addresses. If you want to help with any of these, name the task and we can coordinate. |
|
|
|
|
Show Posts
