Please Help Test Armory 0.91-beta!

[bitpop]

Should the signed version of Armory downloaded from the secure feature be verified offline? How risky is to verify it online?

You're already online so if they got you locally nothing you can do. If installing on offline then recheck.

[1714967926]

1714967926

[1714967926]

1714967926

[1714967926]

1714967926

[etotheipi]

If the offline computer is already upgraded to 0.91+, then you can use the secure downloader to grab the package and "Save with offline-verifiable signature".  Then take that to the offline computer and use "Help"->"Verify Signed Package".  That will check the offline Bitcoin signature and let you save the installer (only after the signature is verified). 

This is specifically so you don't have to trust your online computer, and you don't have to deal with GPG.  The Bitcoin signing key used here is handled at the same security level as the offline GPG key.

[ACVentures]

I'm trying to use Armory online on an OSX 10.8.5

When upgrading from a perfectly working copy of 0.90 beta to the new 0.91.1 beta (and always checking to make sure the sig hash is correct) -> armory app will not even open. Does not load the main application window. Splash screen image for a few seconds, then generic OSX message informing me that Armory quit unexpectedly. Trying to reopen the app OSX again informs me that last time it was being opened it quit out, and asks if I'm sure to reopen. Always fails and crashes.

Where can I mail the log file?

What I think are the relevant bits (the crashed thread) are pasted below:

Thread 2 Crashed:
0   _CppBlockUtils.so                0x000000010580bbec InterfaceToLDB::getValueRef(DB_SELECT, BinaryDataRef) + 44
1   _CppBlockUtils.so                0x000000010580aafe InterfaceToLDB::getStoredDBInfo(DB_SELECT, StoredDBInfo&, bool) + 94
2   _CppBlockUtils.so                0x0000000105809d9a InterfaceToLDB::openDatabases(std::string, BinaryData const&, BinaryData const&, BinaryData const&, ARMORY_DB_TYPE, DB_PRUNE_TYPE) + 1242
3   _CppBlockUtils.so                0x000000010585806c BlockDataManager_LevelDB::initializeDBInterface(ARMORY_DB_TYPE, DB_PRUNE_TYPE) + 412
4   _CppBlockUtils.so                0x00000001058639a3 BlockDataManager_LevelDB::buildAndScanDatabases(bool, bool, bool, bool) + 403
5   _CppBlockUtils.so                0x0000000105a6906b _wrap_BlockDataManager_LevelDB_doInitialSyncOnLoad(_object*, _object*) + 107
6   org.python.python                0x00000001000afcb7 PyEval_EvalFrameEx + 20487
7   org.python.python                0x00000001000b2532 fast_function + 194
8   org.python.python                0x00000001000ade55 PyEval_EvalFrameEx + 12709
9   org.python.python                0x00000001000aaa41 PyEval_EvalCodeEx + 1729
10  org.python.python                0x0000000100035dac function_call + 364
11  org.python.python                0x0000000100010883 PyObject_Call + 99
12  org.python.python                0x00000001000ae17d PyEval_EvalFrameEx + 13517
13  org.python.python                0x00000001000aaa41 PyEval_EvalCodeEx + 1729
14  org.python.python                0x00000001000b2599 fast_function + 297
15  org.python.python                0x00000001000ade55 PyEval_EvalFrameEx + 12709
16  org.python.python                0x00000001000b2532 fast_function + 194
17  org.python.python                0x00000001000ade55 PyEval_EvalFrameEx + 12709
18  org.python.python                0x00000001000b2532 fast_function + 194
19  org.python.python                0x00000001000ade55 PyEval_EvalFrameEx + 12709
20  org.python.python                0x00000001000aaa41 PyEval_EvalCodeEx + 1729
21  org.python.python                0x0000000100035dac function_call + 364
22  org.python.python                0x0000000100010883 PyObject_Call + 99
23  org.python.python                0x000000010001d806 instancemethod_call + 166
24  org.python.python                0x0000000100010883 PyObject_Call + 99
25  org.python.python                0x00000001000b1cfd PyEval_CallObjectWithKeywords + 93
26  org.python.python                0x00000001000ec146 t_bootstrap + 70
27  libsystem_c.dylib                0x00007fff91b85772 _pthread_start + 327
28  libsystem_c.dylib                0x00007fff91b721a1 thread_start + 13

and from the armorylog.txt the very last few lines are:

2014-05-06 19:57 (INFO) -- ArmoryQt.py:1794 - Setting up networking...
2014-05-06 19:57 (INFO) -- ArmoryQt.py:1846 - Internet connection is Available: True
2014-05-06 19:57 (INFO) -- ArmoryQt.py:1847 - Bitcoin-Qt/bitcoind is Available: 8333
2014-05-06 19:57 (INFO) -- ArmoryQt.py:1848 - The first blk*.dat was Available: True
2014-05-06 19:57 (INFO) -- ArmoryQt.py:1849 - Online mode currently possible:   True
2014-05-06 19:57 (INFO) -- ArmoryQt.py:2036 - loadBlockchainIfNecessary
2014-05-06 19:57 (INFO) -- ArmoryQt.py:2082 - Setting netmode: 1
2014-05-06 19:57 (INFO) -- BDM.py:431 - Setting online mode: True (wait=False)
2014-05-06 19:57 (INFO) -- BDM.py:1357 - Go online requested
2014-05-06 19:57 (INFO) -- BDM.py:914 - Setting Armory Home Dir: /Users/REDACTED/Library/Application Support/Armory/
2014-05-06 19:57 (INFO) -- BDM.py:915 - Setting BlkFile Dir:     /Users/REDACTED/Library/Application Support/Bitcoin/blocks
2014-05-06 19:57 (INFO) -- BDM.py:916 - Setting LevelDB Dir:     /Users/REDACTED/Library/Application Support/Armory/databases
2014-05-06 19:57 (INFO) -- ArmoryQt.py:1106 - setupUriRegistration

And then something causes a hard crash. Also, I'm using the 0.9.1 core bitcoin-QT client and it shows that it's connected and sync'd fine, still receiving new blocks.

Any ideas?

[etotheipi]

If you updated from 0.90 to 0.91+, you most likely have to rebuild your databases.

Unfortunately, if you can't even get it to open, you'll have to manually delete the databases.  On OSX it is under the following directory by default:

~/Library/Application Support/Armory/databases

You can navigate to the Armory directory and delete the databases directory (which holds a lot of data).  Next time you start Armory, it will rebuild and rescan, which might take a couple hours, but it should be smooth after that.

[ACVentures]

If you updated from 0.90 to 0.91+, you most likely have to rebuild your databases.

Unfortunately, if you can't even get it to open, you'll have to manually delete the databases.  On OSX it is under the following directory by default:

~/Library/Application Support/Armory/databases

You can navigate to the Armory directory and delete the databases directory (which holds a lot of data).  Next time you start Armory, it will rebuild and rescan, which might take a couple hours, but it should be smooth after that.

Yes, that fixed it, thanks. I suspected that would do the trick, but was hoping to avoid having Armory rescan the whole block chain.

By the way, cool Secure Downloader feature.

Did you just update Armor further? I downloaded 0.91.1 and initially had the error I posted about yesterday, successfully fixed it as you instructed, and now today the secure download area is saying there's a newer Armory version. Clicking it tells me it cant determine the correct version for my OS, and asks me to select from the list of all versions. The only version newer for OSX 10.8 is 0.91.2 but it's listed as a testing branch. Is that to be expected?

[bitpop]

That's normal, same here on Windows

Really wish change log is included otherwise testing version looks scary

[etotheipi]

Sorry about that -- we had to release a few tweaks to 0.91.1 to fix a wallet-recovery tool bug and some unicode path issues.  I put it out as a testing release so it would be available and ready for people to download if needed, but wouldn't spam people with more notifications (of course, I forgot it's going to notify everyone with testing notifications on!).  I'll try to give more of a heads up about it, next time.

Basically, unless you have path issues or wallet recovery tool issues, there's no real reason to upgrade to 0.91.2.

[laurentb]

There is no git tag for 0.91.2, nor are there any tarball source releases on the website.
This is very inconvenient for packagers.

[etotheipi]

There is no git tag for 0.91.2, nor are there any tarball source releases on the website.
This is very inconvenient for packagers.

Ye ask and ye shall receive:  I just pushed the signed tag.  I already had it the tag signed I just forgot to push it to the repo.

We will eventually start doing source tarballs, but we have had a problem where it's bundling up the git repo itself, so the source tarballs are like 100 MB.  Once we figure out how to get dpkg-build to stop doing that, we will add the tarballs to our regular release cycle.

[laurentb]

Thanks!

I'm not sure I get what's happening, but git has a convenient "git archive" feature.

[LunarBit]

Hello.

I have fatal error on "Build Databeses" step of Armory first run. The order in which I did everything:

1) Installed Armory.
2) Installed Bitcoin-qt.
3) Waited days for Bitcoin-qt to sync.
4) Opened Armory, it said it cant find anything. So I installed "bitcoind" through terminal.
5) Opened Armory again - it did "wallet check" and "initializing bitcoin engine", but after that - crash.

I got fresh lastest Ubuntu, installed just for Bitcoin use. Please help.

[goatpig]

Hello.

I have fatal error on "Build Databeses" step of Armory first run. The order in which I did everything:

1) Installed Armory.
2) Installed Bitcoin-qt.
3) Waited days for Bitcoin-qt to sync.
4) Opened Armory, it said it cant find anything. So I installed "bitcoind" through terminal.
5) Opened Armory again - it did "wallet check" and "initializing bitcoin engine", but after that - crash.

I got fresh lastest Ubuntu, installed just for Bitcoin use. Please help.

You should make a ticket for that...

Are you using Ubuntu 14.xx?

[LunarBit]

You should make a ticket for that...

Are you using Ubuntu 14.xx?

13.10.

Ticket where?

[goatpig]

https://bitcoinarmory.com/support/

[bcbrad]

