Date: Wed, 3 Mar 2021 02:31:27 +1000
From: Anthony Towns <aj@erisian.com.au>
To: John Newbery <john@johnnewbery.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210302163127.bjmzcyzdwrsm36fh@erisian.com.au>
References: <CAFp6fsE6gb2PaL3ikDRjS-hNnPLjvtWB+8qZJr3trQe2K9YN+g@mail.gmail.com>
 <CAFmfg2sT0sVVHOe5ZbDo5iDwE1Tk2oOXJiCKhNZv_hZVOVLbRw@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: <CAFmfg2sT0sVVHOe5ZbDo5iDwE1Tk2oOXJiCKhNZv_hZVOVLbRw@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [bitcoin-dev] Proposal for new "disabletx" p2p message
Precedence: list

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