Armory - Discussion Thread

[etotheipi]

It sounds like even if I don't get it right, this is an okay bug to have:  tell the user it didn't work, but it actually did.  Better than telling them it did work when it didn't, and the ensuing confusion...

I think this could cause some of its own problems, though.  If you have a user that simply trusts what the software tells them (which would be 90% of the normal population if/when bitcoin/armory gets extremely popular, luckily it's much lower while bitcoin is a niche market) they may send coins again if it says that it failed, without even looking at the history or manually checking if it really did go through.

It may be a lower priority bug for the time being, but in the long run, it's something you would want to try to find if at all possible, in my opinion.  But that's just my two cents.  

That's an excellent point.  And I didn't mean to suggest the bug was "okay", but simply that it was better than the inverse bug.  I'd still like to find a good way to resolve it... but Armory's mechanism for sending transactions does not make this totally deterministic

[1713301057]

1713301057

[1713301057]

1713301057

[1713301057]

1713301057

[cypherdoc]

he's right; you need to fix it asap.

[picobit]

Indeed.  I actually almost sent the tx again, but fortunately I was paranoid enough to actually test - and if I had done it, it would probably have been saved by being a double-spend.

Perhaps when sending a tx failed, the error message should be that the tx "appears to have failed, but please check by waiting to the next block appear (or check in blockchain.info [link to tx]" or something like this.

[etotheipi]

Indeed.  I actually almost sent the tx again, but fortunately I was paranoid enough to actually test - and if I had done it, it would probably have been saved by being a double-spend.

Perhaps when sending a tx failed, the error message should be that the tx "appears to have failed, but please check by waiting to the next block appear (or check in blockchain.info [link to tx]" or something like this.

Gah, you guys win.  I'll bump up the priority...

And unfortunately, I just hit a seg fault!       So many different conditions to test!  (this was from starting Armory in offline mode, extending the keypool while offline, then switching to online mode).  Okay, more internal testing before a testing release...

[etotheipi]

Good news!  I stumbled on a pretty significant bug, which has only popped up because of the increased network traffic in recent months (probably due to SatoshiDice).  It turns out that tx that were showing up in bundles were eating each other, and Armory wasn't actually processing half of the zero-confirmation transactions it received (and this only happens when there's high network load).  If you've been wondering why Armory doesn't always show your zero-conf transactions, that's why!  

I was tipped off by sending a tx to my Armory wallet while Armory was connected, and it didn't get the zero-conf tx.  That seemed bizarre, since I know that Bitcoin-Qt always broadcasts to all its peers.  I even checked the Armory log and saw the "inv" message for my tx... but Armory somehow never actually got the tx itself (only a notification that it exists).   Anyways, it's fixed now.  

Just a little more internal testing and I'll make a real testing release  BTW, I sent out an email to about 15 people about 1 week ago, to request testing of 0.84. If you did not receive this email, and you are willing to be put on the list, please PM or email me.  

[xcsler]

I'm trying to run Armory on Windows Vista but it takes about 30 minutes or more to load in the online mode.
I have no problems loading in the offline mode. My Bitcoin-qt client is running and all caught up.

Any suggestions are welcome!

Thanks a lot.

[etotheipi]

I'm trying to run Armory on Windows Vista but it takes about 30 minutes or more to load in the online mode.
I have no problems loading in the offline mode. My Bitcoin-qt client is running and all caught up.

Any suggestions are welcome!

Thanks a lot.

Unfortunately, I don't have a good solution for you.  I've noticed that some systems are better than others ... I get 1-2 min on my primary computer, and 6-7 min on my Windows 7 VM.  Haven't seen 30 min, yet, that does sound extreme.  What kind of HDD is the blockchain on?  What are the system specs?  I suppose it could take a really long time for Armory to go digging through 4GB of blockchain on an Athlon64 or something...



http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.84.2-almost-beta_windows.msi
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.84.2-almost-beta_i386.deb
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.84.2-almost-beta_amd64.deb

If you have a problem with the Windows version running 64-bit Windows, try the naive 64-bit version, but only do so if you have issues.

Of course, just as I released this, I discovered there is an issue creating new wallets while the blockchain is scanning... about the worst thing that could happen for new users!  I'm working on that now, but for you veterans, it shouldn't be an issue :-/

One day... I'll get all these kinks worked out...

[xcsler]

I'm running on my HP laptop with an AMD Turion Dual Core RM-72 2.10 GHz.
I also noticed a 30 min or so wait on my new iMac which is running Windows 7 on Parallels Desktop

[OpenYourEyes]

Nice work with the effort you've been putting in etotheipi.

I did switch back to BitCoin-Qt because of the specific bug I was having, but it lacks so many features which I never knew I needed that I've gone back to armory. Looking forward to the updates.

One thing I would like to see would be having the armory interface appear straight away, and it loading the blockchain (and what ever else it does during startup) in the background, informing the user that only basic operations are available until armory has fully loaded.
It would be useful so you can do basic things, like creating a new address, whilst you wait for it to become ready for full use.

[etotheipi]

Nice work with the effort you've been putting in etotheipi.

I did switch back to BitCoin-Qt because of the specific bug I was having, but it lacks so many features which I never knew I needed that I've gone back to armory. Looking forward to the updates.

One thing I would like to see would be having the armory interface appear straight away, and it loading the blockchain (and what ever else it does during startup) in the background, informing the user that only basic operations are available until armory has fully loaded.
It would be useful so you can do basic things, like creating a new address, whilst you wait for it to become ready for full use.

That's exactly what I've spent the last couple months doing!  Download the new version and try it! 

[OpenYourEyes]

Nice work with the effort you've been putting in etotheipi.

I did switch back to BitCoin-Qt because of the specific bug I was having, but it lacks so many features which I never knew I needed that I've gone back to armory. Looking forward to the updates.

One thing I would like to see would be having the armory interface appear straight away, and it loading the blockchain (and what ever else it does during startup) in the background, informing the user that only basic operations are available until armory has fully loaded.
It would be useful so you can do basic things, like creating a new address, whilst you wait for it to become ready for full use.

That's exactly what I've spent the last couple months doing!  Download the new version and try it! 

Fantastic! Compiling it now.

[etotheipi]

Nice work with the effort you've been putting in etotheipi.

I did switch back to BitCoin-Qt because of the specific bug I was having, but it lacks so many features which I never knew I needed that I've gone back to armory. Looking forward to the updates.

One thing I would like to see would be having the armory interface appear straight away, and it loading the blockchain (and what ever else it does during startup) in the background, informing the user that only basic operations are available until armory has fully loaded.
It would be useful so you can do basic things, like creating a new address, whilst you wait for it to become ready for full use.

That's exactly what I've spent the last couple months doing!  Download the new version and try it! 

Fantastic! Compiling it now.

Make sure to switch to the threading branch.   As I alluded to  in my previous post, some operations don't quite work when scanning, but I've disabled most of it.   Trying to fix the rest, now...

[xcsler]

I'm a newbie who has been playing with Armory for a couple of days and I really like it. Thanks etotheipi!
The messages, instructions, and explanations are all very clear and reassuring for someone with my level of newbieness.

The following issues did come up though (I'm not sure if they've already been mentioned in the previous 72 pages):

1) I connected my offline/cold storage computer to my printer via a USB cable but then realized that my printer does have a wireless network connection. I'm not sure if this could theoretically compromise my wallet somehow.

2) While getting comfortable deleting wallets I inadvertently restored my online watching-only wallet with the backup of my offline cold-storage wallet. Perhaps some type of warning could pop up in the future to alert me that I'm about to restore a non-watching wallet. Alternatively, I could use my brain and be more careful.

3) I noticed that when scrolling over the wallet icons with the green or red arrow in the ledger a "bitcoins received" textbox pops up for both icons. There is no "bitcoins sent" textbox.

Thanks again.

[OpenYourEyes]

Nice work with the effort you've been putting in etotheipi.

I did switch back to BitCoin-Qt because of the specific bug I was having, but it lacks so many features which I never knew I needed that I've gone back to armory. Looking forward to the updates.

One thing I would like to see would be having the armory interface appear straight away, and it loading the blockchain (and what ever else it does during startup) in the background, informing the user that only basic operations are available until armory has fully loaded.
It would be useful so you can do basic things, like creating a new address, whilst you wait for it to become ready for full use.

That's exactly what I've spent the last couple months doing!  Download the new version and try it! 

Fantastic! Compiling it now.

Make sure to switch to the threading branch.   As I alluded to  in my previous post, some operations don't quite work when scanning, but I've disabled most of it.   Trying to fix the rest, now...

Not had a chance to try it yet, I keep getting an error during compilation I've not been able to fix.

g++: error: /usr/lib/libpython2.7.a: No such file or directory

I'll have a poke around later on to see if I can resolve it.

[Red Emerald]

I just refreshed my offline laptop (Ubuntu 12.04.1 with no blockchain and no network connection), and I was getting an error when opening Armory.  I get "UnboundLocalError: local variable 'lblText' referenced before assignment" on line 2957 of ArmoryQt.py

I needed to change the first "+=" to " =" and it worked!

I'm testing wallet imports and new wallets and such. I'll let you know if I find anything else.

I'm in offline mode, but it looks like it still tried to check http://bitcoinarmory.com/versions.txt.  You should also sign versions.txt, and maybe check https instead.

EDIT: Wallet imports went well! Detected and corrected my typos perfectly! Although a loading screen while the wallet is being created would be nice.  After I enter my new passphrase it just sits for a little bit.  It would also be nice if it asked me for a name.

[picobit]

Not had a chance to try it yet, I keep getting an error during compilation I've not been able to fix.

