From: Pieter Wuille <bitcoin-dev@wuille•net>
To: lisa neigut <niftynei@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
Date: Tue, 26 Oct 2021 16:26:43 +0000 [thread overview]
Message-ID: <yHOT3ZeXzyc6k8iXDhHfeZuZeYIND51V_-EcadZ9womZdjRLIVOynuOr8lD5FZlSgAGTrgLIzzTKrKxAPz390NoOykkA6wM5CjYgC3yPzT4=@wuille.net> (raw)
In-Reply-To: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4586 bytes --]
On Monday, October 25th, 2021 at 10:56 PM, lisa neigut via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi all,
>
> In a recent conversation with @glozow, I had the realization that the mempool is obsolete and should be eliminated.
Hi Lisa,
I see where this idea is coming from, especially as it relates to reducing complexities around transaction relays, but I strongly believe this is throwing out the baby with the bathwater. Comments inline below.
> In reality however, mempool relay is unnecessary where the majority of hashpower and thus block template creation is concentrated in a semi-restricted set.
The *entire* reason mining and PoW exist, as opposed to having a fixed, centralized (set of) actors who decide transaction ordering, is to make the "censorship rights" of the network permissionless. It is essential that anyone can become a miner if they dislike what existing miners are doing, with income close to proportional to their investment. The existing reality isn't perfect, but it's fairly close to that. Sure, at any given point in time, a nontrivial fraction of mining power is in the hands of a few, but over time, those can, and have, changed a lot. Furthermore, if miners were to actually exercise censorship, it could quite reasonably incentivize other ecosystem players to start mining, perhaps close at cost or even at a small loss.
Your proposal, as far as I can tell, makes it *far* harder to become a miner. Ideas to provide a mechanism for miners to publish their "tx submit" URL/IP/onion on chain don't help; that's dependent on other miners to not censor the publishing. Furthermore, it gives a tremendous centralizing incentive: it's just far easier for most wallets to just submit to the largest few pools, because the cost/complexity of an additional submission is independent of the pool's hashrate, but the benefit is directly proportional to it. There would be very little incentive to submit to a sub-1% pool for anyone.
> Removing the mempool would greatly reduce the bandwidth requirement for running a node,
That's not true due to compact blocks (most transactions are relayed exactly once to every node, and not repeated in blocks), and with Erlay it will be even less the case.
> keep intentionality of transactions private until confirmed/irrevocable,
Except to miners; it's replacing socialized transparency with a few who get to see the actual details. Not the same scale obviously, but there is some similarity to banks in the existing financial system. Our privacy goals shouldn't be relying on a few trusted gatekeepers.
> 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.
There are other solutions to this, like weak blocks (miners get to relay partial PoW solutuon of say 10% of the difficulty to the network; and nodes which receive such a weak block can "forcibly" insert its transaction to their mempool, as there is evidence it's actually being worked on, while still being DoS resistant because partial PoW is still PoW).
> Provided the number of block template producing actors remains beneath, say 1000, it’d be quite feasible to publish a list of tor endpoints that 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.
In this scenario, there is no incentive for miners to relay to each other. The fewer other miners know about a high fee-paying transaction, the better you as a miner.
More conceptually: it is a responsibility of the full node network to relay blocks between miners quickly, to limit how much advantage well-connected miners over less-well-connected ones have. If the network doesn't have the transactions being included in those blocks, this is *far* harder (additional roundtrips, as nodes can't reconstruct from mempools).
> 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.
Yes, it's definitely easier. That doesn't make it right.
Cheers,
--
Pieter
[-- Attachment #2: Type: text/html, Size: 5847 bytes --]
next prev parent reply other threads:[~2021-10-26 16:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-26 2:56 lisa neigut
2021-10-26 8:02 ` ZmnSCPxj
2021-10-26 8:31 ` eric
2021-10-26 8:56 ` ZmnSCPxj
2021-10-26 14:09 ` darosior
2021-10-26 16:38 ` ZmnSCPxj
2021-10-26 16:26 ` Pieter Wuille [this message]
2021-10-26 18:16 ` Gloria Zhao
2021-10-28 1:04 ` ZmnSCPxj
2021-11-03 10:12 ` ZmnSCPxj
2021-10-26 23:44 ` Antoine Riard
2021-10-27 20:01 ` Peter Todd
2021-10-27 8:44 ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-27 23:05 ` yanmaani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='yHOT3ZeXzyc6k8iXDhHfeZuZeYIND51V_-EcadZ9womZdjRLIVOynuOr8lD5FZlSgAGTrgLIzzTKrKxAPz390NoOykkA6wM5CjYgC3yPzT4=@wuille.net' \
--to=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=niftynei@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox