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
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
|
Return-Path: <willtech@live.com.au>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 414F9C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Oct 2021 08:44:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 23D4180D0F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Oct 2021 08:44:49 +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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham 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 6zhOYdH8KKQy
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Oct 2021 08:44:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from KOR01-SL2-obe.outbound.protection.outlook.com
(mail-sl2kor01olkn0163.outbound.protection.outlook.com [104.47.108.163])
by smtp1.osuosl.org (Postfix) with ESMTPS id D4F4080CF8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Oct 2021 08:44:46 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=ICxm9epQlw6UcqojG8oQ6YAXB8hkhJuAuHQ6V+zGv5BIOmZuuJYRKskrlDxZ3EyBlG7FkpbhWQMTzYt2V8Hndz2xB0BxfjtihgQgsZ9nNmqw4K8SHSMc1eT4QTcfKuJFWaRivKoITiyqQCDxAL2TmYR2Ff1lwkKiAvodYD2RfppXyuX2uuX8AUIL7Qfy45Kc4xcf1+HebJxLxixfj1MwBZ1lRud0iXgWivD0yD0CDdgNczjvankrzO0YaG/xCOO2ieKaDFPAC6Q3Etow+UXFaPWyV34eVlklMOnQLQ8Q/+EzDMXCoyWKt8izkfQJn75eR4BiDntplqcBFGhaiDzh2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=gdlcDVPHXia/UfqiVz6rcevqaRqU4vfhF4aBk8dlLQY=;
b=mYcIYClerqB1/8/1yFeVXa993Iggu4o579sPPv3jxVDfkWAQpzJn3Vg6YSESzbyoNpzVWKx6QNbJV7T6NxAwqUsM9HpT+zzco6J2m6FSkq5KqBOlBSoeCVkpXiO1ggd+HxBqI0At5Bq+UHLWNLS7anoSaepayK+nHv6P0G35sBRoxXNZTuiWp3C1nVXyu5ImbzcxCUuNVVwGAWkfC6JKpel1ZGyYBdnfGFcQEFoLr7br7fYdip73NiGHew06vfPA6JIY+gatdfcIXkADEs49Yw2Vc6gejKN/uc5PyWWb6sk1pUlckqeN0j3QXFkzcmaTAC1mROuI2GXfmrpJhkJ+eg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
dkim=none; arc=none
Received: from PS2P216MB1089.KORP216.PROD.OUTLOOK.COM (2603:1096:301:52::11)
by PU4P216MB1370.KORP216.PROD.OUTLOOK.COM (2603:1096:301:a2::10) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.14; Wed, 27 Oct
2021 08:44:42 +0000
Received: from PS2P216MB1089.KORP216.PROD.OUTLOOK.COM
([fe80::4c6c:a1dc:c8c0:fed2]) by PS2P216MB1089.KORP216.PROD.OUTLOOK.COM
([fe80::4c6c:a1dc:c8c0:fed2%3]) with mapi id 15.20.4649.014; Wed, 27 Oct 2021
08:44:42 +0000
From: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>, lisa neigut <niftynei@gmail.com>
Thread-Topic: [bitcoin-dev] death to the mempool, long live the mempool
Thread-Index: AQHXyjxhpu8HKywNhEGV4U0LSP0Vl6vmiFrX
Date: Wed, 27 Oct 2021 08:44:42 +0000
Message-ID: <PS2P216MB1089038AABE45CE8FF36E32F9D859@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>
References: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
In-Reply-To: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
suggested_attachment_session_id: c2c5f273-1199-66da-c4d9-333ab4ac67fd
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [WdnSLaLNV7adFgu3HE+eRQnbObqMeSaa]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6f3f1743-e768-4ea3-1248-08d999260551
x-ms-traffictypediagnostic: PU4P216MB1370:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: fdmJkLduRR2b9FA9M788JXALVeciQJObJur8Qpuhn672HV0LsnCA+GehuPS3HjI4zbU+e9yUGptN7W/X9+Dggm3LlSMVJCrTNrMJPuZAR/cwb4mEFKkECdZ7xQcuZFlzbhlE9/2jqBEET9QSmZFD2u/kk7ujZII232p3VbiuHoHLxw19qfSj6wtVsK9FfyrGayF3Ia8laqzlQO+9SXOmcv636fwhOHD+yZxi/m2cV8GbbIKltB4fdmp+B8OmPE/nupuN5vSHNqLAxOtHDDOgCLwxD196CZsCQdiuCYGxTG1LBMT0EMojhvHAJP5Yc5W2rg8xCyUkMzAJYlICjyi2KWnJFTbsHyRYk2FV3zkuw2qoXUdRG7VES6yNW+FUwK67fHjHvt0p22HgG+3EycYZTY574BzWHfPkoCeXocZzu0g8v5taayAko/0ECBf4EHsG2Is6ql4K26Y5rCEFOFnZl6OCGp38jSq5MdOX78e68hHQMF2VSLx4b7eXaKjvrGk2r5hOD5TX41bDhQza+uLF8ibM1oU8Cq7nKjHJ9/UJf6n6TWZb/9+COxF7ERq9zNNW3VXDqUFS68FhOegqgnk79w==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: WAxXNMvr7asfNGxtO6OdHOu6UaU5zuDiCQ5nutnGnJsQO81hAVWrbJW5V2l7S0iKk6XsOF/P48RQLsfpQcocwowvRCwlL3FLFCsfTSpVo7G6ep1kDVZ+G5uiQ5rrULUTqzhk4bBcyI+5yvWoLe1SmmWa1IYOaPzrkVuZJ+OBNJmsjhMo5QZ3tcQNENeust5+nBTEzGEZuJUBA3Ojaz8PW5TDsj/h70FAEa3R75BiNZNUFDg2H/EOt19qVL87N6Xv8WkBzJAl1k82La6P7zq8h+lF1Dqio7FgSGsO/4qSTj++x+QVMrEQVfLdK3KvlPydEXqpq1sCpqxw1IBsS71InTJLr6LXo2LK9FXOsD+J27TmbDZ+BobtGsmT6I9O76Q11MjjQLxsYcReyF0rtqx29j6OWEiSpPWLSF1yWtPuQrWlK9twGSZlLZLKLUpN/bz0L+rcbb28PN19LEHmQyoH0FLrKcoraysiCrRfXmGBVGMm3JnDSnR3gxhCnwgFtwhN0EzyoAWd26b4HxPKTRdZd0SibHhbPh+P1fw6pT+AvECehGG8cdZAxPVdiaOcN2afeMiGdRZJT0qDkeAb2r4+mh/xhxLXVLRoNxDcILClHXvsC80mbdALh0+gkcCtjNYqUfKCe+SqAAQ+B3rtwRHMFrw2w+I8byqLUdevVOJ3nQhRgevHfvtBbKlhjzR8bqhPmlhcdbl8gTqLpBwSpKvFkA==
Content-Type: multipart/alternative;
boundary="_000_PS2P216MB1089038AABE45CE8FF36E32F9D859PS2P216MB1089KORP_"
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-af45a.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PS2P216MB1089.KORP216.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f3f1743-e768-4ea3-1248-08d999260551
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2021 08:44:42.5865 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU4P216MB1370
X-Mailman-Approved-At: Wed, 27 Oct 2021 16:52:43 +0000
Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
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, 27 Oct 2021 08:44:49 -0000
--_000_PS2P216MB1089038AABE45CE8FF36E32F9D859PS2P216MB1089KORP_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Good Afternoon,
No. This has been discussed previously and eliminated as there is no proof =
that the transaction can exist without population through the mempool. As a=
method of payment not hearing about a transaction until it is possibly min=
ed three months later as I have experienced is non-functional, there were d=
iscussions in this mailing list. The purpose of the mempool is not gossip i=
t is gossip and any node technically can mine if they do.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
duigco.org DUIGCO API
and other projects
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this emai=
l if misdelivered.
________________________________
From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf=
of lisa neigut via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Tuesday, 26 October 2021 1:56 PM
To: bitcoin-dev@lists.linuxfoundation.org <bitcoin-dev@lists.linuxfoundatio=
n.org>
Subject: [bitcoin-dev] death to the mempool, long live the mempool
Hi all,
In a recent conversation with @glozow, I had the realization that the mempo=
ol is obsolete and should be eliminated.
Instead, users should submit their transactions directly to mining pools, p=
referably over an anonymous communication network such as tor. This can eas=
ily be achieved by mining pools running a tor onion node for this express p=
urpose (or via a lightning network extension etc)
Mempools make sense in a world where mining is done by a large number of pa=
rticipating nodes, eg where the block template is constructed by a majority=
of the participants on the network. In this case, it is necessary to socia=
lize pending transaction data to all participants, as you don=92t know whic=
h participant will be constructing the winning block template.
In reality however, mempool relay is unnecessary where the majority of hash=
power and thus block template creation is concentrated in a semi-restricted=
set.
Removing the mempool would greatly reduce the bandwidth requirement for run=
ning a node, keep intentionality of transactions private until confirmed/ir=
revocable, and naturally resolve all current issues inherent in package rel=
ay and rbf rules. It also resolves the recent minimum relay questions, as r=
elay is no longer a concern for unmined transactions.
Provided the number of block template producing actors remains beneath, say=
1000, it=92d be quite feasible to publish a list of tor endpoints that nod=
es can independently + directly submit their transactions to. In fact, mer=
ely allowing users to select their own list of endpoints to use alternative=
ly to the mempool would be a low effort starting point for the eventual rep=
lacement.
On the other hand, removing the mempool would greatly complicate solo minin=
g and would also make BetterHash proposals, which move the block template c=
onstruction away from a centralized mining pool back to the individual mine=
r, much more difficult. It also makes explicit the target for DoS attacks.
A direct communication channel between block template construction venues a=
nd transaction proposers also provides a venue for direct feedback wrt acce=
ptable feerates at the time, which both makes transaction confirmation time=
lines less variable as well as provides block producers a mechanism for (in=
dependently) enforcing their own minimum security budget. In other words, e=
xpressing a minimum acceptable feerate for continued operation.
Initial feerate estimation would need to be based on published blocks, not =
pending transactions (as this information would no longer be available), or=
from direct interactions with block producers.
~niftynei
--_000_PS2P216MB1089038AABE45CE8FF36E32F9D859PS2P216MB1089KORP_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
Good Afternoon,</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
No. This has been discussed previously and eliminated as there is no proof =
that the transaction can exist without population through the mempool. As a=
method of payment not hearing about a transaction until it is possibly min=
ed three months later as I have
experienced is non-functional, there were discussions in this mailing list=
. The purpose of the mempool is not gossip it is gossip and any node techni=
cally can mine if they do.</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
</div>
<div id=3D"Signature">
<div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<div>KING JAMES HRMH
<div>Great British Empire</div>
<div><br>
</div>
<div>Regards,</div>
<div>The Australian</div>
<div>LORD HIS EXCELLENCY JAMES HRMH (& HMRH)</div>
<div>of Hougun Manor & Glencoe & British Empire</div>
<div>MR. Damian A. James Williamson</div>
<div>Wills</div>
<div><br>
</div>
<div>et al.</div>
<div><br>
</div>
<div> </div>
<div>Willtech</div>
<div>www.willtech.com.au</div>
<div>www.go-overt.com</div>
<div>duigco.org DUIGCO API</div>
<div>and other projects</div>
<div> </div>
<div><br>
</div>
<div>m. 0487135719</div>
<div>f. +61261470192</div>
<div><br>
</div>
<div><br>
</div>
This email does not constitute a general advice. Please disregard this emai=
l if misdelivered.<br>
</div>
</div>
</div>
</div>
</div>
<div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> bitcoin-dev <bit=
coin-dev-bounces@lists.linuxfoundation.org> on behalf of lisa neigut via=
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org><br>
<b>Sent:</b> Tuesday, 26 October 2021 1:56 PM<br>
<b>To:</b> bitcoin-dev@lists.linuxfoundation.org <bitcoin-dev@lists.linu=
xfoundation.org><br>
<b>Subject:</b> [bitcoin-dev] death to the mempool, long live the mempool</=
font>
<div> </div>
</div>
<div>
<div>
<div dir=3D"auto">Hi all,</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">In a recent conversation with @glozow, I had the realizat=
ion that the mempool is obsolete and should be eliminated.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Instead, users should submit their transactions directly =
to mining pools, preferably over an anonymous communication network such as=
tor. This can easily be achieved by mining pools running a tor onion node =
for this express purpose (or via a
lightning network extension etc)</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Mempools make sense in a world where mining is done by a =
large number of participating nodes, eg where the block template is constru=
cted by a majority of the participants on the network. In this case, it is =
necessary to socialize pending transaction
data to all participants, as you don=92t know which participant will be co=
nstructing the winning block template.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">In reality however, mempool relay is unnecessary where th=
e majority of hashpower and thus block template creation is concentrated in=
a semi-restricted set. </div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Removing the mempool would greatly reduce the bandwidth r=
equirement for running a node, keep intentionality of transactions private =
until confirmed/irrevocable, and naturally resolve all current issues inher=
ent in package relay and rbf rules.
It also resolves the recent minimum relay questions, as relay is no longer=
a concern for unmined transactions.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Provided the number of block template producing actors re=
mains beneath, say 1000, it=92d be quite feasible to publish a list of tor =
endpoints that nodes can independently + directly submit their transa=
ctions to. In fact, merely allowing users
to select their own list of endpoints to use alternatively to the mempool =
would be a low effort starting point for the eventual replacement.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">On the other hand, removing the mempool would greatly com=
plicate solo mining and would also make BetterHash proposals, which move th=
e block template construction away from a centralized mining pool back to t=
he individual miner, much more difficult.
It also makes explicit the target for DoS attacks.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">A direct communication channel between block template con=
struction venues and transaction proposers also provides a venue for direct=
feedback wrt acceptable feerates at the time, which both makes transaction=
confirmation timelines less variable
as well as provides block producers a mechanism for (independently) enforc=
ing their own minimum security budget. In other words, expressing a minimum=
acceptable feerate for continued operation.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Initial feerate estimation would need to be based on publ=
ished blocks, not pending transactions (as this information would no longer=
be available), or from direct interactions with block producers.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">~niftynei</div>
</div>
</div>
</div>
</body>
</html>
--_000_PS2P216MB1089038AABE45CE8FF36E32F9D859PS2P216MB1089KORP_--
|