path: root/ef/1c2c557ea50fe578b5e25f76f5c5482d4373c2

Delivery-date: Mon, 31 Mar 2025 02:43:11 -0700
Received: from mail-oa1-f58.google.com ([209.85.160.58])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBJGHVG7QMGQEZRL5KDQ@googlegroups.com>)
	id 1tzBfh-00030J-8x
	for bitcoindev@gnusha.org; Mon, 31 Mar 2025 02:43:11 -0700
Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-2c2e9aab58csf1124278fac.1
        for <bitcoindev@gnusha.org>; Mon, 31 Mar 2025 02:43:09 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1743414183; cv=pass;
        d=google.com; s=arc-20240605;
        b=TCSKPscr7iLr3n5vmD+DovPZF1K8P9xcVAQXpttVfOfvkRQHbrtQapXTy8nzjIOsuB
         aE/z7MjcK/ftBuf9xBruLR3G+sxU4lPBxaHBlz//58IJUQZD4iAcbNQiTBYX5YnEhQWp
         r0b2kz+s0EwkmHrgE6Cl71KPoYIcQ82gGwMKY3o4iQTvQDUbLjNOqR18zrbR83bGCFoQ
         jyIh9pxnBaISxlrN8XAEfpeagZK8deF52xCTLjnZWS/Op+k+cunV4TTufqKUJXerqugE
         RDwv7IL2ZG5QvG4nTAamFpNv/NA1qK68HfYM2BHatjdk2S6xP5iG8pLs1YlDDS21W0D+
         MoDQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=Sky4jzNLwO+RZIiaRpvpswmLA1sElA5SduKIaWwMIQA=;
        fh=SrHi32ojG6alVwtqg8dtkrruY23GJOuB3WNeq802WfY=;
        b=jR0DJhM/MauaDTN++HxXQmiFgEd+ZECzI7hFh5yEcKD0igJcSQr7QaClZwmSlDpYMH
         pmXg++LVzoBrg+1t1ycGpIQtVasBoCYQyOyhh8pZyvrM0/OdqKKCd+ZysfjHBNnqjFCW
         1SjMiIykuLCLnOIblTi3BatSNxU/le3KW0B7SOaOi+TAz7gV682D4uXTg87igOa0TwwE
         QoWacdDydwCjdWwnBjqe6R76E1uyKRKm1nUPGfYrog2Rh9DYlYbE3rvnsh7bF1Dwaem2
         CUqlP1DCfhkAYHteN72tRAO8J3fHamcnJaG84+pEh5O5k3tmH+ElYNEPq0scHh7OITp+
         8/vg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=EqmIYdRY;
       spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::32b as permitted sender) smtp.mailfrom=alicexbtong@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1743414183; x=1744018983; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Sky4jzNLwO+RZIiaRpvpswmLA1sElA5SduKIaWwMIQA=;
        b=aMzv355bzCZV5YwkJB8nVIRmMmqwpnnmE60CDjfoUnp7CbTjy3CVyswv9vMn2+OAuY
         EK95huPnkPsxxD/GZVPBquZhRIZ/9gc7ga6MxVd9Orbl7EaXJGbduMyLdPvLUcdmDD0u
         IUL7f1gIkHEIXMSWL1JFryfysBcNLzouQtFUiZ1hAdm31NCX7YonKjkJmWzJxvEuF5Bv
         0mwl/7X7PqoKkA7qW0lokeTDbimSM5U355+h8XGG5MO/CsqkVnns4AHTY/lW8yPgaMSj
         yjS33z6/1fjz2Bz4SXIOl7xtyjzhPnAQQeLlGIHOpuPmwJoRHH6EhJLsrDNYkqiVDOHl
         fRFA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1743414183; x=1744018983; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Sky4jzNLwO+RZIiaRpvpswmLA1sElA5SduKIaWwMIQA=;
        b=TtVZuTA/MRFPhf7hREsre4wRx10pnobVJ6iTQiWl8NDsD70WPRogRea2+kiyPzb8c8
         CRSaBlQ2EshwpbtiMA+WBj8EfYQPjlT/okAMHqJqE5FqZqe4/L//Wju6RDewj98d0wM+
         P2y7JrNhPfvAgLc59afOHk95z9INNwdHBFeb7gb9eoJtqPAsqE+EZha41Lt/HA1AnVcA
         gU1VcfWWqhtuOd2fp8xrJ8rGCjoXqtc1O5VKZO91K1DWm6Ph5znibS8treXV702EboEV
         iQZr5vcgJ+zdi1d+sCFi04AZHPVhsqCZKj+dkvAjaz7HB2usi+Od9Kv2biIKaq+C/mpe
         p8Uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1743414183; x=1744018983;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=Sky4jzNLwO+RZIiaRpvpswmLA1sElA5SduKIaWwMIQA=;
        b=raEaUZlfLcyrxD5Yze4DBCzA3+LoJvNfkGLX0z3KT5uc0qmUQeHTl5L646mEfZitdj
         BB30ugpUqphbN7Tcs6OXrxUGDMk7QRp57e+lQFfde5VfhqHWi6BDxjrE9e9FnVomWLJ1
         PG4ANX/viSm7cCzmoloi3Hv+JF6CaeK04acvKOuzrQi3aNwfVLUoIdvh+ZCxBtzma0+l
         OCZSHBY2CuHBBCwrly60BzJLVXLS+z5x+MwWwf5PlrDzOTHO87S1CUB+FeT8W86v6CoJ
         bMpGUHSwTWkwajE8+RBdjMM+UmaiknN0vo1CAbFLjVebZKRd3TmN7HSiP46j7NbeJJGC
         ArgA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVeEuPJfuXVv7gnzjK7hyPWByT2fLXxx7viYe+Grc8OT7KppPVCuHY2LJudnmXRPbK3ovrw2E5IyDRh@gnusha.org
