[bitcoin-dev] Proposal for new "disabletx" p2p message

[bitcoin-dev] Proposal for new "disabletx" p2p message

[Suhas Daftuar]

[-- Attachment #1: Type: text/plain, Size: 6862 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 7562 bytes --]

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 7772 bytes --]

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 <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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 8451 bytes --]

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[Anthony Towns]

On Wed, Jan 13, 2021 at 01:40:03AM -0500, Matt Corallo via bitcoin-dev wrote:
> 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?

(Maybe I'm missing something, but...)

In the current bitcoin implementation, no -- you either set
m_tx_relay->fRelayTxes to true via the VERSION message (either explicitly
or by not setting fRelay), or you enable it later with FILTERLOAD or
FILTERCLEAR, both of which will cause a disconnect if bloom filters
aren't supported. Bloom filter support is (optionally?) indicated via
a service bit (BIP 111), so you could assume you know whether they're
supported as soon as you receive the VERSION line.

fRelay is specified in BIP 37 as:

  | 1 byte || fRelay || bool || If false then broadcast transactions will
  not be announced until a filter{load,add,clear} command is received. If
  missing or true, no change in protocol behaviour occurs.

BIP 60 defines the field as "relay" and references BIP 37. Don't think
it's referenced in any other bips.

Cheers,
aj

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[Matt Corallo]

So we’d kill two birds with one stone if all bloom support was dropped. As far as I understand, precomputed filters are now provided via p2p connections as well.

Matt

> On Jan 14, 2021, at 00:33, Anthony Towns <aj@erisian.com.au> wrote:
> 
> On Wed, Jan 13, 2021 at 01:40:03AM -0500, Matt Corallo via bitcoin-dev wrote:
>> 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?
> 
> (Maybe I'm missing something, but...)
> 
> In the current bitcoin implementation, no -- you either set
> m_tx_relay->fRelayTxes to true via the VERSION message (either explicitly
> or by not setting fRelay), or you enable it later with FILTERLOAD or
> FILTERCLEAR, both of which will cause a disconnect if bloom filters
> aren't supported. Bloom filter support is (optionally?) indicated via
> a service bit (BIP 111), so you could assume you know whether they're
> supported as soon as you receive the VERSION line.
> 
> fRelay is specified in BIP 37 as:
> 
>  | 1 byte || fRelay || bool || If false then broadcast transactions will
>  not be announced until a filter{load,add,clear} command is received. If
>  missing or true, no change in protocol behaviour occurs.
> 
> BIP 60 defines the field as "relay" and references BIP 37. Don't think
> it's referenced in any other bips.
> 
> Cheers,
> aj
> 

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[Anthony Towns]

On Wed, Jan 06, 2021 at 11:35:11AM -0500, Suhas Daftuar via bitcoin-dev wrote:
> 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.

I think we should separate these ideas -- ie, the protocol change to
allow indicating that you don't want transactions, and the policy change
to protect against partition attacks using that protocol addition.

The idea (obviously?) being that the protocol should be simple and
flexible enough to support many possible policies.

> ==Specification==
> # A new disabletx message is added, [...]
> # 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
> [...]
> # 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)

In particular, I think combining these doesn't make sense for:

 * nodes running with -blocksonly (that want to stay up to date with
   the blockchain, but don't care about txes)
    - not sending disabletx reduces their potential connectivity, if
      nodes are willing to accept more disabletx peers due to the lower
      resource usage
    - sending disabletx means they can't maintain their addr db and find
      other nodes to connect to

 * non-listening nodes running with -connect to one/more preselected peers
    - they can't send disabletx generally because they want txes
    - they don't need addr information (since they only make connections
      to some known peers), and don't have many peers to relay addresses
      on to, so are essentially blackholes, so would like to disable
      addr relay for much the same reasons

So to me that says the protocol part of the design's not as flexible as
it should be, which suggests DISABLETX and DISABLEADDR.

(I think I'm going to flesh out the "FEATURE" idea as an alternative
way of dealing with this, but that can be its own thread)

Cheers,
aj

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[Suhas Daftuar]

[-- Attachment #1: Type: text/plain, Size: 7085 bytes --]

On Thu, Jan 14, 2021 at 1:46 AM Anthony Towns <aj@erisian.com.au> wrote:

> > ==Specification==
> > # A new disabletx message is added, [...]
> > # 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
> > [...]
> > # 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)
>
> In particular, I think combining these doesn't make sense for:
>
>  * nodes running with -blocksonly (that want to stay up to date with
>    the blockchain, but don't care about txes)
>     - not sending disabletx reduces their potential connectivity, if
>       nodes are willing to accept more disabletx peers due to the lower
>       resource usage
>     - sending disabletx means they can't maintain their addr db and find
>       other nodes to connect to
>

This is quite implementation specific, but the Bitcoin Core implementation
of -blocksonly already differs from what you would get if all outbound
connections were treated as block-relay-only peers; I initially tried to
make the -blocksonly setting behave the same as block-relay-only
connections and never relay transactions, but it turned out that Bitcoin
Core currently allows users running in -blocksonly mode to sometimes relay
transactions themselves (there's even a test for it [1]).

This isn't compatible with the design of disabletx, so I don't think it
could be used.  I think that is okay, as I don't think we need to make
allowances right now to encourage the use of more -blocksonly nodes on the
network by prioritizing their existing outbound connections[2]. In the case
of block-relay-only connections, the next step I plan to propose in the
Bitcoin Core implementation is an increase in the number of inbound slots
to accommodate additional disabletx peers, to facilitate an eventual
increase in the number of outbound block-relay-only connections that
Bitcoin Core would initiate by default (and reduce potential concern about
overwhelming the network's capacity).

 * non-listening nodes running with -connect to one/more preselected peers
>     - they can't send disabletx generally because they want txes
>     - they don't need addr information (since they only make connections
>       to some known peers), and don't have many peers to relay addresses
>       on to, so are essentially blackholes, so would like to disable
>       addr relay for much the same reasons
>

While I think it's a valid use-case if someone wants to run nodes in this
way, I don't see why it has direct bearing on this discussion -- adding
protocol support for this use case is not incompatible with my disabletx
proposal; indeed, once we have worked out an addr relay protocol that
supports a peer telling another to not relay addresses, I would plan to use
it along with disabletx.

-----

There was some discussion about this proposal on IRC recently as well [3]
and this issue of mentioning addr-relay in a BIP about tx-relay seems to
have drawn some critique.  I think if there were some other use case that
other developers have which would use disabletx (say, because the current
fRelay solution also is inadequate for those use cases today), yet would
want addr relay on these links, then that would be a good reason to drop
mention of it from the BIP and defer discussion of addr relay entirely to
some new future proposal.  However, I'm not yet aware of such a use case,
as the -blocksonly one mentioned above does not actually fit (and nor do I
think that a -blocksonly mode where transactions are never sent but addr
messages are exchanged is necessary beyond how we already do that today, by
just sending fRelay=false).

Moreover, because there is no specification/BIP that governs how address
relay should work on the network, I think that if we just dropped mention
of addr-relay from the BIP, that software ought to just disable addr-relay
to nodes sending disabletx, anyway!  Addr relay is currently purely local
policy, so I think it's reasonable to conclude that if the only known use
case of a peer sending disabletx is for a behavior that also would drop
addr messages, then optimizing software for that use case is logical and I
would propose that myself for how Bitcoin Core behaves.  It seems polite to
mention this in the BIP as well, so that other software implementors have
the same understanding that I have for how this should work, until we have
an address relay protocol extension that governs it explicitly.

-----

Why not simply add a "disableaddr" type of message now?  I am not opposed
to someone championing an addr relay protocol, but I personally think it is
premature.  I'm not aware of any research or shared understanding of what
the goals of address relay are or ought to be, particularly as they pertain
to how addresses for obscure networks ought to propagate to nodes that may
or may not support those networks.  Moreover, I'm not aware of any research
into what relay strategies make sense to achieve any particular relay goals
we might come up with.  I imagine that we will someday propose a way for
software to communicate support for various network types (as defined in
BIP 155), and that will relate to the kinds of relay policies we expect
software on the network to be running.  But I think any p2p message we add
now to simply "disableaddr" would be made redundant by a more extensive
protocol in the future, so I don't feel comfortable defending a proposal to
add such a message at this time, when it seems to be unnecessary for
today's use cases.

So to summarize my view on this BIP's recommendation against sending addr
messages to disabletx peers: if there is some software that someone plans
to deploy soon that would seek to use disabletx but would prefer addr relay
on these links, then I think that would cause me to re-evaluate this
proposal to figure out the best way to achieve both use cases.  For now I
think the recommendation I've proposed still makes sense.

--Suhas

[1]
https://github.com/bitcoin/bitcoin/blob/f91587f050d9dceb45fe10129a76a4a9a060a09c/test/functional/p2p_blocksonly.py#L36

[2] Perhaps confusingly, running in -blocksonly mode is largely irrelevant
to the outbound peering of such a node, as it makes 10 outbound connections
by default, 8 of which are considered "full-relay" yet send fRelay=false to
not receive inbound transaction traffic, and 2 considered
"block-relay-only", also setting fRelay=false, but also not ever announcing
transactions on those links.  I anticipate that in the future, Bitcoin Core
software running in -blocksonly mode will continue to treat those 8
"full-relay" connections the same as today, and just start sending the
disabletx message on the connections it considers to be truly
block-relay-only (the two existing connections, along with any additional
ones we later add).

[3]
https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-01-12-15.00.log.html

[-- Attachment #2: Type: text/html, Size: 8417 bytes --]

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[John Newbery]

[-- Attachment #1: Type: text/plain, Size: 24862 bytes --]

Hi Suhas,

Thank you for this proposal. I agree with your aims, but I think a new
P2P message isn't necessary to achieve them.

# Motivation

There are two distinct (but interacting) motivations:

1. Allow a node to accept more incoming connections which will only be
   used for block propagation (no transaction relay or addr gossip),
   while minimizing resource requirements.

2. Prevent `addr` gossip messages from being sent to peers which will
   'black hole' those addrs (i.e. not relay them further).

These motivations interact because if we simply increase the number of
block-relay-only connections that nodes make without making any
allowance for the fact those connections won't gossip addr records, then
we'll increase the number of addr black holes and worsen addr gossip.

# Using fRelay=false to signal no transaction relay.

`fRelay` is an optional field in the `version` message. There are three
BIPs concerned with `fRelay`:

- BIP 37[1] introduced the `fRelay` field to indicate to the recipient
  that they must not relay transactions over the connection until a
  `filteradd` message has been received.

- BIP 60[2] aimed to make the `fRelay` field mandatory. It is not clear
  how widely this BIP has been adopted by implementations.

- BIP 111[3] introduced a `NODE_BLOOM` service bit to indicate that
  bloom filters are served by this node. According to this BIP, "If a
  node does not support bloom filters but receives a "filterload",
  "filteradd", or "filterclear" message from a peer the node should
  disconnect that peer immediately."

Within Bitcoin Core:

- PR 1795[4] (merged in January 2013) added support for BIP 37 Bloom
  filters.

- Since PR 2763[5] (merged in June 2013), Bitcoin Core will _always_
  include the `fRelay` flag in `version` messages that it sends. Bitcoin
  Core will tolerate the `fRelay` field being present or absent in any
  `version` message that it receives[6].

- PR 6579[7] (merged in August 2015) implemented BIP 111. From that
  point on, a Bitcoin Core node would disconnect peers that sent it
  `filter*` messages if it hadn't enabled `NODE_BLOOM`, provided the
  peer's version was >= 70011. In PR 7708[8] (merged in March 2016) this
  was extended to disconnect any peer that sends a `filter*` message,
  regardless of its version (in general, a 'polite disconnect' for any
  peer that requests an unsupported service is probably the best
  behaviour). In PR 16152[9] (merged in July 2019), serving Bloom
  filters was disabled by default, due to potential denial-of-service
  attacks being possible against nodes which serve bloom filters on
  public connections.

- PR 6993[10] (merged in November 2015) started reusing the `fRelay`
  field for the new `-blocksonly` mode. If Bitcoin Core is started with
  `-blocksonly` configured, then it includes `fRelay=false` in all of
  the `version` messages it sends. In PR 15759[11] (merged  in September
  2019), this usage of `fRelay` to permanently disable tx relay was
  extended for use by the new block-relay only connection type.

The net effect is that `fRelay` is already being used to indicate that
transactions should not be relayed over a connection. In the motivation
for your BIP, you write:

> 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...

However, as AJ points out in his response [12], the Bitcoin Core node
_does_ know whether transaction relay can be supported as soon as the
`version` message is received:

> [...] you either set m_tx_relay->fRelayTxes to true via the VERSION
> message (either explicitly or by not setting fRelay), or you enable it
> later with FILTERLOAD or FILTERCLEAR, both of which will cause a
> disconnect if bloom filters aren't supported. Bloom filter support is
> (optionally?) indicated via a service bit (BIP 111), so you could
> assume you know whether they're supported as soon as you receive the
> VERSION line.

i.e. if Bitcoin Core node is running under normal configuration with
bloom filters disabled for public connections (which is both the default
setting and highly recommended due to DoS concerns), then as soon as it
receives a `version` message with `fRelay=false`, it can be sure that
there will never be any transaction relay with that peer. If the peer
later tries to enable transaction relay by sending a `filterload`
message, then the node will disconnect that peer immediately.

In summary, we can continue using the `fRelay` field to indicate that
no transaction relay can happen for the entire lifetime of the
connection.  Bitcoin Core can postpone allocating resources for
transaction relay data structures until after the version message has
been received to minimize resource usage for incoming block-relay-only
connections. A rough implementation is here[13]. Obviously, a node that
has been configured to serve bloom filters on public connections would
not be able to take advantage of this and accept additional incoming
block-relay-only peers, but I think that's fine - we already discourage
that configuration.

I think a good counter-argument against simply using `fRelay` for this
purpose is that we shouldn't reuse a protocol feature designed for one
function to achieve a totally different aim. However, we know that nodes
on the network have been using `fRelay` to disable transaction relay
since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
later (when block-relay-only connections were introduced), so using
`fRelay` to disable transaction relay is now de facto part of the p2p
protocol.

# Preventing addr black holes

Addresses of potential peers are gossiped around the p2p network using
`addr` messages. When a Bitcoin Core node learns of a new `addr` record,
it will relay that record to one or two of its peers, chosen at
random[14]. The idea is that eventually the `addr` record will reach
most of the nodes on the network.

If there are too many nodes on the network that receive `addr` records
and do not relay those records on to their peers (termed _addr black
hole_ nodes), then propagation of those `addr` records suffers -- any
individual `addr` record is unlikely to reach a large proportion of
nodes on the network.

Since a motivation for block-relay-only connections is to protect
against eclipse attacks and thwart network topology analysis, Bitcoin
Core will not relay `addr` records on those connections, and will ignore
any `addr` record received over those connections. Therefore, increasing
the number of block-relay-only connections without changing the `addr`
gossip logic is likely to increase the prevalence of addr black holes,
and negatively impact addr propagation. This is why BIP 338 includes:

> 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)

I think a better approach would be for Bitcoin Core to only relay addr
records to an inbound peer if it has previously received an `addr` or
`addrv2` message from that peer, since that indicates definitively that
the peer actively gossips `addr` records. This approach was first
suggested by AJ in the original block-relay-only PR[15].

An advantage of this approach is that it will improve addr propagation
immediately and without any change to the P2P protocol, and will prevent
sending `addr` records to all addr black holes (such as light clients),
not just incoming block-relay-only connections.

# Conclusion

We can increase the permitted number of inbound block-relay-only peers
while minimizing resource requirement _and_ improving addr record
propagation, without any changes to the p2p protocol required.

I propose that for Bitcoin Core version 22.0:

- only initialize the transaction relay data structures after the
  `version` message is received, and only if fRelay=true and
  `NODE_BLOOM` is not offered on this connection.
- only initialize the addr data structures for inbound connections when
  an `addr`, `addrv2` or `getaddr` message is received on the
  connection, and only consider a connection for addr relay if its addr
  data structures are initialized.
- update the inbound eviction logic to protect more inbound peers which
  do not have transaction relay data structures.

Then, in version 23.0:

- modestly increase the number of outbound block-relay-only connections.

John

[1] https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
[2] https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki
[3] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki
[4] https://github.com/bitcoin/bitcoin/pull/1795
[5] https://github.com/bitcoin/bitcoin/pull/2763
[6]
https://github.com/bitcoin/bitcoin/blob/e49117470b77fb7d53be122c6490ba163c6e304d/src/net_processing.cpp#L2582-L2583
[7] https://github.com/bitcoin/bitcoin/pull/6579
[8] https://github.com/bitcoin/bitcoin/pull/7708
[9] https://github.com/bitcoin/bitcoin/pull/16152
[10] https://github.com/bitcoin/bitcoin/pull/6993
[11] https://github.com/bitcoin/bitcoin/pull/15759
[12]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018347.html
[13] https://github.com/jnewbery/bitcoin/tree/2021-02-lazy-init-peer
[14]
https://github.com/bitcoin/bitcoin/blob/e52ce9f2b312b3cf3b0837918e07d7603e241d63/src/net_processing.cpp#L1696-L1700
[15] https://github.com/bitcoin/bitcoin/pull/15759#issuecomment-527012757

> 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.

On Wed, Jan 6, 2021 at 4:35 PM 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 <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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 28353 bytes --]

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 29293 bytes --]

Hi John,

> I think a good counter-argument against simply using `fRelay` for this
> purpose is that we shouldn't reuse a protocol feature designed for one
> function to achieve a totally different aim. However, we know that nodes
> on the network have been using `fRelay` to disable transaction relay
> since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
> usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
> later (when block-relay-only connections were introduced), so using
> `fRelay` to disable transaction relay is now de facto part of the p2p
> protocol.


I don't think this is good practice ecosystem-wise. To understand tx-relay
opt-out from peers correctly, a _non_ Bitcoin Core client has to implement
the `fRelay` subset of BIP37, but ignore the wider part around FILTER*
messages. Or implement those messages, only to disconnect peers sending
them, thus following BIP111 requirements.

Thus, future developers of bitcoin software have the choice between
implementing a standard in a non-compliant way or implementing p2p messages
for a light client protocol in a way of deprecation ? Even further, an
interpretation of BIP 37 ("Being able to opt-out of _inv_ messages until
the filter is set prevents a client being flooded with traffic in the brief
window of time") would make it okay to send TX messages to your inbound
block-relay-only peers. And that your client shouldn't be disconnected for
such behavior.

On the long-term, IMHO, better to have a well-defined standard with a clean
negotiation mechanism rather than relying on code specifics of a given
Bitcoin client. If we don't want to introduce a new message and
corresponding code changes, it would be wise at least to extract VERSION's
`fRelay` and how Core handles it in its own BIP.

> I think a better approach would be for Bitcoin Core to only relay addr
> records to an inbound peer if it has previously received an `addr` or
> `addrv2` message from that peer, since that indicates definitively that
> the peer actively gossips `addr` records. This approach was first
> suggested by AJ in the original block-relay-only PR[15].

If a node is willingly to opt-out from addr-relay from one of its inbound
peers, how is it supposed to do ? Of course, you can drop such messages on
the floor, your peer is just going to waste bandwidth for nothing. IIRC
from past irc p2p meetings, we're really unclear about what a
good-propagation-and-privacy-preserving addr-relay strategy should look
like. Note, that distrusting your inbound peers with your addr-relay might
be a sane direction. Explicit addr-relay negotiation will offer more
flexibility (and more hygienic code paths rather than triggering data
structures initialization in few different locations).

> - update the inbound eviction logic to protect more inbound peers which
> do not have transaction relay data structures.

Given inbound connections might be attacker-controlled and tx-relay opt-out
signaling is also attacker-controlled, wouldn't this give a bias toward an
attacker in occupying our inbound slots ? Compared to honest inbound peers,
which in average are going to be full-relay.

Cheers,
Antoine



Le lun. 1 mars 2021 à 16:07, John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hi Suhas,
>
> Thank you for this proposal. I agree with your aims, but I think a new
> P2P message isn't necessary to achieve them.
>
> # Motivation
>
> There are two distinct (but interacting) motivations:
>
> 1. Allow a node to accept more incoming connections which will only be
>    used for block propagation (no transaction relay or addr gossip),
>    while minimizing resource requirements.
>
> 2. Prevent `addr` gossip messages from being sent to peers which will
>    'black hole' those addrs (i.e. not relay them further).
>
> These motivations interact because if we simply increase the number of
> block-relay-only connections that nodes make without making any
> allowance for the fact those connections won't gossip addr records, then
> we'll increase the number of addr black holes and worsen addr gossip.
>
> # Using fRelay=false to signal no transaction relay.
>
> `fRelay` is an optional field in the `version` message. There are three
> BIPs concerned with `fRelay`:
>
> - BIP 37[1] introduced the `fRelay` field to indicate to the recipient
>   that they must not relay transactions over the connection until a
>   `filteradd` message has been received.
>
> - BIP 60[2] aimed to make the `fRelay` field mandatory. It is not clear
>   how widely this BIP has been adopted by implementations.
>
> - BIP 111[3] introduced a `NODE_BLOOM` service bit to indicate that
>   bloom filters are served by this node. According to this BIP, "If a
>   node does not support bloom filters but receives a "filterload",
>   "filteradd", or "filterclear" message from a peer the node should
>   disconnect that peer immediately."
>
> Within Bitcoin Core:
>
> - PR 1795[4] (merged in January 2013) added support for BIP 37 Bloom
>   filters.
>
> - Since PR 2763[5] (merged in June 2013), Bitcoin Core will _always_
>   include the `fRelay` flag in `version` messages that it sends. Bitcoin
>   Core will tolerate the `fRelay` field being present or absent in any
>   `version` message that it receives[6].
>
> - PR 6579[7] (merged in August 2015) implemented BIP 111. From that
>   point on, a Bitcoin Core node would disconnect peers that sent it
>   `filter*` messages if it hadn't enabled `NODE_BLOOM`, provided the
>   peer's version was >= 70011. In PR 7708[8] (merged in March 2016) this
>   was extended to disconnect any peer that sends a `filter*` message,
>   regardless of its version (in general, a 'polite disconnect' for any
>   peer that requests an unsupported service is probably the best
>   behaviour). In PR 16152[9] (merged in July 2019), serving Bloom
>   filters was disabled by default, due to potential denial-of-service
>   attacks being possible against nodes which serve bloom filters on
>   public connections.
>
> - PR 6993[10] (merged in November 2015) started reusing the `fRelay`
>   field for the new `-blocksonly` mode. If Bitcoin Core is started with
>   `-blocksonly` configured, then it includes `fRelay=false` in all of
>   the `version` messages it sends. In PR 15759[11] (merged  in September
>   2019), this usage of `fRelay` to permanently disable tx relay was
>   extended for use by the new block-relay only connection type.
>
> The net effect is that `fRelay` is already being used to indicate that
> transactions should not be relayed over a connection. In the motivation
> for your BIP, you write:
>
> > 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...
>
> However, as AJ points out in his response [12], the Bitcoin Core node
> _does_ know whether transaction relay can be supported as soon as the
> `version` message is received:
>
> > [...] you either set m_tx_relay->fRelayTxes to true via the VERSION
> > message (either explicitly or by not setting fRelay), or you enable it
> > later with FILTERLOAD or FILTERCLEAR, both of which will cause a
> > disconnect if bloom filters aren't supported. Bloom filter support is
> > (optionally?) indicated via a service bit (BIP 111), so you could
> > assume you know whether they're supported as soon as you receive the
> > VERSION line.
>
> i.e. if Bitcoin Core node is running under normal configuration with
> bloom filters disabled for public connections (which is both the default
> setting and highly recommended due to DoS concerns), then as soon as it
> receives a `version` message with `fRelay=false`, it can be sure that
> there will never be any transaction relay with that peer. If the peer
> later tries to enable transaction relay by sending a `filterload`
> message, then the node will disconnect that peer immediately.
>
> In summary, we can continue using the `fRelay` field to indicate that
> no transaction relay can happen for the entire lifetime of the
> connection.  Bitcoin Core can postpone allocating resources for
> transaction relay data structures until after the version message has
> been received to minimize resource usage for incoming block-relay-only
> connections. A rough implementation is here[13]. Obviously, a node that
> has been configured to serve bloom filters on public connections would
> not be able to take advantage of this and accept additional incoming
> block-relay-only peers, but I think that's fine - we already discourage
> that configuration.
>
> I think a good counter-argument against simply using `fRelay` for this
> purpose is that we shouldn't reuse a protocol feature designed for one
> function to achieve a totally different aim. However, we know that nodes
> on the network have been using `fRelay` to disable transaction relay
> since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
> usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
> later (when block-relay-only connections were introduced), so using
> `fRelay` to disable transaction relay is now de facto part of the p2p
> protocol.
>
> # Preventing addr black holes
>
> Addresses of potential peers are gossiped around the p2p network using
> `addr` messages. When a Bitcoin Core node learns of a new `addr` record,
> it will relay that record to one or two of its peers, chosen at
> random[14]. The idea is that eventually the `addr` record will reach
> most of the nodes on the network.
>
> If there are too many nodes on the network that receive `addr` records
> and do not relay those records on to their peers (termed _addr black
> hole_ nodes), then propagation of those `addr` records suffers -- any
> individual `addr` record is unlikely to reach a large proportion of
> nodes on the network.
>
> Since a motivation for block-relay-only connections is to protect
> against eclipse attacks and thwart network topology analysis, Bitcoin
> Core will not relay `addr` records on those connections, and will ignore
> any `addr` record received over those connections. Therefore, increasing
> the number of block-relay-only connections without changing the `addr`
> gossip logic is likely to increase the prevalence of addr black holes,
> and negatively impact addr propagation. This is why BIP 338 includes:
>
> > 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)
>
> I think a better approach would be for Bitcoin Core to only relay addr
> records to an inbound peer if it has previously received an `addr` or
> `addrv2` message from that peer, since that indicates definitively that
> the peer actively gossips `addr` records. This approach was first
> suggested by AJ in the original block-relay-only PR[15].
>
> An advantage of this approach is that it will improve addr propagation
> immediately and without any change to the P2P protocol, and will prevent
> sending `addr` records to all addr black holes (such as light clients),
> not just incoming block-relay-only connections.
>
> # Conclusion
>
> We can increase the permitted number of inbound block-relay-only peers
> while minimizing resource requirement _and_ improving addr record
> propagation, without any changes to the p2p protocol required.
>
> I propose that for Bitcoin Core version 22.0:
>
> - only initialize the transaction relay data structures after the
>   `version` message is received, and only if fRelay=true and
>   `NODE_BLOOM` is not offered on this connection.
> - only initialize the addr data structures for inbound connections when
>   an `addr`, `addrv2` or `getaddr` message is received on the
>   connection, and only consider a connection for addr relay if its addr
>   data structures are initialized.
> - update the inbound eviction logic to protect more inbound peers which
>   do not have transaction relay data structures.
>
> Then, in version 23.0:
>
> - modestly increase the number of outbound block-relay-only connections.
>
> John
>
> [1] https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
> [2] https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki
> [3] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki
> [4] https://github.com/bitcoin/bitcoin/pull/1795
> [5] https://github.com/bitcoin/bitcoin/pull/2763
> [6]
> https://github.com/bitcoin/bitcoin/blob/e49117470b77fb7d53be122c6490ba163c6e304d/src/net_processing.cpp#L2582-L2583
> [7] https://github.com/bitcoin/bitcoin/pull/6579
> [8] https://github.com/bitcoin/bitcoin/pull/7708
> [9] https://github.com/bitcoin/bitcoin/pull/16152
> [10] https://github.com/bitcoin/bitcoin/pull/6993
> [11] https://github.com/bitcoin/bitcoin/pull/15759
> [12]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018347.html
> [13] https://github.com/jnewbery/bitcoin/tree/2021-02-lazy-init-peer
> [14]
> https://github.com/bitcoin/bitcoin/blob/e52ce9f2b312b3cf3b0837918e07d7603e241d63/src/net_processing.cpp#L1696-L1700
> [15] https://github.com/bitcoin/bitcoin/pull/15759#issuecomment-527012757
>
> > 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.
>
> On Wed, Jan 6, 2021 at 4:35 PM 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 <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.
>>
>> _______________________________________________
>> 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
>

[-- Attachment #2: Type: text/html, Size: 32950 bytes --]

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[John Newbery]

[-- Attachment #1: Type: text/plain, Size: 31296 bytes --]

Antoine,

Nothing in my proposal below precludes introducing a more comprehensive
feature negotiation mechanism at some later date. The only changes I'm
proposing are to Bitcoin Core's policy for how it treats its peer
connections.

> If we don't want to introduce a new message and
> corresponding code changes, it would be wise at least to extract VERSION's
> `fRelay` and how Core handles it in its own BIP.

I believe this is what BIP 60 does, or did you have something else in
mind?

> Explicit addr-relay negotiation will offer more
> flexibility

I agree!

> (and more hygienic code paths rather than triggering data
> structures initialization in few different locations).

Not sure what you mean by hygienic here. This seems like a code style
preference.

> Given inbound connections might be attacker-controlled and tx-relay
opt-out
> signaling is also attacker-controlled, wouldn't this give a bias toward an
> attacker in occupying our inbound slots ? Compared to honest inbound
peers,
> which in average are going to be full-relay.

Sorry - I meant that Bitcoin Core should allow a certain number of
inbound peers that do not relay txs. This would be in addition to the
full-relay inbound peers.

John

On Mon, Mar 1, 2021 at 11:11 PM Antoine Riard <antoine.riard@gmail.com>
wrote:

> Hi John,
>
> > I think a good counter-argument against simply using `fRelay` for this
> > purpose is that we shouldn't reuse a protocol feature designed for one
> > function to achieve a totally different aim. However, we know that nodes
> > on the network have been using `fRelay` to disable transaction relay
> > since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
> > usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
> > later (when block-relay-only connections were introduced), so using
> > `fRelay` to disable transaction relay is now de facto part of the p2p
> > protocol.
>
>
> I don't think this is good practice ecosystem-wise. To understand tx-relay
> opt-out from peers correctly, a _non_ Bitcoin Core client has to implement
> the `fRelay` subset of BIP37, but ignore the wider part around FILTER*
> messages. Or implement those messages, only to disconnect peers sending
> them, thus following BIP111 requirements.
>
> Thus, future developers of bitcoin software have the choice between
> implementing a standard in a non-compliant way or implementing p2p messages
> for a light client protocol in a way of deprecation ? Even further, an
> interpretation of BIP 37 ("Being able to opt-out of _inv_ messages until
> the filter is set prevents a client being flooded with traffic in the brief
> window of time") would make it okay to send TX messages to your inbound
> block-relay-only peers. And that your client shouldn't be disconnected for
> such behavior.
>
> On the long-term, IMHO, better to have a well-defined standard with a
> clean negotiation mechanism rather than relying on code specifics of a
> given Bitcoin client. If we don't want to introduce a new message and
> corresponding code changes, it would be wise at least to extract VERSION's
> `fRelay` and how Core handles it in its own BIP.
>
> > I think a better approach would be for Bitcoin Core to only relay addr
> > records to an inbound peer if it has previously received an `addr` or
> > `addrv2` message from that peer, since that indicates definitively that
> > the peer actively gossips `addr` records. This approach was first
> > suggested by AJ in the original block-relay-only PR[15].
>
> If a node is willingly to opt-out from addr-relay from one of its inbound
> peers, how is it supposed to do ? Of course, you can drop such messages on
> the floor, your peer is just going to waste bandwidth for nothing. IIRC
> from past irc p2p meetings, we're really unclear about what a
> good-propagation-and-privacy-preserving addr-relay strategy should look
> like. Note, that distrusting your inbound peers with your addr-relay might
> be a sane direction. Explicit addr-relay negotiation will offer more
> flexibility (and more hygienic code paths rather than triggering data
> structures initialization in few different locations).
>
> > - update the inbound eviction logic to protect more inbound peers which
> > do not have transaction relay data structures.
>
> Given inbound connections might be attacker-controlled and tx-relay
> opt-out signaling is also attacker-controlled, wouldn't this give a bias
> toward an attacker in occupying our inbound slots ? Compared to honest
> inbound peers, which in average are going to be full-relay.
>
> Cheers,
> Antoine
>
>
>
> Le lun. 1 mars 2021 à 16:07, John Newbery via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> Hi Suhas,
>>
>> Thank you for this proposal. I agree with your aims, but I think a new
>> P2P message isn't necessary to achieve them.
>>
>> # Motivation
>>
>> There are two distinct (but interacting) motivations:
>>
>> 1. Allow a node to accept more incoming connections which will only be
>>    used for block propagation (no transaction relay or addr gossip),
>>    while minimizing resource requirements.
>>
>> 2. Prevent `addr` gossip messages from being sent to peers which will
>>    'black hole' those addrs (i.e. not relay them further).
>>
>> These motivations interact because if we simply increase the number of
>> block-relay-only connections that nodes make without making any
>> allowance for the fact those connections won't gossip addr records, then
>> we'll increase the number of addr black holes and worsen addr gossip.
>>
>> # Using fRelay=false to signal no transaction relay.
>>
>> `fRelay` is an optional field in the `version` message. There are three
>> BIPs concerned with `fRelay`:
>>
>> - BIP 37[1] introduced the `fRelay` field to indicate to the recipient
>>   that they must not relay transactions over the connection until a
>>   `filteradd` message has been received.
>>
>> - BIP 60[2] aimed to make the `fRelay` field mandatory. It is not clear
>>   how widely this BIP has been adopted by implementations.
>>
>> - BIP 111[3] introduced a `NODE_BLOOM` service bit to indicate that
>>   bloom filters are served by this node. According to this BIP, "If a
>>   node does not support bloom filters but receives a "filterload",
>>   "filteradd", or "filterclear" message from a peer the node should
>>   disconnect that peer immediately."
>>
>> Within Bitcoin Core:
>>
>> - PR 1795[4] (merged in January 2013) added support for BIP 37 Bloom
>>   filters.
>>
>> - Since PR 2763[5] (merged in June 2013), Bitcoin Core will _always_
>>   include the `fRelay` flag in `version` messages that it sends. Bitcoin
>>   Core will tolerate the `fRelay` field being present or absent in any
>>   `version` message that it receives[6].
>>
>> - PR 6579[7] (merged in August 2015) implemented BIP 111. From that
>>   point on, a Bitcoin Core node would disconnect peers that sent it
>>   `filter*` messages if it hadn't enabled `NODE_BLOOM`, provided the
>>   peer's version was >= 70011. In PR 7708[8] (merged in March 2016) this
>>   was extended to disconnect any peer that sends a `filter*` message,
>>   regardless of its version (in general, a 'polite disconnect' for any
>>   peer that requests an unsupported service is probably the best
>>   behaviour). In PR 16152[9] (merged in July 2019), serving Bloom
>>   filters was disabled by default, due to potential denial-of-service
>>   attacks being possible against nodes which serve bloom filters on
>>   public connections.
>>
>> - PR 6993[10] (merged in November 2015) started reusing the `fRelay`
>>   field for the new `-blocksonly` mode. If Bitcoin Core is started with
>>   `-blocksonly` configured, then it includes `fRelay=false` in all of
>>   the `version` messages it sends. In PR 15759[11] (merged  in September
>>   2019), this usage of `fRelay` to permanently disable tx relay was
>>   extended for use by the new block-relay only connection type.
>>
>> The net effect is that `fRelay` is already being used to indicate that
>> transactions should not be relayed over a connection. In the motivation
>> for your BIP, you write:
>>
>> > 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...
>>
>> However, as AJ points out in his response [12], the Bitcoin Core node
>> _does_ know whether transaction relay can be supported as soon as the
>> `version` message is received:
>>
>> > [...] you either set m_tx_relay->fRelayTxes to true via the VERSION
>> > message (either explicitly or by not setting fRelay), or you enable it
>> > later with FILTERLOAD or FILTERCLEAR, both of which will cause a
>> > disconnect if bloom filters aren't supported. Bloom filter support is
>> > (optionally?) indicated via a service bit (BIP 111), so you could
>> > assume you know whether they're supported as soon as you receive the
>> > VERSION line.
>>
>> i.e. if Bitcoin Core node is running under normal configuration with
>> bloom filters disabled for public connections (which is both the default
>> setting and highly recommended due to DoS concerns), then as soon as it
>> receives a `version` message with `fRelay=false`, it can be sure that
>> there will never be any transaction relay with that peer. If the peer
>> later tries to enable transaction relay by sending a `filterload`
>> message, then the node will disconnect that peer immediately.
>>
>> In summary, we can continue using the `fRelay` field to indicate that
>> no transaction relay can happen for the entire lifetime of the
>> connection.  Bitcoin Core can postpone allocating resources for
>> transaction relay data structures until after the version message has
>> been received to minimize resource usage for incoming block-relay-only
>> connections. A rough implementation is here[13]. Obviously, a node that
>> has been configured to serve bloom filters on public connections would
>> not be able to take advantage of this and accept additional incoming
>> block-relay-only peers, but I think that's fine - we already discourage
>> that configuration.
>>
>> I think a good counter-argument against simply using `fRelay` for this
>> purpose is that we shouldn't reuse a protocol feature designed for one
>> function to achieve a totally different aim. However, we know that nodes
>> on the network have been using `fRelay` to disable transaction relay
>> since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
>> usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
>> later (when block-relay-only connections were introduced), so using
>> `fRelay` to disable transaction relay is now de facto part of the p2p
>> protocol.
>>
>> # Preventing addr black holes
>>
>> Addresses of potential peers are gossiped around the p2p network using
>> `addr` messages. When a Bitcoin Core node learns of a new `addr` record,
>> it will relay that record to one or two of its peers, chosen at
>> random[14]. The idea is that eventually the `addr` record will reach
>> most of the nodes on the network.
>>
>> If there are too many nodes on the network that receive `addr` records
>> and do not relay those records on to their peers (termed _addr black
>> hole_ nodes), then propagation of those `addr` records suffers -- any
>> individual `addr` record is unlikely to reach a large proportion of
>> nodes on the network.
>>
>> Since a motivation for block-relay-only connections is to protect
>> against eclipse attacks and thwart network topology analysis, Bitcoin
>> Core will not relay `addr` records on those connections, and will ignore
>> any `addr` record received over those connections. Therefore, increasing
>> the number of block-relay-only connections without changing the `addr`
>> gossip logic is likely to increase the prevalence of addr black holes,
>> and negatively impact addr propagation. This is why BIP 338 includes:
>>
>> > 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)
>>
>> I think a better approach would be for Bitcoin Core to only relay addr
>> records to an inbound peer if it has previously received an `addr` or
>> `addrv2` message from that peer, since that indicates definitively that
>> the peer actively gossips `addr` records. This approach was first
>> suggested by AJ in the original block-relay-only PR[15].
>>
>> An advantage of this approach is that it will improve addr propagation
>> immediately and without any change to the P2P protocol, and will prevent
>> sending `addr` records to all addr black holes (such as light clients),
>> not just incoming block-relay-only connections.
>>
>> # Conclusion
>>
>> We can increase the permitted number of inbound block-relay-only peers
>> while minimizing resource requirement _and_ improving addr record
>> propagation, without any changes to the p2p protocol required.
>>
>> I propose that for Bitcoin Core version 22.0:
>>
>> - only initialize the transaction relay data structures after the
>>   `version` message is received, and only if fRelay=true and
>>   `NODE_BLOOM` is not offered on this connection.
>> - only initialize the addr data structures for inbound connections when
>>   an `addr`, `addrv2` or `getaddr` message is received on the
>>   connection, and only consider a connection for addr relay if its addr
>>   data structures are initialized.
>> - update the inbound eviction logic to protect more inbound peers which
>>   do not have transaction relay data structures.
>>
>> Then, in version 23.0:
>>
>> - modestly increase the number of outbound block-relay-only connections.
>>
>> John
>>
>> [1] https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
>> [2] https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki
>> [3] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki
>> [4] https://github.com/bitcoin/bitcoin/pull/1795
>> [5] https://github.com/bitcoin/bitcoin/pull/2763
>> [6]
>> https://github.com/bitcoin/bitcoin/blob/e49117470b77fb7d53be122c6490ba163c6e304d/src/net_processing.cpp#L2582-L2583
>> [7] https://github.com/bitcoin/bitcoin/pull/6579
>> [8] https://github.com/bitcoin/bitcoin/pull/7708
>> [9] https://github.com/bitcoin/bitcoin/pull/16152
>> [10] https://github.com/bitcoin/bitcoin/pull/6993
>> [11] https://github.com/bitcoin/bitcoin/pull/15759
>> [12]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018347.html
>> [13] https://github.com/jnewbery/bitcoin/tree/2021-02-lazy-init-peer
>> [14]
>> https://github.com/bitcoin/bitcoin/blob/e52ce9f2b312b3cf3b0837918e07d7603e241d63/src/net_processing.cpp#L1696-L1700
>> [15] https://github.com/bitcoin/bitcoin/pull/15759#issuecomment-527012757
>>
>> > 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.
>>
>> On Wed, Jan 6, 2021 at 4:35 PM 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 <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.
>>>
>>> _______________________________________________
>>> 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
>>
>

[-- Attachment #2: Type: text/html, Size: 34725 bytes --]

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 34181 bytes --]

> I believe this is what BIP 60 does, or did you have something else in
> mind?

Right, it achieves the first goal of dissociating `fRelay` from BIP37 but
it doesn't document Core specific behavior of disconnecting peers for raw
TX messages reception
from outbound block-relay-only peers, as implemented by PR 15759. I think
BIP 60 is as much unclear as BIP37 "Whether the remote peer should announce
relayed transactions or not, see BIP 0037, since version >= 70001". A first
interpretation could be that all tx-relay messages are disabled. A second
interpretation could be that only _tx-announcement_ messages (e.g INV(TX))
are disabled.

It could be argued that #15759 introduced incompatible changes between a
Bitcon Core 0.19.0 node and a BIP37 compliant peer on the p2p network.
Post-15759, the message space allowed to a BIP37 peer has been
reduced...Note that BIP60 isn't listed as implemented in
bitcoin/doc/bips.md.

I believe that BIP338 has the merit of making those subjects clear and easy
to follow by any Bitcoin software. Instead of spawning discussion around
old, lightclient-related BIPs or Core undocumented disabling transaction
relay mechanism being de facto part of the p2p protocol.

> Sorry - I meant that Bitcoin Core should allow a certain number of
> inbound peers that do not relay txs. This would be in addition to the
> full-relay inbound peers.

Yes, I agree on the purpose. But I don't think we need to "allow" further
disabled-tx peers by our inbound connection selection or eviction logics.
Turning a few bits in a protocol message sounds a too-cheap burden on
potential attackers contrary to most of our current eviction heuristics,
forcing some work ("announce transaction fast, "be located in some subnet",
"announce block fast"). Though better to discuss this later, not the main
point of your proposal.

Antoine

Le mar. 2 mars 2021 à 07:22, John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Antoine,
>
> Nothing in my proposal below precludes introducing a more comprehensive
> feature negotiation mechanism at some later date. The only changes I'm
> proposing are to Bitcoin Core's policy for how it treats its peer
> connections.
>
> > If we don't want to introduce a new message and
> > corresponding code changes, it would be wise at least to extract
> VERSION's
> > `fRelay` and how Core handles it in its own BIP.
>
> I believe this is what BIP 60 does, or did you have something else in
> mind?
>
> > Explicit addr-relay negotiation will offer more
> > flexibility
>
> I agree!
>
> > (and more hygienic code paths rather than triggering data
> > structures initialization in few different locations).
>
> Not sure what you mean by hygienic here. This seems like a code style
> preference.
>
> > Given inbound connections might be attacker-controlled and tx-relay
> opt-out
> > signaling is also attacker-controlled, wouldn't this give a bias toward
> an
> > attacker in occupying our inbound slots ? Compared to honest inbound
> peers,
> > which in average are going to be full-relay.
>
> Sorry - I meant that Bitcoin Core should allow a certain number of
> inbound peers that do not relay txs. This would be in addition to the
> full-relay inbound peers.
>
> John
>
> On Mon, Mar 1, 2021 at 11:11 PM Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> Hi John,
>>
>> > I think a good counter-argument against simply using `fRelay` for this
>> > purpose is that we shouldn't reuse a protocol feature designed for one
>> > function to achieve a totally different aim. However, we know that nodes
>> > on the network have been using `fRelay` to disable transaction relay
>> > since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
>> > usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
>> > later (when block-relay-only connections were introduced), so using
>> > `fRelay` to disable transaction relay is now de facto part of the p2p
>> > protocol.
>>
>>
>> I don't think this is good practice ecosystem-wise. To understand
>> tx-relay opt-out from peers correctly, a _non_ Bitcoin Core client has to
>> implement the `fRelay` subset of BIP37, but ignore the wider part around
>> FILTER* messages. Or implement those messages, only to disconnect peers
>> sending them, thus following BIP111 requirements.
>>
>> Thus, future developers of bitcoin software have the choice between
>> implementing a standard in a non-compliant way or implementing p2p messages
>> for a light client protocol in a way of deprecation ? Even further, an
>> interpretation of BIP 37 ("Being able to opt-out of _inv_ messages until
>> the filter is set prevents a client being flooded with traffic in the brief
>> window of time") would make it okay to send TX messages to your inbound
>> block-relay-only peers. And that your client shouldn't be disconnected for
>> such behavior.
>>
>> On the long-term, IMHO, better to have a well-defined standard with a
>> clean negotiation mechanism rather than relying on code specifics of a
>> given Bitcoin client. If we don't want to introduce a new message and
>> corresponding code changes, it would be wise at least to extract VERSION's
>> `fRelay` and how Core handles it in its own BIP.
>>
>> > I think a better approach would be for Bitcoin Core to only relay addr
>> > records to an inbound peer if it has previously received an `addr` or
>> > `addrv2` message from that peer, since that indicates definitively that
>> > the peer actively gossips `addr` records. This approach was first
>> > suggested by AJ in the original block-relay-only PR[15].
>>
>> If a node is willingly to opt-out from addr-relay from one of its inbound
>> peers, how is it supposed to do ? Of course, you can drop such messages on
>> the floor, your peer is just going to waste bandwidth for nothing. IIRC
>> from past irc p2p meetings, we're really unclear about what a
>> good-propagation-and-privacy-preserving addr-relay strategy should look
>> like. Note, that distrusting your inbound peers with your addr-relay might
>> be a sane direction. Explicit addr-relay negotiation will offer more
>> flexibility (and more hygienic code paths rather than triggering data
>> structures initialization in few different locations).
>>
>> > - update the inbound eviction logic to protect more inbound peers which
>> > do not have transaction relay data structures.
>>
>> Given inbound connections might be attacker-controlled and tx-relay
>> opt-out signaling is also attacker-controlled, wouldn't this give a bias
>> toward an attacker in occupying our inbound slots ? Compared to honest
>> inbound peers, which in average are going to be full-relay.
>>
>> Cheers,
>> Antoine
>>
>>
>>
>> Le lun. 1 mars 2021 à 16:07, John Newbery via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>>
>>> Hi Suhas,
>>>
>>> Thank you for this proposal. I agree with your aims, but I think a new
>>> P2P message isn't necessary to achieve them.
>>>
>>> # Motivation
>>>
>>> There are two distinct (but interacting) motivations:
>>>
>>> 1. Allow a node to accept more incoming connections which will only be
>>>    used for block propagation (no transaction relay or addr gossip),
>>>    while minimizing resource requirements.
>>>
>>> 2. Prevent `addr` gossip messages from being sent to peers which will
>>>    'black hole' those addrs (i.e. not relay them further).
>>>
>>> These motivations interact because if we simply increase the number of
>>> block-relay-only connections that nodes make without making any
>>> allowance for the fact those connections won't gossip addr records, then
>>> we'll increase the number of addr black holes and worsen addr gossip.
>>>
>>> # Using fRelay=false to signal no transaction relay.
>>>
>>> `fRelay` is an optional field in the `version` message. There are three
>>> BIPs concerned with `fRelay`:
>>>
>>> - BIP 37[1] introduced the `fRelay` field to indicate to the recipient
>>>   that they must not relay transactions over the connection until a
>>>   `filteradd` message has been received.
>>>
>>> - BIP 60[2] aimed to make the `fRelay` field mandatory. It is not clear
>>>   how widely this BIP has been adopted by implementations.
>>>
>>> - BIP 111[3] introduced a `NODE_BLOOM` service bit to indicate that
>>>   bloom filters are served by this node. According to this BIP, "If a
>>>   node does not support bloom filters but receives a "filterload",
>>>   "filteradd", or "filterclear" message from a peer the node should
>>>   disconnect that peer immediately."
>>>
>>> Within Bitcoin Core:
>>>
>>> - PR 1795[4] (merged in January 2013) added support for BIP 37 Bloom
>>>   filters.
>>>
>>> - Since PR 2763[5] (merged in June 2013), Bitcoin Core will _always_
>>>   include the `fRelay` flag in `version` messages that it sends. Bitcoin
>>>   Core will tolerate the `fRelay` field being present or absent in any
>>>   `version` message that it receives[6].
>>>
>>> - PR 6579[7] (merged in August 2015) implemented BIP 111. From that
>>>   point on, a Bitcoin Core node would disconnect peers that sent it
>>>   `filter*` messages if it hadn't enabled `NODE_BLOOM`, provided the
>>>   peer's version was >= 70011. In PR 7708[8] (merged in March 2016) this
>>>   was extended to disconnect any peer that sends a `filter*` message,
>>>   regardless of its version (in general, a 'polite disconnect' for any
>>>   peer that requests an unsupported service is probably the best
>>>   behaviour). In PR 16152[9] (merged in July 2019), serving Bloom
>>>   filters was disabled by default, due to potential denial-of-service
>>>   attacks being possible against nodes which serve bloom filters on
>>>   public connections.
>>>
>>> - PR 6993[10] (merged in November 2015) started reusing the `fRelay`
>>>   field for the new `-blocksonly` mode. If Bitcoin Core is started with
>>>   `-blocksonly` configured, then it includes `fRelay=false` in all of
>>>   the `version` messages it sends. In PR 15759[11] (merged  in September
>>>   2019), this usage of `fRelay` to permanently disable tx relay was
>>>   extended for use by the new block-relay only connection type.
>>>
>>> The net effect is that `fRelay` is already being used to indicate that
>>> transactions should not be relayed over a connection. In the motivation
>>> for your BIP, you write:
>>>
>>> > 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...
>>>
>>> However, as AJ points out in his response [12], the Bitcoin Core node
>>> _does_ know whether transaction relay can be supported as soon as the
>>> `version` message is received:
>>>
>>> > [...] you either set m_tx_relay->fRelayTxes to true via the VERSION
>>> > message (either explicitly or by not setting fRelay), or you enable it
>>> > later with FILTERLOAD or FILTERCLEAR, both of which will cause a
>>> > disconnect if bloom filters aren't supported. Bloom filter support is
>>> > (optionally?) indicated via a service bit (BIP 111), so you could
>>> > assume you know whether they're supported as soon as you receive the
>>> > VERSION line.
>>>
>>> i.e. if Bitcoin Core node is running under normal configuration with
>>> bloom filters disabled for public connections (which is both the default
>>> setting and highly recommended due to DoS concerns), then as soon as it
>>> receives a `version` message with `fRelay=false`, it can be sure that
>>> there will never be any transaction relay with that peer. If the peer
>>> later tries to enable transaction relay by sending a `filterload`
>>> message, then the node will disconnect that peer immediately.
>>>
>>> In summary, we can continue using the `fRelay` field to indicate that
>>> no transaction relay can happen for the entire lifetime of the
>>> connection.  Bitcoin Core can postpone allocating resources for
>>> transaction relay data structures until after the version message has
>>> been received to minimize resource usage for incoming block-relay-only
>>> connections. A rough implementation is here[13]. Obviously, a node that
>>> has been configured to serve bloom filters on public connections would
>>> not be able to take advantage of this and accept additional incoming
>>> block-relay-only peers, but I think that's fine - we already discourage
>>> that configuration.
>>>
>>> I think a good counter-argument against simply using `fRelay` for this
>>> purpose is that we shouldn't reuse a protocol feature designed for one
>>> function to achieve a totally different aim. However, we know that nodes
>>> on the network have been using `fRelay` to disable transaction relay
>>> since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
>>> usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
>>> later (when block-relay-only connections were introduced), so using
>>> `fRelay` to disable transaction relay is now de facto part of the p2p
>>> protocol.
>>>
>>> # Preventing addr black holes
>>>
>>> Addresses of potential peers are gossiped around the p2p network using
>>> `addr` messages. When a Bitcoin Core node learns of a new `addr` record,
>>> it will relay that record to one or two of its peers, chosen at
>>> random[14]. The idea is that eventually the `addr` record will reach
>>> most of the nodes on the network.
>>>
>>> If there are too many nodes on the network that receive `addr` records
>>> and do not relay those records on to their peers (termed _addr black
>>> hole_ nodes), then propagation of those `addr` records suffers -- any
>>> individual `addr` record is unlikely to reach a large proportion of
>>> nodes on the network.
>>>
>>> Since a motivation for block-relay-only connections is to protect
>>> against eclipse attacks and thwart network topology analysis, Bitcoin
>>> Core will not relay `addr` records on those connections, and will ignore
>>> any `addr` record received over those connections. Therefore, increasing
>>> the number of block-relay-only connections without changing the `addr`
>>> gossip logic is likely to increase the prevalence of addr black holes,
>>> and negatively impact addr propagation. This is why BIP 338 includes:
>>>
>>> > 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)
>>>
>>> I think a better approach would be for Bitcoin Core to only relay addr
>>> records to an inbound peer if it has previously received an `addr` or
>>> `addrv2` message from that peer, since that indicates definitively that
>>> the peer actively gossips `addr` records. This approach was first
>>> suggested by AJ in the original block-relay-only PR[15].
>>>
>>> An advantage of this approach is that it will improve addr propagation
>>> immediately and without any change to the P2P protocol, and will prevent
>>> sending `addr` records to all addr black holes (such as light clients),
>>> not just incoming block-relay-only connections.
>>>
>>> # Conclusion
>>>
>>> We can increase the permitted number of inbound block-relay-only peers
>>> while minimizing resource requirement _and_ improving addr record
>>> propagation, without any changes to the p2p protocol required.
>>>
>>> I propose that for Bitcoin Core version 22.0:
>>>
>>> - only initialize the transaction relay data structures after the
>>>   `version` message is received, and only if fRelay=true and
>>>   `NODE_BLOOM` is not offered on this connection.
>>> - only initialize the addr data structures for inbound connections when
>>>   an `addr`, `addrv2` or `getaddr` message is received on the
>>>   connection, and only consider a connection for addr relay if its addr
>>>   data structures are initialized.
>>> - update the inbound eviction logic to protect more inbound peers which
>>>   do not have transaction relay data structures.
>>>
>>> Then, in version 23.0:
>>>
>>> - modestly increase the number of outbound block-relay-only connections.
>>>
>>> John
>>>
>>> [1] https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
>>> [2] https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki
>>> [3] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki
>>> [4] https://github.com/bitcoin/bitcoin/pull/1795
>>> [5] https://github.com/bitcoin/bitcoin/pull/2763
>>> [6]
>>> https://github.com/bitcoin/bitcoin/blob/e49117470b77fb7d53be122c6490ba163c6e304d/src/net_processing.cpp#L2582-L2583
>>> [7] https://github.com/bitcoin/bitcoin/pull/6579
>>> [8] https://github.com/bitcoin/bitcoin/pull/7708
>>> [9] https://github.com/bitcoin/bitcoin/pull/16152
>>> [10] https://github.com/bitcoin/bitcoin/pull/6993
>>> [11] https://github.com/bitcoin/bitcoin/pull/15759
>>> [12]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018347.html
>>> [13] https://github.com/jnewbery/bitcoin/tree/2021-02-lazy-init-peer
>>> [14]
>>> https://github.com/bitcoin/bitcoin/blob/e52ce9f2b312b3cf3b0837918e07d7603e241d63/src/net_processing.cpp#L1696-L1700
>>> [15]
>>> https://github.com/bitcoin/bitcoin/pull/15759#issuecomment-527012757
>>>
>>> > 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.
>>>
>>> On Wed, Jan 6, 2021 at 4:35 PM 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 <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.
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 37521 bytes --]

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[Anthony Towns]

On Mon, Mar 01, 2021 at 08:58:46PM +0000, John Newbery via bitcoin-dev wrote:
> We can increase the permitted number of inbound block-relay-only peers
> while minimizing resource requirement _and_ improving addr record
> propagation, without any changes to the p2p protocol required.

+1.

I found this diagram:

https://raw.githubusercontent.com/amitiuttarwar/bitcoin-notes/main/scale-block-relay-only.png

helpful for analysing the possibilities. The greyed-circles indicate
when one node doesn't need to send txs to the other node, and thus can
avoid allocating the tx relay data structures.

> I propose that for Bitcoin Core version 22.0:
> 
> - only initialize the transaction relay data structures after the
>   `version` message is received, and only if fRelay=true and
>   `NODE_BLOOM` is not offered on this connection.

The tx relay data structure should *always* be initialised if you offer
NODE_BLOOM services on the connection.

> - only initialize the addr data structures for inbound connections when
>   an `addr`, `addrv2` or `getaddr` message is received on the
>   connection, and only consider a connection for addr relay if its addr
>   data structures are initialized.

I think it's simpler to initialize the addr data structures for all
connections, and add a bool to register "we've received an ADDR messages
from this peer, so will consider it for announcements". The data structure
is lightweight enough that this should be fine, I think.

I think the ideal rules are slightly more complicated:

Address relay:
  * do GETADDR on every outbound connection except block-relay-only
  * do self announcements on every connection but only having received a
    *ADDR* message of some kind

Set fRelay=false when:
  * running with -blocksonly=1
  * making a block-relay-only outbound connection
  * accepting an inbound connection but you're out of normal slots
    and can only offer a lightweight slot

Tx relay:
  * inbound (you accept the connection):
    + if you advertised bloom services to the node, full tx relay always
    + accept inbound txs, unless you advertised fRelay=false
    + send outbound txs if they didn't specify fRelay=false
      *or* you've run out of normal slots and can only offer a
      lightweight slot

  * outbound (you make the connection to someone else):
    + accept inbound txs, unless you advertised fRelay=false
    + send outbound txs if they didn't specify fRelay=false
      *and* you're not using them as a blocks-relay-only node

Note (because I keep getting them confused): the net.h TxRelay structure
needs to be initialised in order to *send* outbound txs; the txrequest.h
TxRequest structure is used for accepting inbound txs.

I think to support -blocksonly=1 nodes who want to relay their own wallet
addresses occassionally, assigning inbound txs who have fRelay=false to
a *much* lower MAX_PEER_TX_ANNOUNCEMENTS (perhaps 10 or 20, instead of
5000) and not allocating TxRelay for them at all would ensure they're
both functional and lightweight.

Cheers,
aj