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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5DAB3C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 May 2022 18:55:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 374006136B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 May 2022 18:55:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Ls40MwATBaNr
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 May 2022 18:55:45 +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 66FC66136A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 May 2022 18:55:45 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=[127.0.0.1])
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1ntwAX-00057v-CN; Thu, 26 May 2022 04:55:42 +1000
Date: Wed, 25 May 2022 14:55:35 -0400
From: Anthony Towns <aj@erisian.com.au>
To: Gloria Zhao <gloriajzhao@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
User-Agent: K-9 Mail for Android
In-Reply-To: <CAFXO6=K6FXNFwOZ3VyT6_RZY2F2BX+iTy+MyOshRBfNnn9Hqyg@mail.gmail.com>
References: <CAFXO6=JROe_9ih2h+_CCH-UbxehsM5RQ6YyNnPesEpveBEtdow@mail.gmail.com>
<20220518003531.GA4402@erisian.com.au>
<CAFXO6=LWM4eHM=zJhejw5981+8h7QHTbwpz0jEbWkrLOX0037Q@mail.gmail.com>
<20220523213416.GA6151@erisian.com.au>
<CAFXO6=KXToP2MFWQ1JVKX6jV++utw8E4Z13T4cH+mfgtyeUx_A@mail.gmail.com>
<2B3D1901-901C-4000-A2B9-F6857FCE2847@erisian.com.au>
<CAFXO6=K6FXNFwOZ3VyT6_RZY2F2BX+iTy+MyOshRBfNnn9Hqyg@mail.gmail.com>
Message-ID: <8FFE048D-854F-4D34-85DA-CE523C16EEB0@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score-int: -28
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, 25 May 2022 18:55:46 -0000
On 24 May 2022 5:05:35 pm GMT-04:00, Gloria Zhao via bitcoin-dev <bitcoin-d=
ev@lists=2Elinuxfoundation=2Eorg> wrote:
>To clarify, in this situation, I'm imagining something like
>A: 0 sat, 100vB
>B: 1500 sat, 100vB
>C: 0 sat, 100vB
>X: 500 sat, 100vB
>feerate floor is 3sat/vB
>
>With the algo:
>> * is X alone above my fee rate? no, then forget it
>> * otherwise, s :=3D X=2Esize, f :=3D X=2Efees, R :=3D [X]
>> * for P =3D P1=2E=2EPn:
>> * do I already have P? then skip to the next parent
>> * s +=3D P=2Esize, f +=3D P=2Efees, R +=3D [P]
>> * if f/s above my fee rate floor? if so, request all the txs in R
>
>We'd erroneously ask for A+B+C+X, but really we should only take A+B=2E
>But wouldn't A+B also be a package that was announced for B?
In theory, yes, but maybe it was announced earlier (while our node was dow=
n?) or had dropped from our mempool or similar, either way we don't have th=
ose txs yet=2E
>Please lmk if you were imagining something different=2E I think I may be
>missing something=2E
That's what I was thinking, yes=2E
So the other thing is what happens if the peer announcing packages to us i=
s dishonest?
They announce pkg X, say X has parents A B C and the fee rate is garbage=
=2E But actually X has parent D and the fee rate is excellent=2E Do we requ=
est the package from another peer, or every peer, to double check? Otherwis=
e we're allowing the first peer we ask about a package to censor that tx fr=
om us?
I think the fix for that is just to provide the fee and weight when announ=
cing the package rather than only being asked for its info? Then if one pee=
r makes it sound like a good deal you ask for the parent txids from them, d=
edupe, request, and verify they were honest about the parents=2E
>> Is it plausible to add the graph in?
Likewise, I think you'd have to have the graph info from many nodes if you=
're going to make decisions based on it and don't want hostile peers to be =
able to trick you into ignoring txs=2E
Other idea: what if you encode the parent txs as a short hash of the wtxid=
(something like bip152 short ids? perhaps seeded per peer so collisions wi=
ll be different per peer?) and include that in the inv announcement? Would =
that work to avoid a round trip almost all of the time, while still giving =
you enough info to save bw by deduping parents?
> For a maximum 25 transactions,
>23*24/2 =3D 276, seems like 36 bytes for a child-with-parents package=2E
If you're doing short ids that's maybe 25*4B=3D100B already, then the abov=
e is up to 36% overhead, I guess=2E Might be worth thinking more about, but=
maybe more interesting with ancestors than just parents=2E
>Also side note, since there are no size/count params, wondering if we
>should just have "version" in "sendpackages" be a bit field instead of
>sending a message for each version=2E 32 versions should be enough right?
Maybe but a couple of messages per connection doesn't really seem worth ar=
guing about?
Cheers,
aj
--=20
Sent from my phone=2E
|