X-Gm-Message-State: AOJu0YzJTOrnGWGFuVokWWEkdquSfHdUYdn9AJxAot1TRywQeVatVuxL
	qwdZpOJHv7cnhigk/vtf0Bclvsfu+ByXMXIoiKAWQdXSFBZPP1bC
X-Google-Smtp-Source: AGHT+IHf1o/olvU41wKh1xNBlg96YyjQJtdRypJmaqzQdLkwI4PKIIsbH1fxqacteHsd0TsAVgJrHw==
X-Received: by 2002:a05:6870:2e0e:b0:2c2:3d33:836f with SMTP id 586e51a60fabf-2cbcf755f8amr5214281fac.27.1743414182972;
        Mon, 31 Mar 2025 02:43:02 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAL+LauGFYCdNZh+HoMb3EBHRTIU4zZKyDC3u0hS9c+1eQ==
Received: by 2002:a05:6871:b14:b0:2c2:3dd8:d41e with SMTP id
 586e51a60fabf-2c846b1402cls299972fac.0.-pod-prod-04-us; Mon, 31 Mar 2025
 02:43:00 -0700 (PDT)
X-Received: by 2002:a05:6808:f12:b0:3fb:6fd7:fe84 with SMTP id 5614622812f47-3ff0f50343fmr4362049b6e.12.1743414180299;
        Mon, 31 Mar 2025 02:43:00 -0700 (PDT)
Received: by 2002:a05:6808:2797:b0:3f6:a384:eb6f with SMTP id 5614622812f47-3feef8f0f2dmsb6e;
        Sat, 29 Mar 2025 05:34:12 -0700 (PDT)
