MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Wed, 27 Oct 2021 23:05:59 +0000
From: yanmaani@cock.li
To: lisa neigut <niftynei@gmail.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
References: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
Message-ID: <d85b843702f2f04a90158ccc75b06226@cock.li>
User-Agent: Roundcube Webmail/1.3.16
Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
Precedence: list

[I removed a comment regarding the moderation of this list here because 
it caused for my message to be rejected]

On 2021-10-26 02:56, lisa neigut via bitcoin-dev wrote:
> [...] the mempool is obsolete and should be eliminated.
> 
> Instead, users should submit their transactions directly to mining
> pools, [...]
> Mempools make sense in a world where mining is done by a large number
> of participating nodes, [...] 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.

It's true that there is some centralization, but this is hardly a 
desirable goal that should be formally enshrined.

By that point, you might as well block people from keeping their coins 
in their own wallet, on the basis that in practice mostly everyone keeps 
them on the exchange.

And as the others have pointed out: even if you did hold this to be 
desirable, why would removing the mempool be a good idea? The pools 
would still need some way to get transactions, and a mempool seems like 
an excellent way to do this.

I think most of the people here have laid out all of the other obvious 
issues with the proposal.

> Removing the mempool would greatly reduce the bandwidth requirement
> for running a node

You can disable it already if you're strapped for cash. Is there a 
reason why this is not adequate?

> keep intentionality of transactions private until confirmed/irrevocable

What is the "intentionality" of a transaction and why do I want to keep 
it private? My transactions are 100% intentional because I am trying to 
send money, and I wouldn't make them otherwise - what is a 
non-intentional transaction supposed to be?

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

If nothing else, this would be a significant departure from the security 
model of Bitcoin:

> The network is robust in its unstructured simplicity.
> Nodes work all at once with little coordination.
> They do not need to be identified, since messages are not routed to any 
> particular place and only need to be delivered on a best effort basis.
> Nodes can leave and rejoin the network at will, accepting the 
> proof-of-work chain as proof of what happened while they were gone.

If you posit that the security model should be changed, that is one 
thing, but you should lay out your reasoning for this claim.

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

I am amazed that you are intelligent enough to realize these trade-offs, 
yet still made this post. Are you suggesting that you find them to be 
acceptable?

> It also makes explicit the target for DoS attacks.

Perhaps the only good aspect of this proposal. Under such conditions, 
denial of service attacks would be both just and desirable.

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

Why couldn't they just run a website about this for anyone who cares? 
Communicating two numbers can easily be done over HTTP. This technology 
exists already.

> ~niftynei
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev