When payjoin fails, should ask for user confirmation for non-payjoin send
kristapsk opened this issue · 2 comments
When non-coinjoin sends are made with sendpayment.py or JoinMarketQt GUI, before sending out transaction, user is asked for Yes / No confirmation. But when payjoin attempt is made and it fails, it automatically falls back to same non-coinjoin send without asking for user confirmation. It is wrong for two reasons: 1) it should act the same way as when normally non-coinjoin send is made, 2) if payjoin fails, I might want to send using JoinMarket coinjoin instead.
That's not a bad thought, but the earliest discussion of payjoin focused on this as a central mechanic. The idea was, that an attacker can probe UTXOs of a receiver by continually trying and not completing payjoins. The solution was to have the sender send a completely valid payment transaction at the start, and then the receiver can broadcast the non-payjoin payment transaction if anything in the payjoin workflow prevents it from completing. So utxos become the scarce resource for an attacker, much like PoDLE etc.
Which brings me to BIP 78. I'm quite confused to see no mention of this mechanic, it makes me wonder if this is because the doc was updated at some point after discussions. The section on probing attacks talks about a different (I think, weaker) mitigation, but there is no mention of the original PSBT, which must be finalized, ever needing to be broadcast by the receiver. @NicolasDorier could you maybe remind me or help me understand that? i.e. specifically, why does this section not mention the defence that the receiver can simply broadcast the fallback (the original, finalized PSBT sent by the sender?).
What the BIP is very clear on, and it's something I decided to ignore, is that the probing attacks are not relevant for a p2p receiver vs a client-server (i.e. merchant) scenario. Since your wallet won't keep automatically generating invoices/addresses.
In my case I tried to use payjoin to deposit funds to Namecheap, but HTTP request to payjoin endpoint failed with 403 (due to misconfiguration on their side likely).
