diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2021-10-26 08:02:24 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-10-26 08:02:40 +0000 |
| commit | f40745283dcee658dd5ecf07b2cd942eb66ae7f0 (patch) | |
| tree | ac0f12639e9484efbe1ffbb7c97242fc67676875 | |
| parent | 2d5e5bf5b9df5a8bf1c33ba14bf4537c22a3cfb6 (diff) | |
| download | pi-bitcoindev-f40745283dcee658dd5ecf07b2cd942eb66ae7f0.tar.gz pi-bitcoindev-f40745283dcee658dd5ecf07b2cd942eb66ae7f0.zip | |
Re: [bitcoin-dev] death to the mempool, long live the mempool
| -rw-r--r-- | 3c/7165ffbf5fdb1480f3672491f2bd24d7932542 | 154 |
1 files changed, 154 insertions, 0 deletions
diff --git a/3c/7165ffbf5fdb1480f3672491f2bd24d7932542 b/3c/7165ffbf5fdb1480f3672491f2bd24d7932542 new file mode 100644 index 000000000..ef1e62be2 --- /dev/null +++ b/3c/7165ffbf5fdb1480f3672491f2bd24d7932542 @@ -0,0 +1,154 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 84E6FC000E + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <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 +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + |