Topic: Armory - Discussion Thread - page 152. (Read 521829 times)

I actually had thought about that for the Android phone encryption -- the phone will be slow, and I don't want to drain the battery by using some crazy long key stretching.  But even a "weak" key stretching will give you enough time to move the coins before someone could reasonably brute force it (24H, if they're good)

Maybe that's a good compromise.  It would also go along with the idea of having an encrypted test phrase with the wallet, so you outsource the brute-forcing without give them access to the wallet directly (you give them test-encrypted data, they can prove when they've found the encrypted passphrase by giving you the decrypted data/string, but they can't take your coins until you work out an arrangement with them to exchange passphrase for BTC)

Wow, I can't believe that worked!  I only suggested 2008 because I compile with MS Visual Studio 2008, so it seemed like a natural fit.  But...

(1) I don't know why 2010 wouldn't work
(2) I don't know why that fixed it, since most users don't have the redistributable installed yet Armory still works on their system...!?!

Bizarre.  But I'm glad it works!  I'll add that to my list of things to recommend for Windows users with problems running Armory!




Gah!  I thought coin-selection was really stable by now.  If this happens again, and you're willing to send me your watching-only wallet, please let know.  I really want to catch that error in the debugger.  I've had a couple reports of this in the past year, and each time I've implemented something that fixed it for that user.  I guess there's still strange conditions that can cause it...

Btw, yes:  this is exactly the stuff I want out of testers.  There are so many conditions, and so many things that can break from just trivial-looking one-line code changes.  It freaks me out even reorganize code or delete comments before a release, for fear of accidentally changing code flow and breaking seemingly-unrelated things...

I also googled the error and came to a conclusion I was missing MSVC++ but I downloaded the 2010 redistributable. I got the 2008 and it works, thanks!

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

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

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

You might like what casascius came up with:
https://bitcointalksearch.org/topic/10-btc-4-u-2-steal-protected-by-a-weak-5-letter-password-crack-its-yours-128699

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

You should check out BIP38

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.

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

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.

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.

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:
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
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?

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

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

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

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

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

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.

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

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.   

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