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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
|
Return-Path: <roconnor@blockstream.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2F853C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Oct 2022 15:51:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 1694F8274E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Oct 2022 15:51:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1694F8274E
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com
header.i=@blockstream-com.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=2k3L/P2d
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Wh6wIUOa7Q_R
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Oct 2022 15:51:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 69CF082702
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 69CF082702
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Oct 2022 15:51:30 +0000 (UTC)
Received: by mail-pl1-x629.google.com with SMTP id i6so11120624pli.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Oct 2022 08:51:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20210112.gappssmtp.com; s=20210112;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=GK2pEUDOdYH1IM+YZN+tvXUfP4/R4/encBnXZNe0xMc=;
b=2k3L/P2d/OXqDRYQueDKvZtNl1nJMIcUJznS/JHcGRkO2aoWzp0yPZIyXrCjPZ/u04
fT70haEMVx0lJBGf3PopBSHMl05evAQJtPuh/eWTQTBlyH+URRv/aVxp0GBDA84n7EvQ
j0nM15AJcHghIRuHBLpz3XxmjLSwm5YX+EnscwDu5+dpKeY4+H8fDsP5SPakLJchpkrh
bnXj5bcINcl3wK3rqdmB498G4Oa/1/eawad6WcEJi3m5XTYRXqP4e8qpYUnB0wDvOdot
dj7BABnWHl3Rg38UgSEBR9BWk1A2j2l9AnWdhNCrcULN6IWpfao+wuTrzOgZpD2T/n9+
CUmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=GK2pEUDOdYH1IM+YZN+tvXUfP4/R4/encBnXZNe0xMc=;
b=B2xo4iFM5/bVaYCd5oFi8v9bUN+TdL/kU9ccu5mjw5svBtaTP/x7R+AW+Wtg8DH6jY
72fG3CEA0HVFtAHU1qrKMXHi6WU4UFQlyUkqkIirYYWsETeCfcPRJPat3Bf3+X5tTy9H
bWnm+UrZyiiYGbZNA4+cv/seySf6nBjVwEKgMLoaXYyCzgMajKgfJnGJ4iVN1JLXfrYs
8qKBQ8Jz3CSc44VixPD/6QPN5JTKrzbTyfejZVcHA9bwuasK6FPUw4gF7iEytO4Lq9jg
yl91kZ3K9/FLS2ncYN5HkgLrEavIM7A4qQKcmhNN/v9DtPphp6AQRVcc4IU7XoG0Qxau
cVoQ==
X-Gm-Message-State: ACrzQf17FKCvqQ6CuZgH1miYoIqW3pVJxDwh8ODtXcqEdV+8QZE8u8ec
X5rdLKjkOGQO0FZTYou4uU73ohDlGYi+xB/MiCGDvqbNA/s=
X-Google-Smtp-Source: AMsMyM7fcKLwhepYj+7E9AIov4s/+1Z2hc7qF6X/IfRiRUwQIj2WgUWwzqoAhj52aNPI5gSxz2glxwuVj3Rmqd6QOro=
X-Received: by 2002:a17:902:6907:b0:179:c9bc:dd73 with SMTP id
j7-20020a170902690700b00179c9bcdd73mr12793717plk.159.1666021889713; Mon, 17
Oct 2022 08:51:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjXh33AdK96eToHtDP3t_Zx5JbxCqJFbAQRRRKy6rFC2Q@mail.gmail.com>
In-Reply-To: <CAD5xwhjXh33AdK96eToHtDP3t_Zx5JbxCqJFbAQRRRKy6rFC2Q@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Mon, 17 Oct 2022 11:51:17 -0400
Message-ID: <CAMZUoKkTVGDV6B3SiFr3x0wGNF3E0MBV60RdTeOeBAd_YjvwTQ@mail.gmail.com>
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ecc2de05eb3cf242"
Subject: Re: [bitcoin-dev] Does Bitcoin require or have an honest majority
or a rational one? (re rbf)
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: Mon, 17 Oct 2022 15:51:32 -0000
--000000000000ecc2de05eb3cf242
Content-Type: text/plain; charset="UTF-8"
From my limited academic interactions, people generally take the "honest"
to mean following the rules (regardless of how bad it is for you to follow
those rules). This has in turn led to some blockchain designs based on
their own absurd set of rules, and simply waiving away their issues by
stipulating their own honest majority or supermajority requirement. For
example, a proof of stake blockchain might require as a rule that users
securely delete their signing keys after a period of time, and prove their
blockchain secure under these rules. They then argue that so long as the
"honest" majority follows this rule, then there is no risk of
reorganization. If enough users don't delete their signing keys, well
their honest majority assumption is violated, so anything goes.
The thing is that it is most certainly in each user's interest to *not*
delete their signing keys. Each user has strictly more power and options
available by keeping their keys and not deleting them. This rule violation
is undetectable, at least until it is too late and a coalition decides to
try to collaborate for a reorg to their advantage.
It is not reasonable to build a distributed pseudonymous system built on
arbitrary rules and then simply define your system to be secure by fiat.
Users need an incentive to follow the rules of the system or it just won't
work. In particular, the rules ought to form a Nash Equilibrium, and this
is violated by, for example, a requirement that users delete their signing
keys. If Bitcoin relied on users acting against their own interest to
function, I doubt Bitcoin would be in operation today. Certainly I would
have no interest in it.
While it doesn't really matter, I do believe Satoshi was also aware that
the rules cannot just be arbitrary, with no incentive to follow them.
After all, he did note that it was designed to be in the miner's self
interest to build upon the longest (most work) chain, even if that point
ended up being rather involved. That is to say, I don't think that an
"honest" (i.e rule following) majority is meant to be taken as an
assumption, rather it is something that ought to be a consequence of the
design.
Anyhow, the above is simply a comment on "honest majority", and I'm not
trying to make a specific claim about RBF here, though I do have my
opinions and I do see how it is related.
On Sun, Oct 16, 2022 at 1:36 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The Bitcoin white paper says:
>
> The proof-of-work also solves the problem of determining representation in
> majority decision
> making. If the majority were based on one-IP-address-one-vote, it could be
> subverted by anyone
> able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.
> The majority
> decision is represented by the longest chain, which has the greatest
> proof-of-work effort invested
> in it. If a majority of CPU power is controlled by honest nodes, the
> honest chain will grow the
> fastest and outpace any competing chains. To modify a past block, an
> attacker would have to
> redo the proof-of-work of the block and all blocks after it and then catch
> up with and surpass the
> work of the honest nodes. We will show later that the probability of a
> slower attacker catching up
> diminishes exponentially as subsequent blocks are added.
>
>
> This, Satoshi (who doesn't really matter anyways I guess?) claimed that
> for Bitcoin to function properly you need a majority honest nodes.
>
> There are multiple behaviors one can describe as honest, and economically
> rational or optimizing is not necessarily rational.
>
> For example, if I run a shop that takes rain checks, but I sell an item to
> a higher bidder who didn't have a hold on the item, that is not honest, but
> it may be selfish profit maximizing.
>
> Satoshi said an honest majority is required for the chain to be extended.
> Honest is not really defined though. Honesty, in my definition, is that you
> follow a pre specified rule, rational or not.
>
> It seems a lot of the RBF controversy is that Protocol developers have
> aspired to make the honest behavior also be the rational behavior. This is
> maybe a good idea because, in theory, if the honest behavior is rational
> then we can make a weaker assumption of selfishness maximizing a parameter.
>
> However, Satoshi did not particularly bound what aspects of honesty are
> important for the network, because there isn't a spec defining exactly what
> is honest or not. And also as soon as people are honest, you can rely on
> that assumption for good effect.
>
> And sometimes, defining an honest behavior can be creating a higher
> utility system because most people are "law abiding citizens" who might not
> be short term rational. For example, one might expect that miners would be
> interested in making sure lightning closes are "accurate" because
> increasing the utility of lightning is good for Bitcoin, even if it is
> irrational.
>
> It seems that the NoRBF crowd want to rely on an honest majority
> assumption where the honest behavior is not doing replacement if not
> requested. This is really not much different than trying to close lightning
> channels "the right way".
>
> However, where it may be different, is that even in the presence of honest
> majority, the safety of 0conf isn't assured given the potential of race
> conditions in the mempool. Therefore it's not clear to me that 0conf
> working well is something you can drive from the Honest Majority Assumption
> (where honest includes first seen).
>
>
> Overall, it might be nice to more tightly document what bitcoins
> assumptions are in practice and what those assumptions do in terms of
> properties of Bitcoin, as well as pathways to weakening the assumptions
> without compromising the behaviors users expect the network to have. An
> "extended white paper" if you will.
>
>
> It's somewhat clear to me that we shouldn't weaken assumptions that only
> seem local to one subsystem of Bitcoin if they end up destabilizing another
> system. In particular, things that decrease "transaction utility" for end
> users decrease the demand for transactions which hurts the fee market's
> longer term viability, even if we feel good about making an honest policy
> assumption into a self interested policy assumption.
>
> A last reflection is that Bitcoin is specified with an honest majority
> assumption, but also has a rational dishonest minority assumption over both
> endogenous (rewards) and exogenous (electricity) costs. Satoshi did not
> suggest, at least as I read it, that Bitcoin works with an rational
> majority assumption. (If anyone thinks these three are similar properties
> you can make some trivial counterexamples)
>
>
> Cheers,
>
> Jeremy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000ecc2de05eb3cf242
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>From my limited academic interactions, people general=
ly take the "honest" to mean following the rules (regardless of h=
ow bad it is for you to follow those rules).=C2=A0 This has in turn led to =
some blockchain designs based on their own absurd set of rules, and simply =
waiving away their issues by stipulating their own honest majority or super=
majority requirement.=C2=A0 For example, a proof of stake blockchain might =
require as a rule that users securely delete their signing keys after a per=
iod of time, and prove their blockchain secure under these rules.=C2=A0 The=
y then argue that so long as the "honest" majority follows this r=
ule, then there is no risk of reorganization.=C2=A0 If enough users don'=
;t delete their signing keys, well their honest majority assumption is viol=
ated, so anything goes.</div><div><br></div><div>The thing is that it is mo=
st certainly in each user's interest to *not* delete their signing keys=
.=C2=A0=C2=A0 Each user has strictly more power and options available by ke=
eping their keys and not deleting them.=C2=A0 This rule violation is undete=
ctable, at least until it is too late and a coalition decides to try to col=
laborate for a reorg to their advantage.</div><div><br></div><div>It is not=
reasonable to build a distributed pseudonymous system built on arbitrary r=
ules and then simply define your system to be secure by fiat.=C2=A0 Users n=
eed an incentive to follow the rules of the system or it just won't wor=
k.=C2=A0 In particular, the rules ought to form a Nash Equilibrium, and thi=
s is violated by, for example, a requirement that users delete their signin=
g keys.=C2=A0 If Bitcoin relied on users acting against their own interest =
to function, I doubt Bitcoin would be in operation today.=C2=A0 Certainly I=
would have no interest in it.</div><div><br></div><div>While it doesn'=
t really matter, I do believe Satoshi was also aware that the rules cannot =
just be arbitrary, with no incentive to follow them.=C2=A0 After all, he di=
d note that it was designed to be in the miner's self interest to build=
upon the longest (most work) chain, even if that point ended up being rath=
er involved.=C2=A0 That is to say, I don't think that an "honest&q=
uot; (i.e rule following) majority is meant to be taken as an assumption, r=
ather it is something that ought to be a consequence of the design.<br></di=
v><div><br></div><div>Anyhow, the above is simply a comment on "honest=
majority", and I'm not trying to make a specific claim about RBF =
here, though I do have my opinions and I do see how it is related.<br></div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Sun, Oct 16, 2022 at 1:36 PM Jeremy Rubin via bitcoin-dev <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"auto"><div dir=3D"auto">The Bitcoin white paper say=
s:=C2=A0</div><div dir=3D"auto"><br></div>The proof-of-work also solves the=
problem of determining representation in majority decision
<div dir=3D"auto">making. If the majority were based on one-IP-address-one-=
vote, it could be subverted by anyone
</div><div dir=3D"auto">able to allocate many IPs. Proof-of-work is essenti=
ally one-CPU-one-vote. The majority
</div><div dir=3D"auto">decision is represented by the longest chain, which=
has the greatest proof-of-work effort invested
</div><div dir=3D"auto">in it. If a majority of CPU power is controlled by =
honest nodes, the honest chain will grow the
</div><div dir=3D"auto">fastest and outpace any competing chains. To modify=
a past block, an attacker would have to
</div><div dir=3D"auto">redo the proof-of-work of the block and all blocks =
after it and then catch up with and surpass the
</div><div dir=3D"auto">work of the honest nodes. We will show later that t=
he probability of a slower attacker catching up
</div><div dir=3D"auto">diminishes exponentially as subsequent blocks are a=
dded.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">This, Satoshi (who doesn't really matter anyways I guess?) cl=
aimed that for Bitcoin to function properly you need a majority honest node=
s.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">There are multi=
ple behaviors one can describe as honest, and economically rational or opti=
mizing is not necessarily rational.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">For example, if I run a shop that takes rain checks, but I sell=
an item to a higher bidder who didn't have a hold on the item, that is=
not honest, but it may be selfish profit maximizing.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Satoshi said an honest majority is required f=
or the chain to be extended. Honest is not really defined though. Honesty, =
in my definition, is that you follow a pre specified rule, rational or not.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">It seems a lot of the R=
BF controversy is that Protocol developers have aspired to make the honest =
behavior also be the rational behavior. This is maybe a good idea because, =
in theory, if the honest behavior is rational then we can make a weaker ass=
umption of selfishness maximizing a parameter.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">However, Satoshi did not particularly bound what asp=
ects of honesty are important for the network, because there isn't a sp=
ec defining exactly what is honest or not. And also as soon as people are h=
onest, you can rely on that assumption for good effect.</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">And sometimes, defining an honest behavior =
can be creating a higher utility system because most people are "law a=
biding citizens" who might not be short term rational. For example, on=
e might expect that miners would be interested in making sure lightning clo=
ses are "accurate" because increasing the utility of lightning is=
good for Bitcoin, even if it is irrational.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">It seems that the NoRBF crowd want to rely on an hones=
t majority assumption where the honest behavior is not doing replacement if=
not requested. This is really not much different than trying to close ligh=
tning channels "the right way".</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">However, where it may be different, is that even in the p=
resence of honest majority, the safety of 0conf isn't assured given the=
potential of race conditions in the mempool. Therefore it's not clear =
to me that 0conf working well is something you can drive from the Honest Ma=
jority Assumption (where honest includes first seen).</div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Overall, it might=
be nice to more tightly document what bitcoins assumptions are in practice=
and what those assumptions do in terms of properties of Bitcoin, as well a=
s pathways to weakening the assumptions without compromising the behaviors =
users expect the network to have.=C2=A0 An "extended white paper"=
if you will.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">=C2=A0It's somewhat clear to me that we shouldn't=
weaken assumptions that only seem local to one subsystem of Bitcoin if the=
y end up destabilizing another system. In particular, things that decrease =
"transaction utility" for end users decrease the demand for trans=
actions which hurts the fee market's longer term viability, even if we =
feel good about making an honest policy assumption into a self interested p=
olicy assumption.</div><div dir=3D"auto"><br></div><div dir=3D"auto">A last=
reflection is that Bitcoin is specified with an honest majority assumption=
, but also has a rational dishonest minority assumption over both endogenou=
s (rewards) and exogenous (electricity) costs. Satoshi did not suggest, at =
least as I read it, that Bitcoin works with an rational majority assumption=
. (If anyone thinks these three are similar properties you can make some tr=
ivial counterexamples)</div><div dir=3D"auto"><br></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Cheers,</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Jeremy=C2=A0</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000ecc2de05eb3cf242--
|