path: root/e9/017539aeb0d9081e058194ad1a8cb8571af8a3

Delivery-date: Mon, 31 Mar 2025 02:43:25 -0700
Received: from mail-oa1-f55.google.com ([209.85.160.55])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBM6HVG7QMGQETE72F6I@googlegroups.com>)
	id 1tzBfv-00030w-HK
	for bitcoindev@gnusha.org; Mon, 31 Mar 2025 02:43:25 -0700
Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-2c7ece3d81dsf1116797fac.3
        for <bitcoindev@gnusha.org>; Mon, 31 Mar 2025 02:43:23 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1743414198; cv=pass;
        d=google.com; s=arc-20240605;
        b=X3a/0rdr18a6+6BcNdTy7C4xONAKOlQ1hD8fJ0cxmZurjbmOQtzCViQtCJypxggxAH
         FJOoZuQrHdg8NSCEyYmPcpCVJvaxxDPf7ITipwFyPcIMI9p21/XtsHIhRcdYdeLJt/dn
         NCqqCw/165VusU/CWe3eluRiaGz+mMPViRQk8K+Z8YwepEc+3ZR8/pZoJ6yQk24VUA0D
         A4WKyIrQkYjwiqfKq9qDD7pBwobM2Ei0WzerzGKrHPSk39ZMXWmC4SAJ8K9DzPjG1XeV
         LyDh/TsUhXHb5qewvXIFPVNKAggCoDVSslT19NI/NKATKalkbNp31iwAVu7ktX+BG83u
         wiFQ==
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=dtr6meJdI9yKfXEADQltRDH8RWPSeDUr48j3RpG0o/o=;
        fh=g32EEySr/ub/Khr6WSX36S+CmEaDKPXtp8HpbiNoOk8=;
        b=YC2sAzQT4NGxTvf5dio662dQxIDoERtfj1j5sy5szHOITYfnGJxrIkWcKu60Rg4Ofi
         bUQJprjKu4YKYvcyydy0Iug6E3XS++aJMe2/bexHF+XfUUEIK7yx1+4soy0MEldJ0bUX
         L67TcFMHpAb4VYuzZvzNbeJ5XCMWPA3QmKAFKg+2z0KqeNDhZf7pdIM0nZkVOBBhVx3u
         M9qnzfTiNnWlYWYB1ciakNuOyV3Y5/V9iQDvSQ2XV+u4CtsDkkFMyQPR+F+/f+KK6HwN
         EH6q6Q7JBZSpqBxW49VnoTTd/797RdzkEUpnUg7WR2TTYLmA7JFG8yI4sxt9ZhyZBAKC
         /GIQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=PePDmlHM;
       spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c2b 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=1743414198; x=1744018998; 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=dtr6meJdI9yKfXEADQltRDH8RWPSeDUr48j3RpG0o/o=;
        b=DZ1iAdeuOoxsTGzDOs4zLEsvGXthz2C5skeyz6XlKOMJruVFQCt3RQVMIrhnQNNa1P
         +BDjK6T+468xO0Yi1Y5WiEfedMtbbk9hAjOdIX9u0zMkVOT7Osm9cKP8xebI/pAVoFcU
         SX8qchi9HgyxszNwaWfSXSdEfJoy9CyaAtzIqrkXmdpI/NZZx/BIs2/QsO+iL6MNKlGG
         2IbbEyLHFRVQOdlYG86Vqa93PhocwovpyBsc+KT4W74uD6vNeEuH38QNFBYLkLKhe2TY
         6QTZdHxP/PiCmuNzWf2FXFS2wJ7xAeYbvF9kawSqIaYvir+7Fp1Xvvi+0LlBhnbLkKD1
         FmIA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1743414198; x=1744018998; 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=dtr6meJdI9yKfXEADQltRDH8RWPSeDUr48j3RpG0o/o=;
        b=m6vErMZHYgXALoEQIZrq1eG3jPrF1p9fMPpEw6ZigKMOs9q+1x+joML06DEN+IP5hc
         qR5MWS4oMkkPLk03XVNpOwLSKaOHFMNGGmwW3bNJ4KdVQC18E98pzyI9Rz/LHIpfmrgq
         ntoJ4ipKi06eXC5Aimlc5qu/dh15yBbLEvRH3l3RPr/+QPRwoDCN81txIv2IONpjXrGx
         VtGMEIBhGL4AgxVJ1+dAblI+CZEPFVeI7VS519ksMk+PELvM+DHVVB8V/a/mCVilFFJt
         iG4s/YmFvsYIKg8EY7+hqqSUadFLvj/LrNtq68hjTfqkBX9QjN2vKHZ844myL+PeBerA
         jIqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1743414198; x=1744018998;
        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=dtr6meJdI9yKfXEADQltRDH8RWPSeDUr48j3RpG0o/o=;
        b=XMfylM9iJOlqAmfgKrV2SkPdr0bcpuxxDKj1KbRJOcHE65bYaxdXuu9MnMayQx+q1F
         vM7m7yAXTM3fr8g8TJ+KKNjt3EpY+V4TYnQ0lpDtbwzfWZbq6th2tyIHX/l7droJrwQJ
         j7fCIeng1+VSBCSwUiVFpHJvjVuioPYmwX+Wml2/ElO9QqyypAyPOG8DYE1MrUuOSY/X
         yIGqFcX82geFU7qF7+AakZuDRLynlVKqOSovdgM6Lv0BLtLnu07MeVRYcHs2XPxHnoi+
         Se2gtxkgwIQnTjTvDrkpeEP+8YQcfwwmctCoPhXPmPU3YkV25c1ZsrdJnTK0k84aTzJb
         HsSg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCW+8wTAgaBh8g+fydCpM3UZV3D0hq77NgDNHxrfI/ttqUcVujBJT7V0kBrr75Sf5OUMKO4t4KARAOwi@gnusha.org
