Armory 0.93 testing release! (with 0.05 BTC bug bounty)

[Carlton Banks]

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)

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

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.

[1714629246]

1714629246

[goatpig]

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?

[Carlton Banks]

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?

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

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

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.

[Carlton Banks]

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

[goatpig]

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

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

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)

afaik Armory never had tx detail dialogs for coinbase transactions.

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

Yeah sounds like GUI or filter snafu, but the DB is sound. CSV export uses the same code path to get and build tx info as the main ledger. It does make a point of reseting all wallet filters first though. Address ledgers do not use filters either so that's my prime culprit for now.

Here is a set of new questions:

1) Is this error deterministic? Does the missing set of tx in ledgers vary from start to start? Or per rescan?

2) Is there a choice of wallet filters that reveals all missing transactions? From your log file it looks like you are using only 1 wallet, but try the single wallet filter and the custom wallet filter anyways.

3) This could be an issue that occurs only with single wallets. Do you have another wallet with some history you could load along side this one?

4) Can you try syncing Armory with one of the supported OSes? I need to make sure this isn't a Qt related issue.

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

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.

[coinpr0n]

Looks like a solid release. Thank you.

[Carlton Banks]

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

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

It's possible that you already knew about the whole issue, and that I just wasn't explaining myself properly

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)

afaik Armory never had tx detail dialogs for coinbase transactions.

I'm 99% that Alan fixed/implemented it at some point in the past, but when that was and when it broke I cannot recall

1) Is this error deterministic? Does the missing set of tx in ledgers vary from start to start? Or per rescan?

Yes. Always the same tx's.

2) Is there a choice of wallet filters that reveals all missing transactions? From your log file it looks like you are using only 1 wallet, but try the single wallet filter and the custom wallet filter anyways.

No. I'm using a number of wallets that may or may not be greater than 1  Seriously though, I've tried it and there's no effect on which tx's generate the error dialog, or a way of displaying all/only the affected tx's using a custom filter setting.

4) Can you try syncing Armory with one of the supported OSes? I need to make sure this isn't a Qt related issue.

Possibly, I'd have to go the Live Linux route. I'll check .7 isn't the silver bullet before trying that though.

[goatpig]

I'm 99% that Alan fixed/implemented it at some point in the past, but when that was and when it broke I cannot recall

Ok I'll look into that at some point then.

No. I'm using a number of wallets that may or may not be greater than 1  Seriously though, I've tried it and there's no effect on which tx's generate the error dialog, or a way of displaying all/only the affected tx's using a custom filter setting.

(...)

I'll check .7 isn't the silver bullet before trying that though.

I expect the missing txns in ledger and the error dialogs are 2 different issues. I have not managed to reproduce the ledger snafu, and I have reproduced and then fixed the error dialog issue, so I don't think the current state of 0.93-bugfix will fix the ledgers yet.

If you run your own builds, you can pull bugfix and try it right now, but you'll have to rescan your DB to see the effect of the error dialog fix.

Also, try the following trick to see if that fixes the ledger snafu. Comment out this line in ArmoryQt.py #3131, in finishLoadBlockchainGUI(self):

Code:

self.createCombinedLedger()

(had a # in front of it)

Start Armory and see if the ledgers work properly. Otherwise revert the change. If you don't see any ledgers at first, toy with the wallet filter and they'll appear.

[doug_armory]

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.

To some extent, this can't be fixed for now. It's another modal window issue that seems to affect some OSX programs using Qt4. You may have to resort to using the ESC key to get out of certain dialogs, using CTRL+Down to bring up windows and close them by hand, etc. Sorry! I've tried hard to fix the underlying Qt code. (If anybody has a qt.io account, feel free to upvote QTBUG-40585.)

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)

Also related to the modal window thing, although this one does have a workaround. Cancel button added.

[Carlton Banks]

I expect the missing txns in ledger and the error dialogs are 2 different issues. I have not managed to reproduce the ledger snafu, and I have reproduced and then fixed the error dialog issue

Sounds like I definitely explained it wrong: there are NO missing transactions/balance for me. None. In any 0.92.99.x testing version. But I am experiencing the tx info error dialog problem as of .99.3

[goatpig]

Sounds like I definitely explained it wrong: there are NO missing transactions/balance for me. None. In any 0.92.99.x testing version. But I am experiencing the tx info error dialog problem as of .99.3

Oh wow, I completely misinterpreted your posts then.

This is the state of 0.93-bugfix currently:

You won't get the error dialog anymore, that one is fixed for good.

You won't get a dialog at all for coinbase rewards, and I'll have to look into that eventually (possibly have to delay the fix for 0.93.1 if it's too complicated). I couldn't get these dialogs with 0.92.x so I completely ignored that feature since.

Tx details for incoming transactions, excluding those transactions that come from your own wallets, will lack sender data (it can't resolve the supporting txn hashes). You won't see the supporting txout value or fee, and the script type will be displayed as non-standard. I'm implementing the fix for that, but that's going into dev, so it'll have to wait for 0.93.1 (which has another round of DB optimizations coded in already)

[Carlton Banks]

All that sounds great. Thanks for taking time to relay this info, it's appreciated

[jammers]

Just installed it there yesterday, a few minutes for bitcoin to sync to network for the fortnight i've been away, and then less than 2 hours for it to scan and build the db's to be online. very nice!!! also, i then imported three wallets, and really like the way the percentage queues and goes through them. These only took a relatively small time, less than an hour to scan three wallets.

Sooooooo much better than old version, and makes this a lot more bearable for new users. Well done goatpig etc!!!

[jammers]

The Goto button is cut off a little. (Windows 7)

same in win 8.1

[t00tie]

Minor bug:
Looking at the Transaction Info window for a random tx, see the
'Some outputs might be "change." Click for more info'
I clicked the link which leads to https://bitcoinarmory.com/all-about-change which is "Page not found We're sorry, but the page you requested is not found."

(If anyone wants to pay a bug bounty 12aixCHSZcnNyEqhCJqnp5fhbaSjqJ6Fy2, if not I don't intend to complain )

[t00tie]

Display bug:

0.92.99.6 on win7-64

Two watching-only wallets loaded (upgraded from 0.9.3).

Transactions tab, My Wallets filter: No transactions are shown
In previous release version I saw TXs from both wallets in this view. If I choose only one wallet I see the TXs.

On closer examination it seems as if the upgrade from 0.9.3 has lost the info that both wallets are mine so it might not actually be a display bug but some config info/metadata that went missing (I deleted the old DB when asked to).

Any bug bounties or donations welcome to 12aixCHSZcnNyEqhCJqnp5fhbaSjqJ6Fy2

[t00tie]

Bug:

0.92.99.6 on win7-64
Transactions tab, My wallets filter, lots of TXs shown sorted by date desc.

Clicking column headers doesn't change sort order any more (it used to in 0.9.3, at least for the date and Amount columns).

I would really like to sort and filter (two different things) by bitcoins sent/bitcoins received. Sorting is a bug, filtering is a change request (I think).

Bounties/donations to 12aixCHSZcnNyEqhCJqnp5fhbaSjqJ6Fy2

[ba1020]

confirm Armory 0.92.99.6 works perfect on Linux amd64

unfortunately no bug

[justusranvier]

Getting this again (as of 4f8f5b4e51cd1083f46803de9d045b6b09fcbcfb):

Log file opened at 1423671626: redacted/.armory/armorycpplog.txt
-INFO  - 1423671629: (BlockUtils.cpp:778) blkfile dir: redacted/blocks
-INFO  - 1423671629: (BlockUtils.cpp:779) lmdb dir: redacted
-INFO  - 1423671629: (lmdb_wrapper.cpp:478) Opening databases...
-INFO  - 1423671629: (BlockUtils.cpp:1103) Executing: doInitialSyncOnLoad
-INFO  - 1423671629: (BlockUtils.cpp:1174) Total number of blk*.dat files: 230
-INFO  - 1423671629: (BlockUtils.cpp:1175) Total blockchain bytes: 30,747,540,070
-INFO  - 1423671629: (BlockUtils.cpp:1459) Reading headers from db
-INFO  - 1423671633: (BlockUtils.cpp:1485) Found 343038 headers in db
-DEBUG - 1423671633: (Blockchain.cpp:208) Organizing chain w/ rebuild
-WARN  - 1423671634: (BlockUtils.cpp:1203) --- Fetching SSH summaries for 1453 registered addresses
-INFO  - 1423671634: (BlockUtils.cpp:1216) Left off at file 229, offset 39008548
-INFO  - 1423671634: (BlockUtils.cpp:1219) Reading headers and building chain...
-INFO  - 1423671634: (BlockUtils.cpp:1220) Starting at block file 229 offset 39008548
-INFO  - 1423671634: (BlockUtils.cpp:1222) Block height 342976
-DEBUG - 1423671635: (Blockchain.cpp:208) Organizing chain w/ rebuild
-INFO  - 1423671636: (BlockUtils.cpp:1257) Looking for first unrecognized block
-INFO  - 1423671636: (BlockUtils.cpp:1350) Loading block data... file 229 offset 38827605
-ERROR - 1423671636: (BlockUtils.cpp:453) Next block header found at offset 38827613
-INFO  - 1423671636: (BlockUtils.cpp:481) Reading raw blocks finished at file 229 offset 40376126
-INFO  - 1423671636: (BlockUtils.cpp:1274) Wrote blocks to DB in 0.02463s
-WARN  - 1423671636: (BlockUtils.cpp:993) Scanning from 342926 to 342982
-ERROR - 1423671636: (BlockWriteBatcher.cpp:952) Header heigh&dup is not in BLKDATA DB
-ERROR - 1423671636: (BlockWriteBatcher.cpp:953) (342927, 45)
-INFO  - 1423671638: (BlockUtils.cpp:1312) Scanned Block range in 2.18092s
-INFO  - 1423671638: (BlockUtils.cpp:1315) Finished loading at file 229, offset 40376126
-INFO  - 1423671638: (BlockDataViewer.cpp:155) Enabling zero-conf tracking
-ERROR - 1423671639: (BDM_mainthread.cpp:428) BDM thread failed: BDM encountered a critical error

Good: Now a dialog box pops up and explicitly mentions the fatal BDM error, and states that a rebuild and rescan is necessary.

Bad: It's incredibly difficult to do this, because Armory starts up so rapidly that there is very little time available to navigate to that menu option before the error occurs again.

Initiating a rebuild and rescan on the next startup should be automated rather than requiring that kind of a UI race.

[goatpig]

Bad: It's incredibly difficult to do this, because Armory starts up so rapidly that there is very little time available to navigate to that menu option before the error occurs again.

I'll add a checkbox to rebuild and rescan on next start in the error dialog