The Partially Signed Bitcoin Transaction (PSBT) standard was first formalized in BIP-174, authored by Andrew Chow, and presented the first version spec for PSBTs (known as a PSBTv0). The BIP defines a way to represent a bitcoin transaction in an incomplete state. As stated in the BIP, a primary motivation for this was to simplify and standardize how multiple signers might coordinate signing a multisig transaction. 

In the form of a PSBT, an incomplete transaction can be passed along to different user roles (also carefully defined) to be modified and updated. Eventually when the PSBT lifecycle is complete, it results in a valid, signed bitcoin transaction ready for broadcast. A later spec defined in BIP-370 describes a second version known as a PSBTv2 adding additional features and flexibility within the lifecycle.

PSBTs are most commonly encountered when transferring a transaction to a signing device. Coinkite’s ColdCard exposes its operator directly to PSBTs by requiring them to be copied to an SD card for transfer to the device for signing. Other popular devices—such as Ledger which connects to a computer via USB and software like Sparrow or Caravan—still utilize PSBTs as a method for communicating their unsigned transactions between devices. What is passed to the next operator is a PSBT with one additional signature attached to it. In the case of singlesig wallets, this PSBT is ready for the network transaction to be extracted from it.

While the name only suggests that it is partially signed, or that it might need signatures, the BIPs also define a set of operator roles which are capable of not only signing but also updating the inputs or outputs within the PSBT. This may change the PSBT to require more signatures than it previously had required in the earlier stages. 

The true power of the PSBT is within the interplay between these different roles. The unfinished transaction resource traverses its lifetime “saga” toward becoming a valid bitcoin transaction. Each event performed by the operator roles – operators being users or entities affecting the PSBT – will change how the final transaction will look. For a PSBT to properly traverse this path and ensure proper transaction validation, it’s important that each operator understands the scope of their role.

The PSBT saga

The PSBT specification BIP-174 defines several roles each responsible for different parts of the PSBT lifecycle and permitting only certain operations and modifications to the data. The roles are defined in such a way as to imply an order of operations. Each of these roles may only be performed by specified operators, however, it is possible and common for some operators to fill more than one role. For example, a Signer may not be a Creator, but it might be likely that a Signer is also an Updater which would add some additional information to the PSBT describing what it is signing. Each role has its own set of permissions it should limit itself to. Likewise, each role (except for Creator) should only accept PSBTs in certain states.

Following the PSBT saga from the beginning, the PSBT is created with a template of the transaction. The Creator/Updater may add some details it knows about such as the inputs and outputs that the transaction should have. The PSBT is then passed to a Signer where signatures are added for the inputs that Signer is responsible for. The Combiner collects all PSBTs pertaining to the transaction (there may be several versions each with signatures for different inputs) and attempts to merge them into one PSBT with all signatures. From there, the Input Finalizer validates the PSBT and adds scriptSigs. Finally, the Transaction Extractor creates a valid, network serialized, and fully signed transaction from the PSBT.

It is important to remember that the PSBT saga is asynchronous. At any point in its lifecycle, the PSBT resource may be copied and distributed to multiple operators, or operators may each receive different states of the same PSBT to contribute their own changes on their own time. Operators can even receive completely different PSBTs where they may add their updates or signatures before submitting them to the Combiner role where a merge of all the PSBTs is attempted.

Each operator should understand the limitations and responsibilities of each of the roles. The roles as defined imply an agreement about how the PSBT resource should be handled and what states can be expected as it traverses its saga. This is not dissimilar to how APIs publish versions defining how to expect client interfacing will work. In the same way that a server-client relationship is defined by an API specification, the scope of PSBT operator roles define acceptable and expected states the PSBT might be in when handed from one role to the next. Not strictly following such an agreement may create confusion and breakages as inter-party operators collaborating on transactions decide to deviate from the commonly defined roles.

The potential of PSBTs for complex transaction signing

The nature of the asynchronous coordination of PSBT operations simplifies complex transaction signing. The benefit may not be immediately obvious in the case of a singlesignature transaction where the PSBT is merely an interface by which to transmit transaction data to a signing device, but these benefits become more apparent when coordinating signatures across multiple signers.

Collaborative custody at Unchained uses a 2-of-3 signature scheme where at least two keys must sign the transaction. Unchained provides a PSBT to the Signers where the inputs and outputs of the transaction have been defined to match the user’s request. It is up to the Signers to provide signatures for the UTXOs being used as the inputs for the PSBT. This constructed PSBT is distributed simultaneously to all Signers. It does not matter which order the Signers add their signature, and they need not have the state of the other 2 PSBTs to perform their signing. After adding their signature, each of the PSBTs containing one signature are returned to Unchained which picks up the PSBT saga at the Combiner role. These separately signed PSBTs are combined into a single PSBT which provides the needed quorum of signatures. The signed bitcoin transaction can then be created when Unchained fulfills the Extractor role.

