1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
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
|
