path: root/25/13eab81cc44defeaafa70612daa96a7e0227e6

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&#39;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 &quot;fRelay&quot; 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&#39;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, &quot;disabletx&quot;, 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">&lt;pre&gt;
  BIP: XXX
  Layer: Peer Services
  Title: Disable transaction relay message
  Author: Suhas Daftuar &lt;<a href=3D"mailto:sdaftuar@chaincode.com">sdaft=
uar@chaincode.com</a>&gt;
  Comments-Summary: No comments yet.
  Comments-URI:
  Status: Draft
  Type: Standards Track
  Created: 2020-09-03
  License: BSD-2-Clause
&lt;/pre&gt;

=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&#39;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 &quot;disabletx&quot;.
# 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&#39;s protocol version is &gt;=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 &gt;=3D 70017 that do not implement this BIP, a=
nd nodes
with protocol version &lt; 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&#39;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--