Delivery-date: Fri, 28 Mar 2025 12:45:25 -0700
Sender: bitcoindev@googlegroups.com
Date: Fri, 28 Mar 2025 12:28:53 -0700 (PDT)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <d0a0e344-d777-49bc-8b3c-a3462f0d6836n@googlegroups.com>
In-Reply-To: <CALiT-Zrq0Nr9uNWDTMj3=VJ6TCcmeL3s+Jau+nEGHqYqFcfB+g@mail.gmail.com>
References: <450755f1-84c5-4f32-abe0-67087ae884d6n@googlegroups.com>
 <1c7130d4-cbac-4404-968c-9eb7b4e2e4cbn@googlegroups.com>
 <CALiT-Zrq0Nr9uNWDTMj3=VJ6TCcmeL3s+Jau+nEGHqYqFcfB+g@mail.gmail.com>
Subject: Re: [bitcoindev] Re: UTXO probing attack using payjoin
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_161136_807255403.1743190133581"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_161136_807255403.1743190133581
Content-Type: multipart/alternative; 
	boundary="----=_Part_161137_1217636125.1743190133581"

------=_Part_161137_1217636125.1743190133581
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi /dev/fd0 and all,

> The original transaction can be replaced by the attacker, and it would=20
only cost a few hundred sats or nothing if it's payjoin transaction. I=20
think such attacks could still be effective if the attacker has the budget=
=20
and motivation to spy on someone's wallet.

That is true but it is also directly addressed with a mitigation in the=20
section on the attack in BIP78; (already linked here but just to repeat:=20
https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#user-content=
-span_idprobingattackspanOn_the_receiver_side_UTXO_probing_attack=20
)

specifically it says "When the receiver detects an original transaction=20
being broadcast, or if the receiver detects that the original transaction=
=20
has been double spent, then they will reuse the UTXO that was exposed for=
=20
the next payjoin.".

However it is unclear whether that's part of the protocol specification, or=
=20
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=20
mitigations proposed make sense. I think they do. Also that blog post=20
discusses altering the sender code to prevent sending the tx. An=20
implementation might differ, but at least in BIP78 it should be the=20
receiver who broadcasts the initial non-payjoin version after a short=20
timeout. That difference connects with the next point also:

One other important thing that is discussed  in BIP78, there is a=20
difference between a "merchant" (or in any case, payment-receiving-server)=
=20
case vs. a peer to peer payments case. In the latter case you cannot simply=
=20
continuously ask for more and more "invoices" (payjoin urls) from the=20
counterparty. In the former case, you certainly can, and the mitigations=20
mentioned make sense there to prevent the "utxo collection" algorithm of=20
continuously failing to complete or double spending, across multiple=20
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=
=20
"receiver broadcasts original after short delay" saying that an expiration=
=20
MAY be set and applied by receivers, which relates ack to the earlier point=
=20
that for a p2p payment arranged with both parties live is not exposed to a=
=20
repeated request attack, hence it may not be needed. I do think it comes=20
back to the "don't change the currently available utxo until it gets used"=
=20
statement in that BIP78 section mentioned above.

With that nuance even your modified-code-sender could be argued not to be=
=20
an issue, though I think I prefer the BIP78 inclusion of "receiver=20
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=20
coins, they can just .. do sender-side actual payjoins, over and over, to=
=20
try to collect utxos. After all the very first blockchain analysis paper by=
=20
Meiklejohn et al focused on exactly this; see how much info you can get by=
=20
actually paying at a merchant.

I think that whether this is a problem or  not is deeply tied to that=20
inevitable conflict between the desire for privacy and the desire for=20
scalability/low cost. To never co-spend utxos means a wallet fragments to=
=20
infinite utxos. But to cospend maximally (as a naive merchant *might* do -=
=20
receive 1000 payments then send all of them at the same time into a cold=20
wallet) wipes out, at least most of the time, the privacy gain from not=20
reusing addresses in the first place. A payjoin based merchant flow, in the=
=20
simplest version, would end up linking the 1000 anyway (think a chain of=20
1000 payjoins with 1 merchant in and 1 merchant out), but with=20
substantially more deniability/lack of certainty at each step in terms of=
=20
both utxo and amount, and never being hit with "huge transaction during fee=
=20
spike". It should at least be *better*.

If those 1000 payjoins were an attacker, he only really learns about the=20
first utxo, if you snowball like that. To "read"  your current wallet, he=
=20
somehow has to pay for a huge range of different amounts to try to entice=
=20
you to spend *different* utxos; it's not easy, but equally it's ridiculous=
=20
to claim that it doesn't leak anything.

Cheers,
AdamISZ/waxwing

On Thursday, March 27, 2025 at 9:19:38=E2=80=AFAM UTC-3 /dev /fd0 wrote:

> Hi jbesraa,
>
> > While the possibility of UTXO probing via Payjoin is a valid concern=20
> regarding privacy, it's important to note that it might not always come=
=20
> without cost for the attacker. The Payjoin recipient > needs to validate=
=20
> the initial request, ensuring the sender's inputs are broadcastable. This=
=20
> means the recipient could, in practice, broadcast the initial transaction=
=20
> even if the sender aborts the > Payjoin.
>
> > Furthermore, implementing strategies like maintaining a set of 'seen=20
> inputs' can make such probing attempts more easily detectable and less=20
> effective.
>
> The original transaction can be replaced by the attacker, and it would=20
> only cost a few hundred sats or nothing if it's payjoin transaction. I=20
> think such attacks could still be effective if the attacker has the budge=
t=20
> and motivation to spy on someone's wallet.
>
> /dev/fd0
> floppy disk guy
>
>
> On Wed, Mar 26, 2025 at 11:54=E2=80=AFPM jbesraa <jbe...@gmail.com> wrote=
:
>
>> While the possibility of UTXO probing via Payjoin is a valid concern=20
>> regarding privacy, it's important to note that it might not always come=
=20
>> without cost for the attacker. The Payjoin recipient needs to validate t=
he=20
>> initial request, ensuring the sender's inputs are broadcastable. This me=
ans=20
>> the recipient could, in practice, broadcast the initial transaction even=
 if=20
>> the sender aborts the Payjoin. Furthermore, implementing strategies like=
=20
>> maintaining a set of 'seen inputs' can make such probing attempts more=
=20
>> easily detectable and less effective. While these measures don't elimina=
te=20
>> the privacy considerations entirely, they do highlight that recipients h=
ave=20
>> potential defenses and that probing isn't necessarily a risk-free endeav=
or=20
>> for the attacker.
>>
>> On Tuesday, March 25, 2025 at 1:48:15=E2=80=AFPM UTC+2 /dev /fd0 wrote:
>>
>> Hi everyone,=20
>>
>> Sometimes we are curious and want to know about UTXOs in other wallets.=
=20
>> Payjoin allows you to do this and the recipient would never doubt it=20
>> because it's a privacy tool. It's possible to find UTXO in recipient's=
=20
>> wallet without sending any bitcoin. It's called UTXO probing attack and=
=20
>> described in BIP 77-78.
>>
>> I have shared a demo with all the details in this [post][0]. I have used=
=20
>> bullbitcoin wallet for testing this because it was the only [wallet][1]=
=20
>> which supports payjoin v2 (send, receive) and testnet3.
>>
>> I think users should be aware of this tradeoff and the information they=
=20
>> share with the sender in payjoin. Payjoin should only be used with trust=
ed=20
>> senders.
>>
>> [0]:=20
>> https://uncensoredtech.substack.com/p/utxo-probing-attack-using-payjoin
>> [1]: https://en.bitcoin.it/wiki/PayJoin_adoption
>>
>> /dev/fd0
>> floppy disk guy
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to bitcoindev+...@googlegroups.com.
>> To view this discussion visit=20
>> https://groups.google.com/d/msgid/bitcoindev/1c7130d4-cbac-4404-968c-9eb=
7b4e2e4cbn%40googlegroups.com=20
>> <https://groups.google.com/d/msgid/bitcoindev/1c7130d4-cbac-4404-968c-9e=
b7b4e2e4cbn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>> .
>>
>

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
d0a0e344-d777-49bc-8b3c-a3462f0d6836n%40googlegroups.com.

