Topic: Armory 0.95 is out (Read 9232 times)

minor issue: reported here https://github.com/goatpig/BitcoinArmory/issues/275

using latest release armory_0.96.1_amd64.deb (Armory 0.96.1 for Ubuntu/Debian 64-bit):

$ sudo apt install -y ./armory_0.96.1_amd64.deb
.
..
...
Setting up armory (0.96.1-1) ...
   Setting up menu items.
    EXEC: xdg-icon-resource install --novendor --context apps --size 64 /usr/local/share/armory/img/armory_icon_64x64.png armoryicon
xdg-icon-resource: file '/usr/local/share/armory/img/armory_icon_64x64.png' does not exist
    EXEC: xdg-icon-resource install --novendor --context apps --size 64 /usr/local/share/armory/img/armory_icon_64x64.png armoryofflineicon
xdg-icon-resource: file '/usr/local/share/armory/img/armory_icon_64x64.png' does not exist
    EXEC: xdg-icon-resource install --novendor --context apps --size 64 /usr/local/share/armory/img/armory_icon_green_64x64.png armorytestneticon
xdg-icon-resource: file '/usr/local/share/armory/img/armory_icon_green_64x64.png' does not exist
    EXEC: xdg-desktop-menu  install --novendor /usr/share/applications/armory.desktop
    EXEC: xdg-desktop-menu  install --novendor /usr/share/applications/armorytestnet.desktop
    EXEC: xdg-desktop-menu  install --novendor /usr/share/applications/armoryoffline.desktop
...
..
.
$

Hi

I encountered the same error and found a workaround. Successfully compiled Armory 0.96.1 for usage as my offline signer wallet.

I need a 32bit linux version (OpenSUSE Tumbleweed, GCC 7.2) because my cold wallet is on an old Pentium M laptop, so 64bit OS is not an option.
After the compilation error I tried to compile Armory on a Bananpi M1 with armbian. Same error here and I found the following workaround which also helped for the 32bit compile:

in the file BitcoinArmory/cppForSwig/CppBlockUtils.i on line 44 I added the "|| 1" at the end.

It seems that the definition for the case __GNUC__ is only valid for 64bit Intel/AMD targets. my addition simply forces the typedef unsigned long long  instead of long unsigned int.  That does the trick for x86_32 and arm7.

Offline wallet creation and signing work like a charm - I tried 2 small transactions signed with the resulting executables and everything went ok.

I do not know enough C++, python and swig to suggest the real solution, but my workaround might give a hint.


Cheers and many thanks for your work, Goatpig!

First, post in the right thread (hint: this one isn't it. check the stickies). Also post the Armory log files. You will probably also want to use the 0.96.1 testing build 2 as that has many bug fixes for 0.96.

Hi
I've used Armory for years. Lovely software   Since I have upgraded to 0.96.0 (on Windows), one of my wallets behaves weirdly. To be specific: when I click the 'Receive Bitcoins' button, it does exactly nothing. When I have other wallets open, and I click that button, it correctly shows the relevant popup window. (the 'New Receiving Address' window)
Can you advise? Is this a known bug? Is there a work around?
Cheers Dave

Has not been built for x86 in like 3 years. If you can get it to build, it could work on the side, or connected to a remote database. The DB itself can't run on x86 as it will run out of addressable memory.

hi

armory can work on win x86 ?

You can't use greater than 0.14.0 with 0.95.1. You should make your own thread about this and post the armorylog.txt and dbLog.txt files.

Both main and backup computer have 16GB of RAM. Scanning from scratch taking some time is normal, but it just feels odd to me that ArmoryDB will consume 14GB on one computer and hang while it never consumes more than 4GB or less (I think) on the main one.  And a bit unsettling to see it finish with wrong total sum when ArmoryDB is being killed. I've been trying this for some days now btw, having waited for more than a day for the task to complete and also saw other non-reproducable erratic behaviour.

Anyways, should've done some more research than just searching forum and reading through this thread, apologies! Looking at dbLog.txt there seems to be a problem with some blocks. You can not use bitcoind >0.13.1 with 0.95.1 right? Will make an own thread if I'm still curious, Thank You!

Make your own thread, post armorylog.txt and dbLog.txt


A DB is bound to its blockchain data. If you copy the blockchain data over, you can copy the DB over as well. More often than not, the issue is your pathing though.


Basically a useless venture, but sure, I'll indulge:

1) Scanning the entire key space is idiotic. Waste of energy.

2) What kind of scripts are they even scanning for? 0.96 has quite a unique script type construct for compressed keys. It doesn't matter if they by some miracle within a miracle manage to reproduce your private key if they don't know what script hash to look for.

3) This protection (provided by the script hash) is incumbent on avoiding address reuse. As long as you fund a script hash and that script is exotic enough, chances are these type of pointless attacks won't even know what script to look for. If you reuse addresses (a signature reveals the public key), you are loosing the extra protection afforded by the script hash.

This is the main reason for avoiding address reuse btw.

4) Speaking of exotic scripts, you could construct a script that requires the resolution of an extra hash, or use 2-of-3 or 3-of-4 multisig for long term cold storage, if you are afraid there is an odd chance these clowns found one of your keys. Something like nested P2WSH 3-of-3 multisig with an empty IF branch would put your coins behind 2 hashes and 3 private keys.

5) If you are so inclined, you can create a wallet seed with custom entropy through the deck of cards GUI. That's assuming you don't trust the quality of the PRNG on your machine (that's advisable with Windows, since the code is closed source).

Goatpig - Serious question that I hoped you might be able to briefly address.

This project - "Large Bitcoin Collider" - https://lbc.cryptoguru.org/stats - is searching keyspace and trying to find funds. While the statistics say their success is going to be very small, I was wondering if there were any features in Armory that might make their "rattle every doorknob until we find money" strategy that much more difficult.

Just curious what you think.

Thanks in advance...

I thought this is a normal behavior. When you change or create new database Armory needs to scan all your wallets again against the new databases. That is a very resourceful task (hint: now you will understand why on-chain scaling is not efficient and why we need that part of transaction to be off-chain) and I think it needs all the RAM memory for faster processing. I would like to know if there is a cap on the amount of ram that it needs in order to speed things up, but you sound like you have very little ram available on your back-up machine. I think you will need to leave your computer online overnight or when until it finishes. I will take a while.

Maybe someone can teach us how or what can we copy from Armory from another computer that has all wallets synced.

I have problems upgrading from 0.93.3 to 0.95.1 on Ubuntu 14.04.

What I do is:
- delete "databases" and "bittorrentcache" folders in .armory
- remove 0.93.3, install and start 0.95.1
- wait for the database being build (seems to work fine)
- see armory hanging at "Scanning transaction history" (showing no progress for hours)
- ArmoryDB will consume all available memory at this point
- close Armory, kill ArmoryDB process
- restart Armory
- it will finish to main screen, but this years transactions are missing, showing a wrong total sum of funds

This is on my backup computer. On my main computer, also with Ubuntu 14.04 and same wallets, ArmoryDB will also hang at "Scanning transaction history" but not consume all available memory. Also there are error messages when Armory is started from console. I can close Armory there with it shutting down ArmoryDB automatically. When I restart Armory, it completes and shows correct total funds.

I could just copy over everything from the main computer to backup computer, but havent't done so as I wanted to report the issue first.

Well, Flanagan's steps to verify differ in what's being said on the website as he uses pgp key 8C5211764922589A instead of  98832223. I guess both belong to goatpig?

Yes, good sig means the key (mine in this case) properly signed the data inside the "----- PGP SIGNED MESSAGE-----" encapsulation.

Thanks,
Updating my previous post with this command and results !

Just do


This give you the hash for the package. Compare that with the hash in the signed file. If they match, check the signature on the hash file. If the sig is good, you got the right files.

VERIFYING
armory_0.95.1_amd64.deb ?

Now that I got Lubuntu installed in another 64 system, I downloaded the package from https://btcarmory.com/0.95.1-release/

Don't see any information on verification at the site.
What release signature ?
What release signing key?

EDIT: Ok sorry, just saw the information at the site. Will try and report here my process of verification.

STEPS TO VERIFY I've done:

1) Import Armory Signing Key:
gpg --recv-keys --keyserver keyserver.ubuntu.com 4922589A
gpg: key 8C5211764922589A: public key "goatpig (Offline signing key for Armory releases) <[email protected]>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1

2) Download release signing key from: https://btcarmory.com/0.95.1-release/

3) shasum -c sha256sum.asc armory_0.95.1_amd64.deb

