1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
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
|
