public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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



      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 [bitcoin-dev] Proposal for new "disabletx" p2p message 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.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=john@johnnewbery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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