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
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 (&amp; HMRH)</div>
<div>of Hougun Manor &amp; Glencoe &amp; British Empire</div>
<div>MR. Damian A. James Williamson</div>
<div>Wills</div>
<div><br>
</div>
<div>et al.</div>
<div><br>
</div>
<div>&nbsp;</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>&nbsp;</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 &lt;bit=
coin-dev-bounces@lists.linuxfoundation.org&gt; on behalf of lisa neigut via=
 bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br>
<b>Sent:</b> Tuesday, 26 October 2021 1:56 PM<br>
<b>To:</b> bitcoin-dev@lists.linuxfoundation.org &lt;bitcoin-dev@lists.linu=
xfoundation.org&gt;<br>
<b>Subject:</b> [bitcoin-dev] death to the mempool, long live the mempool</=
font>
<div>&nbsp;</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.&nbsp;</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 &nbsp;+ 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_--