mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-04 11:08:05 +01:00
Code Issues Projects Releases Wiki Activity

Relaxing authenticated endpoint

Browse source
This commit is contained in:
nicolas.dorier 2020-05-19 19:14:51 +09:00
parent 5a337c6fc6
commit 3659671a22
No known key found for this signature in database
GPG key ID: 6618763EF09186FE
1 changed files with 6 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
bip-xxxx.mediawiki
View file

@ -65,7 +65,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 an https (or http if it is a Tor hidden service) link to the payjoin endpoint.
* 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 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>.
@ -96,7 +96,9 @@ The payjoin proposal PSBT is sent in the HTTP response body, base64 serialized w
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>.
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 MUST NOT accept a url representing an unencrypted or unauthenticated connection.
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.
Unauthenticated transport is authorized, but [[#output-substitution|Output substitution]] should be disallowed in this case.
===Receiver's well known errors===
@ -280,6 +282,8 @@ On top of this the receiver can poison analysis by randomly faking a round amoun
The receiver is free to change the output paying to himself.
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.
Note that this MUST NOT be authorized over an unauthenticated payjoin endpoint such as http on clearnet, as a man-in-the-middle attacker could substitute with his own address.
===Impacted heuristics===
Our proposal of payjoin is breaking the following blockchain heuristics: