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

[zombieslayer9099]

I have one more small request. Can the minimum required addresses for lockbox creation be lowered to 1? I've got a multisig address that i generated in vanitygen and I can't use it. I don't know how to create it through Bitcoin Qt either

I'm not sure what you mean by 1. 1-of-1 multisig address? That would be a simple P2PKH. 1-of-N? You would still need the N addresses to either fund the multisig script or redeem the P2SH script. What you have is probably a P2SH address (starts with 3?). What are the underlying addresses? You would have to import their respective private keys to your wallets and create a lockbox from that.

The only bug I can find in .6 is when I click View Details after right clicking a TX, Armory still displays transaction inputs on all incoming transactions only as Non-Standard: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy when that is never the case. All outgoing transactions and any incoming transactions that have inputs from my wallets or lockboxes display normally, and it does this on my Ubuntu VM as well. This isn't a major issue but it does bother me a lot.

Addresses starting with 3 are P2SH. Does it do it on addresses starting with 1?

1. Yes, vanitygen script address
2. It does this on all incoming transactions, except for those which have inputs from my wallets/lockboxes.

Also Armory keeps saying in a dialog box 'The scanning process halted unexpectedly' or something like that. I tried rebuilding but it said that again. I'm on my 2nd rebuild and rescan.

[1713503475]

1713503475

[1713503475]

1713503475

[TimS]

(Windows 7, 0.92.99.5) When I try to import a lockbox from a file and select a file, the open file dialog quickly closes and reopens. If I select a file from this reopened dialog, it works correctly (puts the second file's content into the window so that I can import it).

That should be fixed in upcoming .6

Indeed it is, which made me find a new bug: On importing a lockbox, I get the following message:

I'm running a supernode, so it doesn't actually need to rescan anything.

[goatpig]

(Windows 7, 0.92.99.5) When I try to import a lockbox from a file and select a file, the open file dialog quickly closes and reopens. If I select a file from this reopened dialog, it works correctly (puts the second file's content into the window so that I can import it).

That should be fixed in upcoming .6

Indeed it is, which made me find a new bug: On importing a lockbox, I get the following message:

I'm running a supernode, so it doesn't actually need to rescan anything.

Actually, it doesn't need to say that in any mode anymore. I'll nuke that dialog.

[TimS]

The main header says that Armory is disconnected, the status bar says that it is connected.
According to Bitcoin Core, the current block is 342339 (matching Armory) and Armory is not one of the peers connected to it (Bitcoin Core is at the max connections, so I get why Armory isn't connected currently).
It appears that Armory is not connected, but is still keeping up to date somehow...by reading the blocks from disk, maybe? It's odd that the messages don't seem to match. Is this a bug?
Edit: Since posting, Bitcoin Core has received block 342340, and now Armory says "Disconnected" in the status bar.
Edit 2: Now at block 342348, and Armory shows up like my image above ("Armory is disconnected" and "Connected (342348 blocks)").

Also, the "br>" is still visible.

[TimS]

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

[goatpig]

The main header says that Armory is disconnected, the status bar says that it is connected.
According to Bitcoin Core, the current block is 342339 (matching Armory) and Armory is not one of the peers connected to it (Bitcoin Core is at the max connections, so I get why Armory isn't connected currently).
It appears that Armory is not connected, but is still keeping up to date somehow...by reading the blocks from disk, maybe? It's odd that the messages don't seem to match. Is this a bug?
Edit: Since posting, Bitcoin Core has received block 342340, and now Armory says "Disconnected" in the status bar.

That's a simple UI signaling miss, easy fix.

As for Armory's maintenance routine: the backend polls the blkxxxxx.dat files to detect new blocks. The part of the UI you are looking at (the dashboard) is updated through both reactor signals (polling the socket to the local Core instance, from the Python side) and backend signals. The state you are observing with the disconnected message in the bottom right corner is reactor failing to maintain the socket to Core. However the backend maintenance thread is still running and doesn't care for the socket's state.

In this situation, the dashboard will report you as disconnected, and you won't get ZC transactions in the ledger, but any new transaction with at least 1 confirmation will be properly displayed in the ledger, since the backend maintenance thread is still doing its job.

The simplest way I found to avoid this state is to add addnode=127.0.0.1 to your bitcoin.conf to guarantee Core will reserve a socket for your local instance of Armory.

[zombieslayer9099]

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.

[goatpig]

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.

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

[zombieslayer9099]

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.

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

Yea, turns out the backend was stuck, my mistake

[TimS]

(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

Code:

2015-02-07 10:09 (ERROR) -- PyBtcWallet.pyc:2523 - The computed private key address is already in your wallet!

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").

[TimS]

(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.

[goatpig]

(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.

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.

[jammers]

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

[zombieslayer9099]

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

[goatpig]

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

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.

[zombieslayer9099]

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)

[goatpig]

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.

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

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?

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.

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)

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

[TimS]

Question to the folks who've been testing 0.93 the most:  what are your biggest remaining concerns with this release?  If I told you I was going to release the software after fixing the tx export problem (which will be in a .6 release in the next 24 hours), what would you complain about the most?  No version of Armory is perfect, and at some point we have to say "pencils down", as long as there's no security or major usability issues.

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

[Carlton Banks]

Question to the folks who've been testing 0.93 the most:  what are your biggest remaining concerns with this release?  If I told you I was going to release the software after fixing the tx export problem (which will be in a .6 release in the next 24 hours), what would you complain about the most?

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)

[goatpig]

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?