* [bitcoindev] UTXO probing attack using payjoin
@ 2025-03-25 11:46 /dev /fd0
2025-03-25 12:52 ` [bitcoindev] " jbesraa
2025-03-25 13:39 ` [bitcoindev] " Yuval Kogman
0 siblings, 2 replies; 9+ messages in thread
From: /dev /fd0 @ 2025-03-25 11:46 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 1221 bytes --]
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+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/450755f1-84c5-4f32-abe0-67087ae884d6n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 1680 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* [bitcoindev] Re: UTXO probing attack using payjoin
2025-03-25 11:46 [bitcoindev] UTXO probing attack using payjoin /dev /fd0
@ 2025-03-25 12:52 ` jbesraa
2025-03-26 19:38 ` /dev /fd0
2025-03-25 13:39 ` [bitcoindev] " Yuval Kogman
1 sibling, 1 reply; 9+ messages in thread
From: jbesraa @ 2025-03-25 12:52 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2095 bytes --]
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+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1c7130d4-cbac-4404-968c-9eb7b4e2e4cbn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2755 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] UTXO probing attack using payjoin
2025-03-25 11:46 [bitcoindev] UTXO probing attack using payjoin /dev /fd0
2025-03-25 12:52 ` [bitcoindev] " jbesraa
@ 2025-03-25 13:39 ` Yuval Kogman
2025-03-26 19:26 ` /dev /fd0
1 sibling, 1 reply; 9+ messages in thread
From: Yuval Kogman @ 2025-03-25 13:39 UTC (permalink / raw)
To: /dev /fd0; +Cc: Bitcoin Development Mailing List
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] UTXO probing attack using payjoin
2025-03-25 13:39 ` [bitcoindev] " Yuval Kogman
@ 2025-03-26 19:26 ` /dev /fd0
0 siblings, 0 replies; 9+ messages in thread
From: /dev /fd0 @ 2025-03-26 19:26 UTC (permalink / raw)
To: Yuval Kogman; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2395 bytes --]
Hi Yuval,
Thank you for your feedback.
> This will> likely link it to the receiver's other coins eventually, and
certainly
> links it to the receiver's subsequent transactions.
Coin control and labels can be used to avoid this. Consolidation of inputs
is often bad for privacy and makes silent payments, coinjoin etc. useless
in some cases however the user has the choice to select coins manually
while transacting. In payjoin, users can't do much about it. They have to
share UTXOs in response to the original PSBT along with the address to
receive bitcoin.
> 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.
It could be a workaround or temporary fix for this problem. However, if
swapped coins are used in transactions, octojoin could be a better solution
which doesn't require any inputs from the recipient.
> 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?
The recipient would never doubt a sender who insists on using payjoin and
not interested in a normal bitcoin transaction. They would not know the
intentions of the sender before payjoin.
> 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).
It was costless in the demo which could be fixed by bullbitcoin. However,
an attacker with a budget and some motivation can always spy on your wallet
using payjoin. Things become even easier with automated payment systems
such as BTCPay Server.
/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+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALiT-Zq-WmwZCB2uJ4oq%2BevFerRZTwtKcct8sPRE6n%2BJx3CQhQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2921 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: UTXO probing attack using payjoin
2025-03-25 12:52 ` [bitcoindev] " jbesraa
@ 2025-03-26 19:38 ` /dev /fd0
2025-03-28 19:28 ` waxwing/ AdamISZ
0 siblings, 1 reply; 9+ messages in thread
From: /dev /fd0 @ 2025-03-26 19:38 UTC (permalink / raw)
To: jbesraa; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3667 bytes --]
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 <jbesraa@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+unsubscribe@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/CALiT-Zrq0Nr9uNWDTMj3%3DVJ6TCcmeL3s%2BJau%2BnEGHqYqFcfB%2Bg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4811 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: UTXO probing attack using payjoin
2025-03-26 19:38 ` /dev /fd0
@ 2025-03-28 19:28 ` waxwing/ AdamISZ
2025-03-28 23:41 ` Yuval Kogman
2025-03-29 12:34 ` /dev /fd0
0 siblings, 2 replies; 9+ messages in thread
From: waxwing/ AdamISZ @ 2025-03-28 19:28 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: UTXO probing attack using payjoin
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
1 sibling, 1 reply; 9+ messages in thread
From: Yuval Kogman @ 2025-03-28 23:41 UTC (permalink / raw)
To: waxwing/ AdamISZ, /dev /fd0; +Cc: Bitcoin Development Mailing List
On Wed, 26 Mar 2025 at 20:26, /dev /fd0 <alicexbtong@gmail•com> wrote:
> Coin control and labels can be used to avoid this. Consolidation of inputs is often bad for privacy and makes silent payments, coinjoin etc. useless in some cases however the user has the choice to select coins manually while transacting. In payjoin, users can't do much about it. They have to share UTXOs in response to the original PSBT along with the address to receive bitcoin.
In the protocol specifications the receiver is not required to opt-in
to a payjoin in order to get paid, and can just broadcast transaction
they receive from the sender. 0 conf considerations are the same in
either scenario. If the receiver opts in to payjoining, labeling or
other information can be taken into account when selecting coins. BIP
77 arguably even allows for manual coin control, since the protocol is
async, but personally I'm very skeptical that coin control is an
effective tool for preventing such leaks, not just in the context of
payjoin.
> It could be a workaround or temporary fix for this problem. However, if swapped coins are used in transactions, octojoin could be a better solution which doesn't require any inputs from the recipient.
My point was more that this problem is inherent in any on-chain
payment, i.e. even if a payjoin receiver opts out and does not reveal
a UTXO in the payjoin protocol, they are fairly likely to reveal more
or less the same information in the next transaction.
> The recipient would never doubt a sender who insists on using payjoin and not interested in a normal bitcoin transaction. They would not know the intentions of the sender before payjoin.
I don't follow. What does "never doubt" or "insist" mean? Receivers
signal payjoin support, senders can choose to act on that if they
understand it, and then receivers can choose to opt out, it's only at
this 3rd step that the receiver reveals the information, and this is
true of BIPs 79, 78 and 77.
> It was costless in the demo which could be fixed by bullbitcoin.
...
> or nothing if it's payjoin transaction
Not according to the protocol specifications. Transaction replacement
can only be costless if the attacker controls a majority of the
network hashrate.
Receivers can determine a minimum contribution below which they simply
broadcast the fallback transaction, that sets a cost for the attacker.
Receivers also generate BIP 21 payment request URIs, presumably in
some context, and payjoin proposals bind strongly to those URIs in BIP
77, so the receiver can discern and apply a context dependent policy,
allowing the costs to be reduced if there is indeed trust in the
sender, but that's not required.
> However, an attacker with a budget and some motivation can always spy on your wallet using payjoin. Things become even easier with automated payment systems such as BTCPay Server.
The problem that this particular demonstration shows is that the
bullbitcoin mobile app doesn't yet fully implement the protocol.
Secondly, it's not an automated system, but a manual peer to peer
workflow, so the receiver using the bullbitcoin mobile app would need
to actively and manually participate in facilitating the attack.
Hopefully broadcast of the fallback transaction which enforces
costlessness will be implemented, but the absence of that behavior is
more to do with the beta status of the software, not the lack of
consideration for these attacks in payjoin specifications.
In the automated merchant setting, the policy should be more
conservative, but automatic broadcasting of the fallback transaction
is strongly implied by BIPs 79, 78 and 77.
On Fri, 28 Mar 2025 at 20:45, waxwing/ AdamISZ <ekaggata@gmail•com> wrote:
> 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.
...
> 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".
I agree, this should be made more explicit and the attack model
discussed more clearly, at least in BIP 77.
> 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.
Indeed. Dust attacks (whether targeting CIOH or Coe's old
rebroadcasting behavior) also fall into the same analysis. Sybil
attacks on coinjoins or coinswap scale differently but also ultimately
reduce to some cost...
Nitpicking, because I happened to chase some references recently and
realized I made a similar mistake claiming Ron & Shamir was first:
Reid & Harringan's "An analysis of anonymity in the bitcoin system"
was published in 2011 and already does some analysis based on CIOH.
This is cited by Ron & Shamir's "Quantitative analysis of the full
bitcoin transaction graph", preprint first uploaded in 2012-10-16,
presented in FC'13 (April), where Androulaki et al's "Evaluating user
privacy in Bitcoin" was also published (preprint dates to 2012-10-25).
Miekeljohn et al's fistful of bitcoins paper cites all three of these
works FWIW, and Ron & Shamir also cites Hamacher & Katzenbeisser's
"Bitcoin - An Analysis", presented at 28c3 but afaict there was no
paper published, the presentation also refers to Reid & Harrigan.
--
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/CAAQdECAPmrwF%2BRatk0uxgK9-suqQq8WDS2BbQqT4SNT9wyN%2BQQ%40mail.gmail.com.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: UTXO probing attack using payjoin
2025-03-28 19:28 ` waxwing/ AdamISZ
2025-03-28 23:41 ` Yuval Kogman
@ 2025-03-29 12:34 ` /dev /fd0
1 sibling, 0 replies; 9+ messages in thread
From: /dev /fd0 @ 2025-03-29 12:34 UTC (permalink / raw)
To: waxwing/ AdamISZ; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 12222 bytes --]
Hi waxwing,
> 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.".
> In the blog post on substack, I don't see any discussion of whether the
mitigations proposed make sense. I think they do.
The [mitigations][0] are not good enough:
"While the exposed UTXO will be reused in priority to not leak other UTXOs,
there is no strong guarantee about it. This prevents the attacker from
detecting with certainty the next payjoin of the merchant to another peer."
> 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.
An attacker could use social engineering and ask for multiple payjoin URI
or use different nyms. The adversaries I expect to do this are North Korean
hackers and government agencies.
> I mean, obviously, I don't agree with that.
Personally, I would never use payjoin to accept bitcoin payments or
donations from untrusted people.
> 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.
Agree.
> 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.
I don't think every bitcoin merchant could be a victim of this attack.
However, if you are selling something illegal and accept bitcoin payments
using payjoin, then government agencies might be interested in UTXO probing
attacks.
> 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.
Payjoin makes things easier for the attacker. If this attack wasn't a real
problem, I don't think it would have been mentioned as a significant
drawback in the latest PDK [blog post][1].
[0]:
https://github.com/bitcoin/bips/blob/04b2ec649b2201683e63f651d67d30ee4c1f1a28/bip-0078.mediawiki?plain=1#L377
[1]:
https://payjoindevkit.org/2025/03/18/the-evolution-of-payjoin/#the-limitations-of-two-party-payjoins
/dev/fd0
floppy disk guy
On Sat, Mar 29, 2025 at 1:15 AM waxwing/ AdamISZ <ekaggata@gmail•com> wrote:
> 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
> <https://groups.google.com/d/msgid/bitcoindev/d0a0e344-d777-49bc-8b3c-a3462f0d6836n%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/CALiT-Zr78wh7YTE_qi_wotm-84zShDSPth6W4aaaYNMbLGO0sw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 15348 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: UTXO probing attack using payjoin
2025-03-28 23:41 ` Yuval Kogman
@ 2025-03-29 13:00 ` /dev /fd0
0 siblings, 0 replies; 9+ messages in thread
From: /dev /fd0 @ 2025-03-29 13:00 UTC (permalink / raw)
To: Yuval Kogman; +Cc: waxwing/ AdamISZ, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 8808 bytes --]
Hi Yuval,
> My point was more that this problem is inherent in any on-chain
> payment, i.e. even if a payjoin receiver opts out and does not reveal
> a UTXO in the payjoin protocol, they are fairly likely to reveal more
> or less the same information in the next transaction.
I disagree with this, payjoin requires more information to be shared by the
recipient. Next transaction can be managed by the user in different ways to
avoid privacy issues and labels are helpful.
> I don't follow. What does "never doubt" or "insist" mean? Receivers
> signal payjoin support, senders can choose to act on that if they
> understand it, and then receivers can choose to opt out, it's only at
> this 3rd step that the receiver reveals the information, and this is
> true of BIPs 79, 78 and 77.
3 things that would be required for users to opt-out:
1. Feature implemented in the wallets
2. Knowledge about the trade-offs
3. Due diligence in every payjoin transaction
> Not according to the protocol specifications. Transaction replacement
> can only be costless if the attacker controls a majority of the
> network hashrate.
I mean it would not cost anything extra in terms of the fee already added
in the payjoin transaction.
> Receivers can determine a minimum contribution below which they simply
> broadcast the fallback transaction, that sets a cost for the attacker.
I think this would affect payjoin adoption more than attackers.
> The problem that this particular demonstration shows is that the
> bullbitcoin mobile app doesn't yet fully implement the protocol.
It shows problems with both, the implementation and the protocol used in 2
party payjoin.
> Secondly, it's not an automated system, but a manual peer to peer
> workflow, so the receiver using the bullbitcoin mobile app would need
> to actively and manually participate in facilitating the attack.
I wanted to use testnet.demo.btcpayserver.org in this demo with
bullbitcoin wallet. However, I was unable to use payjoin because of errors.
/dev/fd0
floppy disk guy
On Sat, Mar 29, 2025 at 5:11 AM Yuval Kogman <nothingmuch@woobling•org>
wrote:
> On Wed, 26 Mar 2025 at 20:26, /dev /fd0 <alicexbtong@gmail•com> wrote:
> > Coin control and labels can be used to avoid this. Consolidation of
> inputs is often bad for privacy and makes silent payments, coinjoin etc.
> useless in some cases however the user has the choice to select coins
> manually while transacting. In payjoin, users can't do much about it. They
> have to share UTXOs in response to the original PSBT along with the address
> to receive bitcoin.
>
> In the protocol specifications the receiver is not required to opt-in
> to a payjoin in order to get paid, and can just broadcast transaction
> they receive from the sender. 0 conf considerations are the same in
> either scenario. If the receiver opts in to payjoining, labeling or
> other information can be taken into account when selecting coins. BIP
> 77 arguably even allows for manual coin control, since the protocol is
> async, but personally I'm very skeptical that coin control is an
> effective tool for preventing such leaks, not just in the context of
> payjoin.
>
> > It could be a workaround or temporary fix for this problem. However, if
> swapped coins are used in transactions, octojoin could be a better solution
> which doesn't require any inputs from the recipient.
>
> My point was more that this problem is inherent in any on-chain
> payment, i.e. even if a payjoin receiver opts out and does not reveal
> a UTXO in the payjoin protocol, they are fairly likely to reveal more
> or less the same information in the next transaction.
>
> > The recipient would never doubt a sender who insists on using payjoin
> and not interested in a normal bitcoin transaction. They would not know the
> intentions of the sender before payjoin.
>
> I don't follow. What does "never doubt" or "insist" mean? Receivers
> signal payjoin support, senders can choose to act on that if they
> understand it, and then receivers can choose to opt out, it's only at
> this 3rd step that the receiver reveals the information, and this is
> true of BIPs 79, 78 and 77.
>
> > It was costless in the demo which could be fixed by bullbitcoin.
> ...
> > or nothing if it's payjoin transaction
>
> Not according to the protocol specifications. Transaction replacement
> can only be costless if the attacker controls a majority of the
> network hashrate.
>
> Receivers can determine a minimum contribution below which they simply
> broadcast the fallback transaction, that sets a cost for the attacker.
> Receivers also generate BIP 21 payment request URIs, presumably in
> some context, and payjoin proposals bind strongly to those URIs in BIP
> 77, so the receiver can discern and apply a context dependent policy,
> allowing the costs to be reduced if there is indeed trust in the
> sender, but that's not required.
>
> > However, an attacker with a budget and some motivation can always spy on
> your wallet using payjoin. Things become even easier with automated payment
> systems such as BTCPay Server.
>
> The problem that this particular demonstration shows is that the
> bullbitcoin mobile app doesn't yet fully implement the protocol.
> Secondly, it's not an automated system, but a manual peer to peer
> workflow, so the receiver using the bullbitcoin mobile app would need
> to actively and manually participate in facilitating the attack.
> Hopefully broadcast of the fallback transaction which enforces
> costlessness will be implemented, but the absence of that behavior is
> more to do with the beta status of the software, not the lack of
> consideration for these attacks in payjoin specifications.
>
> In the automated merchant setting, the policy should be more
> conservative, but automatic broadcasting of the fallback transaction
> is strongly implied by BIPs 79, 78 and 77.
>
> On Fri, 28 Mar 2025 at 20:45, waxwing/ AdamISZ <ekaggata@gmail•com> wrote:
> > 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.
> ...
> > 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".
>
> I agree, this should be made more explicit and the attack model
> discussed more clearly, at least in BIP 77.
>
> > 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.
>
> Indeed. Dust attacks (whether targeting CIOH or Coe's old
> rebroadcasting behavior) also fall into the same analysis. Sybil
> attacks on coinjoins or coinswap scale differently but also ultimately
> reduce to some cost...
>
> Nitpicking, because I happened to chase some references recently and
> realized I made a similar mistake claiming Ron & Shamir was first:
> Reid & Harringan's "An analysis of anonymity in the bitcoin system"
> was published in 2011 and already does some analysis based on CIOH.
> This is cited by Ron & Shamir's "Quantitative analysis of the full
> bitcoin transaction graph", preprint first uploaded in 2012-10-16,
> presented in FC'13 (April), where Androulaki et al's "Evaluating user
> privacy in Bitcoin" was also published (preprint dates to 2012-10-25).
> Miekeljohn et al's fistful of bitcoins paper cites all three of these
> works FWIW, and Ron & Shamir also cites Hamacher & Katzenbeisser's
> "Bitcoin - An Analysis", presented at 28c3 but afaict there was no
> paper published, the presentation also refers to Reid & Harrigan.
>
--
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/CALiT-ZrRc3WMiudK4fDj9zs8AJntPBvxRS1%3D510R7QChFfnrCA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 10249 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-03-31 9:43 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-03-25 11:46 [bitcoindev] UTXO probing attack using payjoin /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 ` [bitcoindev] " Yuval Kogman
2025-03-26 19:26 ` /dev /fd0
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox