Armory - Discussion Thread

[Ploo]

Redownloaded windows-all and 64 bit for good measure. Uninstalled and removed Armory as you said and reinstalled - same issue. The 64-bit obviously gave a 'not valid win32 app' error.

This is frustrating - really want to get an offline wallet going. Maybe I should man up and just use ubuntu.

[etotheipi]

Redownloaded windows-all and 64 bit for good measure. Uninstalled and removed Armory as you said and reinstalled - same issue. The 64-bit obviously gave a 'not valid win32 app' error.

This is frustrating - really want to get an offline wallet going. Maybe I should man up and just use ubuntu.

While I do generally approve of Ubuntu/Linux, in general, that doesn't change the fact that the App should work on Windows XP.  I'm not sure what could be causing it...

Maybe try installing MSVC++ Redistributable 2008.  Perhaps that will put a usable msvcp90.dll file into your system32 dir.  (you can copy it into the Armory directory to be sure).  I really going out on a limb, though...

[Cryptoman]

I'm having an issue with creating/using a new address (version 0.86/Linux).  I have a wallet with two addresses (neither imported).  When I add a third address using Receive Bitcoins, everything seems to go fine and then I copy the address and close the wallet.  I sent some BTC to that address but didn't see any acknowledgement on the main screen.  I open the wallet again, and the address is gone!  It was definitely there on the third line when I closed the wallet.  So then I create a new address and it gives me the same address again!  Whew, I thought I lost those coins.  I then add the new address and see all three in the wallet again.  Just to be safe, I printed out all the individual keys.

Then I close the app and restart it.  The third key is gone again!  I tried to import the key from the backup, and it says the key is already in the wallet.  I click the Receive Bitcoins button and the same address reappears.  I close the wallet and reopen it, and the address is gone again.  Then, just as I am typing this, I see a transaction appear with that address on the main (Transactions) screen with one confirmation.  I look in the wallet and the address is there, hopefully for good. This is the first time I have seen this sort of behavior.

[gweedo]

I'm having an issue with creating/using a new address (version 0.86/Linux).  I have a wallet with two addresses (neither imported).  When I add a third address using Receive Bitcoins, everything seems to go fine and then I copy the address and close the wallet.  I sent some BTC to that address but didn't see any acknowledgement on the main screen.  I open the wallet again, and the address is gone!  It was definitely there on the third line when I closed the wallet.  So then I create a new address and it gives me the same address again!  Whew, I thought I lost those coins.  I then add the new address and see all three in the wallet again.  Just to be safe, I printed out all the individual keys.

Then I close the app and restart it.  The third key is gone again!  I tried to import the key from the backup, and it says the key is already in the wallet.  I click the Receive Bitcoins button and the same address reappears.  I close the wallet and reopen it, and the address is gone again.  Then, just as I am typing this, I see a transaction appear with that address on the main (Transactions) screen with one confirmation.  I look in the wallet and the address is there, hopefully for good. This is the first time I have seen this sort of behavior.

This only happens when armory is reading the blockchain and you try and add an address.

[etotheipi]

I'm having an issue with creating/using a new address (version 0.86/Linux).  I have a wallet with two addresses (neither imported).  When I add a third address using Receive Bitcoins, everything seems to go fine and then I copy the address and close the wallet.  I sent some BTC to that address but didn't see any acknowledgement on the main screen.  I open the wallet again, and the address is gone!  It was definitely there on the third line when I closed the wallet.  So then I create a new address and it gives me the same address again!  Whew, I thought I lost those coins.  I then add the new address and see all three in the wallet again.  Just to be safe, I printed out all the individual keys.

Then I close the app and restart it.  The third key is gone again!  I tried to import the key from the backup, and it says the key is already in the wallet.  I click the Receive Bitcoins button and the same address reappears.  I close the wallet and reopen it, and the address is gone again.  Then, just as I am typing this, I see a transaction appear with that address on the main (Transactions) screen with one confirmation.  I look in the wallet and the address is there, hopefully for good. This is the first time I have seen this sort of behavior.

This only happens when armory is reading the blockchain and you try and add an address.

