From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id A8B19C0001 for ; Tue, 2 Mar 2021 16:31:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 9711481A6A for ; Tue, 2 Mar 2021 16:31:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.127 X-Spam-Level: * X-Spam-Status: No, score=1.127 tagged_above=-999 required=5 tests=[BAYES_50=0.8, KHOP_HELO_FCRDNS=0.324, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuCBCXp6YxfT for ; Tue, 2 Mar 2021 16:31:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5AFF883A94 for ; Tue, 2 Mar 2021 16:31:37 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1lH7vn-0004eN-MG; Wed, 03 Mar 2021 02:31:33 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Wed, 03 Mar 2021 02:31:27 +1000 Date: Wed, 3 Mar 2021 02:31:27 +1000 From: Anthony Towns To: John Newbery , Bitcoin Protocol Discussion Message-ID: <20210302163127.bjmzcyzdwrsm36fh@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] Proposal for new "disabletx" p2p message X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2021 16:31:38 -0000 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