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
155
156
157
158
159
160
161
|
Return-Path: <yanmaani@cock.li>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7995EC000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Oct 2021 23:06:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 68AEF40595
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Oct 2021 23:06:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level:
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=cock.li
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id AOGYHHoSP4rZ
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Oct 2021 23:06:09 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.cock.li (mail.cock.li [37.120.193.124])
by smtp4.osuosl.org (Postfix) with ESMTPS id B5DDA40586
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Oct 2021 23:06:08 +0000 (UTC)
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail;
t=1635375959; bh=cxuSiYwLnafQgNdZvou4jO3RJn/oTIuuSjGQIkxpTQ8=;
h=Date:From:To:Subject:In-Reply-To:References:From;
b=LNdw/is1OehiZpCYfJdRtt+hy26VwCPfOYi+IChX+6taLyIp/lBoB6DMLH7RGw064
kDjOcglIMea//wi1Pg+OuPrepcwgKzHdkRxAqIAIkzTv6XIM7DCZhBTl6SsreTLaDk
vdMyb2TNtb8Pd5w05rd8vH3n481auyo5EaDuZA2KmY5nG6WMiPTNGuR6j6gyu5EgUS
wd3VRI8dKuLTyGcek9kdoYydyIL2dtfoxwpc+Fak4NVVP+TYbaiw9dOk0lBWRLDzGv
hCHORGm+uMa7rcfY8tIkVZ018+piCZ37/wDreEVPcaLS+jwfdQrjZj118gVS8SUyBr
tQ+nTKDW8hoZA==
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Wed, 27 Oct 2021 23:05:59 +0000
From: yanmaani@cock.li
To: lisa neigut <niftynei@gmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
References: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
Message-ID: <d85b843702f2f04a90158ccc75b06226@cock.li>
X-Sender: yanmaani@cock.li
User-Agent: Roundcube Webmail/1.3.16
X-Mailman-Approved-At: Fri, 29 Oct 2021 15:52:42 +0000
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: Wed, 27 Oct 2021 23:06:11 -0000
[I removed a comment regarding the moderation of this list here because
it caused for my message to be rejected]
On 2021-10-26 02:56, lisa neigut via bitcoin-dev wrote:
> [...] the mempool is obsolete and should be eliminated.
>
> Instead, users should submit their transactions directly to mining
> pools, [...]
> Mempools make sense in a world where mining is done by a large number
> of participating nodes, [...] as you don’t 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.
It's true that there is some centralization, but this is hardly a
desirable goal that should be formally enshrined.
By that point, you might as well block people from keeping their coins
in their own wallet, on the basis that in practice mostly everyone keeps
them on the exchange.
And as the others have pointed out: even if you did hold this to be
desirable, why would removing the mempool be a good idea? The pools
would still need some way to get transactions, and a mempool seems like
an excellent way to do this.
I think most of the people here have laid out all of the other obvious
issues with the proposal.
> Removing the mempool would greatly reduce the bandwidth requirement
> for running a node
You can disable it already if you're strapped for cash. Is there a
reason why this is not adequate?
> keep intentionality of transactions private until confirmed/irrevocable
What is the "intentionality" of a transaction and why do I want to keep
it private? My transactions are 100% intentional because I am trying to
send money, and I wouldn't make them otherwise - what is a
non-intentional transaction supposed to be?
> Provided the number of block template producing actors remains
> beneath, say 1000, it’d be quite feasible to publish a list of tor
> endpoints that nodes can independently + directly submit their
> transactions to.
If nothing else, this would be a significant departure from the security
model of Bitcoin:
> The network is robust in its unstructured simplicity.
> Nodes work all at once with little coordination.
> They do not need to be identified, since messages are not routed to any
> particular place and only need to be delivered on a best effort basis.
> Nodes can leave and rejoin the network at will, accepting the
> proof-of-work chain as proof of what happened while they were gone.
If you posit that the security model should be changed, that is one
thing, but you should lay out your reasoning for this claim.
> 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.
I am amazed that you are intelligent enough to realize these trade-offs,
yet still made this post. Are you suggesting that you find them to be
acceptable?
> It also makes explicit the target for DoS attacks.
Perhaps the only good aspect of this proposal. Under such conditions,
denial of service attacks would be both just and desirable.
> A direct communication channel between block template construction
> venues and transaction proposers also provides a venue for direct
> feedback wrt acceptable feerates at the time, which both makes
> transaction confirmation timelines less variable as well as provides
> block producers a mechanism for (independently) enforcing their own
> minimum security budget. In other words, expressing a minimum
> acceptable feerate for continued operation.
Why couldn't they just run a website about this for anyone who cares?
Communicating two numbers can easily be done over HTTP. This technology
exists already.
> ~niftynei
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