armory_0.95.1_amd64.deb: OK    <-- OK
shasum: armory_0.95.1_osx.tar.gz:
armory_0.95.1_osx.tar.gz: FAILED open or read
shasum: armory_0.95.1_win64.exe: No such file or directory
armory_0.95.1_win64.exe: FAILED open or read
shasum: WARNING: 20 lines are improperly formatted
shasum: WARNING: 2 listed files could not be read
shasum: armory_0.95.1_amd64.deb: no properly formatted SHA1 checksum lines found

3.1)
Compare the hash of the sha256sum.asc file with the one in the application package:
a) Inside the sha256sum.asc file:  
4d692a60afc114f4ccb230d11006c69af12ee37a0b7964b03caff90b6619b75c  armory_0.95.1_amd64.deb

b) sha256sum armory_0.95.1_amd64.deb
4d692a60afc114f4ccb230d11006c69af12ee37a0b7964b03caff90b6619b75c  armory_0.95.1_amd64.deb   <---inside the application package

They coincide so <-- OK


4)  gpg --verify
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

4d692a60afc114f4ccb230d11006c69af12ee37a0b7964b03caff90b6619b75c  armory_0.95.1_amd64.deb
9ec3803b914660c5fbecfd5b2d6e907f64d16f920cd648678137d307399beb8d  armory_0.95.1_osx.tar.gz
ccb495aa3a695e43ac04b4741dd8f8463d5349192a0f5db895dbd2e834e5844a  armory_0.95.1_win64.exe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJYGjjiAAoJEIxSEXZJIliaQ2EP/RwLphwj0z0o00VP/PGHzKYK
UmTHibof3ZavFF1orAdgWDayHoQCsZBcPy8fQcGWZ3zomhAqCC1lN496SHkkWQWH
TAYvMOsRlvMaaNIcoJ+jxyJzjmWd5+FjOEd/Uy9Au6DQFCqIEHTbjth/hyyUouaM
IxqudEiGAye2V5sIP8XWIWz6l8vq9OPKd4x3/F3NvlBY6jpAc81VxGFnfAZgIpW6
+in302WwIg61zG5AeVfju6BKJCREMvJvSvrdcrnK0UZDFm2jnl0IU1Q8omJFZXpG
EL06QBgO0+4aJ0rOu/RIIBzXJQgfj9Eul3ih0M6KbrImIAU3DlDKV3RTaNG9evCX
H5TtTKgux8Yuyljks5qu2WB7Cj8LtjbzPHMf4QT2SfavFpejJJFEAWyx2GdLTd5y
jZ95dwbPby59gyfwK3FNurgRduW+hjTGjTtZAk7CopkbrbLW4NzdjtHfKKzHmqid
yTI2PMCCjOLnAvTxEGKngmACQSvzDT9NN9ImWhf/E0IRKE7JtPPAp4U8xdC0NZDk
yIUP5A4D8d7FDpv8arK8v5PV4WyiCHLjyPRmt5kOc9AAUVr/7oPZO0FI4+VyY24X
ooOtuVmt66hTPyymmd0QUeulgl0PVqsJoyENjvx8H1Q8Wdo2rHseg06r2Q174Ckr
STBuW7eIR89uaLEsgjzC
=NJYO
-----END PGP SIGNATURE-----
gpg: Signature made mié 02 nov 2016 20:05:06 CET
gpg:                using RSA key 8C5211764922589A
gpg: Good signature from "goatpig (Offline signing key for Armory releases) <[email protected]>" [unknown] <-- OK
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 745D 707F BA53 968B DF63  AA8D 8C52 1176 4922 589A

I have to say that 0.95 is light-years faster than I could have ever believed. I only had to build the databases once, and afterward it updates VERY quickly. Thank you very much for your time and effort on this project. I sincerely appreciate your skill and talent.

This ought to be the first time someone argues I release too fast!

TraderTimm: that stuff is fixed in 0.96

This is goatpig's admirable pragmatism at work; there were still bugs like this in 0.95.x, but delaying the release to squash them wasn't really worth the trade-off of not getting the releases out. He's one man, doing the job of several, and at this early stage for the new code in Armory (which AFAIA was a significant re-write), it made more sense to let non-critical bugs slide. Alot of these have been dealt with for 0.96 so far, and certainly some aspect of unconfirmed balances was fixed in the last few days (I know not the details of that though)