[bitcoin-dev] Proposal for new "disabletx" p2p message
Anthony Towns
aj at erisian.com.au
Tue Mar 2 16:31:27 UTC 2021
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
More information about the bitcoin-dev
mailing list