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