Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B9DE3C013A for ; Wed, 10 Feb 2021 13:13:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id AD55085641 for ; Wed, 10 Feb 2021 13:13:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4TwHwpACt05 for ; Wed, 10 Feb 2021 13:13:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 06D3E8623B for ; Wed, 10 Feb 2021 13:13:47 +0000 (UTC) Received: by mail-wr1-f52.google.com with SMTP id u14so2511787wri.3 for ; Wed, 10 Feb 2021 05:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1ATbcOnAUtzz5yAO/5oYVWyZaQrUCTPVp/6PJ1YMFHs=; b=c615QD5tWvep6ospVV3aR09cx/CMVKa9GwLnb4KXrt0jh//QZq6GlD+wyq1HQS6ihu 47ENEBv93E7hZ0PZPvmPGwtyY+le5w7f1mR4CE3X31wo67aADVy5OtUgfHN/3VR9BCff wIl1wHdooG/qDSvquxirsJDpmEhhm3H/UgM2nhIWtyFqqIpLMUlb/R2VDcvUN5Vgtb5j fWIoExZvZKiNglPaiT95qL6OTfh7Jh7CVYsd3lmAOSaToyiBpdKE1vX8LbGjnqQXLANR aaqOtrv2bYcmAyb7s3sIoNsFN1qvIFcbjmU4Zm3aiK/4Cw2XheUXeI3kA01s+i/b2IE3 KXuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1ATbcOnAUtzz5yAO/5oYVWyZaQrUCTPVp/6PJ1YMFHs=; b=GhGRISYFHmxkI96QAdRt91reNZ2xq6gURX0qHd+wzniUomc4OUzSDvEhe6lvELOHfp M2ON5377s3L5R0AGkLVESYtH8Qh3M/G3Ad340gbPBuhWuCuNwEZq4IkOHspaXAWhqqDt fqK0T41XYiLGbW2NKzxscR/2ZiQTzGZ/wH7fSYrMAbnbRh6zOdPVQBHvABpOsAxyphrK 0ryFwH8x0eTm+4G9Ho+23uz5Olf8V4DkTLB3zIQNVpqulVkfkWbo534MI+6JrAhmgeCG XB0RIbbPcW0llnbH0uY428Tu1EnRGtC9a8VTM/OJlxEp5/xneoYOMCJkw5SupQxG2mib d+nA== X-Gm-Message-State: AOAM533+qOD/3l20btv66qor/jn5dppznYnCXK9BTdb28PpW7UNcc9VA Qv1ERtmOC3vrkMAl7+sB7gVCy6sqPej+mCDlGYk5/7L/K9k= X-Google-Smtp-Source: ABdhPJw/1ju9vRydgNVyQbSQQprN4Ucr1e3f9V+I74PfhLwQMLO/wdfsYlDL4pSDfnJ/ucG+ZzLWbCu3u8FcuEYPteQ= X-Received: by 2002:a05:6000:f:: with SMTP id h15mr3704394wrx.148.1612962825288; Wed, 10 Feb 2021 05:13:45 -0800 (PST) MIME-Version: 1.0 From: Antoine Riard Date: Wed, 10 Feb 2021 08:13:34 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000003cc08005bafb2c86" X-Mailman-Approved-At: Wed, 10 Feb 2021 14:19:50 +0000 Subject: [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: Wed, 10 Feb 2021 13:13:53 -0000 --0000000000003cc08005bafb2c86 Content-Type: text/plain; charset="UTF-8" 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 --0000000000003cc08005bafb2c86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm proposing to stop the processing o= f unrequested transactions in Bitcoin Core 22.0+ at TX message reception. A= n unrequested transaction is one defined by which a "getdata" mes= sage for its specific identifier (either txid or wtxid) has not been previo= usly issued by the node [0].

This change is motivated by reducing th= e 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 ban= dwidth and validation resources allocation, or even to wither connections w= ith such DoSy peers. A permissioned peer (PF_RELAY) will still be able to b= ypass such restrictions.

Raw TX message processing has always been t= olerated by Core and as such some Bitcoin clients aren't bothering with= an INV/GETDATA sequence. Such change will break their tx-relay capabilitie= s on the p2p network and require adaptation from them. Given deployment tim= e of any release, I hope it provides a window time wide enough before the o= ld tx-processing behavior becomes the minority.

Eager to gather feed= back on this proposal, especially if such change is deemed as too much cons= training or fast on any Bitcoin software.

Cheers,
Antoine

= [0] See https://g= ithub.com/bitcoin/bitcoin/pull/20277
--0000000000003cc08005bafb2c86--