Out of curiosity, was the interaction between fRelay and bloom disabling ever specified? ie if you aren’t allowed to enable bloom filters on a connection due to resource constraints/new limits, is it ever possible to “set” fRelay later?
Matt > On Jan 6, 2021, at 11:35, Suhas Daftuar via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > > 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 <sdaft...@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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