X-Received: by 2002:a05:6870:56a9:b0:2c6:72d3:fc93 with SMTP id 586e51a60fabf-2cbcf4fbc68mr1253516fac.12.1743251651356;
        Sat, 29 Mar 2025 05:34:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1743251651; cv=none;
        d=google.com; s=arc-20240605;
        b=Aizo/DQKuuUx7B2B98wksNY1y6+l8uzSv73AxZNErv5MllBZkFT4iYcXOFXHgb+oNz
         LmpaOUjmvDXDK8b/wWTepbpjxIq0PgJJy0MONnqM6lsTdpZTVHMKsWxrKiA2/WTWE8mw
         MSCNllR0guoQYPt0S+R/kssMO6e9S3rABoBsOyOQ9eVTFuGoGiQAKUDWjnbw/G5oNruq
         LUIBurzaeAAdCswl7Gjv7TFaq1mdsH1nBxuWCgHkD1uOR8PYjL0/X4gs4BPHlDV+YrOA
         IEUS4SckXDh1BseFeZbU4RWDaOrDbS5g/Ve9eVF/NchYmVkAZkzy8/MU3d+6QvJkwcFi
         P3jw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=iJzsy9f1NWhfhqEx9xuP/Gw86UR/XKi78vkF+Lf0Fuo=;
        fh=zfrgopOiIZUyW/QOQMW3tlf+B0T0p2fpIoXRbxgb3Y8=;
        b=BYffvlFgElcEMd+0+UfhleBZDGWqFSFNa+T02nCSlYvHuWS2btYI9Aku+akYOzTtsv
         bB9qzK4Q6p56x+oa43cuDC+GN2lFvh/WsG9a6s0JYdj/DHt4HPmxTXKn/BC5VpNbBKjA
         LU4fgDc2uet20cRCe8F/tP5ba30hjDSo81V31hjWR67x89xNchpd6KosylObJd495RGd
         XDV2Kx0Oobqh/IQIuRPvgWIu+BI47vksxx4XVY2VvjX9HPqfXvn44E+N48W0La22W+0+
         VuS+TEIJqK3Wxy+2gSyz7BRXzQXtiNfDgO34HYkuHjddbXTLemIBzMHSBBmsXtF0IRQH
         crbg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=EqmIYdRY;
       spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::32b as permitted sender) smtp.mailfrom=alicexbtong@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com. [2607:f8b0:4864:20::32b])
        by gmr-mx.google.com with ESMTPS id 46e09a7af769-72c58153046si183513a34.4.2025.03.29.05.34.11
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 29 Mar 2025 05:34:11 -0700 (PDT)
Received-SPF: pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::32b as permitted sender) client-ip=2607:f8b0:4864:20::32b;
Received: by mail-ot1-x32b.google.com with SMTP id 46e09a7af769-72c40235c34so871427a34.3
        for <bitcoindev@googlegroups.com>; Sat, 29 Mar 2025 05:34:11 -0700 (PDT)
X-Gm-Gg: ASbGncsOZqgmDIz7HvKmRREkfh1EBNqjutjLjEuA5SjKAceQ0Y2vFZnL3mdu0ispb4f
	NPmq0deRZ8niUVhoUrXn1EHpu8o+0rTrBGmPP6FdAbHXIcUA09Sudj77miO9njk1i9u38z3cG7O
	q47pW/MMdNUyLPuV050qh7NstWbAYaLLeYtxuKnFkpsw==
X-Received: by 2002:a05:6830:6101:b0:72b:9d5e:941c with SMTP id
 46e09a7af769-72c637ace9emr1747517a34.13.1743251650917; Sat, 29 Mar 2025
 05:34:10 -0700 (PDT)
MIME-Version: 1.0
References: <450755f1-84c5-4f32-abe0-67087ae884d6n@googlegroups.com>
 <1c7130d4-cbac-4404-968c-9eb7b4e2e4cbn@googlegroups.com> <CALiT-Zrq0Nr9uNWDTMj3=VJ6TCcmeL3s+Jau+nEGHqYqFcfB+g@mail.gmail.com>
 <d0a0e344-d777-49bc-8b3c-a3462f0d6836n@googlegroups.com>
