Topic: Armory - Discussion Thread - page 64. (Read 521749 times)

Interesting. I tried making an unencrypted backup and Armory crashed with the following error...

I then tried running a recovery on the decrypted version and it said 999 errors...


I then backed up the wallet again (encrypted) and performed a recovery and got 998 errors...


The initial recovery that found zero errors was done in online mode, the next two done offline.

0 errors where found (sic)

Just in case it has to do with the wallet itself, can you try making a backup of it, then use the menu item "Wallets"->"Recover Damaged Wallet".  Do a full recovery.  Then try it agian (you can do it from offline mode, then restart Armory).

I would guess maybe a dozen addresses, maybe 60 incoming transactions, and maybe a dozen outbound transactions.

A very similar wallet loads fine. The only major difference between the two is that the one that does not crash only has one outbound transaction.

Does your wallet have lots of transactions with tons of inputs and outputs?  For instance, we noted huge lagging when we loaded a wallet that had 100 transactions, each of which had 1,000+ outputs (even though only one output was related to the user's wallet).

No luck, same issues.

Here is the first error message in the log file (other than using dev warning), the rest of the log is just repeated BDM errors. Also, the wallet consistency check finds no errors. After a while, the lower right corner always returns to the false blocks message.

EDIT:
Oh, the getspendable errors are still there, just down the list from the initial BDM errors. (NVM, deleted old log.)

I believe the getSpendableBalance errors are a symptom of the problem, not the problem itself.    Rather, the problem already happened before it got to that line. 

Actually... looking at the errors makes me think that you're still using the old C++ utilities.  Like you didn't recompile the C++ code after checking out the latest version.  I see


Those prototypes did change in the latest version and now have a second argument.  Try doing a make clean and make and try agian.

Wallet import still crashes Armory on .91 dev branch.

OK, still having the same problem with the new dev branch. Imported wallet after complete sync, application becomes so slow it's hard to tell if it's crashed. Crash occurs at or near the end of transaction history scan. Message in lower right corner says Connected (False Blocks). After restarting, Armory crashes at 99% transaction history scans and message in lower right corner says Connected (0 Blocks). After about 5 minutes it seems to complete, lower right corner now looks normal Connected (29XXX Blocks). A few minutes later the message returns too Connected (False Blocks).

Basically, no different experience than 0.90 version. Although a blank "Factory Reset" window just popped up. Not sure what that's about!

My guess is that it's looking for a header pointer on a zero-confirmation tx.  It doesn't find it, and then the error somehow leads to crashing the readBlkFileUpdate() loop.  We may need to examine how the loop is handling zero-confirmation transaction and make sure there's not any crashing there.

Hi Alan!

I have a strange behaviour, maybe you can point me to the right direction.

we are using Armoryd.py for offline transaction signing.
After that we pass the Tx to another rpc to sign it,
and after it got signed I pass it again to armoryd.py (added own functions to btcUtilsExtra.py to make the broadcast)
but after the broadcast is done the following appears on Log:


The Tx gets boradcasted and arrives to Network and to the Recevier Address. thats not the point,
but: After a few transactions the armoryd.py stops to reporting the correct Ledger.

It responds fine (on rpc) without any problem, but it doesnt get new values from it (new Blocks - changes of balance etc..)
I dont know if it has to see with the error log  I posted below, its just a "maybe detail" of the problem.


Some point where to look in?
Best regards

"Make hardclean" don't help.

Awesome news!
I really like the way the Armory team works. Cutting edge technology, fast updates and in close contact to the users, and fundamental enhancements in the background.

Hats off to all of you, thank you!

Ente

Took just shy of 4 hours. Now syncing, 24% complete and estimating 3 hours to finish. Guesstimating 8 hours total before database build? This may not be as fast as you were expecting, but with how many times I've done this for troubleshooting it seems like a dream. Cuts about 16-20 hours out of what I usually see. This is great so far. Thanks for the update.

The bootstrapping takes way longer than I was expecting when I put this in.  But also the bootstrap file is three months old at this point, as is the last checkpoint in Bitcoin-Qt.  I think with 0.9.0 and the updated checkpoint, the bootstrap will be much faster.

However, even with no time improvement, this should cut down considerably on corrupted blk*.dat files. 

Just installed on Mint16, no issues with make. Currently downloading via CDN, seems to be averaging about 1.6MB on download right now.

Hope this fixes my issues, but very cool to see an improved blockchain download process.

This issue is most commonly associated with updating Armory but not rebuilding all the sub libraries.  But we also modified the Makefile since the last version was released, so it's possible we broke something there.  And you said you did a fresh clone, so my first sentence doesn't make the most sense.

Try going into the cppForSwig directory and doing a "make hardclean", then try again.  I will try this on a fresh Ubuntu installation, too.

New stuff for 0.91-beta!

Finally ready to lock down the feature set for 0.91-beta.  I posted a testing version a couple weeks ago, and then some internal discussions revealed it was actually possible (and easy) to integrate BitTorrent into Armory to dramatically improve the initial synchronization!   But that's not it: we are now running 30+ seedboxes to make sure there is sufficient seeding power for... a lot ... of users simultaneously.  The joys of being a company with capital to make such investments! (and really, it's not terribly expensive)  

