On Tue, 25 Mar 2025 at 12:48, /dev /fd0 <[email protected]> wrote:
> I think users should be aware of this tradeoff and the information they share > with the sender in payjoin. Payjoin should only be used with trusted senders. In the event that the receiver is actually paid (see below), the sender can observe what happens to a payment output, same as they would when a receiver does not support payjoin at all. This will likely link it to the receiver's other coins eventually, and certainly links it to the receiver's subsequent transactions. It seems to me like your reasoning applies to any on chain wallet (with or without payjoin), unless the receiver is using e.g. coinswap after each received payment. In the payjoin setting, the receiver is using coinswap in that manner, then as a payjoin receiver they can elect to only use coinswapped coins as contributed inputs to payjoin transactions. > Sometimes we are curious and want to know about UTXOs in other wallets. > Payjoin allows you to do this and the recipient would never doubt it because > it's a privacy tool. I'm not sure what you mean by "the recipient would never doubt it because it's a privacy tool", it sounds to me like this is mainly a criticism of the UX of payjoin supporting wallets, or of wallets in general for not educating users that privacy is not a binary thing? If that's the case then I'm not sure how to convert that critique into an actionable suggestion. UTXO enumeration is a potentially serious concern in the context of clustering deanonymization attacks, *especially* if coins can be linked without spending them, as that is independent from any common input ownership leaks that may arise when those coins are actually spent. The same leak concern also applies to lightning dual funding, and a similar one (revealing coin relatedness to coordinators) applies to coordinated coinjoins where vendors have made outright false claims... In relation to your statement about users being none the wiser since "it's a privacy tool", that seems part of a broader challenge of communicating nuances and tradeoffs to non-technical users, and one isn't specifically related to payjoin? > It's possible to find UTXO in recipient's wallet without sending any bitcoin. > It's called UTXO probing attack and described in BIP 77-78. "Without sending any bitcoin" is not entirely accurate, in all payjoin protocol specs the receiver only responds after validating the initial unilateral transaction from the sender. This transaction is not yet confirmed, and can of course be double spent by the sender, but that is not costless as the mining fees for double spending or replacing that transaction (depending on whether or not the receiver has broadcast it) must be paid. Probing was initially described in BIP 79 (https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki#contributed-input-choice): >> To prevent an attack where a receiver is continually sent variations of the >> same transaction to enumerate the receivers utxo set, it is essential that >> the receiver always returns the same contributed inputs when it's seen the >> same inputs. This is again described in BIP 78 https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#user-content-span_idprobingattackspanOn_the_receiver_side_UTXO_probing_attack And mentioned in BIP 77 (that could be made more explicit but BIP 77 depends on BIP 78 and refers to it extensively): https://github.com/bitcoin/bips/blob/799e8c145da0304d847abfe59bd2311a1cf78968/bip-0077.mediawiki#request-expiration--original-psbt Note that in all of these specifications of payjoin UTXO probing is not costless since the sender must send a fully signed transaction in order to learn such a UTXO, and this transaction although not confirmed still imposes a fee cost on the sender if broadcast (even if it is replaced). The trust assumption you point out has been described throughout these protocols' evolution, and attempts to minimize that trust to the extent possible have been made in that the leaks are bounded by correctly implemented receivers, and a cost is imposed on the attacker. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAQdECADpUOUN9%2ByBLMR7dVJ2WhsE2uhesSgh%3Dp-jRgzp9AaWQ%40mail.gmail.com.
