Security vs. convenience: Designing “Sell bitcoin” on top of multisig cold storage

Bitcoin native financial services that prioritize security are typically perceived as less convenient than platforms like exchanges, where the primary objective is to facilitate quick and frequent transactions. As a leading provider of bitcoin financial services built on the foundation of multisignature cold storage, Unchained strives to offer clients increasingly convenient experiences–without compromising the security of their bitcoin. This idea is most recently demonstrated through the release of a significant trading desk enhancement, which enables clients to sell bitcoin directly from their multisignature vault 24/7.

This article will review the implementation of this enhancement from the perspective of a product manager, outlining the unique challenges faced and trade-offs made when building on the foundation of multisignature vaults. By sharing our experience, we aim to motivate others in the industry to focus on the development of financial services built on top of multisignature cold storage, ensuring that bitcoin investors who prioritize security can access a wide range of financial services without resorting to exchanges. 

How executing sales worked prior to this enhancement

Before the introduction of this enhancement, Unchained clients could facilitate a bitcoin sale by one of two ways: (1) transact in an OTC fashion during normal business hours or (2) transfer bitcoin to an exchange where they would then complete the sale. As one can imagine, neither option was particularly convenient. 

Transacting OTC, while transparent and compliant, was a laborious and manual process reminiscent of calling a stock broker to place a trade in the 1960s. Furthermore, confining clients to trade within allotted business hours posed a particular issue since, unlike stocks, bitcoin is valued 24/7 and should, therefore, be available to trade around the clock.

Transferring bitcoin to an exchange for the purpose of completing a sale was comparatively more efficient, but exposed the user to various unnecessary risks. Bitcoin transactions are immutable; if a user erroneously sends bitcoin to the wrong address, it results in irretrievable loss of funds. Moreover, this method forces the client to engage with an exchange. Albeit the client’s bitcoin remains within the exchange’s ecosystem for a limited time, during that time the bitcoin becomes subject to third-party risk; the exchange could go out of business, halt sales and withdrawals, or the client’s exchange account could be compromised and drained. For these reasons it’s easy to understand why this process was, likewise, suboptimal.

Conversely, the ability to sell bitcoin directly from a multisignature vault provides Unchained clients with an experience that is much more similar to that of an exchange–all while enabling the user to remain in complete control of their bitcoin until the exact moment they execute the trade. This enhancement demonstrates that convenience and security do not have to be mutually exclusive. To achieve this, we had to overcome a variety of unique challenges inherent to developing on the foundation of multisignature cold storage. 

Navigating complexities

Designing a process that allows users to sell bitcoin directly from a multisignature vault was somewhat of a balancing act. The objective was to create a seamless user experience aside from one intentional point of friction: the signing process.  

For those unfamiliar with the mechanics of multisignature cold storage, the storage method’s ingenuity lies in the carefully orchestrated signing process designed to ensure the security and integrity of the stored funds. Multisignature cold storage is most often configured to be accessed by three private keys, each of which is contained within a dedicated hardware wallet that is not connected to the internet. In order to withdraw bitcoin, the transaction must be signed with two of the three corresponding private keys. Upon receiving the second signature, the transaction can then, and only then, be broadcast to the network. 

Designing around the uncompromising signature process

Understanding that the signing process was, of course, non-negotiable forced us to design around this portion of the client experience and work backwards. The sale experience involves a total of six steps:  

1. Enter sale details
2. Select keys 
3. Review transaction 
4. Sign transaction 
5. Execute sale and broadcast transaction 
6. Summary 

To offset the rigidity of the signing process, we needed to make the experience up until that point as simple and flexible as possible. 

The inclusion of the third step, “Review transaction,” illustrates this concept. On this screen the user takes no action other than to review the details of their transaction before clicking “Continue,” to create the transaction and progress to the next screen where they will sign the transaction. While seemingly unnecessary, the purpose of this screen is to provide the user with a final opportunity to amend the details of their trade before the transaction is officially created. Although clients have the ability to cancel their transaction up until the exact point when they broadcast to the network, due to the uncompromising nature of how bitcoin transactions are signed, once a transaction has been created, it cannot be edited. Clients are made aware of this restriction via text positioned directly above the “Continue” button.

Mitigating unique technical risks

Aside from creating a desirable client experience, mitigating technical risks was also challenging. The most perplexing technical challenge we experienced surrounds the mining fee rate–which is calculated and assigned to the transaction at its inception. For those unfamiliar with the concept of a mining fee rate, it’s important to first understand the relationship between mining fees, mempools and bitcoin mining.

Mining fees, mempools and bitcoin mining

When a bitcoin transaction is broadcast to the network, before it’s confirmed on the blockchain and becomes immutable, it’s initially directed to a pool of unconfirmed transactions, called a mempool. Miners, whose primary goal is to be the first to find the next valid hash and earn the privilege of adding the next block to the chain, will pull transactions from a mempool to include in the next block. However, transactions are not pulled from a mempool on a first come first serve basis. Since bitcoin’s network intentionally limits the number of transactions that can be stored within a block, the order is, instead, determined by one of the most fundamental economic principles: supply and demand.

Attached to each unconfirmed transaction is an incentive set by the transaction author, called a mining fee. The mining fee is designed to motivate miners to prioritize that specific transaction. Mining fees are denominated in bitcoin and calculated using a mining fee rate, expressed in satoshis per byte (ex: 21 sats/vB). Miners set their own fee rates and communicate these rates to transaction-authoring software through APIs (Application Programming Interfaces).

During periods of high network traffic, when the mempool is congested with competing unconfirmed transactions, miners respond by increasing their fee rates. When the mempool API is called by a transaction-authoring software, the miner will provide a range of fee rates that align with varying degrees of prioritization at that particular time. Depending on how quickly the author of the transaction needs their transaction to be plucked from the mempool and confirmed, they may choose to offer a fee that corresponds to low, medium or high priority. 

However, if you offer a low priority fee during periods of high network traffic, you run the risk of the transaction getting “stuck” in the mempool. Furthermore, some mempools implement a time-based expiration for transactions; if fee rates remain high for an extended period of time, the transaction may ultimately be purged from the mempool. Although this is considered an “edgecase,” it does happen. 

If a client’s sale transaction is removed from a mempool and Unchained doesn’t receive the client’s bitcoin, aside from the inconvenience a failed trade may cause the client, the client would also be considered in default and might face potential damages. To mitigate this risk, whenever a client authors a sale transaction through Unchained, our system always assigns a mining fee that corresponds to high priority in the given fee rate climate.

However, this process is further complicated by the fact that the mining fee rate is fixed to the transaction at its inception, instead of upon entering the mempool. Due to the uncompromising signing process inherent to transactions originating from multisignature cold storage, depending on the duration of time between transaction authoring and execution, what was previously considered a high priority mining fee may instead translate to low priority when the transaction enters the mempool. 

To solve for this scenario, we assessed a few transaction acceleration techniques: replace-by-fee and child-pays-for-parent. To understand why we ultimately chose one technique over the other, it’s crucial to first establish a basic understanding of how unspent transaction outputs (UTXOs) contribute to transactions on bitcoin’s network.

The bitcoin network’s UTXO-based transaction model

Unlike the U.S. monetary system, bitcoin’s ledger does not rely on an account-based model. This means there are no accounts designed to store value that are debited or credited each time the owner of the account transacts. Instead, bitcoin’s ledger is based on a UTXO model, which denotes that every transaction has an input and an output. 

Whenever a user authors a transaction, because they can only spend bitcoin in their possession, the input of a transaction consists of one or more UTXOs generated from prior transactions. The output of a transaction represents a consolidated UTXO that has essentially consumed the UTXOs that were “spent” by the sender when they served as the input of the transaction. 

However, until a transaction is plucked from a mempool and confirmed on the blockchain, the UTXOs serving as the input of the transaction are still considered “unspent” by the rest of the network. The UTXO model is the mechanism through which bitcoin’s network effectively prevents users from double-spending their bitcoin. 

Replace-by-fee (RBF) and child-pays-for-parent (CPFP) are both techniques that allow a user to manipulate UTXOs and manage fees when the UTXOs that constitute a transaction are still viewed as unspent by the network. While there are pros and cons associated with both RBF and CPFP, we ultimately chose to utilize the technique that delivered the best client experience.

Manipulating UTXOs: RBF & CPFP

With RBF, the objective is to replace the unconfirmed transaction languishing in the mempool with a new transaction that carries a higher fee and, therefore, assumes priority over the first transaction. This can be accomplished when the sender of a transaction authors a second transaction using the same UTXOs as the first transaction, but attaches a higher fee. Given that miners consistently prioritize transactions with higher fees, the second transaction will take precedence over the first. Once the second transaction is successfully confirmed, miners, vigilant against the double-spending of UTXOs, recognize that the first transaction is now invalid and purge the transaction from the mempool.

With CPFP, the goal is not to replace the unconfirmed transaction, but rather to incentivize the miner to process a set of related transactions. This is accomplished when the intended receiver of a transaction authors a second transaction with a higher fee which consumes what will be the output UTXO of the first, unconfirmed transaction. Being that the second transaction relies on the first and cannot be confirmed unless the first is also confirmed, miners are incentivized to include both transactions in the same block. 

In the instance of a client’s sale transaction, since Unchained assumes the role of receiver, CPFP is the only viable option between the two. By enabling the use of CPFP for sale transactions, we can broadcast a subsequent transaction to ourselves to pay for the first transaction whenever necessary. 

Conclusion

The complexities of designing and developing a trading desk built on the foundation of multisignature cold storage consistently present our team with unique challenges. Nevertheless, time and time again we identify solutions and overcome these challenges to incrementally improve upon our products and deliver value to our clients. We hope to see others in the industry leverage the insights gained from our experience to continue to build on bitcoin and bridge the gap between the traditional financial sector and a bitcoin standard.

Our most recent enhancement, which allows clients to remain in control of their bitcoin until the exact moment they execute the sale and broadcast their transaction to the network, makes Unchained’s trading desk the most secure option on the market. The implementation of this feature demonstrates our unwavering commitment to offering clients increasingly convenient experiences without ever jeopardizing the safety of their assets. 

If you’re interested in building features like this, come work with us!