Topic: Improving Offline Wallets (i.e. cold-storage) - page 5. (Read 19698 times)

I don't see how your proposal offers protection against this.

If your argument is that you'll discover whether the 10 BTC goes to the intended receiver, then just start out by signing a transaction - with the offline wallet - for 10 BTC to the supposed Mt. Gox receive address. If this goes through to your Mt. Gox account, you can proceed to send the remaining 990 BTC.

Imagine having to import keys from 100 different 10 BTC-paper wallets. Now that would be tiring.

- you scan a key with only 10 BTC on it so this is the maximum loss.
- you can use lot's of different computers and mobile phones and tablets to process your transactions
- rPi method is interesting, similar approach is undertaken by Slush & team with their hardware wallet, however their method and all methods that deliver security via dedicated hardware is the following:

1. let's say I would like to transfer 1000BTC to mtGox in hopes of selling the coins. With your approach I would open mtGox account from my online computer, generate bitcoin receive address on my mtGox account and then proceed to sign the transaction on my "offline" rPi super secure device

2. you see where I'm heading?

3. a black hat hacker does not need to hack into my super secure offline rPi device. All it needs to ensure is that the receive address displayed on mtGox account is not the receive address of mtGox but rather one generated by hacker who now receives coins on an address he has secrect key for. In order to do that hacker would "only" need to hack into an "online" computer which by your definition is possible.

I think you don't even need a dedicated machine (Raspberry Pi). You can run a live a persistent usb with linux, with Armory and your wallet in it.

1) you turn off your online computer
2) you boot the computer from the live usb
3) you sign the transactions with armory
4) you turn off the computer, remove the usb, and run your normal OS, online

For extra safety you can format the pendrive on each use, to avoid autoexecuting threats. Anyhow you can disable auto-executing in Linux.

Recommendations I come up:

a) never connect to the internet from the live usb environment (obviously)
b) don't mount your online computer hard drive from the live usb environment
c) for extra tin-foil hat mode, after using the live usb environment and turning off the computer, unplug it and leave it unplugged for a couple of minutes to be sure that all traces of your live environment have been wiped from RAM

Additionally you can make a clone of that usb for redundancy and print a paper backup of your wallet.

Didn't try this method, but it looks like pretty safe if you don't have an old computer/raspberry pi hanging around

No, that is not safe because you have to scan the key into an online computer to use it, at which point it is vulnerable. You could scan it into an offline computer and sign the transaction there, but then why not just keep the key there instead of on paper?

A Raspberry Pi costs $35 and can sufficiently run an offline Armory install. It's a cheap and effective solution.

simpler solution:

