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:
IF
<user_pubkey>
ELSE
<366 days> CHECKSEQUENCEVERIFY DROP
<guardian_pubkey>
ENDIF
CHECKSIG
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