From: Yuval Kogman <nothingmuch@woobling•org>
To: "waxwing/ AdamISZ" <ekaggata@gmail•com>,
"/dev /fd0" <alicexbtong@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: UTXO probing attack using payjoin
Date: Sat, 29 Mar 2025 00:41:34 +0100 [thread overview]
Message-ID: <CAAQdECAPmrwF+Ratk0uxgK9-suqQq8WDS2BbQqT4SNT9wyN+QQ@mail.gmail.com> (raw)
In-Reply-To: <d0a0e344-d777-49bc-8b3c-a3462f0d6836n@googlegroups.com>
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.
next prev parent reply other threads:[~2025-03-29 0:02 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
2025-03-28 23:41 ` Yuval Kogman [this message]
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=CAAQdECAPmrwF+Ratk0uxgK9-suqQq8WDS2BbQqT4SNT9wyN+QQ@mail.gmail.com \
--to=nothingmuch@woobling$(echo .)org \
--cc=alicexbtong@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=ekaggata@gmail$(echo .)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