1 files changed, 13 insertions, 10 deletions
diff --git a/bip-0078.mediawiki b/bip-0078.mediawiki
index 4226be5..f3710d7 100644
--- a/bip-0078.mediawiki
+++ b/bip-0078.mediawiki
@@ -64,7 +64,7 @@ Other than that, our proposal is very similar.
 
 In a payjoin payment, the following steps happen:
 
-* The receiver of the payment, presents a [[bip-021.mediawiki|BIP 21 URI]] to the sender with a parameter <code>pj=</code> describing a payjoin endpoint.
+* The receiver of the payment, presents a [[bip-0021.mediawiki|BIP 21 URI]] to the sender with a parameter <code>pj=</code> describing a payjoin endpoint.
 * The sender creates a signed, finalized PSBT with witness UTXO or previous transactions of the inputs. We call this PSBT the <code>original</code>.
 * The 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>.
 * The sender verifies the proposal, re-signs his inputs and broadcasts the transaction to the Bitcoin network. We call this transaction <code>Payjoin transaction</code>.
@@ -121,7 +121,7 @@ The payjoin proposal MUST NOT:
 
 ===BIP21 payjoin parameters===
 
-This proposal is defining the following new [[bip-021.mediawiki|BIP 21 URI]] parameters:
+This proposal is defining the following new [[bip-0021.mediawiki|BIP 21 URI]] parameters:
 * <code>pj=</code>: Represents an http(s) endpoint which the sender can POST the original PSBT.
 * <code>pjos=0</code>: Signal to the sender that they MUST disallow [[#output-substitution|payment output substitution]]. (See [[#unsecured-payjoin|Unsecured payjoin server]])
 
@@ -209,7 +209,7 @@ In such case, the receiver will need to increase the fee of the transaction afte
 * The sender's wallet software is using round fee rate.
 
 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 more fee so the receiver make sure that the payjoin transaction fee is also 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.
 
 * The sender's transaction is time sensitive.
 
@@ -229,6 +229,9 @@ Our recommendation for <code>maxadditionalfeecontribution=</code> is <code>origi
 |-
 |P2SH-P2WPKH
 |91
+|-
+|P2TR
+|58
 |}
 
 
@@ -249,7 +252,7 @@ The receiver needs to do some check on the original PSBT before proceeding:
 ===Sender's payjoin proposal checklist===
 
 The sender should check the payjoin proposal before signing it to prevent a malicious receiver from stealing money.
- 
+
 * Verify that the absolute fee of the payjoin proposal is equals or higher than the original PSBT.
 * If the receiver's BIP21 signalled <code>pjos=0</code>, disable payment output substitution.
 * Verify that the transaction version, and the nLockTime are unchanged.
@@ -272,7 +275,7 @@ The sender should check the payjoin proposal before signing it to prevent a mali
 ** If the output is the [[#fee-output|fee output]]:
 *** The amount that was substracted from the output's value is less than or equal to <code>maxadditionalfeecontribution</code>. Let's call this amount <code>actual contribution</code>.
 *** Make sure the actual contribution is only paying fee: The <code>actual contribution</code> is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT.
-*** Make sure the actual contribution is only paying for fee incurred by additional inputs: <code>actual contribution</code> is less than or equals to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(original_psbt_inputs) - count(payjoin_proposal_inputs))</code>. (see [[#fee-output|Fee output]] section)
+*** Make sure the actual contribution is only paying for fee incurred by additional inputs: <code>actual contribution</code> is less than or equals to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))</code>. (see [[#fee-output|Fee output]] section)
 ** If the output is the payment output and payment output substitution is allowed.
 *** Do not make any check
 ** Else
@@ -325,7 +328,7 @@ Because the receiver needs to bump the fee to keep the same fee rate as the orig
 
 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.
 
-However, non-interactive receivers (like a payment processor) need to verify the transaction to prevent UTXO probing attacks. 
+However, non-interactive receivers (like a payment processor) need to verify the transaction to prevent UTXO probing attacks.
 
 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.
 
@@ -498,7 +501,7 @@ public async Task<PSBT> RequestPayjoin(
             if (proposedPSBTInput.NonWitnessUtxo != null || proposedPSBTInput.WitnessUtxo != null)
                 throw new PayjoinSenderException("The receiver added non_witness_utxo or witness_utxo to one of our inputs");
             sequences.Add(proposedTxIn.Sequence);
-            
+
             // Fill up the info from the original PSBT input so we can sign and get fees.
             proposedPSBTInput.NonWitnessUtxo = input.SignedPSBTInput.NonWitnessUtxo;
             proposedPSBTInput.WitnessUtxo = input.SignedPSBTInput.WitnessUtxo;
@@ -666,16 +669,16 @@ A successful exchange with:
 * [[https://github.com/BlueWallet/BlueWallet|BlueWallet]] is in the process of implementing the protocol.
 * [[https://github.com/btcpayserver/btcpayserver|BTCPay Server]] has implemented sender and receiver side of this protocol.
 * [[https://github.com/zkSNACKs/WalletWasabi/|Wasabi Wallet]] has merged sender's support.
-* [[https://github.com/JoinMarket-Org/joinmarket-clientserver|Join Market]] is in the process of implementing the protocol.
+* [[https://github.com/JoinMarket-Org/joinmarket-clientserver|Join Market]] has implemented sender and receiver side of this protocol.
 * [[https://github.com/bitcoinjs/payjoin-client|JavaScript sender implementation]].
 
 ==Backward compatibility==
 
-The receivers are advertising payjoin capabilities through [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]].
+The receivers are advertising payjoin capabilities through [[bip-0021.mediawiki|BIP21's URI Scheme]].
 
 Senders not supporting payjoin will just ignore the <code>pj</code> variable and thus, will proceed to normal payment.
 
 ==Special thanks==
 
 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 [[https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki|BIP79 Bustapay]] proposal, this gave a good starting point for our proposal.
+Thanks again to RHavar who wrote the [[bip-0079.mediawiki|BIP79 Bustapay]] proposal, this gave a good starting point for our proposal.