g++: error: /usr/lib/libpython2.7.a: No such file or directory

I'll have a poke around later on to see if I can resolve it.

If you use some kind of Linux, you probably need to install the python-dev package (the name may vary, it contains stuff to compile Python extensions).

[etotheipi]

I'm a newbie who has been playing with Armory for a couple of days and I really like it. Thanks etotheipi!
The messages, instructions, and explanations are all very clear and reassuring for someone with my level of newbieness.

The following issues did come up though (I'm not sure if they've already been mentioned in the previous 72 pages):

1) I connected my offline/cold storage computer to my printer via a USB cable but then realized that my printer does have a wireless network connection. I'm not sure if this could theoretically compromise my wallet somehow.

2) While getting comfortable deleting wallets I inadvertently restored my online watching-only wallet with the backup of my offline cold-storage wallet. Perhaps some type of warning could pop up in the future to alert me that I'm about to restore a non-watching wallet. Alternatively, I could use my brain and be more careful.

3) I noticed that when scrolling over the wallet icons with the green or red arrow in the ledger a "bitcoins received" textbox pops up for both icons. There is no "bitcoins sent" textbox.

Thanks again.

(1)  I'm sure there's a vulnerability there... but luckily I don't think the printer drivers were designed to forward traffic.  I bet if someone on the other side of the network was really good, they could detect when an Armory backup is printing and figure out how to extract it...  But I would put that low on my list of serious concerns (at least, for regular users)

(2) I can't really prevent that.  There's nothing that flags the wallet as having the intention of being online or offline, and a lot of times, the user may just be tired of using offline wallets and want to bring it online-encrypted.  I mean, an "offline wallet" is just a regular wallet.  What makes it "offline" is the system on which it is loaded.

(3) That should be an easy fix.  I'll check on it.

Not had a chance to try it yet, I keep getting an error during compilation I've not been able to fix.

g++: error: /usr/lib/libpython2.7.a: No such file or directory

For reasons described somewhere in the last 72 pages, I static compile python into the C++ utilities, but not all systems have the static libraries.  However, if you modify the Makefile to look for .so instead of .a, it will work.   I should try to add an autodetect branch in the Makefile to automatically do that.  Alternatively, if you are using Ubuntu, installing python-dev should resolve it.

I just refreshed my offline laptop (Ubuntu 12.04.1 with no blockchain and no network connection), and I was getting an error when opening Armory.  I get "UnboundLocalError: local variable 'lblText' referenced before assignment" on line 2957 of ArmoryQt.py

I needed to change the first "+=" to " =" and it worked!

Oh yeah.  Whoops.  Will be fixed in the next attempt of a release...

I'm testing wallet imports and new wallets and such. I'll let you know if I find anything else.

I'm in offline mode, but it looks like it still tried to check http://bitcoinarmory.com/versions.txt.  You should also sign versions.txt, and maybe check https instead.

EDIT: Wallet imports went well! Detected and corrected my typos perfectly! Although a loading screen while the wallet is being created would be nice.  After I enter my new passphrase it just sits for a little bit.  It would also be nice if it asked me for a name.

Yeah, I'm not that advanced yet.  I don't have an SSL cert for the site, and I intentionally did not do any kind of automatic updates so that if it was hijacked, the user still has a chance to figure it out.  I should do all this, but it's not my priority, yet.

The waiting screens are tough to implement, not because I don't know how, but because I don't always know what's going to take a while.  I guess it doesn't hurt to just always have it, and worst case it will pop up for a fraction of a sec...


So, right now my Achilles heel is modifying wallets and/or messing with the BDM while it is scanning.  I thought I had accommodated that in the multi-threaded design (every request just gets added to a queue to be processed next time the BDM isn't busy), but it's been causing seg faults -- I think because things keep getting called out of order relative to how I intended.  I've been trying to work around it... but I think I need to just buckle down and figure it out once and for all.  It would be nice to re-enable key importing/sweeping and creating wallets while the user is waiting for that initial scan.  There's only so long I can work around it!

[Red Emerald]

So my hot wallet causes a segfault.  Armory crashes with both the full and watching-only wallet when online.  I've tested in both OSX and Ubuntu 12.04.

Should I send the watching-only to you, or do you have some logs you want me to send?

[etotheipi]

So my hot wallet causes a segfault.  Armory crashes with both the full and watching-only wallet when online.  I've tested in both OSX and Ubuntu 12.04.

Should I send the watching-only to you, or do you have some logs you want me to send?

Send a log first.  If I can't get what I need, I'll ask for the hot wallet.

[Red Emerald]

So my hot wallet causes a segfault.  Armory crashes with both the full and watching-only wallet when online.  I've tested in both OSX and Ubuntu 12.04.

Should I send the watching-only to you, or do you have some logs you want me to send?

Send a log first.  If I can't get what I need, I'll ask for the hot wallet.

Well the log is just "Segmentation fault (core dumped)"