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

[TimS]

I noticed this little # symbol in the lower left corner of the transaction window. When I hover over it, it expands and tells me where I am in the list. Is this meant to be just a debug thing that should be taken out before final release of 0.93?

Armory's startup time is lower than I can ever remember it being before.

Yep, truly impressive, even when loading a supernode from an HDD.

Armory's startup time is lower than I can ever remember it being before.

How about the (reliably instant) shutdown time also? 0.92.3 can take several minutes to quit if you're unlucky.

So far, so good. But then, maybe I've just been lucky?

[1714644947]

1714644947

[1714644947]

1714644947

[1714644947]

1714644947

[1714644947]

1714644947

[etotheipi]

Armory's startup time is lower than I can ever remember it being before.

Yep, truly impressive, even when loading a supernode from an HDD.

I noticed this little symbol in the lower left corner of the transaction window. When I hover over it, it expands and tells me where I am in the list. Is this meant to be just a debug thing that should be taken out before final release of 0.93?

Heh, we've been debating this widget forever.  I'm not a big fan of its placement, but it is intended to be a permanent fixture.  The idea is that for huge wallet histories, you can use that widget to go to any point in the history (we've been testing with 1VayNert and it definitely helps get through the 10,000 pages of tx history).  You can click on the block or time to manually type/select where you want to go.  Or just click "Top". 

Glad to hear the positive feedback about the changes.  We knew this was going to be a rough testing round given how much has changed under the hood, but it does appear to be wrapping up nicely, and I think 0.93 really is a huge step forward for Armory, especially as an option for exchanges and webservices that need a strong API to the network.

[japerry]

Not a horrible problem but... I've been playing with .5 on Windows 7. If you try to restore a wallet from digital backup Armory prompts for the file name twice. Like I said not terrible. It works, but you have to answer the file name prompt twice.

[goatpig]

I noticed this little # symbol in the lower left corner of the transaction window. When I hover over it, it expands and tells me where I am in the list. Is this meant to be just a debug thing that should be taken out before final release of 0.93?

I've originally developed that as a proof of concept to demonstrate the on-the-fly transaction history paging system the new backend runs on (the previous one would keep all history in RAM on both the C++ and Python side). I didn't expect it would get rolled in this early, but in the end it was better than the piss poor page browsing UI I added the first time around (that huge input box at the bottom on the transaction table in the lobby).

The widget is meant to let you center the transaction table by time or block height, and it was heavily influenced by the large wallet I was developing this around (with 1VayNert and 1ExOdUs, some ~80k pages). I'm not much of UI guru and I would welcome any feedback and suggestions on this feature. One of the reason we released it as it stand is that the simplest way to improve user experience is the let the users tell us what they think.

[goatpig]

Not a horrible problem but... I've been playing with .5 on Windows 7. If you try to restore a wallet from digital backup Armory prompts for the file name twice. Like I said not terrible. It works, but you have to answer the file name prompt twice.

Most likely related to some changes trying to improve the OSX file browser, we'll get it under control.

[etotheipi]

Armory's startup time is lower than I can ever remember it being before.

Yep, truly impressive, even when loading a supernode from an HDD.

I noticed this little symbol in the lower left corner of the transaction window. When I hover over it, it expands and tells me where I am in the list. Is this meant to be just a debug thing that should be taken out before final release of 0.93?

Heh, we've been debating this widget forever.  I'm not a big fan of its placement, but it is intended to be a permanent fixture.  The idea is that for huge wallet histories, you can use that widget to go to any point in the history (we've been testing with 1VayNert and it definitely helps get through the 10,000 pages of tx history).  You can click on the block or time to manually type/select where you want to go.  Or just click "Top". 

Glad to hear the positive feedback about the changes.  We knew this was going to be a rough testing round given how much has changed under the hood, but it does appear to be wrapping up nicely, and I think 0.93 really is a huge step forward for Armory, especially as an option for exchanges and webservices that need a strong API to the network.

Okay, a contest.  Extra 2 bounties for the winner!

Wtf do we do with the paging control widget?  Since writing the above message, we have spent even more time debating this.  The problem stems from the fact that
- If it's placed on the tableview itself, it obstructs things (or at least, it annoys me), and the user may not want/need it
- If it's placed outside the tableview, then the dialog must have extra space to put it.   Not a problem for the main window, but it will need to be placed for the wallet address ledger and the lockbox ledger.  Both those dialogs are short on space.

Obviously we want it to be available for those that need it, and it shouldn't be a easter-egg... it should be easily accessible for users that want it (i.e. we don't want to have a feature then get emails asking for us to implement it because they don't realize it's there).

One option is to leave it where it is, but add a setting to allow the user to disable/hide it.  That's probably the easiest to implement, and not a bad choice.  I'll give an extra two bounties to whoever provides and idea that we like enough to implement.  If you have a transaction history of 1,000,000 rows, spanning multiple years, how would you like to navigate that history?  And if you switch the filter to a wallet that has only one page of history, what happens to that control?  Should it be hidden, moved, or left where it is?  Should it be totally user configurable.

Ideally, whatever it is can be non-intrusive enough to have visible all the time and not inconvenience users that have small transaction histories and/or don't need the fancy controls.

[helgabutters]

1) Exporting transactions doesn't actually export the file until you've done it a second time. "File" > "Export Transactions" > "Export" will make a file that will be 0 bytes in size. Now do the same thing again but select a different wallet to output, the first file will now be filled in properly and the new file will be 0 bytes in size. This cycle continues with every new file that is created being 0 bytes until another export has been done. This also shows up in the error log:
 

Code:

(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/qtdialogs.py", line 9589, in accept
    if self.createFile_CSV():
  File "/usr/lib/armory/qtdialogs.py", line 9723, in createFile_CSV
    combinedLedger = walletGroup.getHistoryPage(page)
  File "/usr/lib/armory/CppBlockUtils.py", line 2046, in getHistoryPage
    def getHistoryPage(self, *args): return _CppBlockUtils.WalletGroup_getHistoryPage(self, *args)
TypeError: WalletGroup_getHistoryPage() takes exactly 4 arguments (2 given)

Traceback (most recent call last):
  File "/usr/lib/armory/qtdialogs.py", line 9589, in accept
    if self.createFile_CSV():
  File "/usr/lib/armory/qtdialogs.py", line 9723, in createFile_CSV
    combinedLedger = walletGroup.getHistoryPage(page)
  File "/usr/lib/armory/CppBlockUtils.py", line 2046, in getHistoryPage
    def getHistoryPage(self, *args): return _CppBlockUtils.WalletGroup_getHistoryPage(self, *args)

2) Can't restore from fragmented backups. "Import or Restore Wallet" > "Fragmented Backup" > "Continue"

Code:

(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/qtdialogs.py", line 12243, in clickedOkay
    dlg = DlgRestoreFragged(self.parent, self.main, doTest)
  File "/usr/lib/armory/qtdialogs.py", line 12921, in __init__
    doItText = tr('Test Backup' if thisIsATest else tR('Restore from Fragments'))
NameError: global name 'tR' is not defined

Traceback (most recent call last):
  File "/usr/lib/armory/qtdialogs.py", line 12243, in clickedOkay
    dlg = DlgRestoreFragged(self.parent, self.main, doTest)
  File "/usr/lib/armory/qtdialogs.py", line 12921, in __init__
    doItText = tr('Test Backup' if thisIsATest else tR('Restore from Fragments'))
NameError: global name 'tR' is not defined

[doug_armory]

Not a horrible problem but... I've been playing with .5 on Windows 7. If you try to restore a wallet from digital backup Armory prompts for the file name twice. Like I said not terrible. It works, but you have to answer the file name prompt twice.

Most likely related to some changes trying to improve the OSX file browser, we'll get it under control.

Gaaaaah, you're right, I forgot to clean something up when reverting the OS X fix. Will fix it right away.

[helgabutters]

1) In the paging control widget if you put a negative "-" in the block number and hit enter nothing happens and this is the log:

Code:

(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 784, in blkEditingFinished
    self.Blk = self.ledgerDelegate.getBlockInVicinity(blk)
  File "/usr/lib/armory/CppBlockUtils.py", line 1937, in getBlockInVicinity
    def getBlockInVicinity(self, *args): return _CppBlockUtils.LedgerDelegate_getBlockInVicinity(self, *args)
OverflowError: in method 'LedgerDelegate_getBlockInVicinity', argument 2 of type 'uint32_t'

Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 784, in blkEditingFinished
    self.Blk = self.ledgerDelegate.getBlockInVicinity(blk)
  File "/usr/lib/armory/CppBlockUtils.py", line 1937, in getBlockInVicinity
    def getBlockInVicinity(self, *args): return _CppBlockUtils.LedgerDelegate_getBlockInVicinity(self, *args)
OverflowError: in method 'LedgerDelegate_getBlockInVicinity', argument 2 of type 'uint32_t'
(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 784, in blkEditingFinished
    self.Blk = self.ledgerDelegate.getBlockInVicinity(blk)
  File "/usr/lib/armory/CppBlockUtils.py", line 1937, in getBlockInVicinity
    def getBlockInVicinity(self, *args): return _CppBlockUtils.LedgerDelegate_getBlockInVicinity(self, *args)
OverflowError: in method 'LedgerDelegate_getBlockInVicinity', argument 2 of type 'uint32_t'

Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 784, in blkEditingFinished
    self.Blk = self.ledgerDelegate.getBlockInVicinity(blk)
  File "/usr/lib/armory/CppBlockUtils.py", line 1937, in getBlockInVicinity
    def getBlockInVicinity(self, *args): return _CppBlockUtils.LedgerDelegate_getBlockInVicinity(self, *args)
OverflowError: in method 'LedgerDelegate_getBlockInVicinity', argument 2 of type 'uint32_t'

2) In the paging control widget if you put letters in the block number and hit enter nothing happens and this is the log:

Code:

(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 783, in blkEditingFinished
    blk = int(self.edtBlock.text())
ValueError: invalid literal for int() with base 10: '320592pp'

Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 783, in blkEditingFinished
    blk = int(self.edtBlock.text())
ValueError: invalid literal for int() with base 10: '320592pp'
(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 783, in blkEditingFinished
    blk = int(self.edtBlock.text())
ValueError: invalid literal for int() with base 10: '320592pp'

Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 783, in blkEditingFinished
    blk = int(self.edtBlock.text())
ValueError: invalid literal for int() with base 10: '320592pp'

3) In the paging control widget if you set the year to something old, such as 1750, you get the following error:

Code:

(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 703, in linkClicked
    self.editDate()
  File "/usr/lib/armory/armorymodels.py", line 780, in editDate
    self.dateChanged()
  File "/usr/lib/armory/armorymodels.py", line 794, in dateChanged
    self.Date = int(time.mktime(ddate.timetuple()))
ValueError: year out of range

Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 703, in linkClicked
    self.editDate()     
  File "/usr/lib/armory/armorymodels.py", line 780, in editDate
    self.dateChanged()
  File "/usr/lib/armory/armorymodels.py", line 794, in dateChanged
    self.Date = int(time.mktime(ddate.timetuple()))
ValueError: year out of range

4) In the paging control widget if you click on the date and in the new window select the year, put a negative "-" in the year (such as -2014) and select a date:

Code:

(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 703, in linkClicked
    self.editDate()
  File "/usr/lib/armory/armorymodels.py", line 780, in editDate
    self.dateChanged()
  File "/usr/lib/armory/armorymodels.py", line 796, in dateChanged
    self.Blk = TheBDM.bdv().getClosestBlockHeightForTime(self.Date)
  File "/usr/lib/armory/CppBlockUtils.py", line 2012, in getClosestBlockHeightForTime
    def getClosestBlockHeightForTime(self, *args): return _CppBlockUtils.BlockDataViewer_getClosestBlockHeightForTime(self, *args)
OverflowError: in method 'BlockDataViewer_getClosestBlockHeightForTime', argument 2 of type 'uint32_t'

Traceback (most recent call last):
  File "/usr/lib/armory/armorymodels.py", line 703, in linkClicked
    self.editDate()     
  File "/usr/lib/armory/armorymodels.py", line 780, in editDate
    self.dateChanged()
  File "/usr/lib/armory/armorymodels.py", line 796, in dateChanged
    self.Blk = TheBDM.bdv().getClosestBlockHeightForTime(self.Date)
  File "/usr/lib/armory/CppBlockUtils.py", line 2012, in getClosestBlockHeightForTime
    def getClosestBlockHeightForTime(self, *args): return _CppBlockUtils.BlockDataViewer_getClosestBlockHeightForTime(self, *args)
OverflowError: in method 'BlockDataViewer_getClosestBlockHeightForTime', argument 2 of type 'uint32_t'

5) In the paging control widget, if you are not already scrolled to the top, click on "#" > "Block" as if you were going to edit it and then click on "Top". The widget will end up horizontally spanning across all the transactions.

https://i.imgur.com/REulQFi.png

[japerry]

Is there any way to "sort" the wallet's in the main display? I know it's being trivial and anal on my part but I'd like to see the wallets presented in a certain order. For instance I'd like to see the wallets presented alphabetically by name or by type with "Watch-Only" wallets at the bottom of the wallet list. As I see it now wallets are displayed by ID so it's a toss-up as to where the wallet gets placed in the display after creation.

[zombieslayer9099]

When creating a transaction from a lockbox, or any transaction that will be unsigned, offline, or just not broadcast at the moment, I cannot close the transaction window. I click the X but it does absolutely nothing. Please add a Close or Cancel button to these windows.

Also regarding the little paging widget, instead of obstructing the transactions, I think it should be made into text boxes below transactions like before and a button to update the screen, maybe a Go To button or something like that

[goatpig]

Is there any way to "sort" the wallet's in the main display? I know it's being trivial and anal on my part but I'd like to see the wallets presented in a certain order. For instance I'd like to see the wallets presented alphabetically by name or by type with "Watch-Only" wallets at the bottom of the wallet list. As I see it now wallets are displayed by ID so it's a toss-up as to where the wallet gets placed in the display after creation.

No such thing currently, we could consider adding a filter for wallet names on top of IDs.

When creating a transaction from a lockbox, or any transaction that will be unsigned, offline, or just not broadcast at the moment, I cannot close the transaction window. I click the X but it does absolutely nothing. Please add a Close or Cancel button to these windows.

I can't reproduce that, can you elaborate on the exact steps and the dialog displaying this behavior? Also this is possibly a OSX thing only.

[doug_armory]

When creating a transaction from a lockbox, or any transaction that will be unsigned, offline, or just not broadcast at the moment, I cannot close the transaction window. I click the X but it does absolutely nothing. Please add a Close or Cancel button to these windows.

Can you provide more exact directions? I can't seem to reproduce this. That said, my suspicion is that, for whatever reasons, this is a Qt issue. I ran into something like this before with Qt 4.8.6. The upgrade to 4.8.7 helped me but doesn't seem to help other people. There's really not much that can be done for now, other than adding the button. You may want to try hitting the escape button. That helped me sometimes when I got stuck.

Also, please check your PMs. I sent one awhile back.

[picobit]

I just tried the newest version (Mac OS X version 10.9.5).

The good news is that building the first database was much faster than it used to be, and that starting up second time was lightning fast.

The bad news is that paper backups do not work.  When I click on the Print button, the OS X print menu comes up, but it is almost unresponsive.  Sometimes it can be cancelled, and once I managed to open the sub-menu and choosing PDF preview (which never came up).  I remember this being a problem once in the past too, but then the problem appeared to go away.

EDIT:  Then I tried to actually make a transaction.  I got this strange error:

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.

What can this possibly mean?
I get this every time I try to make a transaction

EDIT 2:
I could not export the log file (menu item greyed out).  In fact, Armory was completely stuck, had to Force Quit it to get away from the send bitcoin window.  Now it rescans the database, good thing that it takes minutes instead of an hour or two as in the previous version
I exported the log file while it did that, there is no hint of trouble there.

EDIT 3:
I cannot reproduce it.  Once Armory had finished rescanning, I tried again, this time without problems.

I really wonder what kind of "quirk in the way Bitcoin transactions work" this pop-up is supposed to be triggered by...

[goatpig]

I suspect this is a OSX playing nasty with Qt kind of error which eventually trickled down into triggering that error message.

[knahrvorn]

Should it be hidden, moved, or left where it is?  Should it be totally user configurable.

Ideally, whatever it is can be non-intrusive enough to have visible all the time and not inconvenience users that have small transaction histories and/or don't need the fancy controls.

I think this would be best achieved with the widget staying where it is, but make it very transparent, almost invisible. Then, when the user hovers the mouse in the vicinity (maybe 100 pixels) of the widget, it becomes opaque. Make that one setting, and then opaque all the time another. And maybe disabled completely a third. Just my 5 cents.

[bitpop]

May I suggest a selected wallet filter

[helgabutters]

1) (Supernode) "Import Lockbox" > "Done". The "Import Successful" window has the text "If the lockbox is not new and has been used before, Armory will not know about its history until you rescan the databases" which isn't true in supernode.

2) In Lockboxes, select a lockbox and then use the arrow keys up or down. The bitcoin address displayed will not update but when you go to click on almost everything you are actually using the new wallet. You need to click on the lockbox to update the displayed address.

