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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 090C1C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 May 2022 00:35:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id E5EC460864
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 May 2022 00:35:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Pd3X1yYYjXUa
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 May 2022 00:35:41 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp3.osuosl.org (Postfix) with ESMTPS id D003D6080A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 May 2022 00:35:40 +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 1nr7f5-00021K-9M; Wed, 18 May 2022 10:35:37 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Wed, 18 May 2022 10:35:31 +1000
Date: Wed, 18 May 2022 10:35:31 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Gloria Zhao <gloriajzhao@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220518003531.GA4402@erisian.com.au>
References: <CAFXO6=JROe_9ih2h+_CCH-UbxehsM5RQ6YyNnPesEpveBEtdow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFXO6=JROe_9ih2h+_CCH-UbxehsM5RQ6YyNnPesEpveBEtdow@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] Package Relay Proposal
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: Wed, 18 May 2022 00:35:42 -0000
On Tue, May 17, 2022 at 12:01:04PM -0400, Gloria Zhao via bitcoin-dev wrote:
> ====New Messages====
> Three new protocol messages are added for use in any version of
> package relay. Additionally, each version of package relay must define
> its own inv type and "pckginfo" message version, referred to in this
> document as "MSG_PCKG" and "pckginfo" respectively. See
> BIP-v1-packages for a concrete example.
The "PCKG" abbreviation threw me for a loop; isn't the usual
abbreviation "PKG" ?
> =====sendpackages=====
> |version || uint32_t || 4 || Denotes a package version supported by the
> node.
> |max_count || uint32_t || 4 ||Specifies the maximum number of transactions
> per package this node is
> willing to accept.
> |max_weight || uint32_t || 4 ||Specifies the maximum total weight per
> package this node is willing
> to accept.
Does it make sense for these to be configurable, rather than implied
by the version?
I presume the idea is to cope with people specifying different values for
-limitancestorcount or -limitancestorsize, but if people are regularly
relaying packages around, it seems like it becomes hard to have those
values really be configurable while being compatible with that?
I guess I'm asking: would it be better to either just not do sendpackages
at all if you're limiting ancestors in the mempool incompatibly; or
alternatively, would it be better to do the package relay, then reject
the particular package if it turns out too big, and log that you've
dropped it so that the node operator has some way of realising "whoops,
I'm not relaying packages properly because of how I configured my node"?
> 5. If 'fRelay==false' in a peer's version message, the node must not
> send "sendpackages" to them. If a "sendpackages" message is
> received by a peer after sending `fRelay==false` in their version
> message, the sender should be disconnected.
Seems better to just say "if you set fRelay=false in your version
message, you must not send sendpackages"? You already won't do packages
with the peer if they don't also announce sendpackages.
> 7. If both peers send "wtxidrelay" and "sendpackages" with the same
> version, the peers should announce, request, and send package
> information to each other.
Maybe: "You must not send sendpackages unless you also send wtxidrelay" ?
As I understand it, the two cases for the protocol flow are "I received
an orphan, and I'd like its ancestors please" which seems simple enough,
and "here's a child you may be interested in, even though you possibly
weren't interested in the parents of that child". I think the logic for
the latter is:
* if tx C's fee rate is less than the peer's feefilter, skip it
(will maybe treat it as a parent in some package later though)
* if tx C's ancestor fee rate is less than the peer's feefilter, skip
it?
* look at the lowest ancestor fee rate for any of C's in-mempool
parents
* if that is higher than the peer's fee filter, send a normal INV
* if it's lower than the peer's fee filter, send a PCKG INV
Are "getpckgtxns" / "pcktxns" really limited to packages, or are they
just a general way to request a batch of transactions? Particularly in
the case of requesting the parents of an orphan tx you already have,
it seems hard for the node receiving getpckgtxns to validate that the
txs are related in some way; but also it doesn't seem very necessary?
Maybe call those messages "getbatchtxns" and "batchtxns" and allow them to
be used more generally, potentially in ways unrelated to packages/cpfp?
The "only be sent if both peers agreed to do package relay" rule could
simply be dropped, I think.
> 4. The reciever uses the package information to decide how to request
> the transactions. For example, if the receiver already has some of
> the transactions in their mempool, they only request the missing ones.
> They could also decide not to request the package at all based on the
> fee information provided.
Shouldn't the sender only be sending package announcements when they know
the recipient will be interested in the package, based on their feefilter?
> =====pckginfo1=====
> {|
> | Field Name || Type || Size || Purpose
> |-
> |blockhash || uint256 || 32 || The chain tip at which this package is
> defined.
> |-
> |pckg_fee||CAmount||4|| The sum total fees paid by all transactions in the
> package.
CAmount in consensus/amount.h is a int64_t so shouldn't this be 8
bytes? If you limit a package to 101kvB, an int32_t is enough to cover
any package with a fee rate of about 212 BTC/block or lower, though.
> |pckg_weight||int64_t||8|| The sum total weight of all transactions in the
> package.
The maximum block weight is 4M, and the default -limitancestorsize
presumably implies a max package weight of 404k; seems odd to provide
a uint64_t rather than an int32_t here, which easily allows either of
those values?
> 2. ''Only 1 child with unconfirmed parents.'' The package must consist
> of one transaction and its unconfirmed parents. There must not be
> any other transactions in the package. Other dependency relationships
> may exist within the package (e.g. one parent may spend the output of
> another parent) provided that topological order is respected.
I think this means that some of the parents could also have unconfirmed
parents, but they won't be included in the package, and must be requested
via the recipient-initiated approach?
> 5. ''Total fees and weight.'' The 'total_fee' and 'total_weight'
> fields must accurately represent the sum total of all transactions'
> fees and weights as defined in BIP141, respectively.
Presumably this excludes any unconfirmed grandparents and earlier
ancestors since they aren't part of the package, in this approach? Doesn't
that make this both harder to calculate (assuming we already have
ancestor summaries) and less useful, in the case where those ancestors
have a lower fee rate?
> ''Q: Can "getpckgtxns" and "pckgtxns" messages contain only one
> transaction?''
> Yes.
This would be normal if you're requesting a single missing parent for
an orphan you've received, I think?
I'm slightly surprised the process is:
-> INV PCKG1 C
<- GETDATA PCKG1 C
-> PCKGINFO1 blockhash A B C fee weight
rather than announcing the package fee info in the first message.
But if the sender is already applying the feefilter to the package before
announcing it, it probably doesn't matter, and means you're only getting
a 32B INV from every peer, rather than a 32*(n+2) PCKGINFO1 message from
every peer.
I guess tx relay is low priority enough that it wouldn't be worth tagging
some peers as "high bandwidth" and having them immediately announce the
PCKGINFO1 message, and skip the INV/GETDATA step?
Cheers,
aj
|