Date: Thu, 14 Jan 2021 16:46:00 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Suhas Daftuar <sdaftuar@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210114064600.gu2qetgo5cw4tl5q@erisian.com.au>
References: <CAFp6fsE6gb2PaL3ikDRjS-hNnPLjvtWB+8qZJr3trQe2K9YN+g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAFp6fsE6gb2PaL3ikDRjS-hNnPLjvtWB+8qZJr3trQe2K9YN+g@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [bitcoin-dev] Proposal for new "disabletx" p2p message
Precedence: list

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