diff options
| author | Suhas Daftuar <sdaftuar@gmail.com> | 2021-01-06 11:35:11 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-01-06 16:35:25 +0000 |
| commit | 7fa284146042b4416ccaf9b11e01fffa189d212c (patch) | |
| tree | 71ea79159f98d326d9804da8a7df87727bda2b2e | |
| parent | fc469c026387645598487b3a282c912c4c1f0ab8 (diff) | |
| download | pi-bitcoindev-7fa284146042b4416ccaf9b11e01fffa189d212c.tar.gz pi-bitcoindev-7fa284146042b4416ccaf9b11e01fffa189d212c.zip | |
[bitcoin-dev] Proposal for new "disabletx" p2p message
| -rw-r--r-- | 25/13eab81cc44defeaafa70612daa96a7e0227e6 | 399 |
1 files changed, 399 insertions, 0 deletions
diff --git a/25/13eab81cc44defeaafa70612daa96a7e0227e6 b/25/13eab81cc44defeaafa70612daa96a7e0227e6 new file mode 100644 index 000000000..cc600d2ed --- /dev/null +++ b/25/13eab81cc44defeaafa70612daa96a7e0227e6 @@ -0,0 +1,399 @@ +Return-Path: <sdaftuar@gmail.com> +Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 72B4CC013A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 6 Jan 2021 16:35:25 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by silver.osuosl.org (Postfix) with ESMTP id 56090271D9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 6 Jan 2021 16:35:25 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from silver.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id WgrvN9cF72ky + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 6 Jan 2021 16:35:23 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-io1-f50.google.com (mail-io1-f50.google.com + [209.85.166.50]) + by silver.osuosl.org (Postfix) with ESMTPS id 81616237C8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 6 Jan 2021 16:35:23 +0000 (UTC) +Received: by mail-io1-f50.google.com with SMTP id q137so3278772iod.9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 06 Jan 2021 08:35:23 -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=3DenH7/Uf0PlKrJq2IGt5SD6E5JXKLPdeifPZCTBZ9Q=; + b=LW/cI1NrzBSAT2AiW4kRSnSKR7E6hcsGsM3IvlNg0INv+Jo/fQwhQ32JJYj7lKKQw9 + F8mtWh40904HTan7mT2/3jRryweLFdLKg/mTI0waOs2UfVxgp2FHjzGA85bMYffJOn1Q + nTeXjGsOo+U/OX9WSRxOa9SevhomLSM3D4um5ebWkbGa6E7wpmIguUPFf8iW/+LwddvE + HnU+pR8nY5f+vyis6VxpfmQRGc7XbBw8wMEdVGHBGn3KPsAczdRjdTgC6n3H1+RJog5n + tNUilLDvZzcYK3VKp8DTzqwOupQZvWLiikBEdg5AbSofpTH/WN/LHqAUsccs3SADHC/B + 7e0A== +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=3DenH7/Uf0PlKrJq2IGt5SD6E5JXKLPdeifPZCTBZ9Q=; + b=DGfS8ioW65SKsnWBe74RNMDM54DSP7msdXFn2nouDya0Or9Iiu6AwL8SStKI1MR7VN + fdJu/n248SLpU5BL4arRIXHI6YlryIVpjC/Ya+c0PtXKant75skxPB/9FNTvQfllV0Wm + q3TuG2dyb2DPBY6nD2tr/6sALBd22BpyUn3jB2gp9rvPRRxdLpsS/TDqiW8Kizdo/D3B + C3yECbc1ADA5tlOvWchJiVs7W5MjCgwqVlSv8tpsMCxu/3bV8FGMjL3m9pMdZzvXHdog + 6ePbtbm/4hc+9kdf3S+N/0+iSokJr/qH7hcwlzxH9c6k/mJMOqB3UMWUYeM0Ei8sggMS + 8w9g== +X-Gm-Message-State: AOAM531XEIv0g+6vh7spzPnhtiVILWIjkqX/f2vCd4ErTploqN5KWsSc + BEyg18HCyhz8CJoHZYY2in4GQW8of4DwRI0WkBovKpTxN9k= +X-Google-Smtp-Source: ABdhPJyARXTsXOsa548THp0BSTYWrbImp7JAOe5cOfOTkYcR82rlMmFChW0PwLiKFVYHsE18NWK3YQWFP6Sy2irFLLk= +X-Received: by 2002:a5e:a614:: with SMTP id q20mr3478849ioi.198.1609950922151; + Wed, 06 Jan 2021 08:35:22 -0800 (PST) +MIME-Version: 1.0 +From: Suhas Daftuar <sdaftuar@gmail.com> +Date: Wed, 6 Jan 2021 11:35:11 -0500 +Message-ID: <CAFp6fsE6gb2PaL3ikDRjS-hNnPLjvtWB+8qZJr3trQe2K9YN+g@mail.gmail.com> +To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000d218c805b83de8f8" +Subject: [bitcoin-dev] Proposal for new "disabletx" p2p message +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: Wed, 06 Jan 2021 16:35:25 -0000 + +--000000000000d218c805b83de8f8 +Content-Type: text/plain; charset="UTF-8" + +Hi, + +I'm proposing the addition of a new, optional p2p message to allow peers to +communicate that they do not want to send or receive (loose) transactions +for the lifetime of a connection. + +The goal of this message is to help facilitate connections on the network +over which only block-related data (blocks/headers/compact blocks/etc) are +relayed, to create low-resource connections that help protect against +partition attacks on the network. In particular, by adding a network +message that communicates that transactions will not be relayed for the +life of the connection, we ease the implementation of software that could +have increased inbound connection limits for such peers, which in turn will +make it easier to add additional persistent block-relay-only connections on +the network -- strengthening network security for little additional +bandwidth. + +Software has been deployed for over a year now which makes such +connections, using the BIP37/BIP60 "fRelay" field in the version message to +signal that transactions should not be sent initially. However, BIP37 +allows for transaction relay to be enabled later in the connection's +lifetime, complicating software that would try to distinguish inbound peers +that will never relay transactions from those that might. + +This proposal would add a single new p2p message, "disabletx", which (if +used at all) must be sent between version and verack. I propose that this +message is valid for peers advertising protocol version 70017 or higher. +Software is free to implement this BIP or ignore this message and remain +compatible with software that does implement it. + +Full text of the proposed BIP is below. + +Thanks, +Suhas + +--------------------------------------------------- + +<pre> + BIP: XXX + Layer: Peer Services + Title: Disable transaction relay message + Author: Suhas Daftuar <sdaftuar@chaincode.com> + Comments-Summary: No comments yet. + Comments-URI: + Status: Draft + Type: Standards Track + Created: 2020-09-03 + License: BSD-2-Clause +</pre> + +==Abstract== + +This BIP describes a change to the p2p protocol to allow a node to tell a peer +that a connection will not be used for transaction relay, to support +block-relay-only connections that are currently in use on the network. + +==Motivation== + +For nearly the past year, software has been deployed[1] which initiates +connections on the Bitcoin network and sets the transaction relay field +(introduced by BIP 37 and also defined in BIP 60) to false, to prevent +transaction relay from occurring on the connection. Additionally, addr messages +received from the peer are ignored by this software. + +The purpose of these connections is two-fold: by making additional +low-bandwidth connections on which blocks can propagate, the robustness of a +node to network partitioning attacks is strengthened. Additionally, by not +relaying transactions and ignoring received addresses, the ability of an +adversary to learn the complete network graph (or a subgraph) is reduced[2], +which in turn increases the cost or difficulty to an attacker seeking to carry +out a network partitioning attack (when compared with having such knowledge). + +The low-bandwidth / minimal-resource nature of these connections is currently +known only by the initiator of the connection; this is because the transaction +relay field in the version message is not a permanent setting for the lifetime +of the connection. Consequently, a node receiving an inbound connection with +transaction relay disabled cannot distinguish between a peer that will never +enable transaction relay (as described in BIP 37) and one that will. Moreover, +the node also cannot determine that the incoming connection will ignore relayed +addresses; with that knowledge a node would likely choose other peers to +receive announced addresses instead. + +This proposal adds a new, optional message that a node can send a peer when +initiating a connection to that peer, to indicate that connection should not be +used for transaction-relay for the connection's lifetime. In addition, without +a current mechanism to negotiate whether addresses should be relayed on a +connection, this BIP suggests that address messages not be sent on links where +tx-relay has been disabled. + +==Specification== + +# A new disabletx message is added, which is defined as an empty +message where pchCommand == "disabletx". +# The protocol version of nodes implementing this BIP must be set to +70017 or higher. +# If a node sets the transaction relay field in the version message to +a peer to false, then the disabletx message MAY also be sent in +response to a version message from that peer if the peer's protocol +version is >= 70017. If sent, the disabletx message MUST be sent prior +to sending a verack. +# A node that has sent or received a disabletx message to/from a peer +MUST NOT send any of these messages to the peer: +## inv messages for transactions +## getdata messages for transactions +## getdata messages for merkleblock (BIP 37) +## filteradd/filterload/filterclear (BIP 37) +## mempool (BIP 35) +# It is RECOMMENDED that a node that has sent or received a disabletx +message to/from a peer not send any of these messages to the peer: +## addr/getaddr +## addrv2 (BIP 155) +# The behavior regarding sending or processing other message types is +not specified by this BIP. +# Nodes MAY decide to not remain connected to peers that send this +message (for example, if trying to find a peer that will relay +transactions). + +==Compatibility== + +Nodes with protocol version >= 70017 that do not implement this BIP, and nodes +with protocol version < 70017, will continue to remain compatible with +implementing software: transactions would not be relayed to peers sending the +disabletx message (provided that BIP 37 or BIP 60 has been +implemented), and while +periodic address relay may still take place, software implementing this BIP +should not be disconnecting such peers solely for that reason. + +Disabling address relay is suggested but not required by this BIP, to allow for +future protocol extensions that might specify more carefully how address relay +is to be negotiated. This BIP's recommendations for software to not relay +addresses is intended to be interpreted as guidance in the absence of any such +future protocol extension, to accommodate existing software behavior. + +Note that all messages specified in BIP 152, including blocktxn and +getblocktxn, are permitted between peers that have sent/received a disabletx +message, subject to the feature negotiation of BIP 152. + +==Implementation== + +TBD + +==References== + +# Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 +implemented this functionality] since version 0.19.0.1, released in +November 2019. +# For example, see +https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and +https://arxiv.org/pdf/1812.00942.pdf. + +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + +--000000000000d218c805b83de8f8 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi,<div><br></div><div>I'm proposing the addition of a= + new, optional p2p message to allow peers to communicate that they do not w= +ant to send or receive (loose) transactions for the lifetime of a connectio= +n.=C2=A0</div><div><br></div><div>The goal of this message is to help facil= +itate=C2=A0connections on the network over which only block-related data (b= +locks/headers/compact blocks/etc) are relayed, to create low-resource conne= +ctions that help protect against partition attacks on the network.=C2=A0 In= + particular, by adding a network message that communicates that transaction= +s will not be relayed for the life of the connection, we ease the implement= +ation of software that could have increased inbound connection limits for s= +uch peers, which in turn will make it easier to add additional persistent b= +lock-relay-only connections on the network -- strengthening network securit= +y for little additional bandwidth.</div><div><br></div><div>Software has be= +en deployed for over a year now which makes such connections, using the BIP= +37/BIP60 "fRelay" field in the version message to signal that tra= +nsactions should not be sent initially.=C2=A0 However, BIP37 allows for tra= +nsaction relay to be enabled=C2=A0later in the connection's lifetime, c= +omplicating software that would try to distinguish inbound peers that will = +never relay transactions from those that might.</div><div><br></div><div>Th= +is proposal would add a single new p2p message, "disabletx", whic= +h (if used at all) must be sent between version and verack.=C2=A0 I propose= + that this message is valid for peers advertising protocol version 70017 or= + higher.=C2=A0 Software=C2=A0is free to implement this BIP or ignore this m= +essage and remain compatible with software that does implement it.</div><di= +v><br></div><div>Full text of the proposed BIP is below.</div><div><br></di= +v><div>Thanks,<br></div><div>Suhas<br></div><div><br></div><div>-----------= +----------------------------------------</div><div><br></div><div><pre styl= +e=3D"color:rgb(0,0,0);white-space:pre-wrap"><pre> + BIP: XXX + Layer: Peer Services + Title: Disable transaction relay message + Author: Suhas Daftuar <<a href=3D"mailto:sdaftuar@chaincode.com">sdaft= +uar@chaincode.com</a>> + Comments-Summary: No comments yet. + Comments-URI: + Status: Draft + Type: Standards Track + Created: 2020-09-03 + License: BSD-2-Clause +</pre> + +=3D=3DAbstract=3D=3D + +This BIP describes a change to the p2p protocol to allow a node to tell a p= +eer +that a connection will not be used for transaction relay, to support +block-relay-only connections that are currently in use on the network. + +=3D=3DMotivation=3D=3D + +For nearly the past year, software has been deployed[1] which initiates +connections on the Bitcoin network and sets the transaction relay field +(introduced by BIP 37 and also defined in BIP 60) to false, to prevent +transaction relay from occurring on the connection. Additionally, addr mess= +ages +received from the peer are ignored by this software. + +The purpose of these connections is two-fold: by making additional +low-bandwidth connections on which blocks can propagate, the robustness of = +a +node to network partitioning attacks is strengthened. Additionally, by not +relaying transactions and ignoring received addresses, the ability of an +adversary to learn the complete network graph (or a subgraph) is reduced[2]= +, +which in turn increases the cost or difficulty to an attacker seeking to ca= +rry +out a network partitioning attack (when compared with having such knowledge= +). + +The low-bandwidth / minimal-resource nature of these connections is current= +ly +known only by the initiator of the connection; this is because the transact= +ion +relay field in the version message is not a permanent setting for the lifet= +ime +of the connection. Consequently, a node receiving an inbound connection wi= +th +transaction relay disabled cannot distinguish between a peer that will neve= +r +enable transaction relay (as described in BIP 37) and one that will. Moreo= +ver, +the node also cannot determine that the incoming connection will ignore rel= +ayed +addresses; with that knowledge a node would likely choose other peers to +receive announced addresses instead. + +This proposal adds a new, optional message that a node can send a peer when +initiating a connection to that peer, to indicate that connection should no= +t be +used for transaction-relay for the connection's lifetime. In addition, = +without +a current mechanism to negotiate whether addresses should be relayed on a +connection, this BIP suggests that address messages not be sent on links wh= +ere +tx-relay has been disabled. + +=3D=3DSpecification=3D=3D + +# A new disabletx message is added, which is defined as an empty message wh= +ere pchCommand =3D=3D "disabletx". +# The protocol version of nodes implementing this BIP must be set to 70017 = +or higher. +# If a node sets the transaction relay field in the version message to a pe= +er to false, then the disabletx message MAY also be sent in response to a v= +ersion message from that peer if the peer's protocol version is >=3D= + 70017. If sent, the disabletx message MUST be sent prior to sending a vera= +ck. +# A node that has sent or received a disabletx message to/from a peer MUST = +NOT send any of these messages to the peer: +## inv messages for transactions +## getdata messages for transactions +## getdata messages for merkleblock (BIP 37) +## filteradd/filterload/filterclear (BIP 37) +## mempool (BIP 35) +# It is RECOMMENDED that a node that has sent or received a disabletx messa= +ge to/from a peer not send any of these messages to the peer: +## addr/getaddr +## addrv2 (BIP 155) +# The behavior regarding sending or processing other message types is not s= +pecified by this BIP. +# Nodes MAY decide to not remain connected to peers that send this message = +(for example, if trying to find a peer that will relay transactions). + +=3D=3DCompatibility=3D=3D + +Nodes with protocol version >=3D 70017 that do not implement this BIP, a= +nd nodes +with protocol version < 70017, will continue to remain compatible with +implementing software: transactions would not be relayed to peers sending t= +he +disabletx message (provided that BIP 37 or BIP 60 has been implemented), an= +d while +periodic address relay may still take place, software implementing this BIP +should not be disconnecting such peers solely for that reason. + +Disabling address relay is suggested but not required by this BIP, to allow= + for +future protocol extensions that might specify more carefully how address re= +lay +is to be negotiated. This BIP's recommendations for software to not rel= +ay +addresses is intended to be interpreted as guidance in the absence of any s= +uch +future protocol extension, to accommodate existing software behavior. + +Note that all messages specified in BIP 152, including blocktxn and +getblocktxn, are permitted between peers that have sent/received a disablet= +x +message, subject to the feature negotiation of BIP 152. + +=3D=3DImplementation=3D=3D + +TBD + +=3D=3DReferences=3D=3D + +# Bitcoin Core has [<a href=3D"https://github.com/bitcoin/bitcoin/pull/1575= +9">https://github.com/bitcoin/bitcoin/pull/15759</a> implemented this funct= +ionality] since version 0.19.0.1, released in November 2019. +# For example, see <a href=3D"https://www.cs.umd.edu/projects/coinscope/coi= +nscope.pdf">https://www.cs.umd.edu/projects/coinscope/coinscope.pdf</a> and= + <a href=3D"https://arxiv.org/pdf/1812.00942.pdf">https://arxiv.org/pdf/181= +2.00942.pdf</a>. + +=3D=3DCopyright=3D=3D + +This BIP is licensed under the 2-clause BSD license.</pre></div></div> + +--000000000000d218c805b83de8f8-- + |