Feature Request: Single-Key Inheritance through PSBT custody using Envoy app & Envoy+

I’ve thought about this for a while and think that Foundation is in a unique position where they have 4 components necessary to make this feature a reality:

  1. Control over Hardware & Software stack
  2. Open source operating system
  3. Mobile app that can be connected to device
  4. Envoy+ membership with reoccurring subscription (for future users)

How it would functionally work: the user would onboard their wallet and add beneficiaries using the Envoy app. Beneficiaries would simply be wallet addresses, the percent split of owned assets or flat amounts (ex: 50% of balance) and a cell-phone and email address, or potentially, an Envoy/Foundation app user.

The user’s Passport wallet would deterministically generate an encryption key using the user’s wallet’s private key, which would be saved on device and also shared with the beneficiaries – this could be done offline trustlessly, or, through the Envoy app.

Whenever the wallet owner signs a transaction using their prime device, additional transactions (PSBTs) are created and signed, optionally multiple times (There should be multiple PSBT’s available, accounting for the possibility that fees are significantly higher in the future). These PSBT’s are encrypted using the encryption key, not broadcast, but instead uploaded on Envoy’s server for Envoy+ members. This prevents having to share any private key material with Envoy/Foundation. Every time you sign a new transaction using your Passport Prime wallet, new PSBTs are created, signed, encrypted, and shared with Envoy+.

The only thing that Foundation could possibly do if they were to be able to get the encryption key and decrypt the PSBTs, is broadcast your transactions to send your BTC to your beneficiaries. There would be a user-set timelock, that after X amount of time, the PSBTs would be available to be shared your beneficiaries. The beneficiaries can request the inheritance at anytime, but you would be alerted, and any wallet transactions would refresh the timer anyway.

All other inheritance options require using multi-signature setups or introduce other attack vectors. This method would be safe, optional, and still allow users to share their private keys OUTSIDE of Foundation/Envoy’s ecosystem if they do so please, and if you use it in a different (non Foundation) wallet, the PSBT’s would be useless (to my understanding – correct me if I’m wrong), preventing lock-in… At the same time, for those concerned about potential for lost keys (such as in the case of the CA fires recently), this could help address that need.

Given the open source nature of the Passport Prime wallet, preparing the PSBT’s should be trustless, as preparation of the unsigned PSBT is done on the OS chip, signed on the secure element, then signed PSBT can be confirmed on device prior to both transactions being sent out to the Envoy app for 1) broadcast and 2) custody for inheritance planning.

I’d love to hear your thoughts on this. I’ve not seen a company or wallet provider think of this method for inheritance planning before. Traditionally using miniscript, multisig schemes, or custodial arrangements is how it’s done.

Hey @RadRedRover thank you for taking the time to write this post!

It shows that you understand the power of PSBTs! We have discussed internally similar schemes to this one multiple times, because as you correctly stated, we have all the building blocks to create it. PSBTs are a powerful tool, and one that is not being used to its full potential.

In your proposal however, the user would have to somehow send the decryption key to foundation and then it would be us the ones broadcasting it on your behalf. This however opens more questions:

  1. How would that be done? How could an accidental release be prevented?
  2. Since you have to broadcast “something” (the decryption key) anyway, and you need an internet connection for that, why not broadcast the PSBT itself directly and forget about us? Sending us the decryption key and have us broadcast it seems like unnecessary extra steps at that point

Inheritance is a complex subject, and it’s hard to find a flawless system with PSBTs. Again, we love the idea though, and we also think there’s something here that can be used. I can tell you however that although we are not closed to developing something in this line in the future, it is not in our short term plans - we are currently fully focused on releasing Passport Prime and making all systems go for it.

In any case, thank you for the detailed proposal! You might see something similar coming in the future :wink:

1 Like

For point 1:
Jack Dorsey’s Block created Bitkey wallet (a 2-of-3 multisig using a physical device, a mobile key, and a server key [controlled by Block]), and they’re using a similar method for social recovery in the event the user loses one of their keys. This is a good paper of theirs that outlays their recovery methods/features. I still think there is room for improvement, as mentioned above and I go further into below.

During onboarding/selection of a beneficiary, the owner of the wallet provides a key to the beneficiary through a secondary communication method — SMS (or encrypted iMessage), email, or, in-person (face to face). The beneficiary enters the code in their Envoy app, where it is stored. The code that is given is used by the app to open an encrypted connection directly to the wallet owner’s Envoy app. Once that connection is created, the handoff of the encryption key is done, not through Foundation servers, but instead, peer-to-peer, from app-to-app, so Foundation never sees the decryption key.

Now that both the wallet owner and the beneficiary’s apps know what the encryption/decryption key is, the wallet owner will be able can safely provide the encrypted signed PSBT to Foundation/Envoy servers, knowing that Foundation cannot broadcast the message without the key from the beneficiary.

To point #2:
The reason that Foundation is in the loop is to enforce the time-lock on the inheritance. Foundation knows whenever it receives a new encrypted transaction from the user, and knows how long their set lock-period is. Directly handing off the encrypted PSBT to the secondary user makes sense, but then you can’t necessarily enforce the time-lock if the mobile app is open-source. The beneficiary could theoretically receive the decryption key, and receive the encrypted transaction, and completely avoid an app-enforced time-lock.

Foundation being in-the-loop would minimize any chance at Bitcoin being stolen by a malicious beneficiary.

  1. If Foundation servers were to be hacked, the risk would be minimized, as the encrypted transactions would be useless without the decryption key.

  2. Even if they were to be able to get the decryption key, and subsequently decrypt the transactions, the assets would be safe within the beneficiaries wallets, with no possibility of the assets being rerouted to a bad actor’s account, making the signed PSBTs useless (and potentially problematic, as they have no way to know who the accounts in the PSBT belong to)

  3. If for some reason Foundation lost the signed TXNs, or, if the beneficiary lost their decryption key, inheritance is still possible by the user recovering the wallet owner’s recovery phrase… a back-up plan, allowing inheritance to be possible such as by providing a sole beneficiary with the recovery phrase, and a lawyer-custodied passphrase (for instance).

Potential for Custodian-assisted recovery
4) Another thought that came to mind: What if the user could simply choose an address (such as their own exchange account) and add a time-lock — if the user does not use their Passport Prime to sign a transaction within 1 year, Foundation will automatically broadcast the transaction that will send your Bitcoin to Coinbase (or any cex of the user’s choice), and email a pre-written message to a beneficiary/family member. This would remove the need for the beneficiary to be a crypto native — and instead they could refer to the exchange and report the death of their family member — and the person would already be set as the beneficiary on the exchange account.

In summary:
The goal of this is to enable inheritance functionality with as little trust as possible. While there might still be room for failure (early inheritance payout in worst-case scenario), the proposed solution could work at very little cost to Foundation on an ongoing basis. Envoy+ memberships should be more than enough for storage of some metadata and encrypted PSBTs.

When compared to Block/Bitkey’s solution, Block’s solution introduces multiple potential attack vectors including attacks on Bitkey/Block servers, malicious versions of their mobile app being introduced, and opening the door to a non-fully trustless solution. If all things failed with Bitkey, the user could potentially end up losing their Bitcoin, as a successful attacker could sign any transaction.

On the other hand, if Foundation were to implement inheritance in the proposed way, it would be almost trustless, with the only consideration being the possibility that your inheritance is broadcast early (or not broadcast at all)— and I would think that a majority of users (who would be interested in this functionality) would prefer those risk(s) over the risk of user’s keys being compromised and/or not fully secure. In the case of the 4th point above, there is the chance that the exchange no longer exists after the time-lock (such as in the case of FTX/MtGox), but the same can be said about potential loss of key of the beneficiary’s wallet. I think the trade-offs are better than the alternatives.

Overall:
As far as timeline goes, the release of Passport Prime comes first, and I totally understand that! I do think that this implementation is very viable — to your point, there’s something that could be used here. My goal in coming up with this is to identify what the best possible way to make inheritance simple and secure without major drawbacks such as giving up custody of key(s). Even if not soon, I do hope that Foundation does seriously consider the idea as laid out here. This is a very slept-on feature/functionality that could bring a lot of value to the ecosystem, and have other wallets seriously consider the functionality themselves.

2 Likes

Excellent and well thought out @RadRedRover, thank you!

As Jack mentioned, we’ve had something similar to this idea doing the rounds internally for some time now. Would love to bring it to life this year :smiley:

1 Like