say you have 1000 BTC. (I do not, but let's say you do). Simplest cold storage technology is "paper wallet". It can be generated offline, so it is secure and it can use QR codes, so you do not have to type anything assuming your PC has a camera. (€6 expense).

my proposal is that you create 100 paper wallets, this will cost you about 20 printed pages, but you can now distribute 1000 BTC to your 100 paper wallets each having 10 BTC.

when you need to spend your BTC you will need to sacrifice one of your paper wallets and import private key from that wallet into your online computer. However your exposure to loose your BTC due to hackers is only 10 BTC and not 1000 BTC.

unspent coins can be transfered to new blank paper wallets.

pros:
- backup is easy (photocopy)
- it is offline and therefore safe
- when used with QR it is convenient
- having lot's of addresses is safer
- no password to remember
- anonymity is greater as you are spending from 10 BTC addresses rather than from a 1000 BTC one
- can be used on any device anywhere, not special setup is necessary, this increases security as some platforms are inherently safer

cons:
- paper can be destroyed or lost or quality of the print can be degraded. (yes you can scan you paper wallets into a .pdf but what is the point of doing that)
- some (laptop) cameras are poor and will not work in low light conditions to recognize your QR codes.
- sometimes a bit confusing especially if you to not keep track of your spending...

You're right, without using a separate display, you cannot be sure. For my purposes, the possibility of this happening seems slim enough that I'm not concerned.

How would you be sure you aren't signing a larger transaction than you intended?

It is connected to my monitor, but it's not necessary to view the screen. The Pi server sends messages back to Armory which are then displayed in the UI. For instance "Enter passphrase to unlock wallet", "Invalid passphrase, please re-enter", "Unlocking wallet", etc. The only thing you really need is a separate keyboard plugged into the Pi in order for there to be no possible way your wallet passphrase can be captured by your online computer.


I think the idea is that it would become part of the Armory project, usable by anyone. I'm satisfied that it's secure, but before other people use it, it should really be reviewed by someone, ideally etotheipi.

What about making the code public? I'd also like to see it, and use it.

Sure, I'll be in contact with you in the next couple of days. I have the changes committed to a local git branch, so I should be able to pull it out easily enough.

@chrisrico,

Are you willing to donate that code to the Armory project?  I've been meaning to setup something very similar, but it looks like you've already done most of the hard work.  I want to checkout that code, review it thoroughly, and adapt pieces of it into the master branch.  I haven't really looked at it yet, but I expect I'll be breaking it down and integrating it in my own way/style (or perhaps you've already done most of what I planned to do...?).  

If so, can you send me an email to discuss this?  etotheipi at gmail.

^ Interesting. So do you have a separate keyboard for the Pi? And doesn't it have a screen attached, you only interact via command line, or what?

Also, would you mind sharing that software? This sounds like something I could set up myself.

I do. I've got a Raspberry Pi connected to my computer via serial->USB cable. It's had its serial TTY disabled and is running a python script I wrote which listens for ProcolBuffer messages. When it receives a message asking it to sign a transaction, it accepts the wallet's passphrase on its own keyboard, then signs the transaction and passes it back in another PB message. Armory, meanwhile, is also listening for these messages and displays the now signed transaction once it is received and allows me to broadcast it to the network.

So, does anyone have an actual setup they're using now for this task? We have a lot of good ideas, but do we have a working solution?

Hahah,

Actually Armory already does this.  The algorithm could be improved, but it will try to collect dust and throw it on top, as long as it doesn't induce a fee, and it doesn't increase the address linkages (it is from addresses already on the input side).

This will be improved in the future, as someone pointed out that I can treat addresses that have already been linked, as a single "group."  Thus, I can throw in dust from all groups of addresses already represented on the input side, without damaging the input linkages.

I like this. This way you will slowly collect dust over time. You could make it in such a way that whenever possible you squeeze in additional inputs if it does not affect the fee.

What about balancing privacy concerns with economic interest of the economy (that is to contain dust) by requiring higher minimum transaction fee if number of inputs less than number of outputs ?

Would it not solve the problem to change default client behavior to prefer aggregation while choosing input for the transactions?
It does not have to be radical collecting all dust in a single transaction but have a tendency to use at least as many inputs as outputs.

One of my wallets currently has 1813 unspent transactions, mostly less than 0.2 each.  This will get worse before it gets better.

I've been working on what I call a "dust collector" that uses the raw transaction API on the satoshi client to gather up small transactions and turn them into fewer larger transactions.  But it is hard (assuming that you care about doing it right).  And there are huge privacy implications, which is what really made me step back.

Offline and semi-offline wallets just makes it worse.

I do feel that there should be an automated process doing this from time to time, but the balance is hard.  On one hand, older transactions are more secure, and count less when evaluating for relaying and fees.  On the other, if you don't gather them up, the user can be faced with the shocking surprise that their balance can't be spent the way they want to spend it.  On the gripping hand, the user expects the software to provide as much (security|anonymity|privacy) as possible without them having to know how or why or when or where.

Just for reference, I just received a bug report from a user having problems sending a transaction with Armory.  He sent me the *.unsigned.tx which is what would need to be sent over the link:  3.5 MB! 

Yes, the transaction has 483 inputs, and by itself is 120 kB.  But since Armory uses BIP 10, the *.unsigned.tx file includes all the 483 transactions that supply the inputs.  This turns out to be a lot of data...

Granted, it's possible to get it to about half the 3.5 MB, since BIP 10 is an ASCII format and all the transactions are encoded as simple hex.  Could switch to binary.  But that's still 1.7 MB to transfer. 

However, even if it did go smoothly (I'm actually not sure why it failed... it should work), it would probably have a tough time getting into a block, since Armory's linear tx fee rules probably won't work...

So I guess the question is whether this is a truly relevant transaction, period.  Both for offline wallets and online.  I'm thinking that any transaction that is over 10 kB be "rejected", by suggesting the user break it into multiple transactions.  It's not the most elegant solution, but this is extremely rare... I think...

Or is it?  A business processes 500 tx per day.  Even if they sweep the coins every day... this is still a problem.  I really wish Satoshi had put the input values into the transaction (and be part of the string that is signed), so that I could avoid including all the supporting transactions.  But he didn't, so the only way to make this airtight is to include all that extra data.  As such, maybe it's not so ridiculous that the data link would have to handle a few MB...

On the other hand, maybe it's not so ridiculous to make the user wait 2 minutes.  I could be worse... ( like waiting 5 minutes just to load the program )