I was thinking of how to make private cold storage safer specifically against physical attacks.
If an attacker physically threatens someone, he’s most probably going to give his secret keys and loose his funds.
If the funds could only be unlocked in 2 steps:
the first lock triggers a timer based on the blockchain. This is linked with the private key: Let’s say that as soon as the particular private key is loaded, we count x blocks before the next lock is available to unlock. Once the block has been reached, the second lock is available.
The second lock is unlocked by password.
I would imagine that this would demotivate physical attacks:
One could force someone to give you the keys, but if the second block is locked for a month without a way of checking whether the password for the second lock is correct, the attacker couldn’t be sure of the validity of the information during the attack.
Historical detail: I was invited to this 2014 meetup at Princeton and everyone was asked to give a brief talk on a cryptocurrency/blockchain idea. Ittay Eyal and Emin Gün Sirer were there, too. My presentation was this “Vaults” idea, which I have called by various other names over the years, such as “the I-got-robbed button” and “casting a Slow Money spell on your money”. As far as I remember I had never heard of that idea from anyone else and came up with it on my own, while thinking about this major problem that all crypto has of secret key theft. I still think it is a very promising idea, and I’m glad Ittay, Gün, and Malte Möser wrote it up in a real paper and implementation (although it would have felt good if they had given me a shout-out).
TBH I’d love to have the opposite feature. A cold storage trickle wallet that, when untouched for a period of time, will slowly trickle the funds to a hot wallet for when I inevitable lose my keys .
but wouldn’t you also have lost your hot wallet keys too?
I think that this insurance or guarantee to recover your funds or pass them to another person is one of the tricky challenges. It’s also used by some people against blockchain solutions: you need to trust the bank to do such actions.
Nope. Hot wallet on phone and laptop. If I lose those funds so be it.
Hardware cold wallet is stored off premise. Harder to access. If I get the pin wrong 3 times it’s gone.
Most likely event is I forget my pin, or accidentally type pin wrong 3 times.
We should come up with a fancy name for it… Like a Crypto Will. When a specific address hasn’t performed any actions in a defined timeframe the contents start trickling to a previously specified address. Probably a paper wallet which has been attach to your will.
Back to the original topic. If I were to implement a vault I’d probably do it different. Have addresses that require 2 or more (time delayed) on-chain transfers before confirming the transaction.
Time-Delay Vault Scenario (worse)
The thief wants to steal all the crypto from a bank. He knows that he has to time the attack correctly since the crypto vault is only opened at certain times during the week. He taps the network and finds a network pattern that indicates a vault unlock request has been made and times his attack precisely when the fund are available. He enters the bank and forces the banker to transfer him the unvaulted funds.
N Time Delayed Transfers (better?)
A bank requires any cold storage funds to require 2 transfers to occur delayed by 1 day. The thief enters the bank and forces the banker to initiate the transfer to his crypto address. He keeps the banker hostage for 24hours before he can force the banker to make the 2nd transaction request to confirm the transaction.
I feel like your second proposal is closer to my idea.
If cold storage, I’d put a week. Holding someone hostage for a week will dissuade more. It could however also be worse for the one that gets robbed…
Today the best I could think of would be to put a wallet in a safe at the bank. Because the bank is a powerful actor (in the sense it can defend itself very well) you are supposedly able to trust, it is a great defense against theft.
But in a trust less system, it’s a pretty difficult nut to crack.
What about the following:
Password protected transactions : wrong password? Next possible try in XX blocks / XX days. Wrong again? Next time again in xx blocks/days. Maybe a password prompt should not even be showing by default, but would have to be intentionally called by the owner in order to avoid the cancellation of the transaction and forced delay for next try.
Another feature: in case of failure to indentify the owner, the funds are sent to another predefined address, of which the private code is not stored with the initial one.
.