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

Yeah, the logic has been in the code for a while, and I had all these great ideas for wrapping a GUI around it, but no time to do it.  The conference was the perfect excuse to get it done.   We want to showcase the advanced security features of Armory to people going by.  Of course, we have to warn them "This beta only works if you are on a 64-bit OS with 5+ GB of RAM".  Still, it should whet their appetite and give them the impression that Armory is the Cadillac of Bitcoin wallets.  Then when the resource issues are resolved, they'll be excited they can finally use it

You could have Armory have a system where it can connect to a given IP address for sending.  The user could enter a miner's IP directly.

The M-of-N feature is pretty awesome.
It has been in the works for a while now.

Thanks Alan.

I made a lot of progress on the persistent blockchain stuff, but when I realized I couldn't finish it before the conference, I decided I had to finish this feature instead.  I may not have mentioned it here, but a friend paid for an exhibitor booth at the conference, and he and his buddy are running (and I'll be there, too).  And we got a good location, too, by the door.  We'll be doing lots of demos.  I decided having the super-backup system (at least in demo) was worth delaying the persistent blockchain stuff by a week.

I made a lot of good progress on the persistent blockchain stuff, but it'll probably still be a couple weeks after the conference before it's ready.


(1) The encryption uses the same key-stretching as is used for wallet encryption which is a simpler (but less flexible) version of scrypt.  It's hardcoded to use 16 MB of RAM per thread, which means it must do 262,144 SHA512 invocations, and keep each step in RAM as a lookup table to use for 144k lookup operations.    This will take older computers a second or two, but it will be done so infrequently, I decided, I should err on the side of taking too long. 

(2) There is no custom passphrase.  However, the intention of M-of-N was to replace that.  An encrypted backup is just a 2-of-2 backup -- requiring the paper, and the password in your head.  You can, instead, do a 2-of-2 backup with the new utility, and think of one sheet being the encryption key for the other.  But with this, you get an extremely flexible tradeoff of security and redundancy.  M is how much "security" you want, and N is how much redundancy you want (well, N-M).   

I've ranted before about the dangers of having an encrypted paper backup option, because it's the one place where users should not always pick the "best-sounding" option .. i.e. "Oh yeah, encrypt everything, great!".   I have seen probably 200+ BTC lost to forgotten passphrases.  It's tough to have the encrypted backup option while still encouraging people to have at least one unencrypted backup, somewhere.  Or rather, prevent people from unwittingly creating brainwallets.

Is it already possible to have encrypted paper backup with a custom password? Does the encryption for the paper backup also use some key-stretching (like scrypt, pkbdf2)?

So Alan how is it going with the usability issue? I don't mean to be demanding but would like it if you can give me some time frame.

Some bounty-goodness, here:

https://bitcointalksearch.org/topic/bounty-03-btcperson-help-test-armory-backups-demo-m-of-n-gui-more-206874

Yes, I finally got around to implementing this M-of-N backup stuff.  And it turned out pretty awesome (besides needing some polishing).  

The testing will be useful in general, but I especially need it in the next 24 hours so I can demo it at the conference.

It's pretty satisfying to see people discover--and get excited about!--a feature that I carefully implemented to try to fill in all these little holes, not knowing if they'd ever actually be a deterrent for anything.  I don't know if it's making any hackers' lives more difficult, but at least someone noticed the effort I put in to do it   Thanks!

Awesome!

I just checked it and the "Wallet ID" field for the destination address is filled out with the wallet ID for my offline wallet if it's a change address. That's brilliant. And it's even better that Armory pops up a warning if neither of the outputs are owned by me. Then an attacker has to make a three-output transaction in order to trick me, and I will definitely notice if I'm sending to a single address and there are three outputs.

Yes, the offline computer can see that.  Remember *always* to check the transaction on the offline computer, the change address will be marked with the label of the wallet.  If neither address is labeled, you are in trouble.  This is why Armory always tells you to double-check the transaction on the offline computer.

Recently, I did something like that myself.  I was combining a payment with moving some funds. I made a payment using a single input (coin control), and two outputs, one was my payment the other an address in my blockchain.info wallet.  So no change address.  Armory issued a warning that I could be falling victim to the attack you describe.  I cannot remember if it was the online or offline Armory that warned me.  Looks like etotheipi has thought about this vector

Is there anything protection against the following attack?

Say I'm using an offline wallet, and I want to send some funds to an address. My offline wallet contains 1000 BTC at a single address, and I want to send 10 BTC to an address.

My online computer is infected. The Armory running here has been replaced with a malicious version. The malicious version of Armory creates a transaction that, correctly, sends the 10 BTC to my desired destination, but returns the 990 BTC change to an attacker's wallet.

Can the offline Armory version tell if an output is a change address, and thus deduce whether it's sending change back to an address owned by itself or to an attacker?

I can see when I make large transactions that online Armory hides the change address. If the attacker makes the online Armory version hide the change address (which belongs to the attacker), and the offline Armory doesn't know whether it's sending 10 BTC with 990 BTC change, or 10 BTC to one foreign address and 990 BTC to another foreign address, then it's very difficult for me to see in offline Armory what's really happening, since I don't know my own change address.

Is it possible to mark change addresses with some specific color in offline Armory, so I can see that a specific address is indeed a change address, or is this already done?

Thanks!

Indeed, vanitygen has a regular-expressions option, but you can't use the GPU with it.  So I had to use regular-old-CPUs to generate that address, which was expected to take about 70 days with my existing CPU power.  I had a bunch of miners laying around eating GPU cycles, but idle CPUs.  So I put them to work.

It was supposed to be 70 days for 50% chance of finding such an address.  I got lucky and found it after like 4-5 days.  And I've been a celebrity ever since then

exactly, you can specify pattern as a regex, if you create a regex that starts with 1 and continues with only upper case letters and pass it as argument (-h of ocl dosnt have it, dunno if it works there, i guess not!) and enjoy

Regular expression?

regex

Man how on earth did you generate this address? 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX

I'm not actually sure.  I'd be surprised if they were different, though.  So you can use either one (and let me know if that's not the case).  Unfortunately, I don't have a 13.04 system near me, so I can't investigate at the moment.

Was this the right one to use?

./lib/x86_64-linux-gnu/libpython2.7.a

or should I have used this one?

./lib/python2.7/config-x86_64-linux-gnu/libpython2.7.a

The newest version of Armory runs Bitcoin-Qt for you.  That's a "feature".  But it's an annoying feature if you have some non-std configurations.  You can go into the settings and turn it off, to run it yourself.  Or point it to where it's installed and let it do everything for you.  Or let it install it for you, which should work, but who knows, with all these different system configurations.

Okay, so it seems the first time I was searching for libpython2.7 when I should have been searching for libpython2.7.a

After searching the latter I found this:

seth@seth-LockBox:/usr$ find -name libpython2.7.a
./lib/python2.7/config-x86_64-linux-gnu/libpython2.7.a
./lib/x86_64-linux-gnu/libpython2.7.a

Then I changed the directories for BOTH lines 26 AND 29 to the second instance of libpython2.7.a which is:

./lib/x86_64-linux-gnu/libpython2.7.a

Don't ask me why I chose that one. I think I just missed the other one. I'm not sure which one I was SUPPOSED to use, but I will say that I was able to get BitcoinArmory to install after choosing the second one. Can you please confirm that I chose the right one?

Also, I opened up Armory and it's telling me to close my Bitcoin-Qt client. So, now I've got to look into that some.