Other complex uses of PSBTs exist, and the specification for PSBTv2 defined in BIP-370 offers even more flexibility through its modification of the operator roles. Although out of scope for this article, there is also the concept of sighash types which define which pieces of a transaction are signed. These can change which parts of a transaction are malleable to even further expand the possibilities of PSBT use-cases. 

A more recent idea for PSBT use case is to simulate a Dutch auction. A Dutch auction can be understood as:

“an auction in which the auctioneer begins with a high asking price in the case of selling, and lowers it until some participant accepts the price, or it reaches a predetermined reserve price.”

https://en.wikipedia.org/wiki/Dutch_auction

In the context of bitcoin, the seller is selling the ability to be part of a transaction which spends a specific UTXO, which is relevant for example in ordinal theory. The seller creates and publishes a PSBT defining an input spending the desirable UTXO and an output which ensures they will receive a certain amount of bitcoin for spending that UTXO. At regular intervals, the seller will broadcast new versions of this PSBT each time with a lower amount on the output paying their own address. The winner of the auction is the first one to pick up the PSBT. They add inputs which satisfy the seller’s output requirements and an output for themselves if they want one to accept any difference minus miner fees to create a new UTXO. The highest bidder successfully wins the ability to be part of a transaction spending someone else’s UTXO. 

Taproot is a feature recently added to the bitcoin consensus rules which allows transactions to encode much more complex locking scripts in a more data efficient manner. The complexity of signing such transactions may be aided by using a PSBT. Through different operator roles, a taproot-based PSBT might present several spending conditions contained within the same taproot tapscript. How the conditions are fulfilled will be determined by the result of the PSBT saga.

Other potential and current limitations

Though the PSBT specification offers a flexible way to arrive at a valid bitcoin transaction through asynchronous and distributed modification of the transaction state by many parties, communicating the PSBT from one operator to another is still a point of friction. The bitcoin network protocol does not support passing PSBTs from node to node, and it makes sense to not overload the bitcoin transaction relay network with remote signing protocols. There is no existing standard by which a PSBT should be passed between operators. Each vendor has its own way of interacting with PSBTs. Unchained’s collaborative custody Vault service focuses on minimizing this friction while providing flexibility and independence through the FOSS Caravan signing tool. Other signing tools are also developing interoperability with each other to facilitate Signers which may be partial to their own methods. These tools usually provide such interoperability through the use of wallet and other configuration files (such as wallet descriptors) to define what types of PSBTs it should construct or act upon.

Besides using independent tools aligned through configuration, there are other methods on the horizon. Nostr is a new protocol for decentralized message relay that has recently gained popularity amongst bitcoiners. While the nostr network is used primarily as a social network, it is capable of relaying any kind of message, even those intended for machines. The design of the protocol ensures that messages are rapidly distributed through different relays as long as the message signature is valid for the broadcasting user key. While bitcoin’s consensus network does not provide the ability for transmission of PSBTs, perhaps nostr could be a useful alternative to transmit, broadcast, and even discover as yet unfinalized bitcoin transaction data.

Saga consensus

The flexibility provided by the PSBT specification has yet to achieve its full potential. As collaborators develop and explore their operator roles, new use-cases may be discovered. As part of its FOSS offerings, Unchained has published a PSBTv2 helper within its unchained-bitcoin JavaScript library. Though it’s still in its early stages and in need of additional role validation, the provided object class aims to simplify PSBT operations by treating the resource as something which traverses the saga defined by the BIP-370 operator roles. As it is defined at the time of this article, the class performs some of this validation as its objects move from Creator through Signer and prevents certain actions from happening when the PSBT is in an improper state. It even includes a converter for PSBTv0 to PSBTv2 where the new PSBTv2 is taken through the beginning of its saga. Unchained has used this to ensure compatibility with signing devices pushing forward to the new PSBTv2 specification.

As more services begin working with the PSBT saga and associated operator roles, best practices will be learned and adopted around these roles. Understanding the scope of the roles and their associated operator permissions is an important step in communicating the state of a PSBT. While divergence from the prescribed PSBT saga may lead to pitfalls, developing and standardizing conventions will be an important step towards broader adoption and the increased utility of bitcoin transactions.