. Bitcoin Apps Net

Bitcoin Cash Offline Wallet . Docs . White-Label DEX . Offline BTC .

Offline ETH . Prices . Buy Crypto . Exchange . Bitcoin Apps

PSBT (BIP 174) - Partially Signed Bitcoin Transactions

Multisig transactions 1 have been a great use case of Bitcoin for the past few years, they require unsigned or partially signed transactions to be passed between multiple parties to “co-sign” them. However, there is currently no unified format for how multiple parties may share these transactions between multiple signers, it depends on the particular implementation for each wallet making it hard to do among parties using different Bitcoin wallets.

A draft BIP (174), which was proposed last year by Andrew Chow, was recently a subject of interest among Bitcoin developers. It aims to create a standard extensible format that different clients can implement making Partially Signed Bitcoin Transactions (PSBT) easier to pass around users to sign and combine their signatures.

Since signing transactions alsow requires signers to have access to the UTXOs being spent, this format also aims to allow offline signers such as hardware and “air-gappd” wallets to sign transactions without needing to access the UTXO set and witout being defrauded. To explain the need for this BIP, we’re going to start with an example of why this is important.

Say I’m Bob, I’d like to pay Alice 5 BTC in exchange for a service, but I don’t trust Alice and we both trust Mark, so we create a 2-of-3 Multisig address with 5 Bitcoins between Alice, Bob and Mark. Now Alice did not provide the service and I would like to get my money back, I’m going to create a PBST and send it to Mark. Mark, being an Escrow, cares about the security of his coins so he signs my PSBT transaction using an offline machine and sends it back to me, I’ll then take my signed transaction and Mark’s signed transaction, combine and serialize them then broadcast them to the network as a valid serialized network transaction that spends the inputs back to my address using 2 different signatures.

Another example would be the scenario where we are doing something like a group purchase, I can make a PSBT with my inputs, pass it around to different parties, each of them will in turn add their inputs and sign the transaction, then I’ll sign the transaction, finalize and serialize it then send it to the network.

Multisig Workflow using PSBTs

Multisig Workflow using PSBTs

The PSBT format consists of key-value pairs |, the keys are most of the time just a one byte hex integer, or a hex integer concatenated with a public key. They consist of “global types”, which apply to both inputs and outputs,“per-input” and “per-output” types. Currently the defined “per-input” and “per-output” types include: Witness Script, Redeem Script and BIP 32 derivation path, with extra types in the “per-input” field like Witness UTXO and Non-Witness UTXO, Sighash Type , Partial Signature, Finalized scriptSig and Finalized scriptWitness.

The transaction format will be as follows:

{0x70736274}|{0xff}|{global key-value map}|{input key-value map}|...|{input key-value map} NameTypeValueDescription Magic Bytesint32_t0x70736274This is a 4 byte integer that is the ASCII for PSBT SeparatorChar0xffThis is always 0xff to fail any serialization attempt from a non-PSBT serializer Global DataKey-value mapVariesKey-value map for all global data InputsArray of key-value mapsVariesThese are the key-value pairs we mentioned earlier OutputsArray of key-value mapsVariesThese are the key-value pairs we mentioned earlier

There has been discussions in the Bitcoin-dev recently against the key-value model, calling for a simpler set model, it’s argued that this can be better in human readability and have more space efficiency as some keys can be dropped, but this most likely won’t be implemented as it is a drastic change from the original BIP proposal. As proposed by the current BIP, there are 4 different roles a party can play during the partial signing scheme, a Creator, Signer, Combiner and Input Finalizer. A new update to the BIP, currently still being discussed, adds an Updater and a Transaction Extractor roles.

The Creator creates an unsigned transaction and places it in a new PSBT, along with creating an empty input field. The Updater accepts a PSBT and adds information to it, they add the UTXO, redeemScripts, witnessScripts and BIP 32 derivation paths if available. The Signer doesn’t add any data sources, instead they create signatures for the transactions they can sign and add them as a “Partial Signature” key-value pair for the input it relates too, the Signer can also compute addresses, values being sent and transaction fees, showing them to the user as a confirmation and a warning.