In-Reply-To: <d0a0e344-d777-49bc-8b3c-a3462f0d6836n@googlegroups.com>
From: "/dev /fd0" <alicexbtong@gmail.com>
Date: Sat, 29 Mar 2025 18:04:04 +0530
X-Gm-Features: AQ5f1Jr2uTBKorQy9AfC8awRTBg-F755hsYA7AJepjqkJba08pCE5JHaOzQ9hGo
Message-ID: <CALiT-Zr78wh7YTE_qi_wotm-84zShDSPth6W4aaaYNMbLGO0sw@mail.gmail.com>
Subject: Re: [bitcoindev] Re: UTXO probing attack using payjoin
To: "waxwing/ AdamISZ" <ekaggata@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000683aa106317a67b3"
X-Original-Sender: alicexbtong@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=EqmIYdRY;       spf=pass
 (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::32b
 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--000000000000683aa106317a67b3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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/04b2ec649b2201683e63f651d67d30ee4c1f1a=
28/bip-0078.mediawiki?plain=3D1#L377
[1]:
https://payjoindevkit.org/2025/03/18/the-evolution-of-payjoin/#the-limitati=
ons-of-two-party-payjoins

/dev/fd0
floppy disk guy

On Sat, Mar 29, 2025 at 1:15=E2=80=AFAM waxwing/ AdamISZ <ekaggata@gmail.co=
m> 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 budge=
t
> 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-conte=
nt-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 simp=
ly
> 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 expiratio=
n
> MAY be set and applied by receivers, which relates ack to the earlier poi=
nt
> 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 b=
y
> 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 t=
he
> 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 f=
ee
> 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 ridiculou=
s
> 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
>> 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. Thi=
s
>> means the recipient could, in practice, broadcast the initial transactio=
n
>> 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 budg=
et
>> 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> wrot=
e:
>>
>>> 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 m=
eans
>>> the recipient could, in practice, broadcast the initial transaction eve=
n if
>>> the sender aborts the Payjoin. Furthermore, implementing strategies lik=
e
>>> maintaining a set of 'seen inputs' can make such probing attempts more
>>> easily detectable and less effective. While these measures don't elimin=
ate
>>> the privacy considerations entirely, they do highlight that recipients =
have
>>> potential defenses and that probing isn't necessarily a risk-free endea=
vor
>>> for the attacker.
>>>
>>> On Tuesday, March 25, 2025 at 1:48:15=E2=80=AFPM 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 use=
d
>>> 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 trus=
ted
>>> 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-9e=
b7b4e2e4cbn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/1c7130d4-cbac-4404-968c-9=
eb7b4e2e4cbn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>> .
>>>
>> --
> 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-a346=
2f0d6836n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/d0a0e344-d777-49bc-8b3c-a34=
62f0d6836n%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/=
CALiT-Zr78wh7YTE_qi_wotm-84zShDSPth6W4aaaYNMbLGO0sw%40mail.gmail.com.

--000000000000683aa106317a67b3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi waxwing,<div><br></div><div>&gt; 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: <a href=3D"https://github.c=
om/bitcoin/bips/blob/master/bip-0078.mediawiki#user-content-span_idprobinga=
ttackspanOn_the_receiver_side_UTXO_probing_attack">https://github.com/bitco=
in/bips/blob/master/bip-0078.mediawiki#user-content-span_idprobingattackspa=
nOn_the_receiver_side_UTXO_probing_attack</a> )</div>&gt; specifically it s=
ays &quot;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.=
&quot;.<br>&gt;=C2=A0In the blog post on substack, I don&#39;t see any disc=
ussion of whether the mitigations proposed make sense. I think they do. <di=
v><br></div><div>The [mitigations][0] are not good enough:</div><div><br></=
div><div>&quot;While the exposed UTXO will be reused in priority to not lea=
k other UTXOs, there is no strong guarantee about it. This prevents the att=
acker from detecting with certainty the next payjoin of the merchant to ano=
ther peer.&quot;</div><div><br></div><div>&gt;=C2=A0One other important thi=
ng that is discussed =C2=A0in BIP78, there is a difference between a &quot;=
merchant&quot; (or in any case, payment-receiving-server) case vs. a peer t=
o peer payments case. In the latter case you cannot simply continuously ask=
 for more and more &quot;invoices&quot; (payjoin urls) from the counterpart=
