diff options
| author | Anthony Towns <aj@erisian.com.au> | 2021-03-03 02:31:27 +1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-03-02 16:31:38 +0000 |
| commit | acf91f2972a2f4fe0b8e8a0bbfaf647bef5d924c (patch) | |
| tree | b20cab2077928581e0391bf391dbd9c0d40b5e77 | |
| parent | 56d05cad2c983efef96227c1d2fbcf13f3250f8a (diff) | |
| download | pi-bitcoindev-acf91f2972a2f4fe0b8e8a0bbfaf647bef5d924c.tar.gz pi-bitcoindev-acf91f2972a2f4fe0b8e8a0bbfaf647bef5d924c.zip | |
Re: [bitcoin-dev] Proposal for new "disabletx" p2p message
| -rw-r--r-- | 91/ba7a91e4264c8014e1b48cce8e5054bf585e7e | 135 |
1 files changed, 135 insertions, 0 deletions
diff --git a/91/ba7a91e4264c8014e1b48cce8e5054bf585e7e b/91/ba7a91e4264c8014e1b48cce8e5054bf585e7e new file mode 100644 index 000000000..daf9997cd --- /dev/null +++ b/91/ba7a91e4264c8014e1b48cce8e5054bf585e7e @@ -0,0 +1,135 @@ +Return-Path: <aj@erisian.com.au> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id A8B19C0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <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) +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + + |