Date: Tue, 26 Oct 2021 08:02:24 +0000
To: lisa neigut <niftynei@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <wIXL_bs_B1FfWrIOMjdog--VwQWD_okme8nPjerWyszHuKhFcPTi3yetwPKYYYR79PEeQcbA3lqZTL107k_KED8-RMs4HPyvhLh5b1miSr4=@protonmail.com>
In-Reply-To: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
References: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
Precedence: list


Good morning lisa,

> Hi all,
>
> In a recent conversation with @glozow, I had the realization that the mem=
pool 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 e=
asily 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 majori=
ty of the participants on the network. In this case, it is necessary to soc=
ialize pending transaction data to all participants, as you don=E2=80=99t k=
now which participant will be constructing the winning block template.
>
> In reality however, mempool relay is unnecessary where the majority of ha=
shpower and thus block template creation is concentrated in a semi-restrict=
ed set.=C2=A0
>
> Removing the mempool would greatly reduce the bandwidth requirement for r=
unning a node, keep intentionality of transactions private until confirmed/=
irrevocable, and naturally resolve all current issues inherent in package r=
elay 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, s=
ay 1000, it=E2=80=99d be quite feasible to publish a list of tor endpoints =
that nodes can independently =C2=A0+ directly submit their transactions to.=
 In fact, merely allowing users to select their own list of endpoints to us=
e 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 min=
ing and would also make BetterHash proposals, which move the block template=
 construction away from a centralized mining pool back to the individual mi=
ner, much more difficult. It also makes explicit the target for DoS attacks=
.

Unfortunately, this requires that miners have a persistent identity by whic=
h they can be contacted.
While pseudonymity is possible, we all know that in practice, it can be eas=
ily pierced.
For instance, consider that the injunction against address reuse is a recog=
nition that a persistent pseudonym is a privacy leak.

Ideally, the mining set should be as anonymous as possible, as some attacks=
 are possible with sufficient hashpower, and making the miners keep a persi=
stent identity by which they can be found may enable easier state co-option=
 of mines.
The strongest man on Earth cannot destroy his enemy if he does not know who=
 and where his enemy is; so with enemies of Bitcoin and the miners of Bitco=
in.
(granted, near every darned mining pool self-identifies, sigh, wtf)

Ideally, the set of relaying nodes hides the miners.
Of course, in practice we can have a good guess of which relaying nodes are=
 miners and which are not -- those who get blocks earlier are probably mine=
rs.
Against this, we should note that this method of identification is probabil=
istic and not absolute (whereas miners advertising their services so they c=
an be contacted and given unconfirmed transactions are a *definite* flag "I=
 am a miner").
And there is always the chance, however slim, that some node that has not b=
een getting blocks "early" suddenly decides to buy a mining rig and start m=
ining.

In short: what you propose is to switch to side fee markets (as I understan=
d it).
Non-side fees are simply an anonymity layer, by which neither the miner nor=
 the transactor need to know the identity of each other, they simply broadc=
ast to the wider world.
This anonymity layer remains important, however, as they help maintain the =
fee market: https://github.com/libbitcoin/libbitcoin-system/wiki/Side-Fee-F=
allacy


Ultimately, my objection here is simply that this requires miners to identi=
fy themselves.
In practice, miners already identify themselves (even though they really, r=
eally should not), so this objection may be moot at this point.

(Not to mention: something like P2Pool, as-is, would not work well in that =
model; you would need to implement a mempool for those as well)

Regards,
ZmnSCPxj