y. </div><div><br></div><div>An attacker could use social engineering and a=
sk for multiple payjoin URI or use different nyms. The adversaries=C2=A0I e=
xpect to do this are North Korean hackers and government agencies.</div><di=
v><br></div><div>&gt;=C2=A0I mean, obviously, I don&#39;t agree with that.<=
/div><div><br></div><div>Personally, I would never use payjoin to accept bi=
tcoin payments or donations from untrusted people.</div><div><br></div><div=
>&gt;=C2=A0And then there&#39;s the 10000ft view: if an attacker doesn&#39;=
t mind spending coins, they can just .. do sender-side actual payjoins, ove=
r and over, to try to collect utxos.</div><div><br></div><div>Agree.</div><=
div><br></div><div>&gt;=C2=A0I think that whether this is a problem or =C2=
=A0not is deeply tied to that inevitable conflict between the desire for pr=
ivacy and the desire for scalability/low cost. To never co-spend utxos mean=
s a wallet fragments to infinite utxos. </div><div>&gt;=C2=A0But to cospend=
 maximally (as a naive merchant *might* do - receive 1000 payments then sen=
d 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 plac=
e.</div><div><br></div><div>I don&#39;t think every bitcoin merchant could =
be a victim of this attack. However, if you are selling something illegal a=
nd accept bitcoin payments using payjoin, then government agencies might be=
 interested=C2=A0in UTXO probing attacks.<br><br>&gt;=C2=A0To &quot;read&qu=
ot; =C2=A0your current wallet, he somehow has to pay for a huge range of di=
fferent amounts to try to entice you to spend *different* utxos; it&#39;s n=
ot easy, but equally it&#39;s ridiculous to claim that it doesn&#39;t leak =
anything.</div><div><br></div><div>Payjoin makes things easier for the atta=
cker. If this attack=C2=A0wasn&#39;t a real problem, I don&#39;t think it w=
ould have been mentioned as a significant drawback in the latest PDK [blog =
post][1].=C2=A0</div><div><br></div><div>[0]:=C2=A0<a href=3D"https://githu=
b.com/bitcoin/bips/blob/04b2ec649b2201683e63f651d67d30ee4c1f1a28/bip-0078.m=
ediawiki?plain=3D1#L377">https://github.com/bitcoin/bips/blob/04b2ec649b220=
1683e63f651d67d30ee4c1f1a28/bip-0078.mediawiki?plain=3D1#L377</a></div><div=
>[1]:=C2=A0<a href=3D"https://payjoindevkit.org/2025/03/18/the-evolution-of=
-payjoin/#the-limitations-of-two-party-payjoins">https://payjoindevkit.org/=
2025/03/18/the-evolution-of-payjoin/#the-limitations-of-two-party-payjoins<=
/a><br><br>/dev/fd0</div><div>floppy disk guy</div></div><br><div class=3D"=
gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Sat, Mar 29, 2025 at 1:15=E2=80=AFAM waxwing/ AdamISZ &lt;<a href=3D"mailt=
o:ekaggata@gmail.com">ekaggata@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div>Hi /dev/fd0 and all,</div><div=
><br></div><div>&gt; The original transaction can be replaced by the attack=
er, and it would=20
only cost a few hundred sats or nothing if it&#39;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&#39;s wallet.</div><div><br></div><=
div>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: <=
a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#us=
er-content-span_idprobingattackspanOn_the_receiver_side_UTXO_probing_attack=
" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0078.me=
diawiki#user-content-span_idprobingattackspanOn_the_receiver_side_UTXO_prob=
ing_attack</a> )</div><div><br></div><div>specifically it says &quot;When t=
he receiver detects an original 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.&quot;.</div><div><br></div><div>However it is unclear whether that=
&#39;s part of the protocol specification, or whether it should be. So ther=
e&#39;s at least something to discuss there.</div><div><br></div><div>In th=
e blog post on substack, I don&#39;t see any discussion of whether the miti=
gations proposed make sense. I think they do. Also that blog post discusses=
 altering the sender code to prevent sending the tx. An implementation migh=
t differ, but at least in BIP78 it should be the receiver who broadcasts th=
e initial non-payjoin version after a short timeout. That difference connec=
ts with the next point also:</div><div><br></div><div>One other important t=
hing that is discussed=C2=A0 in BIP78, there is a difference between a &quo=
t;merchant&quot; (or in any case, payment-receiving-server) case vs. a peer=
 to peer payments case. In the latter case you cannot simply continuously a=
sk for more and more &quot;invoices&quot; (payjoin urls) from the counterpa=
rty. In the former case, you certainly can, and the mitigations mentioned m=
ake sense there to prevent the &quot;utxo collection&quot; algorithm of con=
tinuously failing to complete or double spending, across multiple payment a=
mounts.</div><div><br></div><div>&gt; It was costless in the demo which cou=
ld be fixed by bullbitcoin</div><div><br></div><div>Yeah I see a couple of =
related things there, BIP77 is more nuanced on the &quot;receiver broadcast=
s original after short delay&quot; saying that an expiration MAY be set and=
 applied by receivers, which relates ack to the earlier point that for a p2=
