Technical Details
This is a proposal of inheritance protocol, which may suit Bitcoin holders, who give importance to trustless and no third party dependency in any part of the flow.
​
We refer Owner and Heir as two main actors of the process in the explanation below.
​
The protocol improves on or may complement existing approaches like sharing private keys, multi-signatures, dead man’s switch, keeping bitcoins permanently in some time-locked P2SH, P2WSH scripts, etc. By the word "trustless", we mean no trust to not only third-party entity. Even an Owner can not fully trust Heir as you will see below.
​
It demands initial setup and some regular status checks for Owner and Heir. We believe that in many cases it should not be a frequent activity for them and it will not be complicated if software support is implemented properly.
​
The protocol utilizes UTXO spending rules with CHECKSEQUENCEVERIFY (OP_CSV) opcodes. In the most simple case, it can be described as Bitcoin script below. UTXO's with such scripts can be spent anytime by Owner. But Heir can spend only when the output age is no less than N days.
​
OP_IF
<Owner Public Key> OP_CHECKSIG
OP_ELSE
<N days> OP_CSV DROP <Heir Public Key> OP_CHECKSIG
OP_ENDIF
The key point is that there is no need for an Owner to permanently keep her bitcoins in such CSV locked escrow UTXOs. It should be enough for Owner to only construct a transaction, which spends Owners's bitcoins and has CSV locked outputs as above. The transaction should not be broadcasted but rather shared directly to Heir. A Heir will broadcast the transaction only when inheritance time comes. As a result, bitcoins will be transferred to the escrow address without Owner's participation. Then Heir need to wait for the time defined in the locking script and redeem bitcoins from the escrow UTXOs.
​
The regular inheritance flow can be described as a diagram
​
It is important to understand that there is no guarantee that the Heir will not act maliciously and will not broadcast the transaction before the inheritance time. As another threat, the transaction to escrow can be compromised and will be broadcast by someone else. To secure herself against such attack vectors the Owner should check her Bitcoin balances with a frequency no less than every N day, which is escrow CSV lock time. Whenever bitcoins are transferred to the escrow address not legitimately the Owner is able to redeem them before the Heir is able to do so.
​
Apart from monitoring overhead, there are items to be considered:​
​
-
Unpredictable fee: Network fees of transactions to escrow can be too low or unnecessarily high at the moment when the transaction is to be broadcasted. This, for example, can be mitigated by pre-signing transactions with different fee options or enabling Heir to change the fee if a transaction was signed by not covering all inputs and outputs. SIGHASH_SINGLE, SIGHASH_ANYONECANPAY, or other signing rules can be used here.
​
-
Lack of privacy: Heir is able to know beforehand how much exactly he is going to inherit and track at least some Owner's balances. The solution for that is not yet obvious and is something to be worked out.