path: root/4b/b4afad671269453ada8f851802623132b3ea9f

Return-Path: <jlrubin@mit.edu>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 83729C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 18:29:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 7592C875C9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 18:29:50 +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 OKoq29s0OUEG
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 18:29:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 64D12875C7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 18:29:49 +0000 (UTC)
Received: from mail-io1-f53.google.com (mail-io1-f53.google.com
 [209.85.166.53]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11BITlsf009582
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 11 Feb 2021 13:29:47 -0500
Received: by mail-io1-f53.google.com with SMTP id u8so6670528ior.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 10:29:47 -0800 (PST)
X-Gm-Message-State: AOAM532GdROK83qLl5ZenNgAGTNpz19+36Dotw4A4qXe3GX+dNDRGowe
 cD47JPGoNp3YtmAJ4DNK9CCfzEWIrTC0RCvHDWA=
X-Google-Smtp-Source: ABdhPJyCY2Rz9j1q31Sd8uqCfsj+hb4IMNSzRBRns66GyMT2kUchUBFJlxjhUvNIGOuXourKDvbBJTUCmvI90+s2Djs=
X-Received: by 2002:a02:c98b:: with SMTP id b11mr9945682jap.123.1613068187182; 
 Thu, 11 Feb 2021 10:29:47 -0800 (PST)
MIME-Version: 1.0
References: <CALZpt+E6UqB5cew145PO2qiEMsELJ-TuGyE5PBL04T1tESiOiQ@mail.gmail.com>
In-Reply-To: <CALZpt+E6UqB5cew145PO2qiEMsELJ-TuGyE5PBL04T1tESiOiQ@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Thu, 11 Feb 2021 10:29:35 -0800
X-Gmail-Original-Message-ID: <CAD5xwhjGsB38otK5+H30XcnFnUdP+D29_k5=p2ZBgXzvdRRggw@mail.gmail.com>
Message-ID: <CAD5xwhjGsB38otK5+H30XcnFnUdP+D29_k5=p2ZBgXzvdRRggw@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004bac3d05bb13b4b8"
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Feb 2021 18:29:50 -0000

--0000000000004bac3d05bb13b4b8
Content-Type: text/plain; charset="UTF-8"

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?
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Wed, Feb 10, 2021 at 6:29 AM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> I'm proposing to stop the processing of unrequested transactions in
> Bitcoin Core 22.0+ at TX message reception. An unrequested transaction is
> one defined by which a "getdata" message for its specific identifier
> (either txid or wtxid) has not been previously issued by the node [0].
>
> This change is motivated by reducing the CPU DoS surface of Bitcoin Core
> around mempool acceptance. Currently, an attacker can open multiple inbound
> connections to a node and send expensive to validate, junk transactions.
> Once the canonical INV/GETDATA sequence is enforced on the network, a
> further protection would be to deprioritize bandwidth and validation
> resources allocation, or even to wither connections with such DoSy peers. A
> permissioned peer (PF_RELAY) will still be able to bypass such restrictions.
>
> Raw TX message processing has always been tolerated by Core and as such
> some Bitcoin clients aren't bothering with an INV/GETDATA sequence. Such
> change will break their tx-relay capabilities on the p2p network and
> require adaptation from them. Given deployment time of any release, I hope
> it provides a window time wide enough before the old tx-processing behavior
> becomes the minority.
>
> Eager to gather feedback on this proposal, especially if such change is
> deemed as too much constraining or fast on any Bitcoin software.
>
> Cheers,
> Antoine
>
> [0] See https://github.com/bitcoin/bitcoin/pull/20277
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">I&#39;m not sure of the e=
xisting behavior is of when we issue a getdata request, but noting that the=
re could be a privacy implication of this sort of change. Could you (or som=
eone else) expand on why this is not a concern here?</div><div><div dir=3D"=
ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank=
">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_bl=
ank"></a></div></div></div><br></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Wed, Feb 10, 2021 at 6:29 AM Antoine Riar=
d via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><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"><div dir=3D"ltr"><div>Hi,<br><br>I=
&#39;m proposing to stop the processing of unrequested transactions in Bitc=
oin Core 22.0+ at TX message reception. An unrequested transaction is one d=
efined by which a &quot;getdata&quot; message for its specific identifier (=
either txid or wtxid) has not been previously issued by the node [0].<br><b=
r>This change is motivated by reducing the CPU DoS surface of Bitcoin Core =
around mempool acceptance. Currently, an attacker can open multiple inbound=
 connections to a node and send expensive to validate, junk transactions. O=
nce the canonical INV/GETDATA sequence is enforced on the network, a furthe=
r protection would be to deprioritize bandwidth and validation resources al=
location, or even to wither connections with such DoSy peers. A permissione=
d peer (PF_RELAY) will still be able to bypass such restrictions.<br><br>Ra=
w TX message processing has always been tolerated by Core and as such some =
Bitcoin clients aren&#39;t bothering with an INV/GETDATA sequence. Such cha=
nge will break their tx-relay capabilities on the p2p network and require a=
daptation from them. Given deployment time of any release, I hope it provid=
es a window time wide enough before the old tx-processing behavior becomes =
the minority.<br><br>Eager to gather feedback on this proposal, especially =
if such change is deemed as too much constraining or fast on any Bitcoin so=
ftware.<br><br>Cheers,<br>Antoine<br><br>[0] See <a href=3D"https://github.=
com/bitcoin/bitcoin/pull/20277" target=3D"_blank">https://github.com/bitcoi=
n/bitcoin/pull/20277</a><br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000004bac3d05bb13b4b8--