Hacker News Reader

Comment by bdamm | Hacker News Reader

The cold wallet problem has vexed me. The solutions seem immature given how widespread this need is. For example, nobody seems to have developed a Shamir's secret sharing approach to cold wallets, which seems like a natural fit. Also, there remain these warnings that one must be very careful about how to transfer funds out of a cold wallet (e.g. in one transaction) which seems to defeat the entire purpose of having a cold wallet (which is safety of the funds.)

View on HN

IMO it should be done like this. You have a hot wallet, probably on your phone that has a half key. You keep a QR code somewhere else with the other half. Combine these two and you have the cold storage private key. Additionally you could have the full private key in a safe or whatever that you never touch.

In this system you can top up your hot wallet by specifying all transaction details and then scanning the QR with the half code to sign the transaction and send it off.

This would roughly as secure as some sort of 2FA method. The attacker needs to have both the phone compromised, and the paper with the half key compromised.

I appreciate everything you just said and agree that this could work well for some people. On the other hand, reading it through the eyes of the 99% of people I know who can barely check their email, everything you said may as well be written in Klingon. It is simply too difficult for most people to understand.

Cryptography is a necessary lesson that we need to teach in 2017. Lowest common denominator is a hard threshold to design security for.

It's not an unsolvable problem with good apps/software though. A key as a sequence of characters is confusing, but depicting an actual key cut in half, that needs to be combined with another, would make sense to people.

As was said elsewhere, a lot of this will come as the space matures.

The attacker only needs to have compromised the device which spends from the wallet file

Only a half key exists in permanent storage on device. The other half paper key is loaded into memory for transaction signing, and then removed from memory the moment the transaction is sent off

You would need both halves to sign a transaction

I agree that you need "both halves" in this scenario to sign the transaction.

At some point during the spend from the wallet, the privkey that matches the wallet pubkey has to touch memory. This privkey can in theory be compromised in a number of ways with malware on the spending system (keylogger, screen caps, process memdump, etc).

I think the safest way to go about this is to generate an entirely new keypair/wallet on an isolated system. Spend from your wallet then transfer the balance to the newly created wallet. This minimizes losses as a result of privkey compromise (unless of course your isolated system isn't so secure)

«nobody seems to have developed a Shamir's secret sharing approach to cold wallets»

This has been developed. Search for multisig wallets, N-of-M, etc

> nobody seems to have developed a Shamir's secret sharing approach to cold wallets

I mean, what is there to develop? Take the wallet's private key, and run it through your favorite implementation. I'm not really sure what a bitcoin specific implementation would do! Just autoload it into your specific bitcoin client for you?

Reply on news.ycombinator.com