Topic: Armory 0.93 testing release! (with 0.05 BTC bug bounty) - page 10. (Read 35724 times)

Looks like a solid release. Thank you.

I just fixed that yesterday in 0.93-bugfix. It'll have to wait for .7


I've been using 0.10 rc3 since .3. Given the symptoms I don't expect this has anything to do with out of order block data anymore.

Something I may not have mentioned: all this is using Bitcoin Core 0.10.0 (currently rc4)

1) No and 2) Yes.

All tx's are in the ledger, balance is correct (checked with 92.3 and 92.99.2). When attempting to display individual tx details, error dialog appears:

"Invalid Tx:

The Transaction you requested be displayed is not in in* Armory's database. This is unusual..."

There is no discernible pattern, some tx's are affected and others of similar type are not (exclusively common sort of tx with 1-2 input/s and 2 outputs). Only real exception to this is that coinbase tx's do not even generate any error dialog. (edit: just cross-checked coinbase tx's in 92.99.2; it refuses to display tx details for coinabse tx's as with .3-.6)


* repeated word "in" is verbatim from the warning dialog


Export transactions .csv contains all details from the transactions that .3-.6 refuse to display. All details from all missing tx's are present and correct. This is indicating to me that the issue is related to reading/interpreting the Db and not writing it.

Do you have a gap in your history is it just missing all tx past a certain point? Can you see these transactions in individual address ledgers? I'd like you to attempt 2 things:

1) Export your transaction history through File -> Export Transactions. Is the CSV missing transactions? Are they same as those missing in your main ledger?

2) Create a new wallet, import some popular private key with lost of history like correct horse battery staple and scan it. Does it exhibit the same issue? Which range of the history is missing?

Here: http://pastebin.com/DuGHXbmH

Not convinced there's anything in there that will help you, but then again I don't know what you're looking for. It looks anomaly/error free to me.

Can you clear your log files, rebuild and rescan the DB with .6 and submit the fresh logs?

Apologies, I missed this post somehow.

#1 concern is that the database coding is still somehow incomplete. I have tested .1, .2, .3, .4 and .6, and the remaining issues are:

• Db not being able to find detailed tx information when double-clicking/right/click selecting from the main tx window (warning appears stating "Armory cannot find this tx in the database. This shouldn't happen!")
• Tx display/column sorting is broken in Address view

These aren't necessarily usability concerns on their own, but it certainly makes me concerned to use the application! To clarify from earlier comments, it's not just coinbase transactions that are lost in the Db, it's everything after some arbitrary point in time about 2 months ago. Every tx I've sent (with 92.3) since testing pre-0.93 suffers the same fate when displayed in 0.92.99.3 -> .6 (admittedly not very many tx's)

I thought of another minor concern: There's nothing (AFAIK) in the UI telling you whether you're running as a supernode or not.

Sounds like something specific to OSX. I'll pass it along.


This missing behavior is a bug actually. I never considered considered the relevant piece of code to fail under this perspective, so nice catch. It's also pretty easy to fix. Note that it will only work if the lockbox you created is funded at some point. Short of that it won't consider those public keys in use and thus won't display them in export lists.


OSX snafu too, I'll pass it along as well.

Ok, also I have 1 question and 2 more 'bugs':

In Export Key Lists, sometimes the wallet doesn't unlock properly and only displays public keys, other times it doesn't show up until i close the wallet's properties. The Goto button in the lockbox transaction is also cut off.

My question regarding the public keys is that Export Key Lists doesn't show the public key used to create lockboxes. Can this be added?

Also, I have one small request. Can a Cancel button be added to the Send Bitcoins window so that I don't have to restart Armory every time I accidentally open it? (this is the second bug)

That's if you receive a ZC before a previous ZC is mined into a block. I'm aware of this issue but it's low on my priority currently.

Bug: Sometimes when receiving or sending bitcoins, it displays the notification more than once (Mac)

just back after a few weeks break today, so i'll get the new version. hopefully db is nice and quick now

That probably happened when we got rid of the option to hide the wallet (which was one of the possible choices on that dialog). I'm looking at the import issue currently.

(0.92.99.6 fullnode, Ubuntu 14.04)
http://imgur.com/B2dUZqP,XISEcY0,qRP1UkL
When trying to delete private keys from wallet and I click the lower radio button (to delete just private keys), it doesn't deselect the top one (to delete the whole wallet). The dialog has the message as if it were going to delete the wallet, but it only deletes the private keys.

(0.92.99.6 supernode, Windows 7)

I'm trying to import a large number (131,070) of private keys into a wallet. When I import a large number of private keys at once (all new, no duplicates), it writes


to armorylog.txt a large number of times. For example, when importing 300 new private keys, it writes that 44,850 times. 44,850 just happens to be the 299th triangular number, strongly suggesting that key n is causing the error to be written n times (give or take). The keys are at http://pastebin.com/E7CjDhmA, in case it matters (they are of a very simple form, only the first or last two bytes are non-zero, so they're not really all that private).

This causes the import process to slow down tremendously.


Some of these imported addresses have an incorrect #Tx count. E.g. 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreakL7yRD, address 1NvxH7VHMwVdwHCpwLLVhecieHZy3oVPoZ, shows 1 Tx and a balance of 0.


At one point, while opening Armory with a large (many imported keys) wallet (I mention that because I think it makes the Wallet Consistency Check take longer, unsurprisingly), the two messages here were overlaid:


and


I have yet to be able to reproduce it to show you a screenshot of the actual problem, and I'm not 100% sure that was the same "Blockchain..." message, but I do recall seeing it start with "Blockchain" (the green bar was on top, obscuring everything past the "B").

Yea, turns out the backend was stuck, my mistake

You're either not looking at the right folder or the backend is stuck on something.

I found a "bug" in the armorycpplog.txt file

Log file opened at 1423312806: /Users/admin/Library/Application Support/Armory/armorycpplog.txt

There is nothing else in the log after that, but Armory has been scanning DB for the past 45 minutes.
Normally it would say 'Finished applying blocks up to (blockheight)' or something like that every 2500 blocks I believe.