X-Gm-Message-State: AOJu0Yw2iuNERtyfKD8MBCBc8U7rUNT94QD2M673gYtprwgYK1LbDyBZ
	qz3JXCgQplzVn1+NZWGAd8om344N4UQWL6nSBDhOLirh7Yh7wZPt
X-Google-Smtp-Source: AGHT+IHX3TKBY4pQiLx/yUVi/0gaxq/+UfG2HipwnIGA+Ue5l/ME7QxFT1zwpgde0MIMG+fFwaT2wA==
X-Received: by 2002:a05:6871:14f:b0:2c2:d2b8:e1ab with SMTP id 586e51a60fabf-2cbcf56d56dmr4377886fac.18.1743414197720;
        Mon, 31 Mar 2025 02:43:17 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJVWPUxcNas7CrzXa8DH6shO80fagkjX2HBSCl7TWnz9A==
Received: by 2002:a05:6870:4691:b0:2c1:3442:67b9 with SMTP id
 586e51a60fabf-2c846fd7353ls249182fac.2.-pod-prod-04-us; Mon, 31 Mar 2025
 02:43:15 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUu9awXYODMIizQj57bbP7uxdD2eLX+Yv8HtMuhh5pHaF4e7s53fweUn3z89THt7ix9Q/Mi4q82qi1F@googlegroups.com
X-Received: by 2002:a05:6830:7002:b0:72b:a61c:cbb2 with SMTP id 46e09a7af769-72c6378e768mr5571709a34.10.1743414195024;
        Mon, 31 Mar 2025 02:43:15 -0700 (PDT)
Received: by 2002:a05:6808:2797:b0:3f6:a384:eb6f with SMTP id 5614622812f47-3feef8f0f2dmsb6e;
        Sat, 29 Mar 2025 06:00:46 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVABEKwQW+zm9M4UZ7j5tPzW8zBDKoxIL0b446cq72tza7Bgzn147XTJENUiGiLggfG3fE/nN87+F64@googlegroups.com
