path: root/92/50adcecb3861088a2f4ef2150da0f2b8026b96

Return-Path: <niftynei@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9055BC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Oct 2021 02:56:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 6BA8B81010
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Oct 2021 02:56:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 z3Waw-cGYry2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Oct 2021 02:56:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [IPv6:2a00:1450:4864:20::22c])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 689E88100D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Oct 2021 02:56:35 +0000 (UTC)
Received: by mail-lj1-x22c.google.com with SMTP id o11so20385745ljg.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Oct 2021 19:56:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=qs0rlJYD+2NmGpWX8LJ7vmuQ3OlsZt6QltRTiXnOb2s=;
 b=piEwzssxRP2RbHT9K1Sagkewb+pulqhzVz4dJFtvOxxCe5p0/fk3fTaPp3k3avovJm
 BGYGnE70ZMD/36N3qeo8bYtaiNRLXgBgVi7Elf1sAOn2xJ7TYCHC0cTQfp2W2LAq6TtW
 wJRekXtObUP9EhSwVVzCk00K3hAlSExaCWHOMMWZ1fTqn4AHYIk2ur3XpKVuH95ALjZ9
 HQiPibDeT9GibfM7eyBgOv9FVTbHV45eBg/fdBE9w5QTOi2qO5f0N3SQPIAbx5cHRqNR
 w+wVQzls3eoLkJgni1pYlFyCIkzIbFVb8z/ZI5tpoinGOz6L01FhrbhEpdAY+0KT0FD+
 KwAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=qs0rlJYD+2NmGpWX8LJ7vmuQ3OlsZt6QltRTiXnOb2s=;
 b=gPMo+UVxUNiUb0cQaawKFuAMDl4ikHNIXdBec4T7wMULzy+KWr8nk/y1qHMBYBBVPG
 W1GJCLe2kgLSzMqWVPY5q6Abj1WBRSVUg0bDq/xW+672uPPc/pMysSCgUAH5XkNC+9tB
 3eUtCZOanhEwCiApcCRDs2cxyprS2eOJtnH909wcSOVfqvV0SsDEHfbT60ioZjfYQUof
 x1/mnlx1btBXLGm8KzMMONJYa4+8/G1+qB9qh0YnRnfUQ1bjUvowK3ENp6womNyS68mV
 3YVoR9Wtfe0sW1saxrESVJjbAfZg55MeDkfM6Bqukf3+jVi5fc7LlhteObmn5AOSgyxF
 0Z/A==
X-Gm-Message-State: AOAM5338HFMRYCsMCaW4/5iMFMJX6ad4lWiFY5uOl/lPItJcxaSIpnC0
 WKfuml4iUfQ+J0M28bozQEg9FLkQN/FkoXN19D+59rdZ
X-Google-Smtp-Source: ABdhPJza2wX8u0rHvrWoaXEJ/I4Vz7DgzSygRqU5x149PGWJo/zwOk7bGYsfzzsQgvJHoZ5gAbcjCaGdHMEC5eLvMLU=
X-Received: by 2002:a05:651c:246:: with SMTP id
 x6mr15970007ljn.266.1635216992705; 
 Mon, 25 Oct 2021 19:56:32 -0700 (PDT)
MIME-Version: 1.0
From: lisa neigut <niftynei@gmail.com>
Date: Mon, 25 Oct 2021 21:56:21 -0500
Message-ID: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000fb1e8f05cf389f56"
X-Mailman-Approved-At: Tue, 26 Oct 2021 07:37:38 +0000
Subject: [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: Tue, 26 Oct 2021 02:56:36 -0000

--000000000000fb1e8f05cf389f56
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

In a recent conversation with @glozow, I had the realization that the
mempool is obsolete and should be eliminated.

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)

Mempools make sense in a world where mining is done by a large number of
participating nodes, eg where the block template is constructed 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=E2=80=
=99t
know which participant will be constructing the winning block template.

In reality however, mempool relay is unnecessary where the majority of
hashpower and thus block template creation is concentrated in a
semi-restricted set.

Removing the mempool would greatly reduce the bandwidth requirement for
running a node, keep intentionality of transactions private until
confirmed/irrevocable, and naturally resolve all current issues inherent in
package relay and rbf rules. It also resolves the recent minimum relay
questions, as relay is no longer a concern for unmined transactions.

Provided the number of block template producing actors remains beneath, say
1000, it=E2=80=99d be quite feasible to publish a list of tor endpoints tha=
t nodes
can independently  + directly submit their transactions 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.

On the other hand, removing the mempool would greatly complicate solo
mining and would also make BetterHash proposals, which move the block
template construction away from a centralized mining pool back to the
individual miner, much more difficult. It also makes explicit the target
for DoS attacks.

A direct communication channel between block template construction 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) enforcing their own minimum security budget. In other
words, expressing 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

--000000000000fb1e8f05cf389f56
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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 realization that th=
e mempool is obsolete and should be eliminated.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Instead, users should submit their transactions dir=
ectly to mining pools, preferably over an anonymous communication network s=
uch 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 whe=
re the block template is constructed by a majority of the participants on t=
he network. In this case, it is necessary to socialize pending transaction =
data to all participants, as you don=E2=80=99t know which participant will =
be constructing the winning block template.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">In reality however, mempool relay is unnecessary where =
the majority of hashpower and thus block template creation is concentrated =
in a semi-restricted set.=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Removing the mempool would greatly reduce the bandwidth requireme=
nt for running a node, keep intentionality of transactions private until co=
nfirmed/irrevocable, and naturally resolve all current issues inherent in p=
ackage relay and rbf rules. It also resolves the recent minimum relay quest=
ions, as relay is no longer a concern for unmined transactions.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Provided the number of block templa=
te producing actors remains beneath, say 1000, it=E2=80=99d be quite feasib=
le to publish a list of tor endpoints that nodes can independently =C2=A0+ =
directly submit their transactions to. In fact, merely allowing users to se=
lect 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 mempo=
ol would greatly complicate solo mining and would also make BetterHash prop=
osals, which move the block template construction away from a centralized m=
ining pool back to the 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 constru=
ction venues and transaction proposers also provides a venue for direct fee=
dback wrt acceptable feerates at the time, which both makes transaction con=
firmation timelines less variable as well as provides block producers a mec=
hanism for (independently) enforcing their own minimum security budget. In =
other words, expressing a minimum acceptable feerate for continued operatio=
n.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Initial feerate estim=
ation would need to be based on published blocks, not pending transactions =
(as this information would no longer be available), or from direct interact=
ions with block producers.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">~niftynei</div>
</div>

--000000000000fb1e8f05cf389f56--