path: root/4e/41cea2f4eead2f20e79b4a05e04d6c6beaa57a

Return-Path: <eric@voskuil.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 36819C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Oct 2021 08:31:20 +0000 (UTC)
Received: by mail-pl1-x629.google.com with SMTP id s24so5810169plp.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <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
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 <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: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 <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