3) "Lockbox" > Check "Simul" > "Merge Promissory Notes" doesn't provide any warning if you create a transaction and don't provide a fee.

[TimS]

Can an Armory data dir/DB be shared between Windows and Ubuntu, e.g. in a VM or dual-boot setup? I tried to have Bitcoin and Armory share (via Shared Folders, Ubuntu is the guest) with Oracle VM VirtualBox and had issues with both.

This was in the log (note that the path there is correct):
-ERROR - 1422668995: (BDM_mainthread.cpp:429) BDM thread failed: Failed to open db /media/sf_Armory/databases/blocks (Invalid argument)

And then when I tried to open it in Windows later, it was corrupt:


Currently doing a rebuild/rescan like it suggested.

[doug_armory]

The bad news is that paper backups do not work.  When I click on the Print button, the OS X print menu comes up, but it is almost unresponsive.  Sometimes it can be cancelled, and once I managed to open the sub-menu and choosing PDF preview (which never came up).  I remember this being a problem once in the past too, but then the problem appeared to go away.

I can't fully reproduce this. I did see a bit of odd behavior and did see a Qt-related crash at one point. Still, I was able to print a paper backup.

Based off what I've seen here and elsewhere, I believe the problem has to do with how Qt handles modal windows. There's just something inherently broken in Qt4 for OSX that the team refuses to fix, and will never fix. (4.8.7 will supposedly be the last Qt4 release.) I had to port over some fixes from Qt5 awhile back just to make Armory reasonably stable. It seems these fixes aren't enough, unfortunately. For me, the fixes are pretty good. For others, they're not enough. Short of an upgrade to Qt5, I doubt there's much I can do, unfortunately. If anybody wants to take a crack and submit some pull requests, I'll be happy to take a look. Otherwise, it is what it is.