Wallet Recovery by a Third Party

I have been thinking about the newcomer problem for a long time now. Here’s my idea to solve it.

The problem is when you introduce people to cryptocurrency and make them install a wallet, they often don’t back up their funds (they don’t write down their seed phrase). This can happen to a friend you gave money to, or to a merchant you onboarded. The result is they end up losing some or all of their money, which is unfortunate.

Most people are not tech-savvy and don’t about how things work under the hood. That’s why we cannot expect everyone to understand what it means to really have control over a coin. that’s why some people will lose their coins eventually.

The simple solution is to use custodial solutions like exchanges, crypto-banks and applications “wallets”. However, this completely goes against the original ethos of Bitcoin, and it doesn’t solve the problems created by the traditionnal banking system.

There is a trade-off. My proposal is a standard non-custodial scheme that could be implemented in wallets so that new users can receive and send transactions without being afraid to lose their funds. This scheme requires a trust third party (how ironic!): the user chooses someone he trusts, called a guardian, who will be able to recover the funds after a given period of time (let’s say 366 days). Note that something similar has been implemented using smart contracts on Ethereum by Argent wallet.

This scheme uses P2SH smart contracts, i.e., funds are sent to P2SH addresses like prxuxxcmne0r6g52e3w6r4vy285n78v4y5436jxad2 (CashAddr format) or 3LSzB4fCQtSE4USGqzBv9VgLEpf1NLNgbX (Legacy format). Therefore it is compatible with Bitcoin Cash (BCH), Bitcoin (BTC) and several other cryptocurrencies.

The general form of the contract redeem script is:


To unlock the funds, the user must use the following script:

<user_sig> 0 <redeem_script>

or, after 1 year and 1 day, the guardian can use the following script:

<guardian_sig> 1 <redeem_script>

Obviously the user can generate as many addresses as he wishes.

On the user’s side, each public key is generated from an extended public key (xpub), using the derivation path m/{TBD}'/145'/0' (BIP-44 purpose to be determined) instead of m/44'/145'/0'. The guardian also have a xpub. When setting up user’s wallet, they both share their xpubs: the user scans a QR code on the guardian’s wallet to get the guardian’s xpub, and the guardian does the same.

The wallet implements this scheme alongside with a classical P2PKH account. It warns users after some time and propose them to consolidate their coins to refresh the CHECKSEQUENCEVERIFY timer.

  • Users can initially use their wallet without writing down their recovery phrase.
  • Once they have done this and are aware of the risks, they can switch to the classical P2PKH mode.
  • They also can become guardians if they want to.

Upsides are:

  • Users can generate an unlimited number of addresses using this scheme.
  • Independence: apart from the setup phase and the recovery phase, no interaction with the guardian is required.
  • Their guardian can help them to recover all their funds.

Downsides are:

  • Scalability/cost: +18 bytes per input. For a 1i/2o transaction (226 bytes using P2PKH), this means a 8% increase of the transaction size/cost; for a 2i/2o transaction (374 bytes), this is a 9.6% increase.
  • Trust: Your guardian can steal your funds after the period of time has expired.
  • Privacy: Your guardian knows every one of your addresses.

The privacy downside is the most concerning.

What do you think of this scheme? Is there a way to improve it?

My initial post on Member (flawed): https://member.cash/?88c3#thread?post=88c32e3a0d

1 Like

Solving this problem is extremely important even at the expense of some trust/privacy. The experience people are used to is similar to bank accounts, where you have a way to recover your funds even if you forget your password.

When thinking about mass adoption, people are willing to sacrifice privacy for convenience (as you mentioned on crypto banks).

The problem I see with this approach is that the user experience isn’t much better than writing the seed (is probably easier to just write and store a seed than to find someone else, in proximity that you can share an xpub with)

An alternative, would be to combine a user secret that can be reproduced based on user input (as proposed in ethereum: https://gitlab.com/status-im/docs/EIPs/blob/secret-multisig-recovery/EIPS/eip-2429.md) with the secret key of the wallet provider (safely stored) and derive some sort of public key from that. This would be layer on top of what you are proposing (and having the guardian be the same wallet software admin)

The way this would work then would be:
If user loses funds:
A) Move to new address based on user secret and authorization by wallet provider
B) Wait timelock and then wallet provider has access to the funds (if its some sort of bank/finance institution- it could “lend” the money to the user and then wait for the timelock to be payed back

1 Like