bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

Update recommendation for receiver and sender

Browse Source
This commit is contained in:
nicolas.dorier 2020-06-17 16:15:53 +09:00
parent a07fef5797
commit f36ca8f43d
No known key found for this signature in database
GPG Key ID: 6618763EF09186FE
1 changed files with 3 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
bip-0078.mediawiki
View File

@ -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> * 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 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>. * 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=== ===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. 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. 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== ==Rationale==
There is several consequences of our proposal: 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== ==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. When the receiver creates a payjoin proposal, they expose one or more inputs belonging to them.