The private key controls the bitcoin wallet, and the scheme is simply a way to describe how the key is stored and kept secure.
Important aspects to consider when choosing a private key management scheme are what you expect your users to use the wallet application for, who they are, how much bitcoin they might store in your product and what layers they need to transact on. For example:
Target audience - Are your users completely new to bitcoin and its concepts, or well versed in all the technological underpinnings?
Use case - Are you building a personal finance product for daily payments, or a long-term life-saving storage solution?
Value stored - While we always strive for no loss of funds, how critical to their financial situation would it be if your user lost access to their funds?
Transaction layers - Do your users need to transact on both the base layer and the lightning network?
The narrower you can define your answer to these questions, the easier it will be to pick the right private key management scheme, and provide a great user experience. If you find yourself wanting to target a wide range, it might be a good idea to use a progressive scheme that changes as the user’s funds and familiarity with bitcoin grows.
The trick to picking a private key management scheme is finding the appropriate balance between convenience on the one hand, and risk of loss and redundant security on the other. While learnings over the last decade mean we can now enable higher security and good user experience at the same time, there is always a balance. Higher security generally means more friction and work for the user, both during setup and usage of a wallet application.
There are many potential threat-vectors for users of non-custodial wallet applications. People will be exposed differently to these vectors, and be more or less comfortable with their risk in each.
As a simplification, we can characterize the main potentials for loss of funds as;
Self-inflicted - you lose access to your own private key
Theft - a third party gains access to your private key
So your goal is to make it hard for users to lose their keys, and at the same time, make it hard for a third party to get to them.
Casa’s wealth security protocol is good reading material for more complete views on threat vectors and risk.
Now that you have a clear picture of your use case, target audience and risk vectors, we can consider which schemes might be suitable for your product.
Recommendation
If your product supports the lightning network by running a local node, the automatic cloud backup scheme is often the best fit. This is due to the need for continuously backing up accurate channel states. It is possible, but more complicated for the user to achieve this with a manual backup.
It is not yet possible to use external signer or multi-key schemes for lightning. This is due to the need for the private key(s) to be available to the lightning node at all times.
Here’s an illustration of the spectrum of suitable schemes for use cases ranging from low value and casual usage, to high value and critical usage.
Or you can follow this flow chart to find a suitable scheme for your use case.
Now let’s dive in and look at the various schemes that might be suitable for a personal wallet application with a single user to understand the differences at a high level.
While multi-key setups can be used for personal use, if several people need to share funds, multiple keys become a necessity. You will often see this referred to as multi-sig setups, stemming from the fact that multiple keys are needed to sign a transaction in order for it to go through and be valid.
The use cases for shared schemes include spouses managing a joint account, groups, organizations or companies managing their funds, as well as inheritance planning. It can also be used for governance of an organization, with transactions used not to transfer funds but to record, or vote, for decisions.
Multi-key - several keys and several people control the wallet
There are also several non-recommended private key schemes not detailed in this guide that are not widely used due to their poor security, lack of interoperability and unnecessary complexity. Below are schemes not recommended to be used in your bitcoin applications and why.
Key sharding (Shamir’s secret sharing): Sometimes referred to as an alternative to multi-key setups, but the security risks are much greater. Its major drawbacks are a single point of failure, no key invalidation, no widely used implementation (though SLIP-0039 does exist), and poor auditability. Read more about the issues with key sharding here.
DAT files: A legacy form of backing up bitcoin private keys that use the generic .dat file type. These are still used today by Bitcoin Core due to security concerns with non-hardened key derivation. This form of private key scheme is not widely adopted due to its lack of interoperability among wallets, not being human-readable like a recovery phrase, and being potentially insecure if the user does not encrypt the keys contained within the file.
1-of-2 multi-key: This multi-key scheme may prevent users from misplacing a private key but offers no security benefits with added complexity to the scheme. Making multiple redundant copies of a single sig key offers the same benefits around key misplacement without the added complexity. Learn more here.