Actually... I think Cryptoman is right.  I just found a bug, induced by one of the last upgrades I made before beta.

An extra method I added to make sure the wallet looks out far enough on newly-imported wallets happens to reduce the key list like that when Armory is restarted, IF the key does not have any tx in the blockchain yet.  It definitely marks the key as "used" for this session, which causes it to show up in the address list AND prevent it from showing again when you select "Receive Bitcoins."  Except that's erased on startup if the address appears to be unused.

That's actually a fairly significant bug, since it may cause address re-use and is [obviously] confusing for the user (and may be confusing to have multiple payors pay the same address).  Luckily this bug can be fixed in one line...

For reference:  the wallet-address list only shows you keys up to the latest one used, but behind the scenes it pre-calculates the next 100 for you, and watches the blockchain for those, in case another app using the wallet distributes more addresses.  So that's why it tells you it's already part of your wallet -- you can't see it, but it is address #3 of 102.   

[etotheipi]

I just found a bug, induced by one of the last upgrades I made before beta.

Confirmed and fixed in master!   Yes, it was that easy (less than 3 minutes)!

If you're compiling from source, you can just do a git pull.  Otherwise, it'll make it into the next release (0.87).

[Cryptoman]

This only happens when armory is reading the blockchain and you try and add an address.

I believe that when I first created the address, Armory was still catching up as you suggest.  However, when I restarted Armory, I waited for it to finish scanning the blockchain before returning to the wallet and trying again, and I experienced the same problem.

etotheipi, thanks for the quick followup.

[Ente]

i can confirm this happens on linux too! it happens only if the harddisk is under full load and bitcoind dosnt respond fast enough (just a guess that this is the problem). Armory thinks he lost the connection due to a short timeout setting (just guessing). is this possible?

Hmm, I've never seen it happen in linux.  I guess my HDD just doesn't get overwhelmed like that.  However, the disconnect-reconnect fluctuations are a symptom of the problem, not the cause.  Perhaps I should add a mechanism to disable the flickering if there's too much...

The real problem is why it's taking longer than 10s to do something that normally takes 0.2 ms.  My guess is it isn't a "legitimate" failure (HDD taking 2500 times longer than normal), it could be an infinite loop in the readBlkFileUpdate method, or it's somehow inducing a rescan when it's only supposed to be doing a quick update.  The debug output should tell me the last line that was run in readBlkFileUpdate, and also tell me the state of a bunch of different variables at that time.

I had the same phenomenon on Debian, reconnecting/disconnecting every second.
I got rid of it with closing Armory and "make swig". Of course the restart may have been enough too.
Somewhere in the process I updated Armory, too. Sorry I don't remember it more specifically.
System is running on a SSD, so I am not sure if it is a hdd issue..

Ente

[Ente]

While keys are more secure than passphrases, they won't protect you in the case we are talking about.

If your system is compromised enough to have a keylogger, it is more than likely compomised enough for the attacker to use your ssh keys. They would just record you password for unlocking the ssh key (assuming you set a password) and use that key instead of the password.

I don't think having your offline system connected like this to a computer that is connected to the Internet can be considered safe.  There are some other hardware wallet implementations being worked on where restricted communication happens over USB. Allowing a full remote login into the rpi is too risky IMO

Yep!
The 99.8% secure and elegant way would be a custom ssh shell.
You connect to the RPi via SSH, but won't get a regular command prompt (with too much rights), but a custom script interface. Something like

Welcome!
Please enter your unsigned TX.
Alternative:
[1] for stats
[2] for full shell (password needed)
[3] for exit

You enter the TX, it automatically returns the signed TX, then ,aybe shuts down the RPI.
For this you wouldn't even need a password or keys for "login".
For enhanced security you should only use "drop me a full shell" via livecd or another offline computer.

30 sec google shows this how to swap the shell for a script:
http://www.alteraforum.com/forum/showthread.php?t=18579&s=1ea4abc27f1684f9871b3508867f8fff&p=72609#post72609

..and any script will do!
The more I think about it - you have a winner there!

Ente

[marcus_of_augustus]

i can confirm this happens on linux too! it happens only if the harddisk is under full load and bitcoind dosnt respond fast enough (just a guess that this is the problem). Armory thinks he lost the connection due to a short timeout setting (just guessing). is this possible?

Hmm, I've never seen it happen in linux.  I guess my HDD just doesn't get overwhelmed like that.  However, the disconnect-reconnect fluctuations are a symptom of the problem, not the cause.  Perhaps I should add a mechanism to disable the flickering if there's too much...

The real problem is why it's taking longer than 10s to do something that normally takes 0.2 ms.  My guess is it isn't a "legitimate" failure (HDD taking 2500 times longer than normal), it could be an infinite loop in the readBlkFileUpdate method, or it's somehow inducing a rescan when it's only supposed to be doing a quick update.  The debug output should tell me the last line that was run in readBlkFileUpdate, and also tell me the state of a bunch of different variables at that time.

I had the same phenomenon on Debian, reconnecting/disconnecting every second.
I got rid of it with closing Armory and "make swig". Of course the restart may have been enough too.
Somewhere in the process I updated Armory, too. Sorry I don't remember it more specifically.
System is running on a SSD, so I am not sure if it is a hdd issue..

Ente

Can confirm I got the same behaviour on Linux Mint (debian variant) ... for me it was because I had a custom bitcoin.conf file which I removed and the error went away. Then I put the bitcoin.conf file back and I then went through commenting out individual lines to identify the culprit and discovered it did not like at least the line

Code:

maxconnections=8

which when commented out stopped the repeated connect/disconnect behaviour. Hope that helps.

[Ente]

Can confirm I got the same behaviour on Linux Mint (debian variant) ... for me it was because I had a custom bitcoin.conf file which I removed and the error went away. Then I put the bitcoin.conf file back and I then went through commenting out individual lines to identify the culprit and discovered it did not like at least the line

Code:

maxconnections=8

which when commented out stopped the repeated connect/disconnect behaviour. Hope that helps.

Hmm.. I didn't change anything on bitcoind[.conf], here the phenomenon just went away by itself after first restart and/or "make swig".
I will have a close look next time if/when this happens again..

What would be the standard data you, etotheipi, would like to have when something strange is observed? Logfile, console output or the like? (Linux here)

Ente

[N.Z.]

Hi all Just tested the best way of using offline part of Amory I can think of.

1. Download Tails. This is Debian LiveCD/LiveUSB system. Why Tails? Because it is well-known system designed with max security in mind (to leave system and disks untouched in particular), has a lot of users and testers and supported by Tor project. These ones are enough for me to trust it.

2. Boot it in custom way: pass 'truecrypt' parameter to kernel and set up root password in welcome screen.

3. Go to online computer and download needed packages from Debian repositories or from here, we need these:

Code:

python-twisted-conch_10.1.0-1_all.deb  
python-twisted-runner_10.1.0-2_i386.deb
python-twisted-core_10.1.0-3_all.deb   
python-twisted-web_10.1.0-1_all.deb
python-crypto_2.1.0-2+squeeze1_i386.deb  
python-twisted-lore_10.1.0-1_all.deb   
python-twisted-words_10.1.0-1_all.deb
python-openssl_0.10-1_i386.deb           
python-twisted-mail_10.1.0-1_all.deb   
python-twisted_10.1.0-3_all.deb
python-pyasn1_0.0.11a-1_all.deb          
python-twisted-names_10.1.0-1_all.deb
python-twisted-bin_10.1.0-3_i386.deb     
python-twisted-news_10.1.0-1_all.deb

