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

From: Antoine Riard <antoine.riard@gmail•com>
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 19:44:45 -0400	[thread overview]
Message-ID: <CALZpt+E_47wmDg3Z2N5=z5x3cca5vSxP6fgYzMK_pybwp1161g@mail.gmail.com> (raw)
In-Reply-To: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>

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

Hi Lisa,

Network mempools constitute a blockspace marketplace where block demand
meets the offer in real-time. Block producers are acting to discover the
best feerate bids compensating for their operational costs and transaction
proposers are acting to offer the best feerate in function of their
confirmation preferences.

Of course in a distributed system like bitcoin, we can't guarantee perfect
information from the market participants. But moving away from this model
by decreasing the ability of the non-mining nodes to observe the current
demand is softening the requirements for potential attackers.

As transaction proposers are competing with each other to publish, they
have an interest to "front-run" each other by querying the pending
transactions to the block producers instead of observing only the published
blocks. Therefore good connections to
the block producers are now critical and censorship-resistance of the
mining endpoints must be guaranteed.

Such a list of endpoints couldn't be static otherwise it's an artificial
barrier to enter in the mining competition, and as such a centralization
vector. Dynamic, trust-minimized discovery of the mining endpoints assumes
an address-relay network, of which the robustness must be high enough
against sophisticated sybil attacks. One current defense mechanism in core
to achieve that is selecting outbound peers based in different /16 subnets
as it's harder for an attacker to obtain IP addresses. Replicating this
mechanism for the mining endpoints binds the mining topology to the
Internet one, which is downgrading the mining competition.

Relying on tor to guarantee the confidentiality of the transaction
announcement is raising its own issues. Flowing by default all the bitcoin
traffic over tor will change the incentive structure of tor attackers,
potentially attracting a new class of attackers able to do deanonymization
attacks, not that expensive in practice [0]. Tor bridges are another
censorship vector as the fingerprint of the bitcoin traffic (a block every
10 min, etc) make it possible to drop or delay the tor channel, in the lack
of high-bandwidth consuming "synthetic" traffic.

Further, identified mining endpoints make it easier to launch partition
attacks, where mining mempools are sent low-feerate clusters of
transactions, to prevent the replacement by a better feerate offer. This is
especially concerning for L2 nodes with time-sensitive requirements [1]

Lastly, removing the mempool won't solve the current issues inherent with
pre-signed transactions under the mempool min fee as ultimately miner's
mempools are also finite in memory and a dynamic lower bound must exist to
prevent spam. These lower bounds potentially increase after the signature
exchange of the time-sensitive transactions.

Antoine

[0] https://www.usenix.org/system/files/sec19-jansen.pdf
[1] See "The Ugly"
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html

Le mar. 26 oct. 2021 à 03:37, lisa neigut via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> a écrit :

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

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