{"number":78,"title":"A Simple Payjoin Proposal","authors":["Nicolas Dorier"],"status":"Deployed","type":"Specification","layer":"Applications","created":"2019-05-01","license":"BSD-2-Clause","requires":[],"replaces":[79],"replacedBy":[],"discussion":[],"abstract":"This document proposes a protocol for two parties to negotiate a coinjoin transaction during a payment between them.","eli5":"Defines Payjoin, a way for the payer and the recipient to both contribute coins to a single payment transaction. Because the result looks like an ordinary payment but breaks common assumptions used by blockchain surveillance, it improves privacy for both parties and for Bitcoin users in general.","categories":["transactions"],"filename":"bip-0078.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki","format":"mediawiki","readingMinutes":22,"inbound":1,"revisions":46,"impact":79,"core":false,"references":[21,79],"lastModified":"2026-05-20","html":"<h2 id=\"introduction\">Introduction</h2>\n<h3 id=\"abstract\">Abstract</h3>\n<p>This document proposes a protocol for two parties to negotiate a coinjoin transaction during a payment between them.</p>\n<h3 id=\"copyright\">Copyright</h3>\n<p>This BIP is licensed under the 2-clause BSD license.</p>\n<h3 id=\"motivation\">Motivation</h3>\n<p>When two parties (later referred to as sender and receiver) want to transact, most of the time, the sender creates a transaction spending their own Unspent Transaction Outputs (UTXOs), signs it and broadcasts it on the network.</p>\n<p>This simple model gave birth to several heuristics impacting the privacy of the parties and of the network as a whole.</p>\n<ul><li>\nCommon input ownership heuristic: In most transactions, all the inputs belong to the same party.\n</li></ul>\n<ul><li>\nChange identification from scriptPubKey type: If all inputs are spending UTXOs of a certain scriptPubKey type, then the change output is likely to have the same scriptPubKey type, too.\n</li></ul>\n<ul><li>\nChange identification from round amount: If an output in the transaction has a round amount, it is likely an output belonging to the receiver.\n</li></ul>\n<p>We will designate these three heuristics as <code>common-input</code>, <code>change-scriptpubkey</code>, <code>change-round-amount</code>.</p>\n<p>The problems we aim to solve are:</p>\n<ul><li>\nFor the receiver, there is a missed opportunity to consolidate their own UTXOs or making payment in the sender's transaction.\n</li></ul>\n<ul><li>\nFor the sender, there are privacy leaks regarding their wallet that happen when someone applies the heuristics detailed above to their transaction.\n</li></ul>\n<p>Our proposal gives an opportunity for the receiver to consolidate their UTXOs while also batching their own payments, without creating a new transaction. (Saving fees in the process) For the sender, it allows them to invalidate the three heuristics above. With the receiver's involvement, the heuristics can even be poisoned. (ie, using the heuristics to intentionally mislead blockchain analysis)</p>\n<p>Note that the existence of this proposal is also improving the privacy of parties who are not using it by making the three heuristics unreliable to the network as a whole.</p>\n<h3 id=\"relation-to-bip79-bustapay\">Relation to BIP79 (Bustapay)</h3>\n<p>Another implementation proposal has been written: <a href=\"https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki\">BIP79 Bustapay</a>.</p>\n<p>We decided to deviate from it for several reasons:</p>\n<ul><li>\nIt was not using PSBT, so if the receiver wanted to bump the fee, they would need the full UTXO set.\n</li></ul>\n<ul><li>\nInability to change the payment output to match scriptPubKey type.\n</li></ul>\n<ul><li>\nLack of basic versioning negotiation if the protocol evolves.\n</li></ul>\n<ul><li>\nNo standardization of error condition for proper feedback to the sender.\n</li></ul>\n<p>Other than that, our proposal is very similar.</p>\n<h2 id=\"specification\">Specification</h2>\n<h3 id=\"protocol\">Protocol</h3>\n<p>In a payjoin payment, the following steps happen:</p>\n<ul><li>\nThe receiver of the payment, presents a <a href=\"/bip/21\">BIP 21 URI</a> to the sender with a parameter <code>pj=</code> describing a payjoin endpoint.\n</li></ul>\n<ul><li>\nThe sender creates a signed, finalized PSBT with witness UTXO or previous transactions of the inputs. We call this PSBT the <code>original</code>.\n</li></ul>\n<ul><li>\nThe receiver replies back with a signed PSBT containing his own signed inputs/outputs and those of the sender. We call this PSBT <code>Payjoin proposal</code>.\n</li></ul>\n<ul><li>\nThe sender verifies the proposal, re-signs his inputs and broadcasts the transaction to the Bitcoin network. We call this transaction <code>Payjoin transaction</code>.\n</li></ul>\n<pre><code>+----------+                        +--------+         +-----------------+\n| Receiver |                        | Sender |         | Bitcoin Network |\n+----+-----+                        +---+----+         +-------+---------+\n     |       +-----------------+        |                      |\n     +-------+ BIP21 with ?pj= +-------&gt;+                      |\n     |       +-----------------+        |                      |\n     |                                  |                      |\n     |        +---------------+         |                      |\n     +&lt;-------+ Original PSBT +---------+                      |\n     |        +---------------+         |                      |\n     |                                  |                      |\n     |       +------------------+       |                      |\n     |       | Payjoin Proposal |       |                      |\n     +-------+      PSBT        +------&gt;+                      |\n     |       +------------------+       |                      |\n     |                                  |   +--------------+   |\n     |                                  |---+ Payjoin      |   |\n     |                                  |   | transaction  +--&gt;+\n     |                                  |   +--------------+   |\n     +                                  +                      +</code></pre>\n<p>The original PSBT is sent in the HTTP POST request body, base64 serialized, with <code>text/plain</code> in the <code>Content-Type</code> HTTP header and <code>Content-Length</code> set correctly. The payjoin proposal PSBT is sent in the HTTP response body, base64 serialized with HTTP code 200.</p>\n<p>To ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header <code>Access-Control-Allow-Origin: *</code>.</p>\n<p>The sender must ensure that the URL refers to a scheme or protocol using authenticated encryption, for example TLS with certificate validation, or a .onion link to a hidden service whose public key identifier has already been communicated via a TLS connection. Senders SHOULD NOT accept a URL representing an unencrypted or unauthenticated connection.</p>\n<p>The original PSBT MUST:</p>\n<ul><li>\nHave all the <code>witnessUTXO</code> or <code>nonWitnessUTXO</code> information filled in.\n</li></ul>\n<ul><li>\nBe finalized.\n</li></ul>\n<ul><li>\nNot include fields unneeded for the receiver such as global xpubs or keypath information.\n</li></ul>\n<ul><li>\nBe broadcastable.\n</li></ul>\n<p>The original PSBT MAY:</p>\n<ul><li>\nHave outputs unrelated to the payment for batching purpose.\n</li></ul>\n<p>The original PSBT SHOULD NOT:</p>\n<ul><li>\nInclude mixed input types until September 2024. Mixed inputs were previously completely disallowed so this gives some grace period for receivers to update.\n</li></ul>\n<p>The payjoin proposal MUST:</p>\n<ul><li>\nUse all the inputs from the original PSBT.\n</li></ul>\n<ul><li>\nUse all the outputs which do not belong to the receiver from the original PSBT.\n</li></ul>\n<ul><li>\nOnly finalize the inputs added by the receiver. (Referred later as <code>additional inputs</code>)\n</li></ul>\n<ul><li>\nOnly fill the <code>witnessUTXO</code> or <code>nonWitnessUTXO</code> for the additional inputs.\n</li></ul>\n<p>The payjoin proposal MAY:</p>\n<ul><li>\nAdd, or replace the outputs belonging to the receiver unless output substitution is disabled.\n</li></ul>\n<p>The payjoin proposal SHOULD NOT:</p>\n<ul><li>\nInclude mixed input types until September 2024. Mixed inputs were previously completely disallowed so this gives some grace period for senders to update.\n</li></ul>\n<p>The payjoin proposal MUST NOT:</p>\n<ul><li>\nShuffle the order of inputs or outputs, the additional outputs or additional inputs must be inserted at a random index.\n</li></ul>\n<ul><li>\nDecrease the absolute fee of the original transaction.\n</li></ul>\n<h3 id=\"bip21-payjoin-parameters\">BIP21 payjoin parameters</h3>\n<p>This proposal is defining the following new <a href=\"/bip/21\">BIP 21 URI</a> parameters:</p>\n<ul><li>\n<code>pj=</code>: Represents an http(s) endpoint which the sender can POST the original PSBT.\n</li></ul>\n<ul><li>\n<code>pjos=0</code>: Signal to the sender that they MUST disallow <a href=\"#output-substitution\">payment output substitution</a>. (See <a href=\"#unsecured-payjoin\">Unsecured payjoin server</a>)\n</li></ul>\n<p>Note: the <code>amount</code> parameter is *not* required.</p>\n<h3 id=\"optional-parameters\"><span id=\"optional-params\"></span>Optional parameters</h3>\n<p>When the payjoin sender posts the original PSBT to the receiver, he can optionally specify the following HTTP query string parameters:</p>\n<ul><li>\n<code>v=</code>, the version number of the payjoin protocol that the sender is using. The current version is <code>1</code>.\n</li></ul>\n<p>This can be used in the future so the receiver can reject a payjoin if the sender is using a version which is not supported via an error HTTP 400, <code>version-unsupported</code>. If not specified, the receiver will assume the sender is <code>v=1</code>.</p>\n<p>If the receiver does not support the version of the sender, they should send an error with the list of supported versions:</p>\n<pre><code>{\n    \"errorCode\": \"version-unsupported\",\n    \"supported\" : [ 2, 3, 4 ],\n    \"message\": \"The version is not supported anymore\"\n}</code></pre>\n<ul><li>\n<code>additionalfeeoutputindex=</code>, if the sender is willing to pay for increased fee, this indicate output can have its value subtracted to pay for it.\n</li></ul>\n<p>If the <code>additionalfeeoutputindex</code> is out of bounds or pointing to the payment output meant for the receiver, the receiver should ignore the parameter. See <a href=\"#fee-output\">fee output</a> for more information.</p>\n<ul><li>\n<code>maxadditionalfeecontribution=</code>, if the sender is willing to pay for increased fee, an integer defining the maximum amount in satoshis that the sender is willing to contribute towards fees for the additional inputs. <code>maxadditionalfeecontribution</code> must be ignored if set to less than zero.  See <a href=\"#fee-output\">fee output</a> for more information.\n</li></ul>\n<p>Note that both <code>maxadditionalfeecontribution=</code> and <code>additionalfeeoutputindex=</code> must be specified and valid for the receiver to be allowed to decrease an output belonging to the sender. This fee contribution can't be used to pay for anything else than additional input's weight.</p>\n<ul><li>\n<code>minfeerate=</code>, a decimal in satoshi per vbyte that the sender can use to constraint the receiver to not drop the minimum fee rate too much.\n</li></ul>\n<ul><li>\n<code>disableoutputsubstitution=</code>, a boolean indicating if the sender forbids the receiver to substitute the receiver's output, see <a href=\"#output-substitution\">payment output substitution</a>. (default to <code>false</code>)\n</li></ul>\n<h3 id=\"receiver-s-well-known-errors\">Receiver's well known errors</h3>\n<p>If for some reason the receiver is unable to create a payjoin proposal, it will reply with a HTTP code different than 200. The receiver is not constrained to specific set of errors, some are specified in this proposal.</p>\n<p>The errors have the following format:</p>\n<pre><code>{\n    \"errorCode\": \"leaking-data\",\n    \"message\": \"Key path information or GlobalXPubs should not be included in the original PSBT.\"\n}</code></pre>\n<p>The well-known error codes are:</p>\n<div class=\"table-wrap\"><table><tbody><tr><th>Error code</th><th>Meaning</th></tr><tr><td>unavailable</td><td>The payjoin endpoint is not available for now.</td></tr><tr><td>not-enough-money</td><td>The receiver added some inputs but could not bump the fee of the payjoin proposal.</td></tr><tr><td>version-unsupported</td><td>This version of payjoin is not supported.</td></tr><tr><td>original-psbt-rejected</td><td>The receiver rejected the original PSBT.</td></tr></tbody></table></div>\n<p>The receiver is allowed to return implementation-specific errors which may assist the sender to diagnose any issue.</p>\n<p>However, it is important that error codes that are not well-known and that the message do not appear on the sender's software user interface. Such error codes or messages could be used maliciously to phish a non-technical user. Instead those errors or messages can only appear in debug logs.</p>\n<p>It is advised to hard code the description of the well known error codes into the sender's software.</p>\n<h3 id=\"fee-output\"><span id=\"fee-output\"></span>Fee output</h3>\n<p>In some situation, the sender might want to pay some additional fee in the payjoin proposal. If such is the case, the sender must use both <a href=\"#optional-params\">optional parameters</a> <code>additionalfeeoutputindex=</code> and <code>maxadditionalfeecontribution=</code> to indicate which output and how much the receiver can subtract fee.</p>\n<p>There are several cases where a fee output is useful:</p>\n<ul><li>\nThe sender's original transaction's fee rate is at the minimum accepted by the network, aka <code>minimum relay transaction fee rate</code>, which is typically 1 satoshi per vbyte.\n</li></ul>\n<p>In such case, the receiver will need to increase the fee of the transaction after adding his own inputs to not drop below the minimum relay transaction fee rate.</p>\n<ul><li>\nThe sender's wallet software is using round fee rate.\n</li></ul>\n<p>If the sender's fee rate is always round, then a blockchain analyst can easily spot the transactions of the sender involving payjoin by checking if, when removing a single input to the suspected payjoin transaction, the resulting fee rate is round. To prevent this, the sender can agree to pay more fee so the receiver make sure that the payjoin transaction fee is also round.</p>\n<ul><li>\nThe sender's transaction is time sensitive.\n</li></ul>\n<p>When a sender picks a specific fee rate, the sender expects the transaction to be confirmed after a specific amount of time. But if the receiver adds an input without bumping the fee of the transaction, the payjoin transaction fee rate will be lower, and thus, longer to confirm.</p>\n<p>Our recommendation for <code>maxadditionalfeecontribution=</code> is <code>originalPSBTFeeRate * 110</code>.</p>\n<h3 id=\"receiver-s-original-psbt-checklist\">Receiver's original PSBT checklist</h3>\n<p>The receiver needs to do some check on the original PSBT before proceeding:</p>\n<ul><li>\nNon-interactive receivers (like a payment processor) need to check that the original PSBT is broadcastable. <code>*</code>\n</li></ul>\n<ul><li>\nIf the sender included inputs in the original PSBT owned by the receiver, the receiver must either return error <code>original-psbt-rejected</code> or make sure they do not sign those inputs in the payjoin proposal.\n</li></ul>\n<ul><li>\nMake sure that the inputs included in the original transaction have never been seen before.\n<ul><li>\nThis prevents <a href=\"#probing-attack\">probing attacks</a>.\n</li></ul>\n<ul><li>\nThis prevents reentrant payjoin, where a sender attempts to use payjoin transaction as a new original transaction for a new payjoin.\n</li></ul>\n</li></ul>\n<p><code>*</code>: Interactive receivers are not required to validate the original PSBT because they are not exposed to <a href=\"#probing-attack\">probing attacks</a>.</p>\n<h3 id=\"sender-s-payjoin-proposal-checklist\">Sender's payjoin proposal checklist</h3>\n<p>The sender should check the payjoin proposal before signing it to prevent a malicious receiver from stealing money.</p>\n<ul><li>\nVerify that the absolute fee of the payjoin proposal is equals or higher than the original PSBT.\n</li></ul>\n<ul><li>\nIf the receiver's BIP21 signalled <code>pjos=0</code>, disable payment output substitution.\n</li></ul>\n<ul><li>\nVerify that the transaction version, and the nLockTime are unchanged.\n</li></ul>\n<ul><li>\nCheck that the sender's inputs' sequence numbers are unchanged.\n</li></ul>\n<ul><li>\nFor each input in the proposal:\n<ul><li>\nVerify that no keypaths are in the PSBT input\n</li></ul>\n<ul><li>\nVerify that no partial signature has been filled\n</li></ul>\n<ul><li>\nIf it is one of the sender's inputs:\n<ul><li>\nVerify that input's sequence is unchanged.\n</li></ul>\n<ul><li>\nVerify the PSBT input is not finalized\n</li></ul>\n</li><li>\nIf it is one of the receiver's inputs:\n<ul><li>\nVerify the PSBT input is finalized\n</li></ul>\n<ul><li>\nVerify that <code>non_witness_utxo</code> or <code>witness_utxo</code> are filled in.\n</li></ul>\n</li><li>\nVerify that the payjoin proposal inputs all specify the same sequence value.\n</li></ul>\n<ul><li>\nVerify that all of sender's inputs from the original PSBT are in the proposal.\n</li></ul>\n</li><li>\nFor each output in the proposal:\n<ul><li>\nVerify that no keypaths are in the PSBT output\n</li></ul>\n<ul><li>\nIf the output is the <a href=\"#fee-output\">fee output</a>:\n<ul><li>\nThe amount that was subtracted from the output's value is less than or equal to <code>maxadditionalfeecontribution</code>. Let's call this amount <code>actual contribution</code>.\n</li></ul>\n<ul><li>\nMake sure the actual contribution is only going towards fees: The <code>actual contribution</code> is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT.\n</li></ul>\n<ul><li>\nMake sure the actual contribution is only paying for fees incurred by additional inputs: <code>actual contribution</code> is less than or equal to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))</code>. (see <a href=\"#fee-output\">Fee output</a> section)\n</li></ul>\n</li><li>\nIf the output is the payment output and payment output substitution is allowed,\n<ul><li>\nDo not make any check\n</li></ul>\n</li><li>\nElse\n<ul><li>\nMake sure the output's value did not decrease.\n</li></ul>\n</li><li>\nVerify that all sender's outputs (ie, all outputs except the output actually paid to the receiver) from the original PSBT are in the proposal.\n</li></ul>\n</li><li>\nOnce the proposal is signed, if <code>minfeerate</code> was specified, check that the fee rate of the payjoin transaction is not less than this value.\n</li></ul>\n<p>The sender must be careful to only sign the inputs that were present in the original PSBT and nothing else.</p>\n<p>Note:</p>\n<ul><li>\nThe sender must allow the receiver to add/remove or modify the receiver's own outputs. (if payment output substitution is disabled, the receiver's outputs must not be removed or decreased in value)\n</li></ul>\n<ul><li>\nThe sender should allow the receiver to not add any inputs. This is useful for the receiver to change the payment output scriptPubKey type.\n</li></ul>\n<ul><li>\nIf the receiver added no inputs, the sender's wallet implementation should accept the payjoin proposal, but not mark the transaction as an actual payjoin in the user interface.\n</li></ul>\n<p>Our method of checking the fee allows the receiver and the sender to batch payments in the payjoin transaction. It also allows the receiver to pay the fee for batching adding his own outputs.</p>\n<h2 id=\"rationale\">Rationale</h2>\n<p>There are several consequences of our proposal:</p>\n<ul><li>\nThe receiver can bump the fee of the original transaction.\n</li></ul>\n<ul><li>\nThe receiver can modify the outputs of the original PSBT.\n</li></ul>\n<ul><li>\nThe sender must provide the UTXO information (Witness or previous transaction) in the PSBT.\n</li></ul>\n<h3 id=\"respecting-the-minimum-relay-fee-policy\">Respecting the minimum relay fee policy</h3>\n<p>To be properly relayed, a Bitcoin transaction needs to pay at least 1 satoshi per virtual byte. When blocks are not full, the original transaction might already at the minimum relay fee rate (currently 1 satoshi per virtual byte), so if the receiver adds their own input, they need to make sure the fee is increased such that the rate does not drop below the minimum relay fee rate. In such case, the sender must set both <code>maxadditionalfeecontribution=</code> and <code>additionalfeeoutputindex=</code>.</p>\n<p>See the <a href=\"#fee-output\">Fee output</a> section for more information.</p>\n<p>We also recommend the sender to set <code>minfeerate=</code>, as the sender's node policy might be different from the receiver's policy.</p>\n<h3 id=\"defeating-heuristics-based-on-the-fee-calculation\">Defeating heuristics based on the fee calculation</h3>\n<p>Most wallets are creating a round fee rate (like 2 sat/b). If the payjoin transaction's fee was not increased by the added size, then those payjoin transactions could easily be identifiable on the blockchain.</p>\n<p>Not only would those transactions stand out by not having a round fee (like 1.87 sat/b), but any suspicion of payjoin could be confirmed by checking if removing one input would create a round fee rate. In such case, the sender must set both <code>maxadditionalfeecontribution=</code> and <code>additionalfeeoutputindex=</code>.</p>\n<p>The recommended value <code>maxadditionalfeecontribution=</code> is explained in the <a href=\"#fee-output\">Fee output</a> section. We also recommend the sender to set <code>minfeerate=</code>, as the sender's node policy might be different from the receiver's policy.</p>\n<h3 id=\"receiver-does-not-need-to-be-a-full-node\">Receiver does not need to be a full node</h3>\n<p>Because the receiver needs to bump the fee to keep the same fee rate as the original PSBT, it needs the input's UTXO information to know what is the original fee rate. Without PSBT, light wallets like Wasabi Wallet would not be able to receive a payjoin transaction.</p>\n<p>The validation (policy and consensus) of the original transaction is optional: a receiver without a full node can decide to create the payjoin transaction and automatically broadcast the original transaction after a timeout of 1 minute, and only verify that it has been propagated in the network.</p>\n<p>However, non-interactive receivers (like a payment processor) need to verify the transaction to prevent UTXO probing attacks.</p>\n<p>This is not a concern for interactive receivers like Wasabi Wallet, because those receivers can just limit the number of original PSBT proposals of a specific address to one. With such wallets, the attacker has no way to generate new deposit addresses to probe the UTXOs.</p>\n<h3 id=\"spare-change-donation\"><span id=\"spare-change\"></span>Spare change donation</h3>\n<p>Small change inside wallets are detrimental to privacy. Mixers like Wasabi wallet, because of its protocol, eventually generate such <a href=\"https://docs.wasabiwallet.io/using-wasabi/ChangeCoins.html#first-round-coinjoin-change\">small change</a>.</p>\n<p>A common way to protect your privacy is to donate those spare changes, to deposit them in an exchange or on your favorite merchant's store account. Those kind of transactions can easily be spotted on the blockchain: There is only one output.</p>\n<p>However, if you donate via payjoin, it will look like a normal transaction.</p>\n<p>On top of this the receiver can poison analysis by randomly faking a round amount of satoshi for the additional output.</p>\n<h3 id=\"payment-output-substitution\"><span id=\"output-substitution\"></span>Payment output substitution</h3>\n<p>Unless disallowed by the sender explicitly via <code>disableoutputsubstitution=true</code> or by the BIP21 URL via the query parameter <code>pjos=0</code>, the receiver is free to decrease the amount or change the scriptPubKey output paying to himself. Note that if payment output substitution is disallowed, the receiver can still increase the amount of the output. (See <a href=\"#reference-impl\">the reference implementation</a>)</p>\n<p>For example, if the sender's scriptPubKey type is P2WPKH while the receiver's payment output in the original PSBT is P2SH, then the receiver can substitute the payment output to be P2WPKH to match the sender's scriptPubKey type.</p>\n<h3 id=\"unsecured-payjoin-server\"><span id=\"unsecured-payjoin\"></span>Unsecured payjoin server</h3>\n<p>A receiver might run the payment server (generating the BIP21 invoice) on a different server than the payjoin server, which could be less trusted than the payment server.</p>\n<p>In such case, the payment server can signal to the sender, via the BIP21 parameter <code>pjos=0</code>, that they MUST disallow <a href=\"#output-substitution\">payment output substitution</a>. A compromised payjoin server could steal the hot wallet outputs of the receiver, but would not be able to re-route payment to himself.</p>\n<h3 id=\"impacted-heuristics\">Impacted heuristics</h3>\n<p>Our proposal of payjoin breaks the following blockchain heuristics:</p>\n<ul><li>\nCommon inputs heuristics.\n</li></ul>\n<p>Because payjoin is mixing the inputs of the sender and receiver, this heuristic becomes unreliable.</p>\n<ul><li>\nChange identification from scriptPubKey type heuristics\n</li></ul>\n<p>When Alice pays Bob, if Alice is using P2SH but Bob's deposit address is P2WPKH, the heuristic would assume that the P2SH output is the change address of Alice. This is now however a broken assumption, as the payjoin receiver has the freedom to mislead analytics by purposefully changing the invoice's address in the payjoin transaction.</p>\n<p>See <a href=\"#output-substitution\">payment output substitution</a>.</p>\n<ul><li>\nChange identification from round change amount\n</li></ul>\n<p>If Alice pays Bob, she might be tempted to pay him a round amount, like <code>1.23000000 BTC</code>. When this happens, blockchain analysis often identifies the output without the round amount as the change of the transaction.</p>\n<p>For this reason, during a <a href=\"#spare-change\">spare change</a> case, the receiver may add an output with a rounded amount randomly.</p>\n<h2 id=\"attack-vectors\">Attack vectors</h2>\n<h3 id=\"on-the-receiver-side-utxo-probing-attack\"><span id=\"probing-attack\"></span>On the receiver side: UTXO probing attack</h3>\n<p>When the receiver creates a payjoin proposal, they expose one or more inputs belonging to them.</p>\n<p>An attacker could create multiple original transactions in order to learn the UTXOs of the receiver, while not broadcasting the payjoin proposal.</p>\n<p>While we cannot prevent this type of attack entirely, we implemented the following mitigations:</p>\n<ul><li>\nWhen the receiver detects an original transaction being broadcast, or if the receiver detects that the original transaction has been double spent, then they will reuse the UTXO that was exposed for the next payjoin.\n</li></ul>\n<ul><li>\nWhile the exposed UTXO will be reused in priority to not leak other UTXOs, there is no strong guarantee about it. This prevents the attacker from detecting with certainty the next payjoin of the merchant to another peer.\n</li></ul>\n<p>Note that probing attacks are only a problem for automated payment systems such as BTCPay Server. End-user wallets with payjoin capabilities are not affected, as the attacker can't create multiple invoices to force the receiver to expose their UTXOs.</p>\n<h3 id=\"on-the-sender-side-double-payment-risk-for-hardware-wallets\">On the sender side: Double payment risk for hardware wallets</h3>\n<p>For a successful payjoin to happen, the sender needs to sign two transactions double spending each other: The original transaction and the payjoin proposal.</p>\n<p>The sender's software wallet can verify that the payjoin proposal is legitimate by the sender's checklist.</p>\n<p>However, a hardware wallet can't verify that this is indeed the case. This means that the security guarantee of the hardware wallet is decreased. If the sender's software is compromised, the hardware wallet would sign two valid transactions, thus sending two payments.</p>\n<p>Without payjoin, the maximum amount of money that could be lost by a compromised software is equal to one payment (via <a href=\"#output-substitution\">payment output substitution</a>). Note that the sender can disallow <a href=\"#output-substitution\">payment output substitution</a> by using the optional parameter <code>disableoutputsubstitution=true</code>.</p>\n<p>With payjoin, the maximum amount of money that can be lost is equal to two payments.</p>\n<h2 id=\"reference-sender-s-implementation\"><span id=\"reference-impl\"></span>Reference sender's implementation</h2>\n<p>Here is pseudo code of a sender implementation. <code>RequestPayjoin</code> takes the BIP21 URI of the payment, the wallet and the <code>signedPSBT</code>.</p>\n<p>The <code>signedPSBT</code> represents a PSBT which has been fully signed, but not yet finalized. We then prepare <code>originalPSBT</code> from the <code>signedPSBT</code> via the <code>CreateOriginalPSBT</code> function and get back the <code>proposal</code>.</p>\n<p>While we verify the <code>proposal</code>, we also import into it information about our own inputs and outputs from the <code>signedPSBT</code>. At the end of this <code>RequestPayjoin</code>, the proposal is verified and ready to be signed.</p>\n<p>We logged the different PSBT involved, and show the result in our <a href=\"#test-vectors\">test vectors</a>.</p>\n<pre><code>public async Task&lt;PSBT&gt; RequestPayjoin(\n    BIP21Uri bip21,\n    Wallet wallet,\n    PSBT signedPSBT,\n    PayjoinClientParameters optionalParameters)\n{\n    Log(\"Unfinalized signed PSBT\" + signedPSBT);\n    // Extracting the pj link.\n    var endpoint = bip21.ExtractPayjointEndpoint();\n    if (signedPSBT.IsAllFinalized())\n        throw new InvalidOperationException(\"The original PSBT should not be finalized.\");\n    PSBTOutput feePSBTOutput = null;\n\n    bool allowOutputSubstitution = !optionalParameters.DisableOutputSubstitution;\n    if (bip21.Parameters.Contains(\"pjos\") && bip21.Parameters[\"pjos\"] == \"0\")\n        allowOutputSubstitution = false;\n\n    if (optionalParameters.AdditionalFeeOutputIndex != null && optionalParameters.MaxAdditionalFeeContribution != null)\n        feePSBTOutput = signedPSBT.Outputs[optionalParameters.AdditionalFeeOutputIndex];\n    Script paymentScriptPubKey = bip21.Address == null ? null : bip21.Address.ScriptPubKey;\n    decimal originalFee = signedPSBT.GetFee();\n    PSBT originalPSBT = CreateOriginalPSBT(signedPSBT);\n    Transaction originalGlobalTx = signedPSBT.GetGlobalTransaction();\n    TxOut feeOutput = feePSBTOutput == null ? null : originalGlobalTx.Outputs[feePSBTOutput.Index];\n    var originalInputs = new Queue&lt;(TxIn OriginalTxIn, PSBTInput SignedPSBTInput)&gt;();\n    for (int i = 0; i &lt; originalGlobalTx.Inputs.Count; i++)\n    {\n        originalInputs.Enqueue((originalGlobalTx.Inputs[i], signedPSBT.Inputs[i]));\n    }\n    var originalOutputs = new Queue&lt;(TxOut OriginalTxOut, PSBTOutput SignedPSBTOutput)&gt;();\n    for (int i = 0; i &lt; originalGlobalTx.Outputs.Count; i++)\n    {\n      originalOutputs.Enqueue((originalGlobalTx.Outputs[i], signedPSBT.Outputs[i]));\n    }\n    // Add the client side query string parameters\n    endpoint = ApplyOptionalParameters(endpoint, optionalParameters);\n    Log(\"original PSBT\" + originalPSBT);\n    PSBT proposal = await SendOriginalTransaction(endpoint, originalPSBT, cancellationToken);\n    Log(\"payjoin proposal\" + proposal);\n    // Checking that the PSBT of the receiver is clean\n    if (proposal.GlobalXPubs.Any())\n    {\n        throw new PayjoinSenderException(\"GlobalXPubs should not be included in the receiver's PSBT\");\n    }\n    ////////////\n\n    if (proposal.CheckSanity() is List&lt;PSBTError&gt; errors && errors.Count &gt; 0)\n        throw new PayjoinSenderException($\"The proposal PSBT is not sane ({errors[0]})\");\n\n    var proposalGlobalTx = proposal.GetGlobalTransaction();\n    // Verify that the transaction version, and nLockTime are unchanged.\n    if (proposalGlobalTx.Version != originalGlobalTx.Version)\n        throw new PayjoinSenderException($\"The proposal PSBT changed the transaction version\");\n    if (proposalGlobalTx.LockTime != originalGlobalTx.LockTime)\n        throw new PayjoinSenderException($\"The proposal PSBT changed the nLocktime\");\n\n    HashSet&lt;Sequence&gt; sequences = new HashSet&lt;Sequence&gt;();\n    // For each inputs in the proposal:\n    foreach (PSBTInput proposedPSBTInput in proposal.Inputs)\n    {\n        if (proposedPSBTInput.HDKeyPaths.Count != 0)\n            throw new PayjoinSenderException(\"The receiver added keypaths to an input\");\n        if (proposedPSBTInput.PartialSigs.Count != 0)\n            throw new PayjoinSenderException(\"The receiver added partial signatures to an input\");\n        PSBTInput proposedTxIn = proposalGlobalTx.Inputs.FindIndexedInput(proposedPSBTInput.PrevOut).TxIn;\n        bool isOurInput = originalInputs.Count &gt; 0 && originalInputs.Peek().OriginalTxIn.PrevOut == proposedPSBTInput.PrevOut;\n        // If it is one of our input\n        if (isOurInput)\n        {\n            OutPoint inputPrevout = ourPrevouts.Dequeue();\n            TxIn originalTxin = originalGlobalTx.Inputs.FromOutpoint(inputPrevout);\n            PSBTInput originalPSBTInput = originalPSBT.Inputs.FromOutpoint(inputPrevout);\n            // Verify that sequence is unchanged.\n            if (input.OriginalTxIn.Sequence != proposedTxIn.Sequence)\n                throw new PayjoinSenderException(\"The proposedTxIn modified the sequence of one of our inputs\")\n            // Verify the PSBT input is not finalized\n            if (proposedPSBTInput.IsFinalized())\n                throw new PayjoinSenderException(\"The receiver finalized one of our inputs\");\n            sequences.Add(proposedTxIn.Sequence);\n\n            // Fill up the info from the original PSBT input so we can sign and get fees.\n            proposedPSBTInput.NonWitnessUtxo = input.SignedPSBTInput.NonWitnessUtxo;\n            proposedPSBTInput.WitnessUtxo = input.SignedPSBTInput.WitnessUtxo;\n            // We fill up information we had on the signed PSBT, so we can sign it.\n            foreach (var hdKey in input.SignedPSBTInput.HDKeyPaths)\n            proposedPSBTInput.HDKeyPaths.Add(hdKey.Key, hdKey.Value);\n            proposedPSBTInput.RedeemScript = signedPSBTInput.RedeemScript;\n            proposedPSBTInput.RedeemScript = input.SignedPSBTInput.RedeemScript;\n        }\n        else\n        {\n            // Verify the PSBT input is finalized\n            if (!proposedPSBTInput.IsFinalized())\n                throw new PayjoinSenderException(\"The receiver did not finalized one of their input\");\n            // Verify that non_witness_utxo or witness_utxo are filled in.\n            if (proposedPSBTInput.NonWitnessUtxo == null && proposedPSBTInput.WitnessUtxo == null)\n                throw new PayjoinSenderException(\"The receiver did not specify non_witness_utxo or witness_utxo for one of their inputs\");\n            sequences.Add(proposedTxIn.Sequence);\n        }\n    }\n\n    // Verify that all of sender's inputs from the original PSBT are in the proposal.\n    if (originalInputs.Count != 0)\n        throw new PayjoinSenderException(\"Some of our inputs are not included in the proposal\");\n\n    // Verify that the payjoin proposal did not introduced mixed inputs' sequence.\n    if (sequences.Count != 1)\n        throw new PayjoinSenderException(\"Mixed sequence detected in the proposal\");\n\n    decimal newFee = proposal.GetFee();\n    decimal additionalFee = newFee - originalFee;\n    if (additionalFee &lt; 0)\n      throw new PayjoinSenderException(\"The receiver decreased absolute fee\");\n    // For each outputs in the proposal:\n    foreach (PSBTOutput proposedPSBTOutput in proposal.Outputs)\n    {\n        // Verify that no keypaths is in the PSBT output\n        if (proposedPSBTOutput.HDKeyPaths.Count != 0)\n            throw new PayjoinSenderException(\"The receiver added keypaths to an output\");\n        if (originalOutputs.Count == 0)\n                continue;\n        var originalOutput = originalOutputs.Peek();\n        bool isOriginalOutput = originalOutput.OriginalTxOut.ScriptPubKey == proposedPSBTOutput.ScriptPubKey;\n        bool substitutedOutput = !isOriginalOutput &&\n                                allowOutputSubstitution &&\n                                originalOutput.OriginalTxOut.ScriptPubKey == paymentScriptPubKey;\n        if (isOriginalOutput || substitutedOutput)\n        {\n            originalOutputs.Dequeue();\n            if (originalOutput.OriginalTxOut == feeOutput)\n            {\n                var actualContribution = feeOutput.Value - proposedPSBTOutput.Value;\n                // The amount that was subtracted from the output's value is less than or equal to maxadditionalfeecontribution\n                if (actualContribution &gt; optionalParameters.MaxAdditionalFeeContribution)\n                    throw new PayjoinSenderException(\"The actual contribution is more than maxadditionalfeecontribution\");\n                // Make sure the actual contribution is only paying fee\n                if (actualContribution &gt; additionalFee)\n                    throw new PayjoinSenderException(\"The actual contribution is not only paying fee\");\n                // Make sure the actual contribution is only paying for fee incurred by additional inputs\n                // This assumes an additional input can be up to 110 bytes.\n                int additionalInputsCount = proposalGlobalTx.Inputs.Count - originalGlobalTx.Inputs.Count;\n                if (actualContribution &gt; originalFeeRate * 110 * additionalInputsCount)\n                    throw new PayjoinSenderException(\"The actual contribution is not only paying for additional inputs\");\n            }\n            else if (allowOutputSubstitution && output.OriginalTxOut.ScriptPubKey == paymentScriptPubKey)\n            {\n                // That's the payment output, the receiver may have changed it.\n            }\n            else\n            {\n                if (originalOutput.OriginalTxOut.Value &gt; proposedPSBTOutput.Value)\n                    throw new PayjoinSenderException(\"The receiver decreased the value of one of the outputs\");\n            }\n            // We fill up information we had on the signed PSBT, so we can sign it.\n            foreach (var hdKey in output.SignedPSBTOutput.HDKeyPaths)\n                proposedPSBTOutput.HDKeyPaths.Add(hdKey.Key, hdKey.Value);\n            proposedPSBTOutput.RedeemScript = output.SignedPSBTOutput.RedeemScript;\n        }\n    }\n    // Verify that all of sender's outputs from the original PSBT are in the proposal.\n    if (originalOutputs.Count != 0)\n    {\n        // The payment output may have been substituted\n        if (!allowOutputSubstitution ||\n            originalOutputs.Count != 1 ||\n            originalOutputs.Dequeue().OriginalTxOut.ScriptPubKey != paymentScriptPubKey)\n            {\n                throw new PayjoinSenderException(\"Some of our outputs are not included in the proposal\");\n            }\n    }\n\n    // After signing this proposal, we should check if minfeerate is respected.\n    Log(\"payjoin proposal filled with sender's information\" + proposal);\n    return proposal;\n}\n\n// Finalize the signedPSBT and remove confidential information\nPSBT CreateOriginalPSBT(PSBT signedPSBT)\n{\n    var original = signedPSBT.Clone();\n    original = original.Finalize();\n    foreach (var input in original.Inputs)\n    {\n        input.HDKeyPaths.Clear();\n        input.PartialSigs.Clear();\n        input.Unknown.Clear();\n    }\n    foreach (var output in original.Outputs)\n    {\n        output.Unknown.Clear();\n        output.HDKeyPaths.Clear();\n    }\n    original.GlobalXPubs.Clear();\n    return original;\n}</code></pre>\n<h2 id=\"test-vectors\"><span id=\"test-vectors\"></span>Test vectors</h2>\n<p>A successful exchange with:</p>\n<div class=\"table-wrap\"><table><tbody><tr><th>InputScriptType</th><th>Original PSBT Fee rate</th><th>maxadditionalfeecontribution</th><th>additionalfeeoutputindex</th></tr><tr><td>P2SH-P2WPKH</td><td>2 sat/vbyte</td><td>0.00000182</td><td>0</td></tr></tbody></table></div>\n<p><code>Unfinalized signed PSBT</code></p>\n<pre><code>cHNidP8BAHMCAAAAAY8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////AtyVuAUAAAAAF6kUHehJ8GnSdBUOOv6ujXLrWmsJRDCHgIQeAAAAAAAXqRR3QJbbz0hnQ8IvQ0fptGn+votneofTAAAAAAEBIKgb1wUAAAAAF6kU3k4ekGHKWRNbA1rV5tR5kEVDVNCHAQQWABTHikVyU1WCjVZYB03VJg1fy2mFMCICAxWawBqg1YdUxLTYt9NJ7R7fzws2K09rVRBnI6KFj4UWRzBEAiB8Q+A6dep+Rz92vhy26lT0AjZn4PRLi8Bf9qoB/CMk0wIgP/Rj2PWZ3gEjUkTlhDRNAQ0gXwTO7t9n+V14pZ6oljUBIgYDFZrAGqDVh1TEtNi300ntHt/PCzYrT2tVEGcjooWPhRYYSFzWUDEAAIABAACAAAAAgAEAAAAAAAAAAAEAFgAURvYaK7pzgo7lhbSl/DeUan2MxRQiAgLKC8FYHmmul/HrXLUcMDCjfuRg/dhEkG8CO26cEC6vfBhIXNZQMQAAgAEAAIAAAACAAQAAAAEAAAAAAA==</code></pre>\n<p><code>Original PSBT</code></p>\n<pre><code>cHNidP8BAHMCAAAAAY8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////AtyVuAUAAAAAF6kUHehJ8GnSdBUOOv6ujXLrWmsJRDCHgIQeAAAAAAAXqRR3QJbbz0hnQ8IvQ0fptGn+votneofTAAAAAAEBIKgb1wUAAAAAF6kU3k4ekGHKWRNbA1rV5tR5kEVDVNCHAQcXFgAUx4pFclNVgo1WWAdN1SYNX8tphTABCGsCRzBEAiB8Q+A6dep+Rz92vhy26lT0AjZn4PRLi8Bf9qoB/CMk0wIgP/Rj2PWZ3gEjUkTlhDRNAQ0gXwTO7t9n+V14pZ6oljUBIQMVmsAaoNWHVMS02LfTSe0e388LNitPa1UQZyOihY+FFgABABYAFEb2Giu6c4KO5YW0pfw3lGp9jMUUAAA=</code></pre>\n<p><code>payjoin proposal</code></p>\n<pre><code>cHNidP8BAJwCAAAAAo8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////jye60aAl3JgZdaIERvjkeh72VYZuTGH/ps2I4l0IO4MBAAAAAP7///8CJpW4BQAAAAAXqRQd6EnwadJ0FQ46/q6NcutaawlEMIcACT0AAAAAABepFHdAltvPSGdDwi9DR+m0af6+i2d6h9MAAAAAAQEgqBvXBQAAAAAXqRTeTh6QYcpZE1sDWtXm1HmQRUNU0IcAAQEggIQeAAAAAAAXqRTI8sv5ymFHLIjkZNRrNXSEXZHY1YcBBxcWABRfgGZV5ZJMkgTC1RvlOU9L+e2iEAEIawJHMEQCIGe7e0DfJaVPRYEKWxddL2Pr0G37BoKz0lyNa02O2/tWAiB7ZVgBoF4s8MHocYWWmo4Q1cyV2wl7MX0azlqa8NBENAEhAmXWPPW0G3yE3HajBOb7gO7iKzHSmZ0o0w0iONowcV+tAAAA</code></pre>\n<p><code>payjoin proposal filled with sender's information</code></p>\n<pre><code>cHNidP8BAJwCAAAAAo8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////jye60aAl3JgZdaIERvjkeh72VYZuTGH/ps2I4l0IO4MBAAAAAP7///8CJpW4BQAAAAAXqRQd6EnwadJ0FQ46/q6NcutaawlEMIcACT0AAAAAABepFHdAltvPSGdDwi9DR+m0af6+i2d6h9MAAAAAAQEgqBvXBQAAAAAXqRTeTh6QYcpZE1sDWtXm1HmQRUNU0IcBBBYAFMeKRXJTVYKNVlgHTdUmDV/LaYUwIgYDFZrAGqDVh1TEtNi300ntHt/PCzYrT2tVEGcjooWPhRYYSFzWUDEAAIABAACAAAAAgAEAAAAAAAAAAAEBIICEHgAAAAAAF6kUyPLL+cphRyyI5GTUazV0hF2R2NWHAQcXFgAUX4BmVeWSTJIEwtUb5TlPS/ntohABCGsCRzBEAiBnu3tA3yWlT0WBClsXXS9j69Bt+waCs9JcjWtNjtv7VgIge2VYAaBeLPDB6HGFlpqOENXMldsJezF9Gs5amvDQRDQBIQJl1jz1tBt8hNx2owTm+4Du4isx0pmdKNMNIjjaMHFfrQABABYAFEb2Giu6c4KO5YW0pfw3lGp9jMUUIgICygvBWB5prpfx61y1HDAwo37kYP3YRJBvAjtunBAur3wYSFzWUDEAAIABAACAAAAAgAEAAAABAAAAAAA=</code></pre>\n<h2 id=\"implementations\">Implementations</h2>\n<ul><li>\n<a href=\"https://github.com/BlueWallet/BlueWallet\">BlueWallet</a> is in the process of implementing the protocol.\n</li></ul>\n<ul><li>\n<a href=\"https://github.com/btcpayserver/btcpayserver\">BTCPay Server</a> has implemented sender and receiver side of this protocol.\n</li></ul>\n<ul><li>\n<a href=\"https://github.com/zkSNACKs/WalletWasabi/\">Wasabi Wallet</a> has merged sender's support.\n</li></ul>\n<ul><li>\n<a href=\"https://github.com/JoinMarket-Org/joinmarket-clientserver\">Join Market</a> has implemented sender and receiver side of this protocol.\n</li></ul>\n<ul><li>\n<a href=\"https://github.com/bitcoinjs/payjoin-client\">JavaScript sender implementation</a>.\n</li></ul>\n<h2 id=\"backward-compatibility\">Backward compatibility</h2>\n<p>The receivers advertise payjoin capabilities through <a href=\"/bip/21\">BIP21's URI Scheme</a>.</p>\n<p>Senders not supporting payjoin will just ignore the <code>pj</code> variable and thus, will proceed to normal payment.</p>\n<h2 id=\"special-thanks\">Special thanks</h2>\n<p>Special thanks to Kukks for developing the initial support to BTCPay Server, to junderw, AdamISZ, lukechilds, ncoelho, nopara73, lontivero, yahiheb, SomberNight, andrewkozlik, instagibbs, RHavar for all the feedback we received since our first implementation. Thanks again to RHavar who wrote the <a href=\"/bip/79\">BIP79 Bustapay</a> proposal, this gave a good starting point for our proposal.</p>","toc":[{"id":"introduction","title":"Introduction","level":2},{"id":"abstract","title":"Abstract","level":3},{"id":"copyright","title":"Copyright","level":3},{"id":"motivation","title":"Motivation","level":3},{"id":"relation-to-bip79-bustapay","title":"Relation to BIP79 (Bustapay)","level":3},{"id":"specification","title":"Specification","level":2},{"id":"protocol","title":"Protocol","level":3},{"id":"bip21-payjoin-parameters","title":"BIP21 payjoin parameters","level":3},{"id":"optional-parameters","title":"Optional parameters","level":3},{"id":"receiver-s-well-known-errors","title":"Receiver's well known errors","level":3},{"id":"fee-output","title":"Fee output","level":3},{"id":"receiver-s-original-psbt-checklist","title":"Receiver's original PSBT checklist","level":3},{"id":"sender-s-payjoin-proposal-checklist","title":"Sender's payjoin proposal checklist","level":3},{"id":"rationale","title":"Rationale","level":2},{"id":"respecting-the-minimum-relay-fee-policy","title":"Respecting the minimum relay fee policy","level":3},{"id":"defeating-heuristics-based-on-the-fee-calculation","title":"Defeating heuristics based on the fee calculation","level":3},{"id":"receiver-does-not-need-to-be-a-full-node","title":"Receiver does not need to be a full node","level":3},{"id":"spare-change-donation","title":"Spare change donation","level":3},{"id":"payment-output-substitution","title":"Payment output substitution","level":3},{"id":"unsecured-payjoin-server","title":"Unsecured payjoin server","level":3},{"id":"impacted-heuristics","title":"Impacted heuristics","level":3},{"id":"attack-vectors","title":"Attack vectors","level":2},{"id":"on-the-receiver-side-utxo-probing-attack","title":"On the receiver side: UTXO probing attack","level":3},{"id":"on-the-sender-side-double-payment-risk-for-hardware-wallets","title":"On the sender side: Double payment risk for hardware wallets","level":3},{"id":"reference-sender-s-implementation","title":"Reference sender's implementation","level":2},{"id":"test-vectors","title":"Test vectors","level":2},{"id":"implementations","title":"Implementations","level":2},{"id":"backward-compatibility","title":"Backward compatibility","level":2},{"id":"special-thanks","title":"Special thanks","level":2}],"history":{"totalCommits":46,"firstCommit":"2020-06-16T12:37:42+09:00","lastUpdated":"2026-05-20T15:49:09-07:00","events":[{"sha":"e872e76a3f2a186e01a56e25b3cf430f67c053d3","date":"2026-05-20T15:49:09-07:00","author":"Murch","message":"bip78: Advance to Deployed","url":"https://github.com/bitcoin/bips/commit/e872e76a3f2a186e01a56e25b3cf430f67c053d3","kind":"status"},{"sha":"24e96e870fffaa257b465ce1f0370c14aac588e8","date":"2025-10-08T14:59:36-07:00","author":"Murch","message":"process: Created ↦ Assigned","url":"https://github.com/bitcoin/bips/commit/24e96e870fffaa257b465ce1f0370c14aac588e8","kind":"edit"},{"sha":"5207ef92a52d0b8902895b0dbb40823a4d698ec9","date":"2025-04-11T20:08:17-07:00","author":"Murch","message":"process: Author ↦ Authors","url":"https://github.com/bitcoin/bips/commit/5207ef92a52d0b8902895b0dbb40823a4d698ec9","kind":"edit"},{"sha":"59730dec4fb641a41589aa1b91d3c452f13e0e36","date":"2025-04-11T20:05:13-07:00","author":"Murch","message":"process: Remove Comments-URI and -Summary","url":"https://github.com/bitcoin/bips/commit/59730dec4fb641a41589aa1b91d3c452f13e0e36","kind":"edit"},{"sha":"a233bde4af52c6a11269e2e6dd9707abce441ffe","date":"2025-04-11T18:19:21-07:00","author":"Murch","message":"process: Standards Track ↦ Specification","url":"https://github.com/bitcoin/bips/commit/a233bde4af52c6a11269e2e6dd9707abce441ffe","kind":"edit"},{"sha":"cd19d89e58b8c9b84f18efb5659220d4755fff0b","date":"2025-07-10T02:24:55+02:00","author":"Yuval Kogman","message":"scripted-diff: fix BIP 2 field order violations","url":"https://github.com/bitcoin/bips/commit/cd19d89e58b8c9b84f18efb5659220d4755fff0b","kind":"edit"},{"sha":"c5220f8c3b43821efa3841a6c5e90af9ce5519e8","date":"2025-04-14T22:35:42+03:00","author":"VolodymyrBg","message":"BIPs 78 and 329: minor grammar and typo fix-ups (#1825)","url":"https://github.com/bitcoin/bips/commit/c5220f8c3b43821efa3841a6c5e90af9ce5519e8","kind":"edit"},{"sha":"bd01a269e5d51d0852be37ca6281f34833f43cdc","date":"2024-05-31T11:45:36-04:00","author":"DanGould","message":"BIP78: Doc `amount` parameter not required","url":"https://github.com/bitcoin/bips/commit/bd01a269e5d51d0852be37ca6281f34833f43cdc","kind":"edit"},{"sha":"72d8bb04b81c9b4298a3f426e9ffa2f1d55bbbc5","date":"2024-05-31T11:43:58-04:00","author":"DanGould","message":"BIP78: Clarify output substitution","url":"https://github.com/bitcoin/bips/commit/72d8bb04b81c9b4298a3f426e9ffa2f1d55bbbc5","kind":"edit"},{"sha":"539fd854988025dc5846299ac5142e39404e236f","date":"2024-05-31T11:39:24-04:00","author":"DanGould","message":"BIP78: Allow mixed inputs","url":"https://github.com/bitcoin/bips/commit/539fd854988025dc5846299ac5142e39404e236f","kind":"edit"},{"sha":"5700a230dc9c1fc31748a3155f4984cc7e5b95ef","date":"2024-06-19T22:13:28-04:00","author":"Stacie","message":"BIP78: spelling and grammar updates","url":"https://github.com/bitcoin/bips/commit/5700a230dc9c1fc31748a3155f4984cc7e5b95ef","kind":"edit"},{"sha":"e4267374fb4642051976ea046ce0aebfb22d36f8","date":"2022-12-20T13:00:13-05:00","author":"Dan Gould","message":"Keep input utxo data through input finalization","url":"https://github.com/bitcoin/bips/commit/e4267374fb4642051976ea046ce0aebfb22d36f8","kind":"edit"},{"sha":"f61885edcf5e63ac205b1ca5f08173f1336bff74","date":"2024-05-01T06:54:05+10:00","author":"John Bampton","message":"docs: fix spelling (#1117)","url":"https://github.com/bitcoin/bips/commit/f61885edcf5e63ac205b1ca5f08173f1336bff74","kind":"edit"},{"sha":"d8db3d76081662a55f34c6fed681b9daf5f6a0bd","date":"2021-08-31T15:43:22+09:00","author":"nicolas.dorier","message":"[BIP78] Fix client implementation when there is output substitution","url":"https://github.com/bitcoin/bips/commit/d8db3d76081662a55f34c6fed681b9daf5f6a0bd","kind":"edit"},{"sha":"ec52492034c9bde14aa22b6afa342161f6ec3c8d","date":"2021-08-17T01:08:10+02:00","author":"rage-proof","message":"typo in bip-0078","url":"https://github.com/bitcoin/bips/commit/ec52492034c9bde14aa22b6afa342161f6ec3c8d","kind":"edit"},{"sha":"1945eda0c2128a29b5537b10daef937bbe27b42b","date":"2021-08-05T15:49:41+09:00","author":"Nicolas Dorier","message":"[BIP78] Recommended fee rate estimation for P2TR","url":"https://github.com/bitcoin/bips/commit/1945eda0c2128a29b5537b10daef937bbe27b42b","kind":"edit"},{"sha":"38d245421041b57ebc6f8e45b7c3a5322c5f9292","date":"2021-03-09T09:09:52+01:00","author":"Dávid Molnár","message":"Fix word duplication","url":"https://github.com/bitcoin/bips/commit/38d245421041b57ebc6f8e45b7c3a5322c5f9292","kind":"edit"},{"sha":"55d37134cf751959839315cb6a2223c376ca8f75","date":"2020-10-29T23:58:50+01:00","author":"rage-proof","message":"Update bip-0078.mediawiki","url":"https://github.com/bitcoin/bips/commit/55d37134cf751959839315cb6a2223c376ca8f75","kind":"edit"},{"sha":"1fbcd28584f6b295a1d8a735e265415c1b3eb7e8","date":"2020-10-18T13:37:50+01:00","author":"Adam Gibson","message":"update Joinmarket BIP78 status","url":"https://github.com/bitcoin/bips/commit/1fbcd28584f6b295a1d8a735e265415c1b3eb7e8","kind":"status"},{"sha":"a4fd5cc8ad6b2a40d9fe00865d1e5e2fefb746e9","date":"2020-07-19T22:51:06+02:00","author":"kiminuo","message":"Update bip-0078.mediawiki","url":"https://github.com/bitcoin/bips/commit/a4fd5cc8ad6b2a40d9fe00865d1e5e2fefb746e9","kind":"edit"},{"sha":"a76f5e433591a415fd9d6b5ab8c26e0ec37cc6df","date":"2020-06-23T17:46:18+09:00","author":"nicolas.dorier","message":"Clarify test vector","url":"https://github.com/bitcoin/bips/commit/a76f5e433591a415fd9d6b5ab8c26e0ec37cc6df","kind":"edit"},{"sha":"b0be77f99eee679ebffe0552d75a4ddca3a6d62e","date":"2020-06-22T11:06:57+09:00","author":"nicolas.dorier","message":"Removing non-sense paragraph","url":"https://github.com/bitcoin/bips/commit/b0be77f99eee679ebffe0552d75a4ddca3a6d62e","kind":"edit"},{"sha":"e6418e5a769d7635824f2ad1bcfe4c720be897c2","date":"2020-06-22T10:58:08+09:00","author":"nicolas.dorier","message":"Fix missing word","url":"https://github.com/bitcoin/bips/commit/e6418e5a769d7635824f2ad1bcfe4c720be897c2","kind":"edit"},{"sha":"5e4cc6d8129a94c653187c38c0bb4a1122722a60","date":"2020-06-22T10:56:22+09:00","author":"nicolas.dorier","message":"Fix grammar, additional note on ability to increase output of the receiver","url":"https://github.com/bitcoin/bips/commit/5e4cc6d8129a94c653187c38c0bb4a1122722a60","kind":"edit"},{"sha":"feac3d0035b32dcc8d66d415fe959c533b38d228","date":"2020-06-19T16:12:29+09:00","author":"nicolas.dorier","message":"Update special thanks","url":"https://github.com/bitcoin/bips/commit/feac3d0035b32dcc8d66d415fe959c533b38d228","kind":"edit"},{"sha":"c449c019f6112cfb2acf16d812429e9df0f147e8","date":"2020-06-19T16:06:19+09:00","author":"nicolas.dorier","message":"Do not allow decrease in absolute fee","url":"https://github.com/bitcoin/bips/commit/c449c019f6112cfb2acf16d812429e9df0f147e8","kind":"edit"},{"sha":"549107933cfa1c3081fca241f500b02c0ee3b353","date":"2020-06-19T15:19:22+09:00","author":"nicolas.dorier","message":"Allow outputs to be increased","url":"https://github.com/bitcoin/bips/commit/549107933cfa1c3081fca241f500b02c0ee3b353","kind":"edit"},{"sha":"bd9740074338593c594394be365c3bed1b6cc3df","date":"2020-06-19T14:47:47+09:00","author":"nicolas.dorier","message":"Introduce pjos=0","url":"https://github.com/bitcoin/bips/commit/bd9740074338593c594394be365c3bed1b6cc3df","kind":"edit"},{"sha":"e2778babfb99ef011270fcda2e29ce076d383527","date":"2020-06-19T14:31:19+09:00","author":"nicolas.dorier","message":"additional comments","url":"https://github.com/bitcoin/bips/commit/e2778babfb99ef011270fcda2e29ce076d383527","kind":"edit"},{"sha":"6d4b491b31554b78d3c662489ca3ee746ec94651","date":"2020-06-19T14:26:51+09:00","author":"nicolas.dorier","message":"Simplify sender's implementation, fix typos","url":"https://github.com/bitcoin/bips/commit/6d4b491b31554b78d3c662489ca3ee746ec94651","kind":"edit"},{"sha":"93c655a1495b61afb9de30970db9353872145e42","date":"2020-06-19T13:24:14+09:00","author":"nicolas.dorier","message":"Fix typo","url":"https://github.com/bitcoin/bips/commit/93c655a1495b61afb9de30970db9353872145e42","kind":"edit"},{"sha":"3a16c24f5e87614ac42173927297f0d013fdc0f2","date":"2020-06-19T13:23:37+09:00","author":"nicolas.dorier","message":"Additional note for HW","url":"https://github.com/bitcoin/bips/commit/3a16c24f5e87614ac42173927297f0d013fdc0f2","kind":"edit"},{"sha":"7803bf8335780ae2fdcc256e4edd81bb9681089d","date":"2020-06-19T13:16:16+09:00","author":"nicolas.dorier","message":"Reformat the check list for sender","url":"https://github.com/bitcoin/bips/commit/7803bf8335780ae2fdcc256e4edd81bb9681089d","kind":"edit"},{"sha":"a3fbc6c6203ef7ded879626ee2fcb689195a7ec1","date":"2020-06-18T11:04:59+09:00","author":"nicolas.dorier","message":"Do not crash reference implementation if there is no address in the bip21","url":"https://github.com/bitcoin/bips/commit/a3fbc6c6203ef7ded879626ee2fcb689195a7ec1","kind":"edit"},{"sha":"a2a085cdb4590a5219292522e5295903d5157e99","date":"2020-06-18T10:11:20+09:00","author":"nicolas.dorier","message":"Add disableoutputsubstitution= optional parameter","url":"https://github.com/bitcoin/bips/commit/a2a085cdb4590a5219292522e5295903d5157e99","kind":"edit"},{"sha":"63aa576facc816bd78e41b41411c15bfca5c895e","date":"2020-06-18T09:59:44+09:00","author":"nicolas.dorier","message":"Update from RHavar remarks","url":"https://github.com/bitcoin/bips/commit/63aa576facc816bd78e41b41411c15bfca5c895e","kind":"edit"},{"sha":"3485af708ce5a485d30cd8f60efe0004e9b4566c","date":"2020-06-17T22:26:03+09:00","author":"nicolas.dorier","message":"Add reference implementation","url":"https://github.com/bitcoin/bips/commit/3485af708ce5a485d30cd8f60efe0004e9b4566c","kind":"edit"},{"sha":"ea7562fc9055227adb129ba0144556e3be050d77","date":"2020-06-17T21:51:09+09:00","author":"nicolas.dorier","message":"Fix old error code","url":"https://github.com/bitcoin/bips/commit/ea7562fc9055227adb129ba0144556e3be050d77","kind":"edit"},{"sha":"3fc7032ec33724eb9a79939358db6729fd3d87c2","date":"2020-06-17T16:20:38+09:00","author":"nicolas.dorier","message":"Fix some formatting","url":"https://github.com/bitcoin/bips/commit/3fc7032ec33724eb9a79939358db6729fd3d87c2","kind":"edit"},{"sha":"f36ca8f43d51a71b6f5528baa65091e75433ed44","date":"2020-06-17T16:15:53+09:00","author":"nicolas.dorier","message":"Update recommendation for receiver and sender","url":"https://github.com/bitcoin/bips/commit/f36ca8f43d51a71b6f5528baa65091e75433ed44","kind":"edit"},{"sha":"a07fef579775cd80ae310b91d0277a976b4ef83b","date":"2020-06-17T16:04:49+09:00","author":"nicolas.dorier","message":"Add fee output section","url":"https://github.com/bitcoin/bips/commit/a07fef579775cd80ae310b91d0277a976b4ef83b","kind":"edit"},{"sha":"d72e27535ed7ec3d70c14897519cef779bd93408","date":"2020-06-17T15:06:28+09:00","author":"nicolas.dorier","message":"[MoveOnly] Move optional parameters at the beginning","url":"https://github.com/bitcoin/bips/commit/d72e27535ed7ec3d70c14897519cef779bd93408","kind":"rename"},{"sha":"801cc71114d2c7630f0b58122efb9facb390f4f0","date":"2020-06-16T14:25:52+09:00","author":"nicolas.dorier","message":"Update PSBT invariants","url":"https://github.com/bitcoin/bips/commit/801cc71114d2c7630f0b58122efb9facb390f4f0","kind":"edit"},{"sha":"631d8e65cd01bdcb8d6e0b93c4c36fd039d5744b","date":"2020-06-16T14:17:36+09:00","author":"nicolas.dorier","message":"Simplifies sender recommendation","url":"https://github.com/bitcoin/bips/commit/631d8e65cd01bdcb8d6e0b93c4c36fd039d5744b","kind":"edit"},{"sha":"d13c78467191ffe9beb24823ce7dd7e12ec63199","date":"2020-06-16T13:39:27+09:00","author":"nicolas.dorier","message":"Remove parts refering to RBF, add recommendations for maxadditionalfeecontribution","url":"https://github.com/bitcoin/bips/commit/d13c78467191ffe9beb24823ce7dd7e12ec63199","kind":"edit"},{"sha":"73a4d7c4baa71355e145158156d41238722f58a1","date":"2020-06-16T12:37:42+09:00","author":"nicolas.dorier","message":"Rename to BIP78","url":"https://github.com/bitcoin/bips/commit/73a4d7c4baa71355e145158156d41238722f58a1","kind":"rename"}]}}