p payment arranged with both parties live is not exposed to a repeated requ=
est attack, hence it may not be needed. I do think it comes back to the &qu=
ot;don&#39;t change the currently available utxo until it gets used&quot; s=
tatement in that BIP78 section mentioned above.</div><div><br></div><div>Wi=
th that nuance even your modified-code-sender could be argued not to be an =
issue, though I think I prefer the BIP78 inclusion of &quot;receiver broadc=
asts after an expiration&quot; being a requirement, not a &quot;MAY&quot;.<=
/div><div><br></div><div>&gt; Payjoin should only be used with trusted send=
ers.</div><div><br></div><div>I mean, obviously, I don&#39;t agree with tha=
t.</div><div><br></div><div>And then there&#39;s the 10000ft view: if an at=
tacker doesn&#39;t mind spending coins, they can just .. do sender-side act=
ual payjoins, over and over, to try to collect utxos. After all the very fi=
rst blockchain analysis paper by Meiklejohn et al focused on exactly this; =
see how much 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 de=
sire for scalability/low cost. To never co-spend utxos means a wallet fragm=
ents to infinite utxos. But to cospend maximally (as a naive merchant *migh=
t* 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 n=
ot 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 o=
f 1000 payjoins with 1 merchant in and 1 merchant out), but with substantia=
lly more deniability/lack of certainty at each step in terms of both utxo a=
nd amount, and never being hit with &quot;huge transaction during fee spike=
&quot;. It should at least be *better*.</div><div><br></div><div>If those 1=
000 payjoins were an attacker, he only really learns about the first utxo, =
if you snowball like that. To &quot;read&quot;=C2=A0 your current wallet, h=
e somehow has to pay for a huge range of different amounts to try to entice=
 you to spend *different* utxos; it&#39;s not easy, but equally it&#39;s ri=
diculous to claim that it doesn&#39;t leak anything.</div><div><br></div><d=
iv>Cheers,</div><div>AdamISZ/waxwing</div><br><div class=3D"gmail_quote"><d=
iv dir=3D"auto" class=3D"gmail_attr">On Thursday, March 27, 2025 at 9:19:38=
=E2=80=AFAM UTC-3 /dev /fd0 wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 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 privacy, it&#39;s important to note that it mi=
ght not always come without cost for the attacker. The Payjoin recipient &g=
t; needs to validate the initial request, ensuring the sender&#39;s inputs =
are broadcastable. This means the recipient could, in practice, broadcast t=
he initial transaction even if the sender aborts the &gt; Payjoin.<br><br>&=
gt;=C2=A0Furthermore, implementing strategies like maintaining a set of &#3=
9;seen inputs&#39; can make such probing attempts more easily detectable an=
d less effective.<br><br></div></div><div dir=3D"ltr"><div>The original tra=
nsaction can be replaced by the attacker, and it would only cost a few hund=
red sats or nothing if it&#39;s payjoin transaction. I think such attacks c=
ould still be effective if the attacker has the budget and motivation to sp=
y on someone&#39;s wallet.</div><div><br></div><div>/dev/fd0</div><div>flop=
py 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 rel=3D"nofollow">jbe...@g=
mail.com</a>&gt; wrote:<br></div></div><div class=3D"gmail_quote"><blockquo=
te class=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 prob=
ing via 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">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">https://en.bitcoin.it/wiki/PayJoin_adoption</a><br><b=
r>/dev/fd0<br>floppy disk guy</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 rel=3D"nofollow">bitcoindev+...@googlegroups.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" rel=3D"nofollow" target=3D"_blank">htt=
ps://groups.google.com/d/msgid/bitcoindev/1c7130d4-cbac-4404-968c-9eb7b4e2e=
4cbn%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" target=
=3D"_blank">bitcoindev+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&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/d0a0e344-d777-49bc-8b3c-a3462f0d6836n%40googlegrou=
ps.com</a>.<br>
</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/CALiT-Zr78wh7YTE_qi_wotm-84zShDSPth6W4aaaYNMbLGO0sw%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CALiT-Zr78wh7YTE_qi_wotm-84zShDSPth6W4aaaYNMbLGO0sw%40mail.g=
mail.com</a>.<br />

--000000000000683aa106317a67b3--