------=_Part_161137_1217636125.1743190133581
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>Hi /dev/fd0 and all,</div><div><br /></div><div>&gt; The original tran=
saction can be replaced by the attacker, and it would=20
only cost a few hundred sats or nothing if it's payjoin transaction. I=20
think such attacks could still be effective if the attacker has the=20
budget and motivation to spy on someone's wallet.</div><div><br /></div><di=
v>That is true but it is also directly addressed with a mitigation in the s=
ection on the attack in BIP78; (already linked here but just to repeat: htt=
ps://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#user-content-sp=
an_idprobingattackspanOn_the_receiver_side_UTXO_probing_attack )</div><div>=
<br /></div><div>specifically it says "When the receiver detects an origina=
l transaction being broadcast, or if
 the receiver detects that the original transaction has been double=20
spent, then they will reuse the UTXO that was exposed for the next=20
payjoin.".</div><div><br /></div><div>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.</div><div><br /></div><div>In the blog po=
st on substack, I don't see any discussion of whether the mitigations propo=
sed 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 n=
ext point also:</div><div><br /></div><div>One other important thing that i=
s discussed=C2=A0 in BIP78, there is a difference between a "merchant" (or =
in any case, payment-receiving-server) case vs. a peer to peer payments cas=
e. In the latter case you cannot simply continuously ask for more and more =
"invoices" (payjoin urls) from the counterparty. In the former case, you ce=
rtainly can, and the mitigations mentioned make sense there to prevent the =
"utxo collection" algorithm of continuously failing to complete or double s=
pending, across multiple payment amounts.</div><div><br /></div><div>&gt; I=
t was costless in the demo which could be fixed by bullbitcoin</div><div><b=
r /></div><div>Yeah I see a couple of related things there, BIP77 is more n=
uanced 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 no=
t exposed to a repeated request attack, hence it may not be needed. I do th=
ink it comes back to the "don't change the currently available utxo until i=
t gets used" statement in that BIP78 section mentioned above.</div><div><br=
 /></div><div>With that nuance even your modified-code-sender could be argu=
ed not to be an issue, though I think I prefer the BIP78 inclusion of "rece=
iver broadcasts after an expiration" being a requirement, not a "MAY".</div=
><div><br /></div><div>&gt; Payjoin should only be used with trusted sender=
s.</div><div><br /></div><div>I mean, obviously, I don't agree with that.</=
div><div><br /></div><div>And then there's the 10000ft view: if an attacker=
 doesn't mind spending coins, they can just .. do sender-side actual payjoi=