X-Received: by 2002:a05:6808:1a12:b0:3f6:a889:59c6 with SMTP id 5614622812f47-3ff0f60fa3emr1348528b6e.26.1743253246280;
        Sat, 29 Mar 2025 06:00:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1743253246; cv=none;
        d=google.com; s=arc-20240605;
        b=ikDikjupoRlzerckVRWB0T1SuGY/jGrE0OM7I4yI4hNSM9LjoIfpPCnmBFs0RuXfbl
         CYzTQ5qjrVCWUzbtU4ni75GbnN9E7VLxA1P8jv0bIDBzNr0m+SwEtVc1xtv2DrTYAfRP
         Upaw2IZsk9mfI3UDaizTpYIuiridj794mFVjv5rBKqFZ8rQKXgyv35fGSG8dyFBynZzw
         TA9/cW6a8Ae8fbp+3QReXQdHQ55YQwG4ChZnlQF9ck4ikAjj8AXw52WQH8L+v4c5F4Fk
         JTwqX45b0DPLi2prqm5xpcxqPNQ4uYWvBPv0uwlK/6ZYebNNybbcdj4GikmcH1nekMlq
         EFuA==
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=FHy9WaDELi+Z5K6fhF+mp8aoNrU0LWXsb0LKi+TlZsE=;
        fh=PyxRnfJw1KCqUBRpzBU79/ozrHxyjFasuMZ6vjyOB3Q=;
        b=TZIuDOQXzHXlqKTnRNnwsF1ijcHjQIzDcF1+4BCQ6YIf35eyun4tX1eoxgifD1eHHa
         5vvo9n/CXRYHO3PoJYgeYuHM1rCFkrY0VZNr1zEvO15RDU5KpBEpyWxVeaEy8ruwv+sW
         dRGzVr9vR87VFu/VrVm4d1iu5ebk7l3PrKhye9cNIvF/vYCZvpxj7GMOXkImtpBRx4P2
         JSQeiZaoHuNIgt6Z4dk+RFxjlA7jTOEdFYzfslfbArQW+l1XMje2JiJRiwlzyYRb+UrO
         CnSfjDH7asd2aZpsfaShPCN9BqdTZhVNZA4O61x5QEJs1ime7E0HDeKVo8NaJHJHeyna
         dNjw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=PePDmlHM;
       spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c2b 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-oo1-xc2b.google.com (mail-oo1-xc2b.google.com. [2607:f8b0:4864:20::c2b])
        by gmr-mx.google.com with ESMTPS id 5614622812f47-3ff0516772bsi196596b6e.1.2025.03.29.06.00.46
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 29 Mar 2025 06:00:46 -0700 (PDT)
Received-SPF: pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c2b as permitted sender) client-ip=2607:f8b0:4864:20::c2b;
Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-601c469cce3so760192eaf.2
        for <bitcoindev@googlegroups.com>; Sat, 29 Mar 2025 06:00:46 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCXA/m2xy5lEMsy9Gn72XxFFsPIGn+xmgYI72uEoWFb0WeiachQqdA44UHdagKKK1rHe6LM3HInYZlzb@googlegroups.com
X-Gm-Gg: ASbGnctmNNykE6nO4rwvL1FlEmTkj3D764Na4s6Dj+E8R7OBvH2hfH80a1XaertmJJD
	4hIM98wqII8oTXARThBEnjojEHKoKQl1aGgHHddAigheYLeNVqH5SbdTg1Wko6aqUcUBjnD1zZl
	muuxt3do20sf2OJ7sHqDBbAbAsTyrmgGpDKtAAc2rL4A==
X-Received: by 2002:a4a:ee86:0:b0:5fe:9edb:eafe with SMTP id
 006d021491bc7-60290f5ad9fmr1132443eaf.5.1743253245849; Sat, 29 Mar 2025
 06:00:45 -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> <CAAQdECAPmrwF+Ratk0uxgK9-suqQq8WDS2BbQqT4SNT9wyN+QQ@mail.gmail.com>