Don`t forget to check hashes and signatures!
Also download latest Armory .deb file from Armory website.

4. Make Truecrypt container in USB drive, put all debs to folder, say, 'armory' in this tc-container.

5. Plug in USB drive to computer booted with Tails as said above. Mount tc-container, run

Code:

dpkg -i /media/truecrypt1/armory/*.deb

6. We got an secure offline environment: if it is unencrypted, it disappears when you shutdown computer. Total geek 

Did I miss something? Maybe we should ask etotheipi to include offline bundle for Tails as it is already made for Ubuntu?

[chrisrico]

Yep!
The 99.8% secure and elegant way would be a custom ssh shell.
You connect to the RPi via SSH, but won't get a regular command prompt (with too much rights), but a custom script interface. Something like

Welcome!
Please enter your unsigned TX.
Alternative:
[1] for stats
[2] for full shell (password needed)
[3] for exit

You enter the TX, it automatically returns the signed TX, then ,aybe shuts down the RPI.
For this you wouldn't even need a password or keys for "login".
For enhanced security you should only use "drop me a full shell" via livecd or another offline computer.

30 sec google shows this how to swap the shell for a script:
http://www.alteraforum.com/forum/showthread.php?t=18579&s=1ea4abc27f1684f9871b3508867f8fff&p=72609#post72609

..and any script will do!
The more I think about it - you have a winner there!

Ente

That would be awesome, but I'm not sure how to do this over a serial connection, since I'm not using ssh, but screen.

[prezbo]

etotheipie, would it be possible to add the root key + chain code to the "backup individual keys" option, so it can be easily saved to a file? I would like to encrypt it with a password me/my family knows and print it out. This way if a burglar found it it wouldn't be so easy to sweep the funds. Or even better yet, have the option making an encrypted paper backup, but that would be probably much more time consuming to implement.

[etotheipi]

etotheipie, would it be possible to add the root key + chain code to the "backup individual keys" option, so it can be easily saved to a file? I would like to encrypt it with a password me/my family knows and print it out. This way if a burglar found it it wouldn't be so easy to sweep the funds. Or even better yet, have the option making an encrypted paper backup, but that would be probably much more time consuming to implement.

I've been meaning to add the root key+chaincode to the "backup individual keys" window.  But I didn't have any plans to make the backups encrypted.  Once you have an encrypted wallet and an encrypted backup, you effectively have a brainwallet (requiring either brain+paperdata or brain+HDDdata).  And I've ranted before about this, so I'll not go on a rant this time.  But the gist is this:  you don't anticipate using your paper backup, potentially for 5 years.  If you encrypt it, you will forget that password within 5 years, and then your backup is useless.  Even if you don't forget it, you're very likely to take it to the grave with you when you get hit by a bus, and I'm sure your family would be thrilled to find evidence of $20k worth of BTC in your safety-deposit box, but no way to recover it.

Yes, yes.  I'm protecting users from themselves.  That's what I hate about the "war on drugs" -- the difference is, I'm not going to arrest you if you encrypt it yourself   I just don't want to encourage it, because then everyone will do it by default, and lots of people will lose BTC.  For most Bitcoin users, 99% of the risk is virtual, not someone gaining physical access to your paper backup.

Okay, so I guess I ranted about it, anyway   I will add the data to the individual keys dialog.  I should've put it on there from the start, anyway.  If you want to encrypt it, you can save it to a file and encrypt it however your little heart desires

EDIT: I just realized there could be a MINOR benefit to the encryption:  "Please print out this sheet of paper and then write this code on it in permanent ink!".  It would print out an encrypted copy, which would protect against malicious printers.  And then the user writes the code on it so that it's not a brain-required backup, but the printer doesn't have access to it.  Hmm...

[prezbo]

Okay, so I guess I ranted about it, anyway  I will add the data to the individual keys dialog.  I should've put it on there from the start, anyway.  If you want to encrypt it, you can save it to a file and encrypt it however your little heart desires

This is all I would need, thank you.

I will elaborate on why I think an encrypted backup would be a good idea, although I do agree with everything you said, to some extent.
I do not own a safe, so if someone were to break in my house and get to the paper backup, the funds would probably be gone before I would realized it had been stolen. So my idea is to have hdd backup of the wallet with a strong passphrase, and a single copy of a paper wallet with a weak enough passphrase that I could bruteforce it in a decent amount of time in case I would forget it, but would give me enough time to clear the funds out if someone were to steal it. I hope that makes sense.

[Red Emerald]

etotheipie, would it be possible to add the root key + chain code to the "backup individual keys" option, so it can be easily saved to a file? I would like to encrypt it with a password me/my family knows and print it out. This way if a burglar found it it wouldn't be so easy to sweep the funds. Or even better yet, have the option making an encrypted paper backup, but that would be probably much more time consuming to implement.

I've been meaning to add the root key+chaincode to the "backup individual keys" window.  But I didn't have any plans to make the backups encrypted.  Once you have an encrypted wallet and an encrypted backup, you effectively have a brainwallet (requiring either brain+paperdata or brain+HDDdata).  And I've ranted before about this, so I'll not go on a rant this time.  But the gist is this:  you don't anticipate using your paper backup, potentially for 5 years.  If you encrypt it, you will forget that password within 5 years, and then your backup is useless.  Even if you don't forget it, you're very likely to take it to the grave with you when you get hit by a bus, and I'm sure your family would be thrilled to find evidence of $20k worth of BTC in your safety-deposit box, but no way to recover it.

Yes, yes.  I'm protecting users from themselves.  That's what I hate about the "war on drugs" -- the difference is, I'm not going to arrest you if you encrypt it yourself   I just don't want to encourage it, because then everyone will do it by default, and lots of people will lose BTC.  For most Bitcoin users, 99% of the risk is virtual, not someone gaining physical access to your paper backup.

Okay, so I guess I ranted about it, anyway   I will add the data to the individual keys dialog.  I should've put it on there from the start, anyway.  If you want to encrypt it, you can save it to a file and encrypt it however your little heart desires

EDIT: I just realized there could be a MINOR benefit to the encryption:  "Please print out this sheet of paper and then write this code on it in permanent ink!".  It would print out an encrypted copy, which would protect against malicious printers.  And then the user writes the code on it so that it's not a brain-required backup, but the printer doesn't have access to it.  Hmm...

You should check out BIP38

[Ente]

etotheipie, would it be possible to add the root key + chain code to the "backup individual keys" option, so it can be easily saved to a file? I would like to encrypt it with a password me/my family knows and print it out. This way if a burglar found it it wouldn't be so easy to sweep the funds. Or even better yet, have the option making an encrypted paper backup, but that would be probably much more time consuming to implement.

You might like what casascius came up with:
https://bitcointalk.org/index.php?topic=128699.0

Basically a Bitcoin note with qr-code and everything, where the single private key is secured via password/phrase.
Yep, isn't integrated into Armory. Maybe have the key both on the note and imported/exported in Armory.
Yep, I am careful with encrypting *every* backup of my bitcoins. I prefer at least one unencrypted copy, be it printout or usbstick, somewhere safe.

Ente

[Ente]

Okay, so I guess I ranted about it, anyway  I will add the data to the individual keys dialog.  I should've put it on there from the start, anyway.  If you want to encrypt it, you can save it to a file and encrypt it however your little heart desires

This is all I would need, thank you.

I will elaborate on why I think an encrypted backup would be a good idea, although I do agree with everything you said, to some extent.
I do not own a safe, so if someone were to break in my house and get to the paper backup, the funds would probably be gone before I would realized it had been stolen. So my idea is to have hdd backup of the wallet with a strong passphrase, and a single copy of a paper wallet with a weak enough passphrase that I could bruteforce it in a decent amount of time in case I would forget it, but would give me enough time to clear the funds out if someone were to steal it. I hope that makes sense.

Oh, a timelock! I like that idea! :-)
"Dear heir. It seems like I was hit by a bus. Sorry. Please search long enough to find the right five-letter password for a little surprise."

Ente

[Ente]

(Sorry for tripplepost)

I just got an error.
I have one adress with two tx inside (= I sent 1 and 2 bitcoins there). Trying to send the whole sum of one of the input transactions (2 bitcoins), Armory wants to send fees. I accept sending fees, and tell Armory to send the remaining back to the same adress. Result:

SelectCoins returned a list of size zero. This is problematic and probably not your fault.

There are a dozen ways to avoid this, as a user. But since you asked for testers and feedback, I will post everything here, until you ask me to use bitcoin-qt again ;-)

edit: tx went through when the fee and bitcoins to be sent were smaller than one input.

Ente