From: Anthony Towns <aj@erisian•com.au>
To: John Newbery <john@johnnewbery•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal for new "disabletx" p2p message
Date: Wed, 3 Mar 2021 02:31:27 +1000 [thread overview]
Message-ID: <20210302163127.bjmzcyzdwrsm36fh@erisian.com.au> (raw)
In-Reply-To: <CAFmfg2sT0sVVHOe5ZbDo5iDwE1Tk2oOXJiCKhNZv_hZVOVLbRw@mail.gmail.com>
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
prev parent reply other threads:[~2021-03-02 16:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 16:35 Suhas Daftuar
2021-01-13 6:40 ` Matt Corallo
2021-01-14 5:32 ` Anthony Towns
2021-01-14 5:39 ` Matt Corallo
2021-01-14 6:46 ` Anthony Towns
2021-01-19 19:19 ` Suhas Daftuar
2021-03-01 20:58 ` John Newbery
2021-03-01 23:11 ` Antoine Riard
2021-03-02 12:11 ` John Newbery
2021-03-02 22:42 ` Antoine Riard
2021-03-02 16:31 ` Anthony Towns [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210302163127.bjmzcyzdwrsm36fh@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=john@johnnewbery$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox