Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 84E6FC000E for ; Tue, 26 Oct 2021 08:02:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 65B0540129 for ; Tue, 26 Oct 2021 08:02:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHjFPXyb77Ds for ; Tue, 26 Oct 2021 08:02:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by smtp2.osuosl.org (Postfix) with ESMTPS id 1DF724010B for ; Tue, 26 Oct 2021 08:02:38 +0000 (UTC) Date: Tue, 26 Oct 2021 08:02:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1635235355; bh=X4uTGMiGcc1QyY07Nwe15nSrw8oXNqONDKW6HqdJBBY=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=wl3hg2X2kPouAkrWSFoit9BfwEfa6W21mgDsr7ejRTh/aJ16yXEKEG/X7IW4p+XyE S3ipz8vW6uBoHS8h+NTDS4IL2Gibqv36nDURYVKJQ1nhYnHrmpXznYFursSLEBWPHK tthfCeOV4VKqXJC6kHu5G+wwnc/c8ld8Y9OwZQmQ= To: lisa neigut , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: 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 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 08:02:40 -0000 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