From: <eric@voskuil.org>
To: "'ZmnSCPxj'" <ZmnSCPxj@protonmail.com>,
 "'Bitcoin Protocol Discussion'" <bitcoin-dev@lists.linuxfoundation.org>,
 "'lisa neigut'" <niftynei@gmail.com>
References: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
 <wIXL_bs_B1FfWrIOMjdog--VwQWD_okme8nPjerWyszHuKhFcPTi3yetwPKYYYR79PEeQcbA3lqZTL107k_KED8-RMs4HPyvhLh5b1miSr4=@protonmail.com>
In-Reply-To: <wIXL_bs_B1FfWrIOMjdog--VwQWD_okme8nPjerWyszHuKhFcPTi3yetwPKYYYR79PEeQcbA3lqZTL107k_KED8-RMs4HPyvhLh5b1miSr4=@protonmail.com>
Date: Tue, 26 Oct 2021 01:31:18 -0700
Message-ID: <009901d7ca43$d9dd2f50$8d978df0$@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQJDAyeTF0obM0rXsoFCJ4mLR5qu7QE+548YqwSEQfA=
Content-Language: en-us
Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
Precedence: list

Agree ZmnSCPxj

Hi lisa,

I'm all for removing it from memory. :) Did that a while ago. We just =
call it the transaction pool.

There will always be unconfirmed transactions floating around (even just =
from reorgs). Best to store them somewhere. Disk is cheap, block =
distribution (e.g. compact) works better if you have them already =
prevalidated, even if you aren't going to mine on them.

How you get them technically is not so important. There will always be a =
set of unconfirmed transactions, it's conceptual. But above all, =
anonymity is very important - on both ends. This is why transactions =
have integral fees. Anyone can get paid to mine, just need the txs.

Mining may be semi-restricted set is today, it may not be tomorrow. =
Imagine China everywhere, just like financial controls already are. =
That's when you see what Bitcoin can do from a security standpoint.

Treating miners as someone else is a poor security architecture. =
Everyone should look like a potential miner on the network, and a =
potential spender.

I think you are thinking of it a bit backwards. A node is a big pool of =
connected transactions. Block headers come along occasionally, and =
impose order on a subset of them.

e

> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> On =
Behalf
> Of ZmnSCPxj via bitcoin-dev
> Sent: Tuesday, October 26, 2021 1:02 AM
> 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
>=20
>=20
> Good morning lisa,
>=20
> > 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=E2=80=99t 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=E2=80=99d 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.
>=20
> Unfortunately, this requires that miners have a persistent identity by =
which
> they can be contacted.
> While pseudonymity is possible, we all know that in practice, it can =
be easily
> pierced.
> For instance, consider that the injunction against address reuse is a
> recognition that a persistent pseudonym is a privacy leak.
>=20
> Ideally, the mining set should be as anonymous as possible, as some =
attacks
> are possible with sufficient hashpower, and making the miners keep a
> persistent 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
> Bitcoin.
> (granted, near every darned mining pool self-identifies, sigh, wtf)
>=20
> 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 =
miners.
> Against this, we should note that this method of identification is =
probabilistic
> and not absolute (whereas miners advertising their services so they =
can 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
> been getting blocks "early" suddenly decides to buy a mining rig and =
start
> mining.
>=20
> In short: what you propose is to switch to side fee markets (as I =
understand 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 =
broadcast
> 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-
> Fallacy
>=20
>=20
> Ultimately, my objection here is simply that this requires miners to =
identify
> themselves.
> In practice, miners already identify themselves (even though they =
really,
> really should not), so this objection may be moot at this point.
>=20
> (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)
>=20
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev