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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
