Our goal at Misthos is to provide the best wallet experience for businesses, teams, or pretty much any context in which there is shared ownership of Bitcoin involved.
To achieve this goal, one of our guiding principles is that the needs of the group as a whole are paramount when considering new features as well as the overall UI and UX experience.
This principle can come into tension with other aspects of wallet development so in this article I will discuss some of the features we have shipped since our launch on testnet that highlight the trade-offs and how we are mitigating resulting risks.
One area of tension is that a group naturally changes over time as people join and leave. Catering to the needs of the group means enabling this change and reducing any friction that may come with it. But this is fundamentally in conflict with how a primitive multisig wallet works on a technical level. When generating a multisig address the public keys that the address is associated with are hardcoded and can not simply be ‘switched out’. Changing any of the keys would result in a different address.
Our mitigation approach for this is quite simple: Essentially we are simulating the experience of one continuous logical wallet over time even though the custodians of the wallet may change. This works due to the fact that it is best practice in Bitcoin to generate a new address every time someone intends to receive income. Doing so not only has benefits such as better privacy and security but allows us to change the underlying wallet configuration every time a new custodian joins or leaves. When a new address is generated it will always be backed by the keys representing the current configuration of custodian.
But unfortunately this is not enough. Wanting to simulate the experience of one continuous wallet that belongs to a dynamic group of people introduces a lot of complexity and risk that needs to be explicitly dealt with and in some cases even exposed to the end users.
- What happens with Bitcoin that is secured by old addresses when the wallet configuration is updated?
- What if Bitcoin gets sent to an old address that no longer represents the current configuration?
- What if Partners have left and the old addresses aren’t accessible anymore?
- How is the user able to assess the risks involved and know what actions must be taken to ensure the funds always remain accessible to the current group?
Under normal circumstances (meaning always receiving income on an up to date address + making payouts in a regular frequency relative to the dynamic of the group) none of these questions have much relevance. But since we are dealing with Bitcoin and it is imperative that the collectively owned Bitcoin should always remain retrievable, we have taken a number of measures to ensure this always remains the case. These measures are in place to ensure a minimal risk of losing access to funds even in a highly dynamic environment.
1. Automatic transfer — Every time a payout from the wallet is created all unspent transaction outputs (UTXOs) that are stored in old addresses are selected as inputs to the new transaction so that the Bitcoin is moved to a change address generated from the current configuration.
2. Redundancy — In Misthos there are two levels of consensus. The consensus required by the application logic before a transaction is broadcast is called the Policy and currently defaults to N of N (eg. 3 of 3 Partners must approve a transaction for it to be broadcast). The Policy is not equal to the configuration of the addresses however. They default to requiring N/2 of N (rounded up eg. 1 of 2, 2 of 3, 2 of 4 etc.). That means that even if (N-1)/2 partners associated with a given address leave a venture the Bitcoin will still be accessible.
3. Dead Man’s Switch — Redundancy doesn’t protect us from all risks. E.g. what if Bitcoin is sent to an old address and more than (N-1)/2 Partners have left the Venture since the address was exposed (eg. 3 out of a formerly 5 person Venture have left)? To handle this situation, as a last resort to keeping the Bitcoin accessible for the group, all addresses eventually become spendable by just 1 key. To enable this we use the Bitcoin Scripting language to implement a smart contract that includes a relative time-lock with a default lockup period of 12672 blocks (approx. 3 Months).
4. Exposing all relevant information — The Wallet Address History exposes a clear overview of all the addresses, including the associated balance, risk-status, custodians, and activity history. This insight gives Partners a quick and easy way to pinpoint vulnerabilities and trains them to properly maintain their Venture funds without needing to be warned at all.
5. Calls to action within the UI — Whenever a situation arises where funds associated with a particular address are at risk of being locked Partners are alerted and prompted to make a payout which will cause the funds to be transferred to an up to date address. Also when removing a Partner would result in funds becoming temporarily or completely inaccessible users are warned and prompted to take action before the Partner leaves the venture.
We consider these features that provide transparency and fallback options as baseline requirements for teams wanting to handle Bitcoin collectively. It would be terrible if Bitcoin were to become inaccessible due to a team member leaving or private keys being lost. Integrating these features was an important prerequisite for our launch on mainnet. We look forward to your feedback.
