summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorlisa neigut <niftynei@gmail.com>2021-10-25 21:56:21 -0500
committerbitcoindev <bitcoindev@gnusha.org>2021-10-26 02:56:36 +0000
commit2d5e5bf5b9df5a8bf1c33ba14bf4537c22a3cfb6 (patch)
tree58ee97db10c70f0b230557002321b9b5a15ab3d1
parent825dcabb2bb4a4d89ccae3370c41c4d0c9801ec2 (diff)
downloadpi-bitcoindev-2d5e5bf5b9df5a8bf1c33ba14bf4537c22a3cfb6.tar.gz
pi-bitcoindev-2d5e5bf5b9df5a8bf1c33ba14bf4537c22a3cfb6.zip
[bitcoin-dev] death to the mempool, long live the mempool
Diffstat
-rw-r--r--92/50adcecb3861088a2f4ef2150da0f2b8026b96190
1 files changed, 190 insertions, 0 deletions
diff --git a/92/50adcecb3861088a2f4ef2150da0f2b8026b96 b/92/50adcecb3861088a2f4ef2150da0f2b8026b96
new file mode 100644
index 000000000..85e0d2449
--- /dev/null
+++ b/92/50adcecb3861088a2f4ef2150da0f2b8026b96
@@ -0,0 +1,190 @@
+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--
+
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-30 08:46:24 +0000