diff options
| author | nicolas.dorier <nicolas.dorier@gmail.com> | 2020-06-17 16:15:53 +0900 |
|---|---|---|
| committer | nicolas.dorier <nicolas.dorier@gmail.com> | 2020-06-17 16:15:53 +0900 |
| commit | f36ca8f43d51a71b6f5528baa65091e75433ed44 (patch) | |
| tree | b7d64c56351c74e799ef41d40895ee347215a4df /bip-0078.mediawiki | |
| parent | a07fef579775cd80ae310b91d0277a976b4ef83b (diff) | |
| download | bips-f36ca8f43d51a71b6f5528baa65091e75433ed44.tar.xz | |
Update recommendation for receiver and sender
Diffstat (limited to 'bip-0078.mediawiki')
| -rw-r--r-- | bip-0078.mediawiki | 8 |
1 files changed, 3 insertions, 5 deletions
diff --git a/bip-0078.mediawiki b/bip-0078.mediawiki index 74ab76c..5c06c2f 100644 --- a/bip-0078.mediawiki +++ b/bip-0078.mediawiki @@ -232,8 +232,9 @@ The receiver needs to do some check on the original PSBT before proceeding: * Non-interactive receivers (like a payment processor) need to check that the original PSBT is broadcastable. <code>*</code> * If the sender included inputs in the original PSBT owned by the receiver, the receiver must either return error <code>invalid-transaction</code> or make sure they do not sign those inputs in the payjoin proposal. * If the sender's inputs are all from the same scriptPubKey type, the receiver must match the same type. If the receiver can't match the type, they must return error <code>unavailable</code>. +* Make sure that the inputs included in the original transaction has never been seen before. (Prevent [[#probing-attack|probing attacks]].) -<code>*</code>: Interactive receivers are not required to validate the original PSBT because they are not exposed to probing attacks. +<code>*</code>: Interactive receivers are not required to validate the original PSBT because they are not exposed to [[#probing-attack|probing attacks]]. ===Sender's payjoin proposal checklist=== @@ -266,9 +267,6 @@ Note: 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. -On top of those check, it is recommended, but not required for the sender to check that: -* If the sender is making a payjoin with a change (ie, not in the [[#spare-change|spare change]] case), make sure the receiver is paying for any batched output. - ==Rationale== There is several consequences of our proposal: @@ -348,7 +346,7 @@ For this reason, during a [[#spare-change|spare change]] case, the receiver may ==Attack vectors== -===On the receiver side: UTXO probing attack=== +===<span id="probing-attack"></span>On the receiver side: UTXO probing attack=== When the receiver creates a payjoin proposal, they expose one or more inputs belonging to them. |