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: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id C0AB5C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Oct 2021 08:56:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id A2546401C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Oct 2021 08:56:23 +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 QyqVukZKP1FL
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Oct 2021 08:56:22 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by smtp2.osuosl.org (Postfix) with ESMTPS id 420264010B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Oct 2021 08:56:21 +0000 (UTC)
Date: Tue, 26 Oct 2021 08:56:10 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1635238579;
bh=2xyvnF1w9hVQox38eGBya7LmHkdI7yIjVVfkmZPz6BE=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=mT+fPjkuEjBXDAgI8QGYGwNZUj6fZferJnvIepG7xi4gpcTjEn+w05Wzea8twCZBx
mi3xBrlluiYUqeJBmFQ1xrn6/qdegjIS4CquwV9/VGz1FXTHlJKfKiJBMbEWaeXQcP
B9Wwm4IU4SAepQFYaJp69Nqs4bjrX64OEGP4zQ4w=
To: "eric@voskuil.org" <eric@voskuil.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <a33WOOHRYsOk5DCaJQAQUh-fwyudYXQYggn54KmIKx_CVA4qCnjaAxG3-Drl639NTGC8smZUNeIulUcAxoOp44kRZhf8BQS0JqqW1BkJpCU=@protonmail.com>
In-Reply-To: <009901d7ca43$d9dd2f50$8d978df0$@voskuil.org>
References: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
<wIXL_bs_B1FfWrIOMjdog--VwQWD_okme8nPjerWyszHuKhFcPTi3yetwPKYYYR79PEeQcbA3lqZTL107k_KED8-RMs4HPyvhLh5b1miSr4=@protonmail.com>
<009901d7ca43$d9dd2f50$8d978df0$@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: 'Bitcoin Protocol Discussion' <bitcoin-dev@lists.linuxfoundation.org>,
'lisa neigut' <niftynei@gmail.com>
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:56:23 -0000
Good morning e, and lisa,
> Agree ZmnSCPxj
>
> Hi lisa,
>
> I'm all for removing it from memory. :) Did that a while ago. We just cal=
l 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 distributi=
on (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 fe=
es. Anyone can get paid to mine, just need the txs.
>
> Mining may be semi-restricted set is today, it may not be tomorrow. Imagi=
ne 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 c=
onnected transactions. Block headers come along occasionally, and impose or=
der on a subset of them.
On the subject of thinking backwards....
The current design gossips txes.
I believe much of what lisa wants would be doable by gossiping mining endpo=
ints instead of txes.
Then transactors can connect to mining endpoints.
Tx gossip is limited by fees (which is why the RBF rules even exist in the =
first place).
Thus, mining endpoint gossip must be limited by something as well, such as =
by requiring some trivial stake of BTC.
(BTC exchanges are commonplace enough, I believe, that requiring completely=
new miners (i.e. those who currently own 0 BTC) to acquire some trivial st=
ake of BTC would be feasible; for most people it would be easier to buy BTC=
than to acquire a mining rig and the supporting infrastructure needed for =
a mine.)
We could have the endpoint encoded in some sign-to-contract or pay-to-contr=
act construction.
Miners can change their identity by spending their stake (which makes nodes=
drop their endpoint record).
Then, they can use now-common anonymity techniques --- mostly CoinJoin, but=
also the upcoming CoinSwap implementation --- to acquire a new stake whose=
identity is not easily traceable to the previous stake.
(This is not proof-of-stake, BTW --- the stake only attests the mining endp=
oint (in much the same way published Lightning channels are attested by the=
ir funding tx outpoints), and has no effect on block validity, only on goss=
iping of mining endpoints.)
The advantage here is that we expect the set of miner identities to change =
less often than the set of txes, thus reducing global bandwidth usage,
Against the above, we must notice that the anonymity-preserving regular cha=
nging of staked identity is more expensive than having a persistent identit=
y.
WE should really design systems where anonymity-preservation should be as c=
heap as possible, but onchain activity is no longer cheap at all, given the=
growing importance of Bitcoin.
--
Also:
> A direct communication channel between block template construction venues=
and transaction proposers also provides a venue for direct feedback wrt ac=
ceptable feerates at the time, which both makes transaction confirmation ti=
melines less variable
Unless you contact ***all*** miners globally, there is always some non-zero=
probability that one of the miners you did *not* contact (and thus does no=
t have your tx, and thus will not be able to confirm your tx) gets the next=
block.
Since miners can enter and leave the network at any time, it is entirely po=
ssible that this mechanism *increases* variability rather than decreases it=
.
Regards,
ZmnSCPxj
|
