From: waxwing/ AdamISZ <ekaggata@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: UTXO probing attack using payjoin
Date: Fri, 28 Mar 2025 12:28:53 -0700 (PDT) [thread overview]
Message-ID: <d0a0e344-d777-49bc-8b3c-a3462f0d6836n@googlegroups.com> (raw)
In-Reply-To: <CALiT-Zrq0Nr9uNWDTMj3=VJ6TCcmeL3s+Jau+nEGHqYqFcfB+g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 8252 bytes --]
Hi /dev/fd0 and all,
> The original transaction can be replaced by the attacker, and it would
only cost a few hundred sats or nothing if it's payjoin transaction. I
think such attacks could still be effective if the attacker has the budget
and motivation to spy on someone's wallet.
That is true but it is also directly addressed with a mitigation in the
section on the attack in BIP78; (already linked here but just to repeat:
https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#user-content-span_idprobingattackspanOn_the_receiver_side_UTXO_probing_attack
)
specifically it says "When the receiver detects an original transaction
being broadcast, or if the receiver detects that the original transaction
has been double spent, then they will reuse the UTXO that was exposed for
the next payjoin.".
However it is unclear whether that's part of the protocol specification, or
whether it should be. So there's at least something to discuss there.
In the blog post on substack, I don't see any discussion of whether the
mitigations proposed make sense. I think they do. Also that blog post
discusses altering the sender code to prevent sending the tx. An
implementation might differ, but at least in BIP78 it should be the
receiver who broadcasts the initial non-payjoin version after a short
timeout. That difference connects with the next point also:
One other important thing that is discussed in BIP78, there is a
difference between a "merchant" (or in any case, payment-receiving-server)
case vs. a peer to peer payments case. In the latter case you cannot simply
continuously ask for more and more "invoices" (payjoin urls) from the
counterparty. In the former case, you certainly can, and the mitigations
mentioned make sense there to prevent the "utxo collection" algorithm of
continuously failing to complete or double spending, across multiple
payment amounts.
> It was costless in the demo which could be fixed by bullbitcoin
Yeah I see a couple of related things there, BIP77 is more nuanced on the
"receiver broadcasts original after short delay" saying that an expiration
MAY be set and applied by receivers, which relates ack to the earlier point
that for a p2p payment arranged with both parties live is not exposed to a
repeated request attack, hence it may not be needed. I do think it comes
back to the "don't change the currently available utxo until it gets used"
statement in that BIP78 section mentioned above.
With that nuance even your modified-code-sender could be argued not to be
an issue, though I think I prefer the BIP78 inclusion of "receiver
broadcasts after an expiration" being a requirement, not a "MAY".
> Payjoin should only be used with trusted senders.
I mean, obviously, I don't agree with that.
And then there's the 10000ft view: if an attacker doesn't mind spending
coins, they can just .. do sender-side actual payjoins, over and over, to
try to collect utxos. After all the very first blockchain analysis paper by
Meiklejohn et al focused on exactly this; see how much info you can get by
actually paying at a merchant.
I think that whether this is a problem or not is deeply tied to that
inevitable conflict between the desire for privacy and the desire for
scalability/low cost. To never co-spend utxos means a wallet fragments to
infinite utxos. But to cospend maximally (as a naive merchant *might* do -
receive 1000 payments then send all of them at the same time into a cold
wallet) wipes out, at least most of the time, the privacy gain from not
reusing addresses in the first place. A payjoin based merchant flow, in the
simplest version, would end up linking the 1000 anyway (think a chain of
1000 payjoins with 1 merchant in and 1 merchant out), but with
substantially more deniability/lack of certainty at each step in terms of
both utxo and amount, and never being hit with "huge transaction during fee
spike". It should at least be *better*.
If those 1000 payjoins were an attacker, he only really learns about the
first utxo, if you snowball like that. To "read" your current wallet, he
somehow has to pay for a huge range of different amounts to try to entice
you to spend *different* utxos; it's not easy, but equally it's ridiculous
to claim that it doesn't leak anything.
Cheers,
AdamISZ/waxwing
On Thursday, March 27, 2025 at 9:19:38 AM UTC-3 /dev /fd0 wrote:
> Hi jbesraa,
>
> > While the possibility of UTXO probing via Payjoin is a valid concern
> regarding privacy, it's important to note that it might not always come
> without cost for the attacker. The Payjoin recipient > needs to validate
> the initial request, ensuring the sender's inputs are broadcastable. This
> means the recipient could, in practice, broadcast the initial transaction
> even if the sender aborts the > Payjoin.
>
> > Furthermore, implementing strategies like maintaining a set of 'seen
> inputs' can make such probing attempts more easily detectable and less
> effective.
>
> The original transaction can be replaced by the attacker, and it would
> only cost a few hundred sats or nothing if it's payjoin transaction. I
> think such attacks could still be effective if the attacker has the budget
> and motivation to spy on someone's wallet.
>
> /dev/fd0
> floppy disk guy
>
>
> On Wed, Mar 26, 2025 at 11:54 PM jbesraa <jbe...@gmail•com> wrote:
>
>> While the possibility of UTXO probing via Payjoin is a valid concern
>> regarding privacy, it's important to note that it might not always come
>> without cost for the attacker. The Payjoin recipient needs to validate the
>> initial request, ensuring the sender's inputs are broadcastable. This means
>> the recipient could, in practice, broadcast the initial transaction even if
>> the sender aborts the Payjoin. Furthermore, implementing strategies like
>> maintaining a set of 'seen inputs' can make such probing attempts more
>> easily detectable and less effective. While these measures don't eliminate
>> the privacy considerations entirely, they do highlight that recipients have
>> potential defenses and that probing isn't necessarily a risk-free endeavor
>> for the attacker.
>>
>> On Tuesday, March 25, 2025 at 1:48:15 PM UTC+2 /dev /fd0 wrote:
>>
>> Hi everyone,
>>
>> 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. 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.
>>
>> I have shared a demo with all the details in this [post][0]. I have used
>> bullbitcoin wallet for testing this because it was the only [wallet][1]
>> which supports payjoin v2 (send, receive) and testnet3.
>>
>> 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.
>>
>> [0]:
>> https://uncensoredtech.substack.com/p/utxo-probing-attack-using-payjoin
>> [1]: https://en.bitcoin.it/wiki/PayJoin_adoption
>>
>> /dev/fd0
>> floppy disk guy
>>
>> --
>> 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+...@googlegroups•com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/1c7130d4-cbac-4404-968c-9eb7b4e2e4cbn%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/1c7130d4-cbac-4404-968c-9eb7b4e2e4cbn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/d0a0e344-d777-49bc-8b3c-a3462f0d6836n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 10711 bytes --]
next prev parent reply other threads:[~2025-03-28 19:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 11:46 [bitcoindev] " /dev /fd0
2025-03-25 12:52 ` [bitcoindev] " jbesraa
2025-03-26 19:38 ` /dev /fd0
2025-03-28 19:28 ` waxwing/ AdamISZ [this message]
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 ` [bitcoindev] " Yuval Kogman
2025-03-26 19:26 ` /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=d0a0e344-d777-49bc-8b3c-a3462f0d6836n@googlegroups.com \
--to=ekaggata@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