Topic: Feature suggestion for more secure wallets (Read 1248 times)

These are great points. I see bitcoin as a core technology and a core store of value. In order to distill this into something that ordinary people can safely use, a lot of stuff has to grow up around it. I'm glad to see people are thinking about this and working on it. I'm hoping that many people become a little more sophisticated about how they secure their savings. The alternative is to trust some other person or organization to do it for you. I think it's pretty cool that bitcoin gives you the opportunity to actually secure large amounts of wealth without relying on anybody else.

You're right. I was being  dufus. 

Fair enough didn't mean to imply that they would have to understand all the nuts and bolts. If that was the case very few people could use BTC. I know I couldn't. But the steps that they need to follow TODAY are too complex. Widespread adoption of smartcards and smartcard readers on consumer devices may well change that. But even then, physical theft of your smartcard combined with a keylogger or just someone watching you enter your password would place at risk ALL of your bitcoins. ATM cards get stolen and PINs compromised every day, but at least the damage is limited.


No I don't. But to refill my wallet when I've spent my $100 is a simple process. I go to an ATM and I withdraw. As long as I don't need a large amount the process is hassle free. And IF something goes wrong and my PIN is compromised I only lose a small amount.

Refilling my "mobile phone account" from my "secure account" using the webservice you outlined here is a royal PITA, even if I only want 1 BTC. What's worse is that I could still lose all my BTC if there was a trojan lurking on my PC just waiting for my investment account's private key to be loaded into memory in plaintext form (as it ultimately needs to be if I am to sign transactions using it). The solution is not JUST keeping the keys to the kingdom in stronger and stronger vaults, but to limit the damage that can be done if (when) these keys are compromised.

I think there would be a way to do this if you could take the amount into account. You'd send a big transaction to yourself in the amount of your wallet, but that transaction would only allow spending of itself according to the script.


We're just at the stage of discussing the underlying technology. There are lots of ways to package it and make it easier to use. Your grandparents won't have to understand how ECDSA works in order to send some coins, and they won't have to understand these protocols, they'll just have to insert a smart card.


You probably wouldn't do this for small transactions. You don't mind carrying around $100 in your wallet, and you won't mind carrying around a few bitcoins on your mobile phone, or in a bitcoin client with default security.

You won't be able to do it with scripting even if you could take amounts into account, because the script for this transaction would have to affect all FUTURE transactions from this wallet. This is fundamentally diferent from what scripts do today. You may be right that it is too big a change to introduce at this point. On the other hand, you have to consider how common things like the allinvain heist would become if bitcoins became mainstream. Unless wallet security is simplified vastly simplified, the VAST majority of users will be insecure. Suggestions for USB drives in safes and wallets printed to paper abound on these forums. My sister won't ever do that, not to mention my parents or grandparents.

A couple more such heists could well kill the possibility that Bitcoin (or any other cryptocurrency) could ever go mainstream. The only reason why anyone uses credit cards online is because credit card companies have proven to absorb (or offload to merchants) a lot of fraudulent transactions. The client is rarely left to take the loss when CC details are compromised. People don't need a reason to distrust computers. It comes naturally to most.


I like this a lot. It may well be the best we can do. Certainly a lot simpler than a live distro with a wallet on a USB key in a safe. But it's a pity that we lose the ability to do small transactions without hassle.

I think it is a great idea. Actually, the exact same idea (more or less) was keeping me up last night. As far as requiring a new block chain, I am pretty sure that bitcoin will either (a) modify the block chain protocol to incorporate to new features or (b) fail when a competing cryptocurrency launches. Given that thresholds are everywhere in everyday banking, I'm sure that they will get added to cryptocurrency when either (a) or (b) happens.

This is a very cool idea, and many others could be built on this kind of scripting. The problem is that bitcoin scripts can't take transaction amounts into account. I think adding in this functionality at this point is a little too ambitious. It would probably better be done as a separate block chain.

Getting back to the original idea, remember it just makes the attacker take one additional step (compromising a safe haven account), and there are simpler ways of making the attacker take another step. I think the best thing about this scheme is the auditing it provides. When somebody tries to steal from you, you know about it before it's too late.

