|If you find WORDS helpful, Bitcoin donations are unnecessary but appreciated. Our goal is to spread and preserve Bitcoin writings for future generations. Read more.||Make a Donation|
Posted January 18, 2020
A simple (worst case) evaluation of MultiSig wallet backups by 6102bitcoin
Consider a bitcoin wallet with a total of n keys, of which m are required to spend. X backups are made per key. When making bitcoin backups for this wallet there are three important things to consider;
1. Number of backups
We wish to minimize the number of backups required, predominantly because placing backups in a secure location can be time consuming, and checking backups are in place increases at least linearly with the number of backups required. The total number of backups required is equal to nX.
2. Risk of Theft
A thief can steal the bitcoin with access m backups (in the worst case scenario). Let this be the ‘theft tolerance’ of the setup.
With regard to the risk of theft, unless you are under targeted attack the theft tolerance of your backups is critical, rather than the % of keys the thief must access.
Note: Users who may be under targeted attack may prefer to evaluate the percentage of keys which must be accessed by the thief rather than the number of keys.
3. Risk of Inability to Recover
Losing access to a minimum of X(n-m+1)-1 backups does not impinge on the ability to recover the bitcoin. Let this be the ‘minimum backup redundancy’. Losing more than this number of backups could potentially make recovering the bitcoin impossible.
With regard to minimum backup redundancy the % of keys that can be lost is considered more important than the actual number of keys.
With this in mind we present an overview table of different m-of-n wallet configurations with different numbers of backups per key (X).
Redundancy (%) vs Total Backups
When comparing the redundancy in terms of % backups you can afford to loose vs the total number of backups required to place it is striking how limited the redundancy of a 3of3 scheme is, even with 9 backups of each key.
If course, this is because we have assumed that that the ‘worst case scenario’ unfolds (e.g. for a 3of3 every one of the keys lost is the same key) which is very unlikely. This is done to be prudent, however future work could incorporate the statistical likelihood of these events, rather than assuming worst case scenarios.