Crypto Wallets 2.0, Improving Asset Security and Agility
In 2008, the same year that Satoshi Nakamoto published the famous Bitcoin white paper, a group of cryptography researchers in Denmark implemented the first production deployment of a technique known as Multiparty Computation (MPC). It was not obvious at that time, but MPC would ultimately become the basis for Crypto Wallets 2.0, ushering in an era of increased security for institutional- and consumer-grade wallets, with native support for any digital asset.
Originally, Bitcoin only supported transaction signing using a single approver model with a single private key. It wasn’t long before bad actors began exploiting the vulnerability of this security model. By late 2011, multiple party approval support was added in the form of scripts to natively support multiple signatures (multisig) on Bitcoin.
Multisig was an important enhancement to first generation institutional-grade wallets, but it wasn’t natively supported by most of the expanding array of digital assets and it introduced a number of undesirable attributes such as increased operational complexity, higher transaction fees and more. As a result, multisig adoption was generally limited to exchanges, brokers, custodians and large institutional traders which used it with a smaller number of higher value transactions.
All of that is changing as version 2.0 wallets eliminate the undesirable attributes of multisig, and enable superior, institutional-grade security to be adopted by institutions and individual wallet holders alike.
Threshold Signatures
MPC can be applied to a variety of problems which benefit from eliminating the dependency on a third party to guard secrets. When MPC is applied to protect secrets in the form of the private keys that is used to generate a digital signature, it’s referred to as a Threshold Signature.
Threshold Signatures support multiple party approval models just like multisig, but they are preferred for a variety of reasons such as:
Native support for every digital asset and ledger - no smart contracts or special coding required,
Key share refresh without requiring a transaction or a change of the wallet address,
Smaller transaction sizes for better throughput and lower transaction fees,
Sustained secure operations - even if some of the parties become corrupted,
Greater transaction privacy - eliminating the electronic breadcrumb trail of security updates and approvers,
Practical support for greater than 2 of 3 approver schemes – up to 20 of 20,
Elimination of dependency on hardware security modules (HSMs),
Collectively higher security efficacy than multisig.
Drop-in Replacement For MultiSig
Threshold Signatures can be implemented in ways which allow it to be operationally consistent with multisig. This makes it easier for your teams to adopt a new approach, as their operational practices do not have to change.
For example, multisig supports asynchronous approvals, allowing each party to individually approve a transaction independent of the online status of other approvers. While many MPC computation require all parties to be online concurrently, specific implementations of Threshold Signatures can support asynchronous approvals – just like multisig!
More information on drop-in replacement for multisig is available via this blog post.
Consistent Multiparty Approval For All Digital Assets
One of the challenges with multisig is that many digital assets do not natively support the programing or smart contracts to collect and record multiple signatures. This may require each individual digital asset to develop and implement their own smart contracts to support MultiSig, which can result in material delays in asset support, security vulnerabilities resulting from varying implementation approaches, bugs and more.
In contrast, Threshold Signatures appear on-chain as a single signature, regardless of the number of parties required to approve the transaction. Every ledger and digital asset natively support a single signature model, which generally means they can all support Threshold Signatures without smart contracts or any special developments.
More information on multiparty approval when multisig is not supported is available via this blog post.
Suitable to Institutions and Consumers
Threshold Signatures can support as few as 2 of 2 to as many as 20 of 20 approvers. For practical reasons, most implementations won’t use more approvers than their use case justifies. MPC-based wallets using Threshold Signatures are now available from multiple vendors, supporting use cases for consumers and institutions.
In some implementations, a wallet provider may allow consumers to use their wallets as a service, where the end user is one approver and the service provider is the second approver. The service provider is typically verifying that the transaction and user verifications fall within pre-defined guidelines. Valid transactions can be approved so rapidly that the end user doesn’t even realize that anyone other than themselves is approving the transaction.
In other implementations, the wallet maybe integrated with an institution’s backend infrastructure and business processes to provide rigorous checks and balances to ensure that transactions are only executed when a specified quorum of approvers is satisfied. Regardless of the need, a 2.0 crypto wallet can be spun up with Threshold Signature support as required.
More information
Crypto wallets supporting Threshold Signatures are just one example of MPC in action. You’re invited to visit www.mpcalliance.org to learn more about multiparty computation in general, Crypto Wallets 2.0 and their use of Threshold Signatures. The MPC Alliance is an industry association of MPC developers and practitioners that are collaborating together to accelerate industry awareness and adoption of Multiparty Computation solutions.
Sepior is a co-founder of the MPC Alliance and a provider of MPC security and privacy preserving solutions, including Threshold Signatures for 2.0 Crypto Wallets. Visit www.sepior.com for more information.