In-Reply-To: <CAAQdECAPmrwF+Ratk0uxgK9-suqQq8WDS2BbQqT4SNT9wyN+QQ@mail.gmail.com>
From: "/dev /fd0" <alicexbtong@gmail.com>
Date: Sat, 29 Mar 2025 18:30:39 +0530
X-Gm-Features: AQ5f1Jr5SyqbC6SijM2LEVW8odIiGWMVr4Kv2ebfEIm5cMCp0MMhhzRAgL6KX5A
Message-ID: <CALiT-ZrRc3WMiudK4fDj9zs8AJntPBvxRS1=510R7QChFfnrCA@mail.gmail.com>
Subject: Re: [bitcoindev] Re: UTXO probing attack using payjoin
To: Yuval Kogman <nothingmuch@woobling.org>
Cc: "waxwing/ AdamISZ" <ekaggata@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="00000000000078fab306317ac616"
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=PePDmlHM;       spf=pass
 (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c2b
 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 (/)

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

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=E2=80=AFAM 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. The=
y
> have to share UTXOs in response to the original PSBT along with the addre=
ss
> 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 soluti=
on
> 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 t=
he
> 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 o=
n
> your wallet using payjoin. Things become even easier with automated payme=
nt
> 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 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.
> ...
> > 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 b=
y
> 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.
>

--=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-ZrRc3WMiudK4fDj9zs8AJntPBvxRS1%3D510R7QChFfnrCA%40mail.gmail.com.

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

<div dir=3D"ltr">Hi Yuval,<div><br></div><div>&gt; My point was more that t=
his problem is inherent in any on-chain</div>&gt; payment, i.e. even if a p=
ayjoin receiver opts out and does not reveal<br>&gt; a UTXO in the payjoin =
protocol, they are fairly likely to reveal more<br>&gt; or less the same in=
formation in the next transaction.<br><br>I disagree with this, payjoin req=
uires 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.<div><br></div><div>&gt; I don&#39;t follow. What does &quot;n=
ever doubt&quot; or &quot;insist&quot; mean? Receivers</div>&gt; signal pay=
join support, senders can choose to act on that if they<br>&gt; understand =
it, and then receivers can choose to opt out, it&#39;s only at<br>&gt; this=
 3rd step that the receiver reveals the information, and this is<br>&gt; tr=
ue of BIPs 79, 78 and 77.<br><br>3 things that would be required for users =
to opt-out:<br><div><br></div><div>1. Feature implemented in the wallets</d=
iv><div>2. Knowledge about the trade-offs</div><div>3. Due diligence in eve=
ry payjoin transaction</div><div><br></div><div>&gt; Not according to the p=
rotocol specifications. Transaction replacement</div>&gt; can only be costl=
ess if the attacker controls a majority of the<br>&gt; network hashrate.<br=
><br>I mean it would not cost anything extra in terms of the fee already ad=
ded in the payjoin transaction.<div><br></div><div>&gt; Receivers can deter=
mine a minimum contribution below which they simply</div>&gt; broadcast the=
 fallback transaction, that sets a cost for the attacker.<br><br>I think th=
is would affect payjoin adoption more than attackers.<div><br></div><div>&g=
t; The problem that this particular demonstration shows is that the</div>&g=
t; bullbitcoin mobile app doesn&#39;t yet fully implement the protocol.<br>=
<br>It shows problems with both, the implementation and the protocol used i=
n 2 party payjoin.<div><br></div><div>&gt; Secondly, it&#39;s not an automa=
ted system, but a manual peer to peer</div>&gt; workflow, so the receiver u=
sing the bullbitcoin mobile app would need<br>&gt; to actively and manually=
 participate in facilitating the attack.<div><br></div><div>I wanted to use=
=C2=A0<a href=3D"http://testnet.demo.btcpayserver.org">testnet.demo.btcpays=
erver.org</a>=C2=A0in this demo with bullbitcoin=C2=A0wallet. However, I wa=
s unable to use payjoin because of errors.</div><div><br></div><div>/dev/fd=
0</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 5:11=E2=80=AFAM Yuval Kogman &lt;<a href=3D"mailto:nothingmuch@woobling=
.org">nothingmuch@woobling.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">On Wed, 26 Mar 2025 at 20:26, /dev /fd0 &lt;<=
a href=3D"mailto:alicexbtong@gmail.com" target=3D"_blank">alicexbtong@gmail=
.com</a>&gt; wrote:<br>
&gt; Coin control and labels can be used to avoid this. Consolidation of in=
puts is often bad for privacy and makes silent payments, coinjoin etc. usel=
ess in some cases however the user has the choice to select coins manually =
while transacting. In payjoin, users can&#39;t do much about it. They have =
to share UTXOs in response to the original PSBT along with the address to r=
eceive bitcoin.<br>
<br>
In the protocol specifications the receiver is not required to opt-in<br>
to a payjoin in order to get paid, and can just broadcast transaction<br>
they receive from the sender. 0 conf considerations are the same in<br>
either scenario. If the receiver opts in to payjoining, labeling or<br>
other information can be taken into account when selecting coins. BIP<br>
77 arguably even allows for manual coin control, since the protocol is<br>
async, but personally I&#39;m very skeptical that coin control is an<br>
effective tool for preventing such leaks, not just in the context of<br>
payjoin.<br>
<br>
&gt; It could be a workaround or temporary fix for this problem. However, i=
f swapped coins are used in transactions, octojoin could be a better soluti=
on which doesn&#39;t require any inputs from the recipient.<br>
<br>
My point was more that this problem is inherent in any on-chain<br>
payment, i.e. even if a payjoin receiver opts out and does not reveal<br>
a UTXO in the payjoin protocol, they are fairly likely to reveal more<br>
or less the same information in the next transaction.<br>
<br>
&gt; 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.<br>
<br>
I don&#39;t follow. What does &quot;never doubt&quot; or &quot;insist&quot;=
 mean? Receivers<br>
signal payjoin support, senders can choose to act on that if they<br>
understand it, and then receivers can choose to opt out, it&#39;s only at<b=
r>
this 3rd step that the receiver reveals the information, and this is<br>
true of BIPs 79, 78 and 77.<br>
<br>
&gt; It was costless in the demo which could be fixed by bullbitcoin.<br>
...<br>
&gt; or nothing if it&#39;s payjoin transaction<br>
<br>
Not according to the protocol specifications. Transaction replacement<br>
can only be costless if the attacker controls a majority of the<br>
network hashrate.<br>
<br>
Receivers can determine a minimum contribution below which they simply<br>
broadcast the fallback transaction, that sets a cost for the attacker.<br>
Receivers also generate BIP 21 payment request URIs, presumably in<br>
some context, and payjoin proposals bind strongly to those URIs in BIP<br>
77, so the receiver can discern and apply a context dependent policy,<br>
allowing the costs to be reduced if there is indeed trust in the<br>
sender, but that&#39;s not required.<br>
<br>
&gt; However, an attacker with a budget and some motivation can always spy =
on your wallet using payjoin. Things become even easier with automated paym=
ent systems such as BTCPay Server.<br>
<br>
The problem that this particular demonstration shows is that the<br>
bullbitcoin mobile app doesn&#39;t yet fully implement the protocol.<br>
Secondly, it&#39;s not an automated system, but a manual peer to peer<br>
workflow, so the receiver using the bullbitcoin mobile app would need<br>
to actively and manually participate in facilitating the attack.<br>
Hopefully broadcast of the fallback transaction which enforces<br>
costlessness will be implemented, but the absence of that behavior is<br>
more to do with the beta status of the software, not the lack of<br>
consideration for these attacks in payjoin specifications.<br>
<br>
In the automated merchant setting, the policy should be more<br>
conservative, but automatic broadcasting of the fallback transaction<br>
is strongly implied by BIPs 79, 78 and 77.<br>
<br>
On Fri, 28 Mar 2025 at 20:45, waxwing/ AdamISZ &lt;<a href=3D"mailto:ekagga=
ta@gmail.com" target=3D"_blank">ekaggata@gmail.com</a>&gt; wrote:<br>
&gt; One other important thing that is discussed=C2=A0 in BIP78, there is a=
 difference between a &quot;merchant&quot; (or in any case, payment-receivi=
ng-server) case vs. a peer to peer payments case. In the latter case you ca=
nnot simply continuously ask for more and more &quot;invoices&quot; (payjoi=
n urls) from the counterparty. In the former case, you certainly can, and t=
he mitigations mentioned make sense there to prevent the &quot;utxo collect=
ion&quot; algorithm of continuously failing to complete or double spending,=
 across multiple payment amounts.<br>
...<br>
&gt; 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 &quot;receiver=
 broadcasts after an expiration&quot; being a requirement, not a &quot;MAY&=
quot;.<br>
<br>
I agree, this should be made more explicit and the attack model<br>
discussed more clearly, at least in BIP 77.<br>
<br>
&gt; And then there&#39;s the 10000ft view: if an attacker doesn&#39;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 c=
an get by actually paying at a merchant.<br>
<br>
Indeed. Dust attacks (whether targeting CIOH or Coe&#39;s old<br>
rebroadcasting behavior) also fall into the same analysis. Sybil<br>
attacks on coinjoins or coinswap scale differently but also ultimately<br>
reduce to some cost...<br>
<br>
Nitpicking, because I happened to chase some references recently and<br>
realized I made a similar mistake claiming Ron &amp; Shamir was first:<br>
Reid &amp; Harringan&#39;s &quot;An analysis of anonymity in the bitcoin sy=
stem&quot;<br>
was published in 2011 and already does some analysis based on CIOH.<br>
This is cited by Ron &amp; Shamir&#39;s &quot;Quantitative analysis of the =
full<br>
bitcoin transaction graph&quot;, preprint first uploaded in 2012-10-16,<br>
presented in FC&#39;13 (April), where Androulaki et al&#39;s &quot;Evaluati=
ng user<br>
privacy in Bitcoin&quot; was also published (preprint dates to 2012-10-25).=
<br>
Miekeljohn et al&#39;s fistful of bitcoins paper cites all three of these<b=
r>
works FWIW, and Ron &amp; Shamir also cites Hamacher &amp; Katzenbeisser&#3=
9;s<br>
&quot;Bitcoin - An Analysis&quot;, presented at 28c3 but afaict there was n=
o<br>
paper published, the presentation also refers to Reid &amp; Harrigan.<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-ZrRc3WMiudK4fDj9zs8AJntPBvxRS1%3D510R7QChFfnrCA%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CALiT-ZrRc3WMiudK4fDj9zs8AJntPBvxRS1%3D510R7QChFfnrCA%40ma=
il.gmail.com</a>.<br />

--00000000000078fab306317ac616--