The Combiner merges one or more PSBTs removing any duplicate key-value pairs, the Combiner does not need to understand how to interpret the script, it just combines them according to the specifications. The Finalizer accepts only one PBST, it determines if the input has enough data to pass validation and if it does it constructs the scriptSig and scriptWitness and gets rid of all data except UTXO and unknown fields in the input key-value map.

The Transaction Extractor accepts a single PSBT and checks if all the inputs have complete scriptSigs and scriptWitnesses, if they do, the Extractor serializes the transactions and outputs a fully valid network transaction. The format is designed to be extended in the future by adding new types for the key-value pairs, making it backward compatible as Signers that don’t identify the new codes will just ignore them. To ensure compatibility it also designed to not be “unserializable” by normal transaction unserializers.

Regarding the encoding of a PSBT, it can either be represented by a Base64 string or a plain binary file with the .psbt file extension. A MIME type name will be added once the BIP has been revised.

This new format can bring a whole new adoption level to Multisig wallets, the BIP is still currently listed as a Draft but we should seeing it promoted to Proposed soon and maybe start seeing implementations pop up once in a while!

BIP 174 draft revision
Proposed changes to BIP174 draft
Bip 174 Proposal discussion
reference implementation

Imagine a situation where users, who could be collaborating remotely in some project and who’ve never met each other before, need to collectively agree to make a group payment. Each member will chip in some BCH and everyone will pay for it together, like a group of friends would settle a restaurant bill.

One way to do it would be for each member to prepare a transaction and then send the TXID to a chosen coordinator, who whould gather the payments from each participant and make sure the overall purchase is settled.

This system implies that there is a central trusted entity – someone who would have the responsibility to collect the money, make the payment and then make sure it went through correctly so he could send everyone a receipt afterwards.

This is a fine strategy to adopt with friends, but for unknown parties who don’t trust each other there is a problem: it is not a decentralized solution. Whenever a middleman, an escrow or any other trusted party is required, the solution is no longer decentralized. You trust someone to get the job done.

PSBT

Enter Partially Signed Bitcoin Transactions (PSBT).

You may be familiar with the concept of a multi-signature, or multisig, system? In this type of system two or more people must sign a transaction in order for it to be valid.

Multisig payments had one limitation, though: the act of signing must be simultaneous. Everyone who agrees with a transaction must sign it at once before it is broadcast to the network.

Now imagine that there was a protocol such that a Bitcoin transaction that required multiple signatures was created but this transaction did not have to be built at once.

One user could sign today, another user could examine the TX and decide whether to sign later on and so forth. All this without a trusted intermediary!

That is what PSBT achieves. BIP 174 was proposed in mid 2017 to address exactly this scenario – and this system is already available in the current Bitcoin Cash Here’s a simple example scenario that illustrates how PSBT works.

To make a group payment, one of the group members creates a PSBT and adds unspent outputs, both his and other’s and the desired target output (who will receive the payment).

Other users whose inputs are included in the PSBT receive the transaction by email or chat. The user analyzes the inputs, outputs and amounts and decides whether it’s correct or not. If there is agreement, the user then adds his signature to the PSBT.

Once every participant has added their signature, the PSBT is complete. It is then compiled into a regular multisig Bitcoin transaction just as if it had been signed simultaneously. The TX is transmitted and mined like any other transaction.

That is how PSBT’s work! Fully decentralized – no single entity needs to be relied on or trusted to coordinate and distribute funds.

Users must only know each others’s Bitcoin addresses. This is a requirement for all Bitcoin payment processing anyway. So the only manual coordination that is needed between users is to know each others’ addresses. For which they can coordinate via email or chat.

References

DEX White-Label Product

PSBT BIP 174 Andrew Chow GitHub.com

Third-Party Library Implementation

PSBT Trustless Txs

PSBT Documentation

Multisig

DEX Automatic MarketMakers


Bitcoin Cash Offline Wallet . Docs . White-Label DEX . Offline BTC .

Offline ETH . Prices . Buy Crypto . Exchange . Bitcoin Apps