Improving Offline Wallets (i.e. cold-storage)

[chrisrico]

your online webserver will maintain the audio connection with the "offline" wallet

Maybe if you're running your web server out of your basement or your own data center. I really don't see a hosted solution of reasonable cost offering this feature at all. I still don't see how user-specified transport medium is an inferior solution. It would be easier for you to add to Armory, and allow for more flexibility for users. If someone wants a super secure audio connection, they could do that. If someone wants a perhaps equally secure serial or firewalled VPN connection, they could do that.

[1714018547]

1714018547

[1714018547]

1714018547

[1714018547]

1714018547

[1714018547]

1714018547

[1714018547]

1714018547

[1714018547]

1714018547

[Peter Todd]

Additionally, a coworker pointed out that modem firmware is designed for exactly this kind of communication:  noisy analog channel, with unknown quality and potential bit-rate.  The job of the modem software is to figure it out, and give you a nice clean interface for error-free file transfer.   And modems over phone had pretty good transfer rates, relative to the data sizes we need here.

Look into packet radio: http://en.wikipedia.org/wiki/Packet_radio Ham radio enthusiasts have already developed pretty well debugged code and protocols that does the data->audio->data chain over links far worse than any PC audio ever will be.

[etotheipi]

your online webserver will maintain the audio connection with the "offline" wallet

Maybe if you're running your web server out of your basement or your own data center. I really don't see a hosted solution of reasonable cost offering this feature at all. I still don't see how user-specified transport medium is an inferior solution. It would be easier for you to add to Armory, and allow for more flexibility for users. If someone wants a super secure audio connection, they could do that. If someone wants a perhaps equally secure serial or firewalled VPN connection, they could do that.

We're talking about two different things here.

--I'm talking about a solution that can be employed by regular end-users, or small-scale business owners without being computer/linux-savvy.  I want to make it possible for people to access this level of security without being an expert in anything -- which includes avoiding anything with the command line, understanding hardware, or dealing with driver issues.  The audio solution is fantastic in this respect. 

--What you're talking about it a low-level interface for people who know what they're doing, to fill-in-the-blank.  In essence, implement the hooks to make it easy for other developers to dig in, and do it the way they want to do it.

What you're talking about is fantastic, and I actually plan to do that.  But I also want a fully-integrated solution that "works out of the box" on most systems -- both usable and secure.  If I integrate pieces of modem firmware into Armory and auto-detect the audio-link, a user only needs to plug in a cable and click an Armory button on each system.  Figuring out which /dev/* device and which protocol to use should not be part of that.  But it can be available for the hardcore users.

And I'm not entirely convinced that a "hosted solution" would not be willing to use something unique.  If Bitcoin becomes more widespread, and lots of business owners start trying to integrate Bitcoin into their web services, then why wouldn't there be some kind of customized solution for dealing with it?  As you said, it can be set up so they can use whatever device they want, but it wouldn't surprise me if something as crazy as this turned out to fit the bill, given that it is super-cheap, super-secure, and easy to setup without risk of doing it wrong.

[etotheipi]

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 )

[kjj]

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.

[grau]

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.

[grau]

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 ?

[Jan]

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.

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.

[etotheipi]

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.

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.

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.

[runeks]

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?

[chrisrico]

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.

[runeks]

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

[etotheipi]

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.

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

[chrisrico]

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.

[runeks]

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.

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

[chrisrico]

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

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.

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

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.

[TierNolan]

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.

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

[chrisrico]

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.

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

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.

[qbits]

A quick overview of Armory's offline wallets to setup the discussion for how to improve it (and for those that aren't familiar):

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

[chrisrico]

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.