[bitcoin-dev] death to the mempool, long live the mempool

[lisa neigut <niftynei@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2667 bytes --]

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’t
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’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.

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

[-- Attachment #2: Type: text/html, Size: 3139 bytes --]