ns, over and over, to try to collect utxos. After all the very first blockc=
hain analysis paper by Meiklejohn et al focused on exactly this; see how mu=
ch info you can get by actually paying at a merchant.</div><div><br /></div=
><div>I think that whether this is a problem or=C2=A0 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 wa=
llet) wipes out, at least most of the time, the privacy gain from not reusi=
ng addresses in the first place. A payjoin based merchant flow, in the simp=
lest version, would end up linking the 1000 anyway (think a chain of 1000 p=
ayjoins 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 amoun=
t, and never being hit with "huge transaction during fee spike". It should =
at least be *better*.</div><div><br /></div><div>If those 1000 payjoins wer=
e an attacker, he only really learns about the first utxo, if you snowball =
like that. To "read"=C2=A0 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.</div><div><br /></div><div>Cheers,</div><div>AdamISZ/waxwing=
</div><br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_att=
r">On Thursday, March 27, 2025 at 9:19:38=E2=80=AFAM UTC-3 /dev /fd0 wrote:=
<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"=
ltr">Hi jbesraa,<div></div></div><div dir=3D"ltr"><div><br>&gt;=C2=A0While =
the possibility of UTXO probing via Payjoin is a valid concern regarding pr=
ivacy, it&#39;s important to note that it might not always come without cos=
t for the attacker. The Payjoin recipient &gt; needs to validate the initia=
l request, ensuring the sender&#39;s inputs are broadcastable. This means t=
he recipient could, in practice, broadcast the initial transaction even if =
the sender aborts the &gt; Payjoin.<br><br>&gt;=C2=A0Furthermore, implement=
ing strategies like maintaining a set of &#39;seen inputs&#39; can make suc=
h probing attempts more easily detectable and less effective.<br><br></div>=
</div><div dir=3D"ltr"><div>The original transaction can be replaced by the=
 attacker, and it would only cost a few hundred sats or nothing if it&#39;s=
 payjoin transaction. I think such attacks could still be effective if the =
attacker has the budget and motivation to spy on someone&#39;s wallet.</div=
><div><br></div><div>/dev/fd0</div><div>floppy disk guy<br></div><div><br><=
/div></div><br><div class=3D"gmail_quote"></div><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 26, 2025 at 11:54=E2=80=
=AFPM jbesraa &lt;<a href data-email-masked rel=3D"nofollow">jbe...@gmail.c=
om</a>&gt; wrote:<br></div></div><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">While the possibility of UTXO probing vi=
a Payjoin is a valid concern=20
regarding privacy, it&#39;s important to note that it might not always come=
=20
without cost for the attacker. The Payjoin recipient needs to validate=20
the initial request, ensuring the sender&#39;s inputs are broadcastable.=20
This means the recipient could, in practice, broadcast the initial=20
transaction even if the sender aborts the Payjoin. Furthermore,=20
implementing strategies like maintaining a set of &#39;seen inputs&#39; can=
 make
 such probing attempts more easily detectable and less effective. While=20
these measures don&#39;t eliminate the privacy considerations entirely, the=
y
 do highlight that recipients have potential defenses and that probing=20
isn&#39;t necessarily a risk-free endeavor for the attacker.<br><br><div><d=
iv dir=3D"auto">On Tuesday, March 25, 2025 at 1:48:15=E2=80=AFPM UTC+2 /dev=
 /fd0 wrote:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">Hi everyone, <br><br>Some=
times 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&#3=
9;s a privacy tool. It&#39;s possible to find UTXO in recipient&#39;s walle=
t without sending any bitcoin. It&#39;s called UTXO probing attack and desc=
ribed in BIP 77-78.<br><br>I have shared a demo with all the details in thi=
s [post][0]. I have used bullbitcoin wallet for testing this because it was=
 the only [wallet][1] which supports payjoin v2 (send, receive) and testnet=
3.<br><br>I think users should be aware of this tradeoff and the informatio=
n they share with the sender in payjoin. Payjoin should only be used with t=
rusted senders.<br><br>[0]: <a href=3D"https://uncensoredtech.substack.com/=
p/utxo-probing-attack-using-payjoin" rel=3D"nofollow" target=3D"_blank" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://unc=
ensoredtech.substack.com/p/utxo-probing-attack-using-payjoin&amp;source=3Dg=
mail&amp;ust=3D1743274526874000&amp;usg=3DAOvVaw0wLolOGKRzZQnbyCOXEZdP">htt=
ps://uncensoredtech.substack.com/p/utxo-probing-attack-using-payjoin</a><br=
>[1]: <a href=3D"https://en.bitcoin.it/wiki/PayJoin_adoption" rel=3D"nofoll=
ow" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Den&amp;q=3Dhttps://en.bitcoin.it/wiki/PayJoin_adoption&amp;source=3Dgmai=
l&amp;ust=3D1743274526874000&amp;usg=3DAOvVaw0YkPehwJD4ULQZ5hkAlz3U">https:=
//en.bitcoin.it/wiki/PayJoin_adoption</a><br><br>/dev/fd0<br>floppy disk gu=
y</blockquote></div>

<p></p></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@googlegro=
ups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/1c7130d4-cbac-4404-968c-9eb7b4e2e4cbn%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=3D"nofollow" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gro=
ups.google.com/d/msgid/bitcoindev/1c7130d4-cbac-4404-968c-9eb7b4e2e4cbn%254=
0googlegroups.com?utm_medium%3Demail%26utm_source%3Dfooter&amp;source=3Dgma=
il&amp;ust=3D1743274526874000&amp;usg=3DAOvVaw2y1OIOOeaGSVvx7iAWRU-y">https=
://groups.google.com/d/msgid/bitcoindev/1c7130d4-cbac-4404-968c-9eb7b4e2e4c=
bn%40googlegroups.com</a>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/d0a0e344-d777-49bc-8b3c-a3462f0d6836n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/d0a0e344-d777-49bc-8b3c-a3462f0d6836n%40googlegroups.com</a>.<br />

------=_Part_161137_1217636125.1743190133581--

------=_Part_161136_807255403.1743190133581--