Please consider adding an indication the Caps Lock key is on for ANY password field.  I had a minor meltdown today when trying to access a wallet I had recently set up.  It turns out the Caps Lock key was inadvertently on when I originally typed the password (it's very easy to accidentally hit on my keyboard).  I had my backup handy either way, but it was very frustrating not being able to access my wallet when I expected to.  I even thought to check the Caps Lock state when failing to unlock my wallet and only much later had the idea to try it with Caps Lock on.  Because I couldn't see the password when originally typing, I had no idea it was set incorrectly from the start.

A bright yellow indicator that Caps Lock is on for all password entry fields (setting and unlocking) would go a long way towards avoiding mistakes like this.

[S5QUwMta4CM6]

I have just upgraded to 0.91.1 and one of my wallets was corrupt. I tried to repair it and eventually restored it from a paper backup. I think about 90 per cent of my bitcoins are missing from the wallet. I think this is because no change has been restored to the wallet.

For example https://blockchain.info/tx/ca1c362e6c9130d1bee164613e1143ed60f6838bf129aba28791a8e0542174fb I sent 0.007727 BTC from 16Rj.. to 15jd.. and received 0.076973 in change to 14B1.. but 14B1.. is no longer associated with the spending wallet.

I don't know the cause of this yet and I have opened a support ticket but I just want to send a word of caution - if Armory is working fine and you haven't upgraded yet, then think twice—unless you know what caused my problem and if you do, can you please let me know

[etotheipi]

I have just upgraded to 0.91.1 and one of my wallets was corrupt. I tried to repair it and eventually restored it from a paper backup. I think about 90 per cent of my bitcoins are missing from the wallet. I think this is because no change has been restored to the wallet.

For example https://blockchain.info/tx/ca1c362e6c9130d1bee164613e1143ed60f6838bf129aba28791a8e0542174fb I sent 0.007727 BTC from 16Rj.. to 15jd.. and received 0.076973 in change to 14B1.. but 14B1.. is no longer associated with the spending wallet.

I don't know the cause of this yet and I have opened a support ticket but I just want to send a word of caution - if Armory is working fine and you haven't upgraded yet, then think twice—unless you know what caused my problem and if you do, can you please let me know

We need people to upgrade.  The upgrade itself is not responsible for any wallet issues -- any issues happened a while ago, it's upgrading that helps you identify that it happened.  I found your support ticket and will respond shortly.   We will get this fixed for you.

[Rampion]

Two short questions:

If consistency check is OK on 0.9.1 then we are all good?
0.9.2 is still unstable and thus 0.9.1 is the recommended release?

Thank you Alan.

[S5QUwMta4CM6]

I have just upgraded to 0.91.1 and one of my wallets was corrupt. I tried to repair it and eventually restored it from a paper backup. I think about 90 per cent of my bitcoins are missing from the wallet. I think this is because no change has been restored to the wallet.

For example https://blockchain.info/tx/ca1c362e6c9130d1bee164613e1143ed60f6838bf129aba28791a8e0542174fb I sent 0.007727 BTC from 16Rj.. to 15jd.. and received 0.076973 in change to 14B1.. but 14B1.. is no longer associated with the spending wallet.

I don't know the cause of this yet and I have opened a support ticket but I just want to send a word of caution - if Armory is working fine and you haven't upgraded yet, then think twice—unless you know what caused my problem and if you do, can you please let me know

We need people to upgrade.  The upgrade itself is not responsible for any wallet issues -- any issues happened a while ago, it's upgrading that helps you identify that it happened.  I found your support ticket and will respond shortly.   We will get this fixed for you.

Thanks for your prompt reply. I have also discovered in 0.91.1 that

—performing a Wallet Recovery > Select Loaded Wallet brings up no data fields and no Spendable BTC.
—a Full Recovery then results in "Wallet is consistent, nothing to fix" but all transaction balances are set to 0 (zero) with a 0.00 wallet balance.

Quitting and restarting Armory will correct this and cause the previous balance to be displayed in that wallet again. This leads me to conclude there are other potential problems with 0.91.1 which are that

• when selecting a Loaded Wallet for recovery its Wallet ID, Name, Description and Spendable BTC balance are not displayed
• carrying out a Full Recovery on a wallet that has passed the initial Wallet Consistency Check causes all transaction balances to be displayed as 0 (zero) with a 0.00 wallet balance until Armory is restarted

This is in addition to the problem above. Thanks.

[ResonantBlue]

Hi,

I'm running Armory-0.91 on Linux, and it crashes after it finishes synchronizing with the network. Once it starts 'Building Databases' I see a 'Connected 0 blocks' at the bottom then it shuts down.

Edit: it used to work fine a couple days ago.

Edit #2: I was going to try to rebuild the database using Help > Rebuild and Rescan Databases but I don't even have a Help menu, not even that menu at the top. Is this supposed to be only on Windows clients? I don't remember ever having this!

I know this is an old topic, but I was recently getting the same results and couldn't figure out why.  I am using Armory 0.92.3 (the 0.91-beta is history now) on Ubuntu 14.04.1 and every time it would get to the "Building Databases" section, it would crash right as it was beginning to rebuild the databases.  However, I had my databases installed in a separate NTFS partition that I share with Windows.  I don't know if that has anything to do with it but I figured I'd try and move my databases to the default /home/.armory directory to see if there was a difference.  Now it's been building the databases for a while and it hasn't crashed.  I wonder if any other Linux users have found problems when Armory is installed in a directory other than the default home directory.

My brother recommended Armory, so I've been wanting to give it a try.  However, he uses Windows and I use Linux so he's been using his for a while now and I've been struggling to get mine to work for the last couple of weeks.
I'll report back later after I make more progress.