Topic: Some feature requests (Read 211 times)

Just use a multisig script.

By session I mean a temporary key for that particular signing day.

I am thinking of a situation where you have to travel to collect fragments.  Once you have used them, you have to travel to bring them back.

Just copying the fragment would fix that, so maybe I am overthinking things. 

In retrospect, the low tech solution is best.  All you need is a pen and paper.

I was thinking risk of theft or destruction during transit, but the stored fragment isn't sufficient to release the funds on its own and the original paper backup is still back at the safe location.

As the price rises, the level of professionalism in securing the fragments increases. 

Ideally, people should put the security in place before they have a significant fraction of their wealth in cryptocurrency.

There are 3 main types of risk

- theft
- extortion
- destruction

Armory is mainly targeted at protecting against destruction and electronic theft.

The primary point of fragments is to protect against destruction of the seed by placing them in multiple locations.  This can include destruction by forgetting the seed. 

If the fragments are in multiple locations, then more than one must be destroyed simultaneously.

It also protects against opportunistic thefts.  If someone happens to steal one fragment, it is worthless.

The risk model in the early days was that forgetting your password was vastly more likely than physical theft.  Is that still true with rising valuations?

A safe deposit box gives protection against extortion risk.  Telling someone where the fragment is doesn't help them.

There is a tension between redundancy and extortion risk.

If you have a safe deposit box, then that protects against extortion only if the fragment in the safe deposit box is required to release the funds (so N of N). 

If that condition is met, then it removes the redundancy.  Damage to the paper backup in the safe deposit box means all funds are lost.

Maybe the solution is to have 2 safe deposit boxes.  They are only a few hundred dollars a year.

1&2 will be easy with once BIP32 is supported. Doesn't work so well with the Armory chain derivation.

I don't get the point of 3. what's to stop whoever created a session from reusing it? The idea of a "session" is that there is a clear way to close/revoke the session.

I had a fun weekend last week trying to manage multiple coins with all the airdrops going on.

I wonder if the risk profile has changed.  As the price rises, the security level needs to be increased.

It occurs to me that a few features would be really useful and enhance security of the paper backups.

- Child wallets

This would involve two levels of deterministic wallet (might I say hierarchical).

When creating a new wallet, you could click one and say "create child wallet".

It would compute hash(parent.seed | index) and use that to create the new wallet.

If a child wallet is compromised, it wouldn't affect other child wallets or the parent wallet.

The use case for this is to have multiple wallets for different coins all sourced from the same root.

The weakness is ensuring that the same child wallet index isn't created twice.  The offline computer could store the highest index used for each parent without much risk (or even the highest index used for any parent). 

Alternatively, the offline computer could pick a random index from 1 to 1 million.  Unless someone has around 1000 child wallets, a collision isn't very likely.

It can also check any visible wallets for a collision.

The big advantage is that it allows export of all the private keys from an "expired" wallet without compromising the root paper backup.

The recommendation would be:

Move Bitcoin to new (child) wallet

Once that is confirmed, export all private keys for expired wallet.

- Sign from backup

This means that there is no local storage of private keys for high value actual cold store. 

There shouldn't be listing of the wallet on any computer (offline or online).

The unsigned transaction would be read in and then you would be prompted for the data stored on the backup.

It would give the usual warnings and then sign the transaction.  The private key would be erased from memory.

- Signing session keys

This is again for high value signing.

I am thinking of something like

Create random "session key" and print/write to paper.

Get first paper backup

Encrypt the data on the first paper backup with the session key

Return first paper backup

Get second paper backup

Encrypt the data on the second paper backup with the session key

(and so on)

Once you have enough fragments

Enter session key

All fragments are loaded and decrypted

You can then do "sign from backup" for the transaction.

Destroy session key

Delete encrypted files (kind of optional at this point)