A hardware wallet on your iPhone, how Apple or Google could build the perfect Bitcoin wallet
Everybody who has used Bitcoin knows that self-custody is hard. While creating a seed phrase is trivial, storing and protecting it against misplacement is hard. Many users do not understand that storing a seed phrase requires you not to lose or put it online. We have become too conditioned to rely on a bank to bail us out if we lose account access.
But what if Apple or Google built a native wallet for iOS and Android that would be just as secure as a hardware wallet and easier to recover if you lose your keys? If this is even possible, how could it look? In this article, I will describe how I would build a native wallet for iOS and Android that would be integrated directly into Apple and Google Pay.
Secure element — support for secp256k1 is required
Every iOS and Android device contains a piece of hardware called a secure enclave. A secure enclave allows a user to store private keys safely, and these keys never leave the device. Since these keys never leave the device, they cannot be exported.
For an iOS or Android device to support the ideal Bitcoin wallet, it must support secp256k1, the type of signature scheme used on the Bitcoin network. As of this writing, few devices support this scheme, and users must own a compatible device. I believe that secp256k1 support will become ubiquitous in future.
Compatible devices can securely create a private key and use it to sign transactions, much like how hardware wallets work today.
Adding multiple devices
Users may wish to spend funds from multiple devices, but the secure enclave prevents the export of its keys. How would you enable multiple devices to spend the same funds? Multisig!
The Bitcoin protocol natively supports m-of-n multisig, meaning multiple keys can spend the same UTXOs.
Adding a device would generate a multisig wallet where any eligible key can spend the funds.
OP_IF <numWallets> <publicKey1> <publicKey2> … <publicKeyN> <numWallets> OP_CHECKMULTISIG
It’s important to note that adding or removing a trusted device would require migrating all existing funds to a new multisig. Apple or Google could provide a simple step-by-step process for this.
Having multiple devices would also provide some redundancy, such that if you lose one device, you can still spend the funds using your other devices.
Seed phrase free backups
Since the secure enclave prevents exporting keys, users cannot write down a seed phrase and back up their wallets if they lose their device(s). This would be a disaster! I hear you saying, but fear not. Users could securely recover their funds from Apple or Google if they lose their devices.
The Bitcoin protocol supports CSV (CheckSequenceVerify). CSV is an opcode that can be included in a Bitcoin script, allowing a key to spend funds after a certain timestamp has been reached. This key cannot spend the funds before the timelock, giving users full control of their funds before the timestamp. The user can also reset the timelock by sending their funds to a new multisig with an updated timestamp. In this case, Apple or Google would be the trusted custodian of the key, and they can recover the funds after the timelock is reached. If users lose access to their keys, they must contact support and have Apple or Google move the funds once the timelock has lapsed. This process would require authentication and potentially a fee.
Apple and Google can push notifications to users, reminding them that the timelock is near and should be reset. Users can then migrate the funds to a new multisig or go through the recovery process.
We can modify the script above so that a trusted third party (in this case, Apple or Google) can spend the funds if a certain timelock is reached. Users can still spend the funds if they have the private key and haven’t migrated to a new multisig with an updated timelock.
OP_IF
<numWallets> <publicKey1> <publicKey2> … <publicKeyN> <numWallets> OP_CHECKMULTISIG
OP_ELSE
<timelockValue> OP_CHECKSEQUENCEVERIFY OP_DROP
<userPublicKey> <thirdPartyPublicKey> OP_2 OP_CHECKMULTISIG
OP_ENDIF
2FA Multisig
Another neat feature that Apple or Wallet could add would be a 2FA multisig, similar to Blockstream Green's. Funds would be sent to a n-of-m multisig, with the user holding one or multiple keys and Apple or Google holding another. Apple or Google would co-sign the transaction if the user provided a valid 2FA code, or the user could approve the transaction on another device with a key (this other wallet could co-sign instead of Apple or Google). Users could also choose either method, opting for the most convenient.
Conclusion
I hope you enjoyed reading this article. Of course, everything I say in this article is conjecture. I have no idea how Apple or Google would build a Bitcoin wallet. They will probably build something quite different and service other use cases, such as a business multisig or the lightning network.
What do you think of this idea? What would you change about it? Leave your comment below.
