From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 54CBFC013A for ; Fri, 12 Feb 2021 11:49:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 4327D87428 for ; Fri, 12 Feb 2021 11:49:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3J7WVkb1L3fY for ; Fri, 12 Feb 2021 11:49:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by hemlock.osuosl.org (Postfix) with ESMTPS id 515A687418 for ; Fri, 12 Feb 2021 11:49:56 +0000 (UTC) Received: by mail-wr1-f43.google.com with SMTP id v7so2389344wrr.12 for ; Fri, 12 Feb 2021 03:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KRy3hYnE0PVi9XB8oXxSH6qFT2+j3lLvisMhYqnZses=; b=rDxL5Lc5uD3gr0COtlLN5SsX+S5AhC0IUlrJ5LLe5eA6Am330tSz8qIedZa++8SEj6 3hCVu5HRPrKBWoR7DVn2QzrHLgcX9Hu0ICfyQfyIG6P/FeR91ZTy5aNFPO1GIbRFDC6V 1llF61GWdWPnjp3c5H2ZIGDZLNYWCnV2g62Fu6zX3XiX/0E3nLNDnGQsLiC3nUUquI3p 68gusz7m6sqGhTAH4SnQxKy9uTweD5XqYBfInSNaHGFsNUn/WHu/oUaBVizjqjpJrzcT 50/OchaNl2z2dDwKhdiGxnBL1237jgRV3YTesFsWRtyvdZDV4dA33lsZX8d5tAJm8Ztf pK1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KRy3hYnE0PVi9XB8oXxSH6qFT2+j3lLvisMhYqnZses=; b=BvDGCfS7bmgqn9Lje/o+wngcFkv6K9jTRSDQ9Fma6cEaDAD8N+SWroftIFBxSPjoWg zOjVY2L+vVuYjosJqB9K3og0YRbkPGB3Zodm479Ah90NM/cHUtva8O8G5RA21b/SqBXA xrXvcfPTNlraGo1gOCz/hGE/qZf2BGKALFAFQf69b7BHQ3m9uYiW6Q2ZqLI+uyBzmFh6 CQuddiKE3/kZdQ6ClOF3t3Y9YZZG+fC3PH2yukz2/J+UfvzzDH3frP543Lhi6Wtlm4mH DmvBLlxOAp57WGtgABSUHIZguLGrfcsM5WHOfOw28oCpk9GXwy40mGwvOjLBvMkAcHeX hOMQ== X-Gm-Message-State: AOAM530/t0Oy2/Pb48VOrnkBEdDGcFe+7fW++GJAzKfD6N0ncFC9D5I2 YrfCicKCD3vSIvtF95XHiWAdWoZUyGlN8P+iaBc= X-Google-Smtp-Source: ABdhPJwG8IykI5K9HM9qt1Zp8+MN99ocvSRf1blHQigAwXzcFYnQdozppvl34MQeWpUVgQroMQktg30llAl6xsGdk4k= X-Received: by 2002:a05:6000:104:: with SMTP id o4mr2952511wrx.419.1613130594663; Fri, 12 Feb 2021 03:49:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Fri, 12 Feb 2021 06:49:42 -0500 Message-ID: To: Pieter Wuille Content-Type: multipart/alternative; boundary="000000000000123fc805bb223ca3" X-Mailman-Approved-At: Fri, 12 Feb 2021 12:20:23 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 11:49:57 -0000 --000000000000123fc805bb223ca3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeremy, If I understand correctly your concern, you're worried that change would ease discovery of the node's tx-relay topology ? I don't scope transaction origin inference, if you suppose the unrequested-tx peer sending is the attacker it must have learnt the transaction from somewhere else which is more likely to be the tx owner rather than the probed node. As far I can think of this change, a peer might send an unrequested transaction to this node and observe that it's either a) processed, the node has learnt about the txid from another peer or b) rejected, the node has never learnt about the txid. The outcome can be queried by sending a GETDATA for the "is-unrequested" txid. I think the same result can already be achieved by sending an INV and observing if a GETDATA is replied back to guess the presence of another peer with already the knowledge of the txid. Or alternatively, just connect to this other peer and wait for an announcement. What else can we think of ? >From my side, compared to the already-existing heuristics, I don't see how this change is easing attackers' work. That said, I don't deny our transaction announcements/requests logic is worthy of more study about its privacy properties, especially when you acknowledge the recent overhaul of the transaction request and the upcoming Erlay changes. Cheers, Antoine Le jeu. 11 f=C3=A9vr. 2021 =C3=A0 16:15, Pieter Wuille a =C3=A9crit : > > I'm not sure of the existing behavior is of when we issue a getdata > request, but noting that there could be a privacy implication of this sor= t > of change. Could you (or someone else) expand on why this is not a concer= n > here? > > > What kind of privacy concern are you talking about? I'm not sure I see ho= w > this could matter. > > Cheers, > > -- > Pieter > > --000000000000123fc805bb223ca3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeremy,

If I understand correct= ly your concern, you're worried that change would ease discovery of the= node's tx-relay topology ? I don't scope transaction origin infere= nce, if you suppose the
unrequested-tx peer sending is the attacker it m= ust have learnt the transaction from somewhere else which is more likely to= be the tx owner rather than the probed node.

As far I can think of = this change, a peer might send an unrequested transaction to this node and = observe that it's either a) processed, the node has learnt about the tx= id from another peer or b) rejected, the node has never learnt about the tx= id. The outcome can be queried by sending a GETDATA for the "is-unrequ= ested" txid.

I think the same result can already be achieved by= sending an INV and observing if a GETDATA is replied back to guess the pre= sence of another peer with already the knowledge of the txid. Or alternativ= ely, just connect to this other peer and wait for an announcement.

W= hat else can we think of ?

From my side, compared to the already-ex= isting heuristics, I don't see how this change is easing attackers'= work. That said, I don't deny our transaction announcements/requests l= ogic is worthy of more study about its privacy properties, especially when = you acknowledge the recent overhaul of the transaction request and the upco= ming Erlay changes.

Cheers,
Antoine

Le=C2=A0jeu. 11 f=C3=A9vr. 2021 =C3=A0=C2=A016:15, Pieter Wuille <bitcoin-dev@wuille.net> a =C3= =A9crit=C2=A0:
<= div>
I'= m not sure of the existing behavior is of when we issue a getdata request, = but noting that there could be a privacy implication of this sort of change= . Could you (or someone else) expand on why this is not a concern here?
=

What kind of privacy concern a= re you talking about? I'm not sure I see how this could matter.

Cheers,

--
Pieter

--000000000000123fc805bb223ca3--