And yet there's more!  I had been meaning to update the announcement system for a long time, and never quite had the motivation to do it.  With the necessity to periodically update the bootstrap.dat.torrent file, I decided now was the time.  

Armory now has a hard-coded offline signing Bitcoin key, that is used to sign all announcement data, including torrents, upgrade info and alerts.  This channel is protected to the same level of security as the releases themselves.  It will be used sparingly:

• URLs, hashes, changelogs for all new versions of Armory and CoreBitcoin.  This made it possible to also integrate a "Secure Downloader" that downloads installers and verifies signatures for you!
• Notifications list for critical announcements and alerts (including low-priority testing announcements if selected in the settings)

It's all stored in an announce file which is periodically retrieved by Armory.  If the announce file has no valid signature, it's as if it doesn't exist.  Similarly, when data is downloaded, it must match the hash in the announce file, or it will be discarded.  All text files will, themselves, be in Armory signature blocks, and can be manually verified in Armory via Tools -> Message Signing/Verification from the main window.


tl;dr

• Automatic usage of torrent and Armory seedboxes to bootstrap a cold start.  I downloaded the blockchain at 4 MB/s on my connection! (unfortunately, bitcoin-qt still takes 2-3 hours to process the bootstrap.dat, but the total time is still faster for most, and much more reliable)
• Armory works even if the torrent library is actually removed.  I don't think most people would care, but just in case... remove the BitTornado directory and it will sync with the network normally via Bitcoin P2P.
• Secure downloader provides a secure way to update Armory without using GPG.  This even includes the ability to "Save with offline-verifiable signatures".  This means you can create a .signed file to take to the offline computer and it won't even write the package to disk unless the signature is valid.
• General notifications:  We finally have a way to issue critical security alerts if the need arises.  Can select the threshold in the settings, including a "testing" mode, which we might use to communicate with people actively helping test.

We are still tweaking a few things, but otherwise the testing version is about ready to go.  It's on 0.91-dev if anyone is willing to help sanity check that all the files are committed, etc.  Will merge into the "testing" branch and make Windows and OSX installers in the next two days.  I will also start another testing thread (with bug bounty!) when we do.

P.S. - If you run with 0.91-dev right now, you'll need to use --test-announce to see the announcements, downloads and use torrent.  And they're all fake at the moment (except for the torrent), so it the actual information displayed isn't all that meaningful.  The Armory downloads for Mac and Ubuntu should technically work, but may not download anything actually useful (though you can test the offline-verify-signature feature)

I have problem with 0.91-dev branch on Arch Linux. Tried a fresh clone and it is not help.

Today I was facing a strange bug.

Recently I moved all my funds from my old offline wallet to a new one. Yesterday I installed Armory on a new machine and reimported my new offline watch only wallet and the old one, too. After armory has rebuild and scanned the blockchain the balance of my old wallet was zero and all my funds are in the new one - exactly as expected.

I was glad Armory finished all the blockchain building&scanning and wanted to shut down my ubuntu machine. But my Armory GUI did not want to close immediately and my Ubuntu said something like "Cannot shutdown because armory is still running.. Force shutdown?". I decided to wait one more minute but this process did not complete and I finally forced the shutdown.

Today I started Armory again and whooo - my old wallet balance says that this wallet has some coins! I checked the transaction log but there were not any new transactions to this wallet. So I tried to initiate a test transaction to check if I really own these coins. After broadcasting it Armory came up with an error msg "Transaction may have not been broadcasted/may not appear in the blockchain". Okay, I think I really don't own this Coins anymore and there is a database mixup because I forced Armory to shutdown.

Now I am rescanning the transaction history and will report what happens. Or shall I rather "rebuild & rescan" the database?

What's the difference between rebuild&rescan? Does rebuild mean "Download the blockchain again" ?

