Long term storage in transaction form

Long term storage in transaction form

One of Bitcoin's popular usages is long term storage of funds.
A few methods exist :

1. Digital form
A copy of the private key is kept in a file on a hard drive or other digital media either off or online, usually encrypted with a password.

The downside :
The integrity of the file can not be verified without actually testing the file on a computer. Downloading the file or loading the media is a must.
If the file is online, it will be copied, maybe even deleted.

2. Physical form
A copy of the private key is printed on a physical medium, usually paper encrypted with a password.

The downside :
The key can be lost, stolen or damaged.
Creating multiple copies of the key also poses a problem. It's hard to keep track of many copies, and also requires the usage of a very strong password, in case one is stolen without the knowledge of the owner.

3. Mnemonic form
A seed for generating a private key in a deterministic process is chosen by the owner.

The downside :
The key or seed simply cannot be backed-up or verified without resorting to one of the previous methods.
To withdraw the funds, the owner must use a computer to sign the transaction, and also be connected to the bitcoin network, to transmit the signed tx.


I propose a method that combines all of the first three, and a couple of new processes to create a safer long term storage solution.

The process :

Alice wants to store her bitcoins for long term.

Offline:
She creates two private and public key pairs and the two corresponding public addresses. Address A and address B.

Online:
She sends all the bitcoins she would like to store to address A like she would normally.
The bitcoins are now signed to address A.

Offline again:
She then signs a transaction (T) for these same bitcoins, this time from address A to address B.
She does not transmit this signed transaction.

Alice now holds:

Private key for address A. The address that holds Alice's bitcoins on the blockchain.
Private key for address B. A second address, currently holding 0 BTC not seen on the blockchain.
Signed transaction T, ready to be transmitted to the network, of bitcoins from address A to address B.

Alice now destroys the private key for address A.

This slightly different method allow for some complex operations. These are some examples :

1. A digital will :

Alice funds address A with 3 different bitcoin transactions.
Along with address B, Alice creates addresses C and D.
She signs each one of the 3 tx's in A like so :
T1 = T:A->B
T2 = T:A->C
T3 = T:A->D

She gives away the private keys for addresses B, C and D to their owners, and in time, the pre-signed transactions T{1,2,3} will be spent on the network.
Addressed B, C and D are funded without the need for Alice's private key for address A, and without the need for trust.

2. A physical "security by obscurity" case :

In addition to address B, Alice can create addresses {C, D, E...} which will be used as decoy paper wallets in an off-site location.
Alice only needs to create one real BIP0038 encrypted paper wallet, and the rest could be used as encrypted decoys, wasting time for a thief.
Since all paper wallets hold 0 balance, and have never been seen on the network, a theif would have a very hard time picking the right one.
The transaction that spends the bitcoins to the real paper wallet should remain private, however even if the transaction does leak into the network, the bitcoins are still not lost.

3. Minimizing exposure of secrets :

Alice uses the same method as the original, except she creates address B using a deterministic process from a seed.
She now has no digital or physical assets to keep, except for the transaction T.
It's safer for her to use any method of backup for T, instead of the seed or A's private key.
In case T leaks and is transmitted to the network, Alice is still in full control over her coins.

4. This last kind of operation is still considered sci-fi today (the code does not exist yet), but in theory this can be done :

A sort of "trip-wire" system can be built that will:

1. Store a copy of a transaction T(A->B)
2. Be connected to as many nodes as possible on the network, preferably to major pools' nodes
3. Constantly monitor the bitcoin memory pool for any transactions, call them M(A->?), outbound from address A to any other address
4. In case of such transaction M, immediately transmit transaction T to all connected nodes
5. With any luck, transaction T is mined on the next block, and transaction M is considered a double spend

Alice gets a second chance.
The process can even repeat for a number of "hops" between addresses, if more than one was compromised.


In conclusion, Alice's only real thing of value now is the pre-signed transaction T.
Trusting a 3rd party with the transaction is much easier and safer than trusting it with the private key that holds the bitcoins themselves.
Since the transaction was actually designed to be public there is no major threat in it leaking to the network prematurely, and if it does actually leak, Alice is the first to know.

The process of withdrawing the bitcoins is simple. Either transmit the original transaction T, or if a system like in (4) is employed, a "release" switch could be used to do that too.
Address B should now hold the bitcoins, and it can now be imported to the wallet.

- arubi
15.02.14
19oufRirjCDHrbLouLJ2X3Zc3t1HaYRdf6
----------------------------------
H97JNnedREQT0CwA41JYp5y2Fckx7BFv1NXnKkSE9y6e15OG+DB1UI/841iZ+r8JA+2Q1hNtdah8X57qIZu5Z8M=