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 95452C013A for ; Wed, 13 Jan 2021 06:49:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 7A8C08715D for ; Wed, 13 Jan 2021 06: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 z7bRLhJK2q39 for ; Wed, 13 Jan 2021 06:49:56 +0000 (UTC) X-Greylist: delayed 00:09:49 by SQLgrey-1.7.6 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by hemlock.osuosl.org (Postfix) with ESMTPS id C8EA887153 for ; Wed, 13 Jan 2021 06:49:55 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id C46FF442DE1; Wed, 13 Jan 2021 06:40:03 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; s=1610518862; t=1610520003; bh=bCbLi0KrRDIwgy7dGAUZjtCi+LonTAq+qlKz+sZ+nrw=; h=From:Subject:Date:References:In-Reply-To:To:From; b=Wg6oE8gZaqP+MFBc+3ZZTtVAs5L0YNOD7Fby24Pzh9/gu+ZnGDAOxunpwBNRnoei/ 3Jmo3mUgdbDvvzI88Eo0tPSLWx/5ycTdjS8Ldh0vrYsE4+DYtZjvilvYReGcCjasjJ yK4mUXH8rd9yKnf1MSUMMxIJtLmPXe2CEXR7teW3LOO5q4tlzy1BV5OQCxRLRDWPAI sZnngs/uNOX1WE8ORSLXnbfopeY+DMaocoKZtQPjM3VVqcW59vRvispZrlWkY06ckX PJBpHkNsjlW9zeC6jQ2bEzw94GaQ1EwHWFIZchAJuhJ6U7+LpLGULERjfj2rztzzuj Zk83bETdg6+aw== Content-Type: multipart/alternative; boundary=Apple-Mail-20F0586B-F0E5-485E-897F-2232FAEB9F72 Content-Transfer-Encoding: 7bit From: Matt Corallo Mime-Version: 1.0 (1.0) Date: Wed, 13 Jan 2021 01:40:03 -0500 Message-Id: <10E92E80-75A3-4C45-8CEA-F1EAA2149761@mattcorallo.com> References: In-Reply-To: To: Suhas Daftuar , Bitcoin Protocol Discussion Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 06:49:57 -0000 --Apple-Mail-20F0586B-F0E5-485E-897F-2232FAEB9F72 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Out of curiosity, was the interaction between fRelay and bloom disabling eve= r specified? ie if you aren=E2=80=99t allowed to enable bloom filters on a c= onnection due to resource constraints/new limits, is it ever possible to =E2= =80=9Cset=E2=80=9D fRelay later? Matt > On Jan 6, 2021, at 11:35, Suhas Daftuar via bitcoin-dev wrote: >=20 > =EF=BB=BF > Hi, >=20 > I'm proposing the addition of a new, optional p2p message to allow peers t= o communicate that they do not want to send or receive (loose) transactions f= or the lifetime of a connection.=20 >=20 > The goal of this message is to help facilitate connections on the network o= ver which only block-related data (blocks/headers/compact blocks/etc) are re= layed, to create low-resource connections that help protect against partitio= n attacks on the network. In particular, by adding a network message that c= ommunicates that transactions will not be relayed for the life of the connec= tion, we ease the implementation of software that could have increased inbou= nd connection limits for such peers, which in turn will make it easier to ad= d additional persistent block-relay-only connections on the network -- stren= gthening network security for little additional bandwidth. >=20 > Software has been deployed for over a year now which makes such connection= s, using the BIP37/BIP60 "fRelay" field in the version message to signal tha= t transactions should not be sent initially. However, BIP37 allows for tran= saction relay to be enabled later in the connection's lifetime, complicating= software that would try to distinguish inbound peers that will never relay t= ransactions from those that might. >=20 > This proposal would add a single new p2p message, "disabletx", which (if u= sed at all) must be sent between version and verack. I propose that this me= ssage is valid for peers advertising protocol version 70017 or higher. Soft= ware is free to implement this BIP or ignore this message and remain compati= ble with software that does implement it. >=20 > Full text of the proposed BIP is below. >=20 > Thanks, > Suhas >=20 > --------------------------------------------------- >=20 > 
>   BIP: XXX
>   Layer: Peer Services
>   Title: Disable transaction relay message
>   Author: Suhas Daftuar 
>   Comments-Summary: No comments yet.
>   Comments-URI:
>   Status: Draft
>   Type: Standards Track
>   Created: 2020-09-03
>   License: BSD-2-Clause
>
>=20 > =3D=3DAbstract=3D=3D >=20 > 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. >=20 > =3D=3DMotivation=3D=3D >=20 > 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 mes= sages > received from the peer are ignored by this software. >=20 > 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 no= t > 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 c= arry > out a network partitioning attack (when compared with having such knowledg= e). >=20 > The low-bandwidth / minimal-resource nature of these connections is curren= tly > known only by the initiator of the connection; this is because the transac= tion > relay field in the version message is not a permanent setting for the life= time > of the connection. Consequently, a node receiving an inbound connection w= ith > transaction relay disabled cannot distinguish between a peer that will nev= er > enable transaction relay (as described in BIP 37) and one that will. More= over, > the node also cannot determine that the incoming connection will ignore re= layed > addresses; with that knowledge a node would likely choose other peers to > receive announced addresses instead. >=20 > This proposal adds a new, optional message that a node can send a peer whe= n > initiating a connection to that peer, to indicate that connection should n= ot be > used for transaction-relay for the connection's lifetime. In addition, wit= hout > a current mechanism to negotiate whether addresses should be relayed on a > connection, this BIP suggests that address messages not be sent on links w= here > tx-relay has been disabled. >=20 > =3D=3DSpecification=3D=3D >=20 > # A new disabletx message is added, which is defined as an empty message w= here 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 p= eer 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. I= f 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 mess= age 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). >=20 > =3D=3DCompatibility=3D=3D >=20 > Nodes with protocol version >=3D 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 t= he > disabletx message (provided that BIP 37 or BIP 60 has been implemented), a= nd while > periodic address relay may still take place, software implementing this BI= P > should not be disconnecting such peers solely for that reason. >=20 > Disabling address relay is suggested but not required by this BIP, to allo= w for > future protocol extensions that might specify more carefully how address r= elay > 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 s= uch > future protocol extension, to accommodate existing software behavior. >=20 > Note that all messages specified in BIP 152, including blocktxn and > getblocktxn, are permitted between peers that have sent/received a disable= tx > message, subject to the feature negotiation of BIP 152. >=20 > =3D=3DImplementation=3D=3D >=20 > TBD >=20 > =3D=3DReferences=3D=3D >=20 > # Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 implemen= ted 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. >=20 > =3D=3DCopyright=3D=3D >=20 > This BIP is licensed under the 2-clause BSD license. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-20F0586B-F0E5-485E-897F-2232FAEB9F72 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Out of curiosity, was the i= nteraction between fRelay and bloom disabling ever specified? ie if you aren= =E2=80=99t allowed to enable bloom filters on a connection due to resource c= onstraints/new limits, is it ever possible to =E2=80=9Cset=E2=80=9D fRelay l= ater?

Matt

On Jan 6, 2021, at 11:35, Suhas Daftuar v= ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

<= /blockquote>
=EF=BB=BF
Hi,

I'm proposing the addition of a new, optio= nal p2p message to allow peers to communicate that they do not want to send o= r receive (loose) transactions for the lifetime of a connection. 
=

The goal of this message is to help facilitate conn= ections on the network over which only block-related data (blocks/headers/co= mpact blocks/etc) are relayed, to create low-resource connections that help p= rotect against partition attacks on the network.  In particular, by add= ing a network message that communicates that transactions will not be relaye= d for the life of the connection, we ease the implementation of software tha= t could have increased inbound connection limits for such peers, which in tu= rn will make it easier to add additional persistent block-relay-only connect= ions on the network -- strengthening network security for little additional b= andwidth.

Software has been deployed for over a yea= r now which makes such connections, using the BIP37/BIP60 "fRelay" field in t= he version message to signal that transactions should not be sent initially.=   However, BIP37 allows for transaction relay to be enabled later i= n the connection's lifetime, complicating software that would try to disting= uish 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.&= nbsp; I propose that this message is valid for peers advertising protocol ve= rsion 70017 or higher.  Software is free to implement this BIP or i= gnore this message and remain compatible with software that does implement i= t.

Full text of the proposed BIP is below.

Thanks,
Suhas

--= -------------------------------------------------

<= pre style=3D"color:rgb(0,0,0);white-space:pre-wrap"><pre> BIP: XXX Layer: Peer Services Title: Disable transaction relay message Author: Suhas Daftuar <sdaftu= ar@chaincode.com> 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 pe= er 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 messa= ges 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 car= ry out a network partitioning attack (when compared with having such knowledge)= . The low-bandwidth / minimal-resource nature of these connections is currentl= y known only by the initiator of the connection; this is because the transacti= on relay field in the version message is not a permanent setting for the lifeti= me of the connection. Consequently, a node receiving an inbound connection wit= h transaction relay disabled cannot distinguish between a peer that will never= enable transaction relay (as described in BIP 37) and one that will. Moreov= er, the node also cannot determine that the incoming connection will ignore rela= yed 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, witho= ut a current mechanism to negotiate whether addresses should be relayed on a connection, this BIP suggests that address messages not be sent on links whe= re tx-relay has been disabled. =3D=3DSpecification=3D=3D # A new disabletx message is added, which is defined as an empty message whe= re pchCommand =3D=3D "disabletx". # The protocol version of nodes implementing this BIP must be set to 70017 o= r higher. # If a node sets the transaction relay field in the version message to a pee= r to false, then the disabletx message MAY also be sent in response to a ver= sion 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 verack. # A node that has sent or received a disabletx message to/from a peer MUST N= OT 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 messag= e 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 sp= ecified 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, an= d nodes with protocol version < 70017, will continue to remain compatible with implementing software: transactions would not be relayed to peers sending th= e 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 f= or future protocol extensions that might specify more carefully how address rel= ay 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 su= ch 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. =3D=3DImplementation=3D=3D TBD =3D=3DReferences=3D=3D # Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 implemented this functio= nality] since version 0.19.0.1, released in November 2019. # For example, see https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and <= a href=3D"https://arxiv.org/pdf/1812.00942.pdf">https://arxiv.org/pdf/1812.0= 0942.pdf. =3D=3DCopyright=3D=3D This BIP is licensed under the 2-clause BSD license.
_______________________________________________
bitcoi= n-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /span>
= --Apple-Mail-20F0586B-F0E5-485E-897F-2232FAEB9F72--