Maybe you could do this independently of bitcoin. Somebody could start a web service that provides you with a public key. You encrypt your wallet as usual, then you encrypt the wallet with the public key. When you want to open the wallet you send it to them and have them decrypt their encryption (or they just send you the private key).

But they don't do it immediately. They send you emails and text messages that someone's trying to decrypt your wallet. Only after a day, or after you've proved in some other way that it was you, do they send you the partially decrypted wallet.

Anyone else? Or is this not even worth shooting down?

Threshold schemes like those you describe are some of the best mitigtions to the sorts of attacks that are most likley to exist; while I have not given your specific examples a ton of thought I do think they have merit.

I'd ideally like to post this in the Development and technical discussion board, maybe a mod can move it there. Been frequenting the forum a couple of months now, but am more of a lurker than a poster. In this instance, however, I believe I have something worthwhile to contribute.

After the allinvain heist and the confirmation of the existence of a bitcoin stealing trojan, the boards have been awash with suggestions for securing bitcoin wallets, and while most of these will undeniably make it far harder, or even impossible, for a thief to steal significant amounts of bitcoin from a properly secured wallet, securing a large amount of BTC needs to be far easier to make it accessible to the general public.

What I would like to propose is an additional transaction type that would allow you to specify constraints on the use of funds from a specific address. This is analogous to the existence of cash withdrawal limits on an ATM card that the bank customer may configure. The CREATECONSTRAINT transaction would not move cash between adresses like normal transactions but would list a source adress (to which the constraints would apply, a MAXMOVE amount and a list of N safe haven adresses.

Once the constraint transaction has been incorporated into the blockchain, the network would disallow any subsequent transactions that attempt to move more than MAXMOVE bitcoins to any adress not in the list of safe haven adresses. This would be enforced on a per block basis, in other words nodes have to ensure that the total amount of bitcoins moved from the source adress in a specific block does not exceed MAXMOVE. If multiple transactions using that source address are received, any transactions targeting safe haven adresses will be prioritised, and all others would be added in, in the order received up to the point where adding the next transaction would violate the constraint.

In practice this would mean that I could safely keep thousands of bitcoins in a single address in a wallet, configure the address to not allow transactions of more than X BTC per block (where X is a reasonable number for everyday expenses) unless the receiver is one of a small list of alternate adressess that I control. Obviously this helps nothing if the private keys for the safe haven addresses reside on the same machine as that of the primary address, but these could be addresses that reside on my mobile, addresses of trusted friends or even a mybitcoin or mtg*x deposit address. I could also keep them on a USB stick with a live distro, but I probably don't need to keep the stick in a safe, since the adresses are usually empty.

If my primary address is compromised I can request the movement of my funds to one of the safe haven addresses and only lose a relatively small amount depending on how quickly I reacted. I can also do the same thing if the address is not compromised but I need to do a transaction larger than MAXMOVE.

Of course safe haven addresses are also adresses and as such could have their own constraints. The uber paranoid could create complex networks of wallets that need to be traversed before the money reaches an unconstrained address. Unless the attacker manages to compromise ALL the wallets in the chain, he will only be able to siphon money off very gradually (or not at all if MAXMOVE=0). Similar things could be achieved with multi-signature transactions, but this method has the advantage that small value transactions remain as simple as they are today even when sourcing funds from high value wallets.

A CREATECONSTRAINT transcation is checked for validity by ensuring that if any CREATECONSTRAINT transaction for this address allready exists, then the new transaction may only tighten the constraints (i.e. reduce MAXMOVE, specify a subset of previously listed safe havens) and never relax them. One could also consider having some default MAXMOVE amount defined for all adresses. The first CREATECONSTRAINT transaction that gets processed for a given address would be allowed to increase MAXMOVE from this default level.

This doesn't help if your wallet is compromised and you only realise it 10000 blocks later, but it would be simple for third parties to build payment notification services that would send you an SMS/e-mail every time BTCs are sent from one of your addresses.

If the extra kBs consumed in the blockchain are an issue one could always prevent gratuitous use of the CREATECONSTRAINT transaction by requiring a non-trivial transaction fee.

Comments?