, 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