Key Calendar for Physical Security

Short version:

Decentralized group of oracles publish PGP public keys, followed after a delay by the corresponding private keys. Bitcoiners can get some physical security by time locking keys needed to spend utxos by encrypting the spend keys to a PGP public key published by the oracle. In order to spend the funds, they must wait for the private key to be published. If a robber asks them to send funds, it is not possible to do so without waiting for the timeout or by some other method that is not attractive for the robber. This is sort of like CLTV, but you can “renew” the timeout without making an on chain transaction.

Long version:

As the price of bitcoin goes up, bitcoin holders may worry about their physical security. The best case scenario is when no one knows about the wealth you control, but this may not be achievable for everyone due to exchange data spills, KYC record keeping, tax reporting requirements or other information leaks.

What can you do to protect yourself from the dreaded five dollar wrench attack or hostage ransom attack? A dog and a shotgun are nice to have, but it is fundamentally very difficult to defend yourself from a physical attack from a smart, patient adversary.

It’s worth noticing that there have been publicly identifiable rich people for a long time, yet robberies and hostage attacks remain infrequent. Unfortunately, Bitcoin has properties that give reason to suspect that physical attacks could be more likely.

1. You do not need to involve or inform any other people to transfer bitcoin to an attacker’s address. Bitcoin transfers are private.
2. You can transfer a fortune in bitcoin within a few minutes. Bitcoin transfers are fast.
3. Bitcoin transfers are irreversible.

These properties are of course a great asset when you need them, but having all three could be a big liability, if it attracts robbers.

In order to thwart attackers, it would be a good idea to set it up so that you cannot have all three at the same time. For example, you could lock your coins with a script that allows the coins to be spent either with the help of a third party, or no sooner than one year in the future. That way you cannot pay a robber without involving the third party, and if the third party fails you get your coins back at the end of the year.

As a more flexible variation on the above scenario, suppose that there were some oracle — perhaps a tor hidden service — that simply published a PGP public key every day, and then 30 days later it published the corresponding private key. Now your coins could be locked with a script that opens two ways:

1. You can spend the coins immediately.
2. You can spend the coins at the end of one year.

Then you encrypt the spend key for Option 1 to the PGP key of the oracle, and delete your unencrypted copies of the spend key. Now the coins are locked for 30 days, until the oracle publishes the PGP private key. Once the PGP private key is published, you could decrypt your spend private key and if you like, you could encrypt it again to a new PGP public key published by the oracle to again lock the coins for 30 days.

Automatic Lock Renewal

As a method to automatically renew the lock, what you could do is the following.

1. Oracle has a list of 30 secrets. It switches to the next secret every day. After the final secret it switches back to the first secret.
2. You send a secret to the Oracle, and ask to make a public key.
3. The Oracle combines your secret with the Oracle’s secret for that day. Oracle uses a secure hash to combine the Oracle secret and your secret. (Let’s say the secret is an ECIES private key.)
4. The Oracle sends you back the corresponding public key.
5. You encrypt your file to the public key and delete the original.
6. Now you have to wait until 30 days pass and the Oracle returns to the correct secret, so that you are able to obtain your key. If you do not obtain the secret, the window closes at the end of the day for 30 more days.
7. Attacker cannot get your private key from the oracle before robbing you because they do not have your secret.

Keys in the oracle carousel could expire after some number of rotations (e.g. expire after 12 rotations and become accessible every day for some grace period like 1 year so that people can use them to decrypt their files and move them to a different carousel key.)

Additional thoughts:

• Oracles could publish a PGP public key each day, and make the corresponding private key accessible one year later. If you wanted to lock your coins for a shorter time, just pick an older PGP public key, for example pick one published 335 days ago so that you can get the private key in 30 days.
• For redundancy you could encrypt your private key with PGP keys from several different Oracles.
• Wallets could handle all of this time-locking behind the scenes and simply present the user with a “lock coins for x days” interface.
• Locking can occur on a per-utxo basis, so you could stagger your utxos on the calendar. E.g. you could give yourself access to a different chunk of bitcoin each month for 12 months.
• If you find that you need to sell a bunch of bitcoin, but yours are all locked up, you can always use loans and futures contracts.
• An alternative to CLTV for a backup spend method could be something like an M of N Shamir scheme with shards at several bank deposit boxes, lawyer, etc.
• Oracles could get paid for private keys with lightning, and use lightning capacity as an anti Sybil proof.
• This idea is very private and decentralized. For example, the Oracle has no insight into who uses the service, or how much money is being protected.