Has anyone looked at my post about armoryd: https://bitcointalksearch.org/topic/m.10204608 ?
Should I not get my hopes up for armoryd? Or should I maybe pay to have these issues addressed?
Topic: Armory 0.93 testing release! (with 0.05 BTC bug bounty) - page 9. (Read 35768 times)
Coin control seems to be broken in 0.93bugfix atm. I get:
"There was an error constructing your transaction due to a quirk in the way bitcoin transactions work. If you see this error more than once try sending your BTC in two or more separate transactions."
"There was an error constructing your transaction due to a quirk in the way bitcoin transactions work. If you see this error more than once try sending your BTC in two or more separate transactions."
Agreed, it's hardly priority if alot of extra Db coding is needed. I'm contemplating whether such code could be re-used to offer an extended public key view with sorting re-enabled in future, so it can at least be left until after the new wallet format happens.
The threading, signaling and UI interfacing can be leveraged, but I suspect each filter needs to be developed individually.
Agreed, it's hardly priority if alot of extra Db coding is needed. I'm contemplating whether such code could be re-used to offer an extended public key view with sorting re-enabled in future, so it can at least be left until after the new wallet format happens.
I can confirm the first issue is fixed in current 0.93 testing branch for me. 2nd issue remains though.
This isn't broken per say, it's disabled. The previous version of Armory kept all history in RAM both on the C++ and Python side. This allowed for ledger sorting on the Python side, but was slow and mainly, it scaled poorly.
To implement proper scalability, there is no more history saved on the Python side. The only thing kept in RAM is the few ledger entries currently displayed in the ledger. The C++ side only keeps a snapshot of transaction count per block range, and builds pages of transaction ledgers on demand.
To offer other type of filters (such as ordering by transaction amount or address comment) will require constructing dedicated history summaries for each filter type. It is doable but requires a lot of extra work to put it in place. Indeed, the filter by block height is very fast to compute, as transaction history is keyed by block height in the DB. As such, the summary for each address and wallet is computed in the main backend thread, after the DB has been initialized.
More sophisticated filters such as ordering by value can't be preprocessed as easily. You would need to compute the full address and wallet ledgers to know the exact transaction value for each. Not only does it require extra code to achieve this, the operation is also too slow to let it run in the main backend thread. It would dramatically slow startup speed otherwise. As a result they would have to be computed in parallel, and some UI needs to be added to inform the user of the filter availability, kind of like the consistency check.
That's too much effort for the benefit considering our current priority queue, so you shouldn't expect to see this feature back in the near future.
- 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
I can confirm the first issue is fixed in current 0.93 testing branch for me. 2nd issue remains though.
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
Getting this again (as of 4f8f5b4e51cd1083f46803de9d045b6b09fcbcfb):
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.
Quote
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
-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.
confirm Armory 0.92.99.6 works perfect on Linux amd64
unfortunately no bug
unfortunately no bug
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
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
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
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
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)
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
) The Goto button is cut off a little. (Windows 7)
same in win 8.1
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!!!
Sooooooo much better than old version, and makes this a lot more bearable for new users. Well done goatpig etc!!!
All that sounds great. Thanks for taking time to relay this info, it's appreciated
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)
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
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.)
Quote
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. 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.
Quote
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.
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()
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.
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
Quote
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.
Jump to: