You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: bip-0078.mediawiki
+3-5Lines changed: 3 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -232,8 +232,9 @@ The receiver needs to do some check on the original PSBT before proceeding:
232
232
* Non-interactive receivers (like a payment processor) need to check that the original PSBT is broadcastable. <code>*</code>
233
233
* 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.
234
234
* 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>.
235
+
* Make sure that the inputs included in the original transaction has never been seen before. (Prevent [[#probing-attack|probing attacks]].)
235
236
236
-
<code>*</code>: Interactive receivers are not required to validate the original PSBT because they are not exposed to probing attacks.
237
+
<code>*</code>: Interactive receivers are not required to validate the original PSBT because they are not exposed to [[#probing-attack|probing attacks]].
237
238
238
239
===Sender's payjoin proposal checklist===
239
240
@@ -266,9 +267,6 @@ Note:
266
267
Our method of checking the fee allows the receiver and the sender to batch payments in the payjoin transaction.
267
268
It also allows the receiver to pay the fee for batching adding his own outputs.
268
269
269
-
On top of those check, it is recommended, but not required for the sender to check that:
270
-
* 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.
271
-
272
270
==Rationale==
273
271
274
272
There is several consequences of our proposal:
@@ -348,7 +346,7 @@ For this reason, during a [[#spare-change|spare change]] case, the receiver may
348
346
349
347
==Attack vectors==
350
348
351
-
===On the receiver side: UTXO probing attack===
349
+
===<span id="probing-attack"></span>On the receiver side: UTXO probing attack===
352
350
353
351
When the receiver creates a payjoin proposal, they expose one or more inputs belonging to them.
0 commit comments