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
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
|
Return-Path: <email@yancy.lol>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 74034C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Oct 2022 11:06:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 4842B403A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Oct 2022 11:06:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4842B403A7
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ip5prqQtINO9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Oct 2022 11:06:38 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 52DC14035A
Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net
[217.70.183.201])
by smtp4.osuosl.org (Postfix) with ESMTPS id 52DC14035A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Oct 2022 11:06:38 +0000 (UTC)
Received: (Authenticated sender: email@yancy.lol)
by mail.gandi.net (Postfix) with ESMTPA id 6966B1BF206;
Sun, 30 Oct 2022 11:06:34 +0000 (UTC)
MIME-Version: 1.0
Date: Sun, 30 Oct 2022 12:06:32 +0100
From: email@yancy.lol
To: Anthony Towns <aj@erisian.com.au>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <Y13NM4dyuD6ktvlf@erisian.com.au>
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
<194063b733e539e8e24cfd83fa879ed0@dtrt.org>
<Y13NM4dyuD6ktvlf@erisian.com.au>
Message-ID: <41aec8aec49c5ca8e21f0641f5bb65fc@yancy.lol>
X-Sender: email@yancy.lol
Content-Type: multipart/alternative;
boundary="=_1eaf4296ec9b9f875f040b16e38db12f"
X-Mailman-Approved-At: Sun, 30 Oct 2022 11:23:39 +0000
Subject: Re: [bitcoin-dev] On mempool policy consistency
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: Sun, 30 Oct 2022 11:06:40 -0000
--=_1eaf4296ec9b9f875f040b16e38db12f
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
format=flowed
> Whether that's terrible or not depends on how easy it is to retry (and
> how
> likely the retry is to succeed) after a failure -- if a TCP packet
> fails,
> it just gets automatically resent, and if that succeeds, there's a
> little
> lag, but your connection is still usable
I'm not sure if that analogy fits here. A TCP packet will be retried
(as opposed to UDP), although usually the retry strategy is because of
an underlying connection issue, not a protocol mismatch or in this case
"policy" mismatch, right?
If network propagation and node discovery becomes an issue, and as
Antoine mentions, there becomes a need for competing services as I
understand it, could that give rise to indexes and trackers who spider
the network to create world view? Perhaps it's a bad idea since "third
party" trackers are security holes, however, to my knowledge, we already
have "trusted" nodes during the initial bootstrap process. Even so, I
don't think we could preclude such solutions from occurring organically
if the need is arises.
Cheers,
-Yancy
On 2022-10-30 02:02, Anthony Towns via bitcoin-dev wrote:
> On Fri, Oct 28, 2022 at 09:45:09PM -1000, David A. Harding via
> bitcoin-dev wrote:
>
>> I think this might be understating the problem. A 95% chance of
>> having
>> an outbound peer accept your tx conversely implies 1 in 20 payments
>> will
>> fail to propagate on their initial broadcast.
>
> Whether that's terrible or not depends on how easy it is to retry (and
> how
> likely the retry is to succeed) after a failure -- if a TCP packet
> fails,
> it just gets automatically resent, and if that succeeds, there's a
> little
> lag, but your connection is still usable. I think it's *conceivable*
> that
> a 5% failure rate could be detectable and automatically rectified. Not
> that I have a good idea how you'd actually do that, in a way that's
> efficient/private/decentralised...
>
>> Some napkin math: there are about 250,000 transactions a day; if
>> we round that up to 100 million a year and assume we only want one
>> transaction per year to fail to initially propagate on a network where
>> 30% of nodes have adopted a more permissive policy, lightweight
>> clients
>> will need to connect to over 50 randomly selected nodes.[1]
>
> A target failure probability of 1-in-1e8 means:
>
> * with 8 connections, you need 90% of the network to support your txs
> * with 12 connections, you need ~79%
> * with 24 connections (eg everyone running a long-lived node is
> listening, so long lived nodes make 12 outbound and receive about
> ~12 inbound; shortlived nodes just do 24 outbound), you need ~54%
>
> So with that success target, and no preferential peering, you need
> a majority of listening nodes to support your tx's features in most
> reasonable scenarios, I think.
>
>> For a more
>> permissive policy only adopted by 10% of nodes, the lightweight client
>> needs to connect to almost 150 nodes.
>
> I get 175 connections needed for that scenario; or 153 with a target
> failure rate of 1-in-10-million.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--=_1eaf4296ec9b9f875f040b16e38db12f
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Whether that's terrible or not depends on how easy it is to retry (and how<=
br />likely the retry is to succeed) after a failure -- if a TCP packet fai=
ls,<br />it just gets automatically resent, and if that succeeds, there's a=
little<br />lag, but your connection is still usable</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
I'm not sure if that analogy fits here. A TCP packet will be retried =
(as opposed to UDP), although usually the retry strategy is because of an u=
nderlying connection issue, not a protocol mismatch or in this case "policy=
" mismatch, right?</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
If network propagation and node discovery becomes an issue, and as <span st=
yle=3D"font-variant-ligatures: no-common-ligatures;"><span style=3D"font-fa=
mily: arial, sans-serif;">Antoine</span></span> mentions, there becomes a n=
eed for competing services as I understand it, could that give rise to inde=
xes and trackers who spider the network to create world view? Perhaps=
it's a bad idea since "third party" trackers are security holes, however, =
to my knowledge, we already have "trusted" nodes during the initial bootstr=
ap process. Even so, I don't think we could preclude such solutions f=
rom occurring organically if the need is arises.</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Cheers,</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
-Yancy</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
On 2022-10-30 02:02, Anthony Towns via bitcoin-dev wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">On Fri, Oct 28, 2022 at 09:45:09PM -1000, David A. Har=
ding via<br />bitcoin-dev wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">I think this might be understating the problem. =
A 95% chance of having<br />an outbound peer accept your tx conversely impl=
ies 1 in 20 payments will<br />fail to propagate on their initial broadcast=
=2E</blockquote>
<br />Whether that's terrible or not depends on how easy it is to retry (an=
d how<br />likely the retry is to succeed) after a failure -- if a TCP pack=
et fails,<br />it just gets automatically resent, and if that succeeds, the=
re's a little<br />lag, but your connection is still usable. I think it's *=
conceivable* that<br />a 5% failure rate could be detectable and automatica=
lly rectified. Not<br />that I have a good idea how you'd actually do that,=
in a way that's<br />efficient/private/decentralised...<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">Some napkin math: there are about 250,000 transactions=
a day; if<br />we round that up to 100 million a year and assume we only w=
ant one<br />transaction per year to fail to initially propagate on a netwo=
rk where<br />30% of nodes have adopted a more permissive policy, lightweig=
ht clients<br />will need to connect to over 50 randomly selected nodes.[1]=
</blockquote>
<br />A target failure probability of 1-in-1e8 means:<br /><br /> * wi=
th 8 connections, you need 90% of the network to support your txs<br />&nbs=
p;* with 12 connections, you need ~79%<br /> * with 24 connections (eg=
everyone running a long-lived node is<br /> listening, so=
long lived nodes make 12 outbound and receive about<br />  =
;~12 inbound; shortlived nodes just do 24 outbound), you need ~54%<br /><br=
/>So with that success target, and no preferential peering, you need<br />=
a majority of listening nodes to support your tx's features in most<br />re=
asonable scenarios, I think.<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">For a more<br />permissive policy only adopted by 10% =
of nodes, the lightweight client<br />needs to connect to almost 150 nodes.=
</blockquote>
<br />I get 175 connections needed for that scenario; or 153 with a target<=
br />failure rate of 1-in-10-million.<br /><br />Cheers,<br />aj<br />_____=
__________________________________________<br />bitcoin-dev mailing list<br=
/><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.linuxfoundation.org</a><br /><a href=3D"https://lists.linuxfoundation.or=
g/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noopener noreferre=
r">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></bloc=
kquote>
</div>
</body></html>
--=_1eaf4296ec9b9f875f040b16e38db12f--
|
