Forbes contributors publish independent expert analyses and insights.
My PhD student and I just finished a new research paper on multisignature (threshold) signatures in Bitcoin. In Bitcoin, ownership isn’t physical; it’s cryptographic. Whoever controls the private keys controls the coins. This design is both elegant and unforgiving. It removes the need for trust, but it also removes the safety net. Lose your keys, and your money is gone forever. The same feature that gives Bitcoin its strength, complete self-sovereignty, also exposes the human factor.
To manage that risk, Bitcoin lets users protect funds through multi-signature schemes, where several private keys are needed to authorize a transaction. For example, you can require three of five signatures before coins can move. The more signatures required, the harder it is for an attacker to steal funds. But the harder it becomes for an attacker, the easier it becomes for the owner to lose access himself. Security improves, but usability declines. Somewhere between those extremes lies the optimal balance: enough friction to deter theft, but not so much that it locks out the rightful owner. Our paper solves for the right balance.
We identify how to adjust this balance with changes in the user’s or attacker’s environment, leading to some counterintuitive results. For example, If the user places his private keys into a safe that deters a potential thief, one might expect that the user can relax his multi-signature threshold since he has increased the security of his setup. But decreasing the attacker’s probability lowers the expected loss from an attack, allowing the user to afford a higher threshold. In effect, the lower probability of theft makes a high threshold “cheaper,” which is why the user should increase, rather than decrease, the threshold.
Similarly, embossing private keys onto a fire-resistant plate will increase the probability of the user retaining his signatures over time (e.g. if his house burns down). This will lower the user’s expected loss, which makes high thresholds cheaper. So the user should again pick a higher, not lower, threshold number of signatures.
The key idea here is that high thresholds have a benefit but also a cost. As such, when you improve the security (using the safe) or usability (the titanium plate) of your setup, you are naturally decreasing the expected loss of an attack, and therefore reducing the cost of a high threshold. So you can afford to raise your threshold. Thus, high thresholds and security improvements are complements, not substitutes.
Over time, the probability that either the owner or an attacker can access a key naturally decays. Devices fail, passwords are forgotten, and hardware is misplaced. Attackers face decay also — vulnerabilities are patched, exploits fade, and incentives evolve. What’s safe today can become too rigid tomorrow, and what’s convenient now can become dangerously exposed later. Bitcoin security, like everything else, lives on a curve that bends over time.
That reality points toward a better design: dynamic multi-signature schemes that evolve as risk does. A wallet might start with a four-of-five requirement in its early, high-risk phase, then relax to three-of-five after a certain period. Early on, the system stays conservative, guarding funds when they’re most vulnerable, then gradually shifts toward accessibility as signatures eventually get lost. Letting time influence access makes Bitcoin security behave more like real risk — high at first, lower later.
Smarter hardware, better recovery tools, and clearer key management let users set higher thresholds safely. Stronger encryption and improved operational security do the same by lowering the odds of compromise. Each advance expands the design space for long-term custody. In effect, both technology and human behavior become levers for balancing two opposing forces, fear of loss and fear of theft.
Finally, we prove that degraded multisig schemes are optimal, and implement them in Taproot using timelocks, inspired by Jimmy Song’s early work in this area. Check out the paper and the GitHub implementation for details.
