From: Yuval Kogman <nothingmuch@woobling•org>
To: "/dev /fd0" <alicexbtong@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] UTXO probing attack using payjoin
Date: Tue, 25 Mar 2025 14:39:41 +0100 [thread overview]
Message-ID: <CAAQdECADpUOUN9+yBLMR7dVJ2WhsE2uhesSgh=p-jRgzp9AaWQ@mail.gmail.com> (raw)
In-Reply-To: <450755f1-84c5-4f32-abe0-67087ae884d6n@googlegroups.com>
On Tue, 25 Mar 2025 at 12:48, /dev /fd0 <alicexbtong@gmail•com> 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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAQdECADpUOUN9%2ByBLMR7dVJ2WhsE2uhesSgh%3Dp-jRgzp9AaWQ%40mail.gmail.com.
next prev parent reply other threads:[~2025-03-26 18:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 11:46 /dev /fd0
2025-03-25 12:52 ` [bitcoindev] " jbesraa
2025-03-26 19:38 ` /dev /fd0
2025-03-28 19:28 ` waxwing/ AdamISZ
2025-03-28 23:41 ` Yuval Kogman
2025-03-29 13:00 ` /dev /fd0
2025-03-29 12:34 ` /dev /fd0
2025-03-25 13:39 ` Yuval Kogman [this message]
2025-03-26 19:26 ` [bitcoindev] " /dev /fd0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAQdECADpUOUN9+yBLMR7dVJ2WhsE2uhesSgh=p-jRgzp9AaWQ@mail.gmail.com' \
--to=nothingmuch@woobling$(echo .)org \
--cc=alicexbtong@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox