From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 36819C000E for ; Tue, 26 Oct 2021 08:31:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 14E5480F3B for ; Tue, 26 Oct 2021 08:31:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV81i7zDl16k for ; Tue, 26 Oct 2021 08:31:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by smtp1.osuosl.org (Postfix) with ESMTPS id E277980F2E for ; Tue, 26 Oct 2021 08:31:20 +0000 (UTC) Received: by mail-pl1-x629.google.com with SMTP id s24so5810169plp.0 for ; Tue, 26 Oct 2021 01:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20210112.gappssmtp.com; s=20210112; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=dyIxqlMXZH0AHmC8ckiBoDG5UXgyHNBSylq1cBoZ/Sg=; b=hdf/x9vPZtqcf6TwcWm840rh9rbINdYR3Jrk8d1iEdTPiixSIFyAXwK4YTQ/+/3rw7 PMrQQAKEae+qymyBIH0f2mq70iLc7hSAnUtKnQdVxAMoGgdGpC74wUJU+dXMTZUKxNrC NAkeFogv46O/a5zs0gbAzG6oXHlbyHlnYmNlcLHLHbR+9lEh1+Wx0SgTp0qWiaI2T0K9 94EWMqhX89XRAJt7MAroomyDRMHf1FX7jCnX/MbyTJCauG+a9Pt16X58P1FDLvwFuc9G l/P+oxBWXfWxknlUzQafEBj0CRcFUWK7CwmnUKkRYztTaFR8cxUZ8WVVgt5iPCNZkyG4 V2qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=dyIxqlMXZH0AHmC8ckiBoDG5UXgyHNBSylq1cBoZ/Sg=; b=mk1h3qDjCU3r6Oaun59hcBzq4PsT5NjaCCLYK8G1ZsgzhsKe3q/L8UbwqMVlDBX0Xq BvTTwxBKb8boyOfNu/0dnbkBhBV0S/scpUwWGhS9cdlcZq8ofPAstUbzR2IT3zlISEGs dDnLCLnVxTT31PGOzwX6NMlpL2TgeUDEElnSDtNo9mFduTYzgGq//m2LZCP4qW0/YaMq 5kLf8SMJLH7RzBIqNbNxPlp2byW4qTLlM5OhGAYmfNNNLwTTL0kl8cRd74tJQhvzlDFo kg3DJNxwukJYk+hOcx7Y0/4vzNByBskArLlIBuqzy25kg7VZHRyULCHCFnZmOpz858v6 PDdg== X-Gm-Message-State: AOAM532v3gbwQHrtu9lDrdeBYEE4q1Wm+ErxiwZ06OB4jlHG6RqG/gqC lxicy6CCxjUfHH/CYQbUXQeF2SW5e5rceQ== X-Google-Smtp-Source: ABdhPJz7R4l0qPDfTFVKi/vSnZ7ZDQs8Mq8+oBiItf+px1bDiKfLXzWI9pnSI4Xg0pkFzadDaty0lQ== X-Received: by 2002:a17:90b:4c03:: with SMTP id na3mr18719316pjb.90.1635237079709; Tue, 26 Oct 2021 01:31:19 -0700 (PDT) Received: from ERICDESKTOP ([2601:600:9c00:1d0::9b05]) by smtp.gmail.com with ESMTPSA id z15sm9747759pga.16.2021.10.26.01.31.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Oct 2021 01:31:19 -0700 (PDT) From: To: "'ZmnSCPxj'" , "'Bitcoin Protocol Discussion'" , "'lisa neigut'" References: In-Reply-To: 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 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJDAyeTF0obM0rXsoFCJ4mLR5qu7QE+548YqwSEQfA= Content-Language: en-us 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:31:22 -0000 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 On = Behalf > Of ZmnSCPxj via bitcoin-dev > Sent: Tuesday, October 26, 2021 1:02 AM > To: lisa neigut ; Bitcoin Protocol Discussion = 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