Bitkey’s inheritance feature makes it easy and secure for benefactors to not only pass on bitcoin to a friend or loved one, but to also give beneficiaries the same security, usability, and recovery tools that Bitkey offers. Built on top of Bitkey’s strong foundation of recovery tools, inheritance uses many of the same concepts that make it hard to lose access to your bitcoin, outlined in our recovery paper, to protect your funds for your beneficiaries. Here’s a closer look at how it works.
Design properties
- Block never sees the benefactor’s unencrypted private key.
- Block stores an encrypted copy of the benefactor’s private key and does not have access to the decryption key. Upon completion of an inheritance claim, this encrypted key material is provided to the beneficiary directly, without ever being decrypted on the server. The beneficiary decrypts this key material locally on their device.
- Beneficiary does not receive any key material or the inheritance amount until inheritance is complete.
- The beneficiary of a Bitkey wallet does not receive any key material or the inheritance amount until an inheritance claim has completed its waiting period.
- Inheritance leverages existing cryptographic structures.
- By leveraging the same encryption patterns and secure channels exchanged when creating a Trusted Contact for social recovery, Inheritance gains the same design benefits of cryptographic communication without the need for identity verification or secrets to remember.
- Beneficiaries can leverage Bitkey’s recovery mechanisms.
- Since inheritance requires your beneficiary to have their own Bitkey, beneficiaries have multiple recovery options for the bitcoin they inherit. With Bitkey’s recovery mechanisms, your beneficiary can regain access to their inheritance even if they lose their phone, cloud, or Bitkey device.
Inheritance set-up
To facilitate an inheritance transaction–to transfer your wallet balance to your beneficiary on your behalf–your beneficiary ultimately needs one of your three private keys to use with the Block server key. However, it is crucial that:
- Bitkey servers never have access to this key, and
- your beneficiary does not have access to this key until the inheritance process is completed.
To ensure the benefactor’s private key material (PKMat) is never accessible to Bitkey’s servers, the benefactor first encrypts it with a Private Key Encryption Key (PKEK) on their app. Once the private key material key is encrypted, it is safe to upload to Bitkey’s server–an arrangement that also prevents your beneficiary from having access to this key until inheritance is completed.
To ensure that this PKEK can ultimately be given to the beneficiary in a way that allows for a balance transfer once inheritance is complete, we encrypt the PKEK with the beneficiary’s Trusted Contact Encryption Key (TCEK)–a key that is created during the inheritance invitation process. Both of these encrypted keys (PKMat and PKEK) are now safe to upload to Bitkey’s servers by the benefactor.
This setup allows the process to be reversed by the beneficiary upon completion of the inheritance, at which point their TCEK can decrypt the PKEK, which can ultimately decrypt the benefactor’s PKMat and allow a balance transfer to occur.
Inheritance claims
While Bitkey’s servers cannot access the keys to transfer inheritance funds directly, it does facilitate the dispersal of encrypted keys to a beneficiary. This ensures that beneficiaries do not receive any sensitive information until the inheritance is approved. This entire process is called an inheritance claim.
Claim approval is done via a system we call Delay and Notify. This system, also used in our recovery process, creates a six-month waiting period before the Bitkey server can proceed with an inheritance transaction. During this time, Bitkey attempts to contact the benefactor via all contact methods the benefactor has set up: push notification, SMS, and/or email. If the benefactor denies the claim at any point during the six-month waiting period, the claim stops, no key material is given to the beneficiary, and no inheritance transaction occurs.
If and when the Delay and Notify period expires, Bitkey’s servers provide the beneficiary with the two encrypted keys (PKMat and PKEK). With these keys, the beneficiary can begin the process of transferring the benefactor’s full wallet balance to their own wallet, using the benefactor’s decrypted app key and server key as signers.
Inheritance transfer process
Once the six-month Delay and Notify period has passed, Bitkey provides the beneficiary with the encrypted PKEK and encrypted PKMat data, as well as a wallet descriptor for the benefactor. The beneficiary uses their TCEK private key to decrypt the PKEK and subsequently uses this key to decrypt the benefactor’s PKMat.
At this point, the beneficiary gains access to the benefactor’s wallet information for the first time. The beneficiary uses this information to create a full balance transfer from the benefactor’s wallet to their own, using the benefactor’s decrypted private key (PKMat) to sign it.
Once a transaction has been created and signed in the app, it is sent to Bitkey’s server to be signed by the benefactor’s server key. Bitkey can only cosign a transaction that is both 1) a claim associated with a completed Delay and Notify period and 2) sent to the beneficiary’s wallet address. This dual validation protects your funds from being transferred for any reason other than an approved inheritance claim, to any other address, without requiring full control of the signing process.
Why we require Bitkey hardware
One obvious trade-off in Bitkey’s inheritance system is the requirement of hardware for the beneficiary. This was not a decision made lightly.
On the one hand, requiring hardware adds a cost to use the feature and few steps to the beneficiary’s user experience. On the other hand, comparable third-party inheritance solutions are typically offered on a monthly or annual subscription basis, and the fee from a one-time hardware purchase is significantly less expensive by comparison. Requiring hardware also saves a beneficiary from the added step of assessing and choosing among many possible means of holding the bitcoin they inherit after you’ve passed, which is particularly beneficial for those beneficiaries who aren’t already knowledgeable about bitcoin when they inherit it.
The design we use for inheritance is called Direct Key Distribution, where we distribute one private key directly to the beneficiary to facilitate the transfer of funds.
In order to safely transfer funds to a beneficiary, there needs to be some proof of the benefactor/beneficiary relationship. In Bitkey’s direct key distribution, we accomplish this by storing a decryption key in the beneficiary’s cloud backup, along with authorization keys that can start the inheritance process. No hardware is technically needed for this to work. So, why do we require it?
For Bitkey wallets, sensitive cloud data is encrypted by Bitkey hardware before it is stored. This ensures no third party can access your wallet in the event that your cloud data is compromised or otherwise accessed by someone other than you. Without a hardware requirement, storing this data for inheritance would be less secure.
Additionally, many customers use the same account for their cloud provider as and their email. This reality presents a unique attack scenario. If a customer's cloud data is compromised, their email could be as well. With only the beneficiary's cloud data as authentication, an attacker with access to the beneficiary's account could restore the account and change the contact information. This could allow an attacker to claim an inheritance without the beneficiary's knowledge. Accounts with hardware, however, are recovered with a key that is encrypted with hardware. When recovering without hardware, a delay period is required. This means an attacker cannot gain access to the account with temporary access, but would need to maintain it through the security delay period, increasing the difficulty of this type of attack.
Inheritance, by definition, is a feature that needs to last a lifetime, so its design needs to be durable for long periods of time. Over a lifetime, it’s not uncommon for people to change service providers, phones and email accounts. When this happens, users sometimes lose their cloud data.
Requiring hardware solves all of these problems. It allows us to securely authenticate the beneficiary when starting an inheritance claim, as well as recover user data should they lose their cloud backup, by encrypting their inheritance decryption keys with the hardware before backing up on Bitkeys servers. These backups–which can only be decrypted by Bitkey hardware–allow inheritance relationships to be restored even if the beneficiary’s app and cloud are lost. If the beneficiary’s hardware is lost, we can replace it using our existing recovery mechanisms, keeping the data needed for inheritance safe by re-encrypting it with replacement hardware.
Why we enforce a six-month Delay and Notify period
Inheritance is built on a lot of the technologies that we built for Bitkey’s Social Recovery feature. However, the security model is quite different. Inheritance is, effectively, a reverse social recovery. In social recovery, you, the protected customer, are in control of starting the process. For inheritance, that’s not possible, so the beneficiary is in control of the process.
While a beneficiary should be someone you trust, we can’t simply take the word of anyone who initiates the inheritance process and must have built in protection for the benefactor. While only your beneficiary can start the inheritance process, we want to ensure the benefactor and beneficiary both have an opportunity to indicate they have not been compromised in some way. This is where the six-month Delay and Notify period fits in. During this time, we use every contact method available to try to reach the benefactor to ensure that the attempt is valid.
Unlike Social Recovery, no access is granted until after the six-month Delay and Notify period is completed. This means that the beneficiary cannot gain any balance information by simply starting the process, keeping you in control of your funds and privacy.
Why we chose Direct Key Distribution
In Bitkey’s Direct Key Distribution model, we distribute one private key directly to the beneficiary to facilitate the transfer of funds when the full inheritance process is complete. Bitkey’s server facilitates the policy for this operation, after being triggered by the beneficiary. During development, we did consider one alternative model: Server-driven Covenants. Here’s why we ultimately chose Direct Key Distribution.
Server-driven covenants overview
In a Server-driven Covenants approach, the benefactor would generate a set of inheritance transactions whenever they received or sent funds from their wallet. The set of transactions would include:
- An escrow transaction to an ephemeral wallet that is spendable with a short timelock
- A transaction of inheritance funds per beneficiary from the ephemeral wallet to a pre-specified receive address for that beneficiary.
Upon triggering the inheritance claim–which would require a quorum of people to coordinate and inform Block–the escrow transaction would be broadcast and beneficiaries informed. If the claim was illegitimate, the benefactor could claw back the funds into their own account within the transaction timelock period. After the timelock expired, the server would broadcast the pre-generated transactions from the ephemeral wallet to the pre-specified receive addresses for each beneficiary and broadcast the transaction(s).
Downsides to Server-driven Covenants Approach
The two downsides to Server-driven Covenants are:
- The beneficiary must ensure the wallet associated with the address receiving the inheritance is always accessible and in their control. In situations where the inheritance transaction is being sent to another wallet or an exchange, this can be a massive footgun.
- The funds available to the beneficiary are those contained in the benefactor-generated transaction. If the benefactor doesn’t update their inheritance transactions before the inheritance flow is triggered, the beneficiary is left with only part of the inherited funds.
Direct Key Distribution and Bitkey’s hardware requirement eliminates both of these downsides in a way that we believe is better for both benefactors and beneficiaries.
Feedback welcome
At Bitkey, we believe the strongest products come from collaborating with the communities who ultimately use them. That’s why we’re committed to building in the open and sharing designs like this publicly. Bitkey’s inheritance feature is just one part of our broader mission to make bitcoin self-custody as accessible and secure as possible for everyone.
Have thoughts, questions, or feedback on this feature? Message us at [email protected].