2014-03-14 00:41 (INFO) -- armoryengine.py:12479 - Reading blockchain, pct complete: 0.0
2014-03-14 00:41 (INFO) -- armoryengine.py:12479 - Reading blockchain, pct complete: 0.0
2014-03-14 00:41 (INFO) -- armoryengine.py:12479 - Reading blockchain, pct complete: 0.0
2014-03-14 00:41 (INFO) -- armoryengine.py:12479 - Reading blockchain, pct complete: 0.0
2014-03-14 00:41 (INFO) -- armoryengine.py:12479 - Reading blockchain, pct complete: 0.0
2014-03-14 00:41 (INFO) -- armoryengine.py:12479 - Reading blockchain, pct complete: 0.0
2014-03-14 00:41 (INFO) -- ArmoryQt.py:4465 - Dashboard switched to fully-online mode
2014-03-14 00:41 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-03-14 00:41 (INFO) -- ArmoryQt.py:3780 - Switching Armory functional mode to "Online"
2014-03-14 00:41 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-03-14 00:41 (INFO) -- ArmoryQt.py:4465 - Dashboard switched to fully-online mode
2014-03-14 00:41 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-03-14 00:41 (INFO) -- ArmoryQt.py:3780 - Switching Armory functional mode to "Online"
2014-03-14 00:41 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-03-14 00:41 (INFO) -- ArmoryQt.py:1913 - Syncing wallet: WALLET1
2014-03-14 00:41 (INFO) -- ArmoryQt.py:1913 - Syncing wallet: WALLET2
2014-03-14 00:41 (INFO) -- ArmoryQt.py:1913 - Syncing wallet: WALLET3
2014-03-14 00:41 (INFO) -- ArmoryQt.py:1925 - Current block number: 290451
2014-03-14 00:53 (INFO) -- ArmoryQt.py:4465 - Dashboard switched to fully-online mode
2014-03-14 00:53 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-03-14 00:53 (INFO) -- ArmoryQt.py:3780 - Switching Armory functional mode to "Online"
2014-03-14 00:53 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-03-14 00:53 (INFO) -- ArmoryQt.py:4465 - Dashboard switched to fully-online mode
2014-03-14 00:53 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-03-14 00:53 (INFO) -- ArmoryQt.py:3780 - Switching Armory functional mode to "Online"
2014-03-14 00:53 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-03-14 00:53 (INFO) -- ArmoryQt.py:4781 - New Block! : 290452
2014-03-14 00:53 (INFO) -- ArmoryQt.py:4805 - Current block number: 290452
2014-03-14 00:53 (INFO) -- ArmoryQt.py:4982 - BDM is safe for clean shutdown
2014-03-14 00:53 (INFO) -- armoryengine.py:13435 - Shutdown Requested
2014-03-14 00:53 (ERROR) -- armoryengine.py:13216 - Resetting BDM and all wallets
2014-03-14 00:53 (INFO) -- armoryengine.py:13481 - BDM is shutdown.
2014-03-14 00:53 (INFO) -- armoryengine.py:11263 - Called stopBitcoind
2014-03-14 00:53 (WARNING) -- armoryengine.py:661 - Killing process pid=2332
2014-03-14 00:53 (INFO) -- ArmoryQt.py:5010 - Attempting to close the main window!
2014-03-14 00:54 (ERROR) -- armoryengine.py:12346 - BDM was not ready for your request!  Waited 20 sec.
2014-03-14 00:54 (ERROR) -- armoryengine.py:12347 -   getattr   name: hasTxWithHash
2014-03-14 00:54 (ERROR) -- armoryengine.py:12348 - BDM currently doing: Shutdown (47513644)
2014-03-14 00:54 (ERROR) -- armoryengine.py:12349 - Waiting for completion: ID= 56394262
2014-03-14 00:54 (ERROR) -- armoryengine.py:12350 - Direct traceback
2014-03-14 00:54 (ERROR) -- armoryengine.py:12353 - Traceback:
Traceback (most recent call last):
  File "/usr/lib/armory/armoryengine.py", line 12343, in passthruFunc
    out = self.outputQueue.get(True, self.mtWaitSec)
  File "/usr/lib/python2.7/Queue.py", line 176, in get
    raise Empty
Empty
2014-03-14 00:54 (ERROR) -- armoryengine.py:12346 - BDM was not ready for your request!  Waited 20 sec.
2014-03-14 00:54 (ERROR) -- armoryengine.py:12347 -   getattr   name: hasTxWithHash
2014-03-14 00:54 (ERROR) -- armoryengine.py:12348 - BDM currently doing: Shutdown (47513644)
2014-03-14 00:54 (ERROR) -- armoryengine.py:12349 - Waiting for completion: ID= 63415093
2014-03-14 00:54 (ERROR) -- armoryengine.py:12350 - Direct traceback
2014-03-14 00:54 (ERROR) -- armoryengine.py:12353 - Traceback:
Traceback (most recent call last):
  File "/usr/lib/armory/armoryengine.py", line 12343, in passthruFunc
    out = self.outputQueue.get(True, self.mtWaitSec)
  File "/usr/lib/python2.7/Queue.py", line 176, in get
    raise Empty
Empty
2014-03-14 00:54 (ERROR) -- armoryengine.py:12346 - BDM was not ready for your request!  Waited 20 sec.
2014-03-14 00:54 (ERROR) -- armoryengine.py:12347 -   getattr   name: hasTxWithHash
2014-03-14 00:54 (ERROR) -- armoryengine.py:12348 - BDM currently doing: Shutdown (47513644)
2014-03-14 00:54 (ERROR) -- armoryengine.py:12349 - Waiting for completion: ID= 66787172
2014-03-14 00:54 (ERROR) -- armoryengine.py:12350 - Direct traceback
2014-03-14 00:54 (ERROR) -- armoryengine.py:12353 - Traceback:
Traceback (most recent call last):
  File "/usr/lib/armory/armoryengine.py", line 12343, in passthruFunc
    out = self.outputQueue.get(True, self.mtWaitSec)
  File "/usr/lib/python2.7/Queue.py", line 176, in get
    raise Empty

The last error log block appeared some more times

Update:
Okay, after rescanning the database it shows the (hopefully) correct balance again. I suggest to do a auto-rescan if this error can be tracked.