summaryrefslogtreecommitdiff
path: root/7c/05953184a58182a3c9ce3c8a68a6903f2eb113
blob: f077f91c38b966986dbc99678bae2e6817c09fb8 (plain)
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
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4FC66C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 23:54:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 0A97884002
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 23:54:15 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0A97884002
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=oA+roffC
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 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 ROWRXG1bGVgQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 23:54:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 74C1983FAD
Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com
 [IPv6:2607:f8b0:4864:20::1131])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 74C1983FAD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 23:54:13 +0000 (UTC)
Received: by mail-yw1-x1131.google.com with SMTP id
 00721157ae682-3690482f5dfso8509347b3.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 16:54:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=OgOdlzDUrnFSYaozP168PV6zpEIYRrrIzGusWSmC7Xo=;
 b=oA+roffCy3D/PqihACwjHsEaXt8QaXznswDgH/ZEAZGcnQGb2bbP4vi7r1+s3O6175
 MUNb6uor8kFqwyuktZXuR4iC8gpiou6R1akv9nlWIanITU3jP6SgNVRoe+nbr+SkLahU
 B2W7ReFu5Fh9WzZA6OsfRopN7u6r2Upx1JlAqQK+nzGYNXhrWSEgcSa49JLariiC73Cr
 1VmQzm7BURj1jz8gkw41+zA4yV0MpZQgoxq/gHvMZBe2sR6yzf2ZCZbHMgt8fVWivAo1
 UyBvAFPuICS1pjx6YFNGyrR73Ol/T8CDl9tX37k5wHYFfxQ8oUfQYnVMHhTPLmM0BuwX
 jsjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc: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=OgOdlzDUrnFSYaozP168PV6zpEIYRrrIzGusWSmC7Xo=;
 b=8N0//43x94Wcf88OjjLm9yZ35cKfM7f/T5qcrbQ1ROUnLfjYnTKr4aa/Vs1F81SMjG
 wuT9txIOrBbOuMrU7tjpaPGHJLRZpr6h3/oZyouJSVh32cFQQrultYyTLst/0adRm63Q
 oIUZuzCi7KgCi200o66T27BR2sj/wmOCcqT/qfFi2rSPxnpSVV6b5r5OFtLifNiPgsYL
 ojZ+jb0tehSOcdk1jtsL8tJ2tjun5FXIJScQ2s8mCF0xn+cwfYZIbcRejVXWY0l98wfi
 9xKMJGIkDObPnQ5gjCsd7DxFXsMJeyfyWJ0AJ6CxM02jPlvqZwGHB2KLJ5i3fkv5Vtq3
 eREA==
X-Gm-Message-State: ACrzQf18fEkHzD7hndGMdfpzbmKOKaryT+bbtl+vs2JIHAGOnv73bJ55
 xUd9Khh0wGufQu3g0nq4RIE9mJr8K3IWBSWj0f31yGOYSOc=
X-Google-Smtp-Source: AMsMyM6E2aJsBRp+t2ELBW4whc/2I42XTg5ccnTT7irFTOqvq+3VDgcAIZPKxKFIYrp5KIVNbKheR8NrsX6Ed7+rCos=
X-Received: by 2002:a0d:d911:0:b0:369:375c:6657 with SMTP id
 b17-20020a0dd911000000b00369375c6657mr2495127ywe.355.1666310052162; Thu, 20
 Oct 2022 16:54:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjXh33AdK96eToHtDP3t_Zx5JbxCqJFbAQRRRKy6rFC2Q@mail.gmail.com>
 <Y1HLgLkCmVJQtqT+@petertodd.org>
In-Reply-To: <Y1HLgLkCmVJQtqT+@petertodd.org>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Thu, 20 Oct 2022 16:54:00 -0700
Message-ID: <CAD5xwhhiOReFJq2gOk2n5tJpD-X-x8aKGrdkdrwi1yJCis0y4g@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000beb27c05eb800a8a"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Thu, 20 Oct 2022 23:54:15 -0000

--000000000000beb27c05eb800a8a
Content-Type: text/plain; charset="UTF-8"

The difference between honest majority and longest chain is that the
longest chain bug was something acknowledged by Satoshi & patched
https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420
.


OTOH, we have more explicit references that the honest majority really
should be thought of as good guys vs bad guys... e.g.
>
> Thanks for bringing up that point.
> I didn't really make that statement as strong as I could have. The
> requirement is that the good guys collectively have more CPU power than any
> single attacker.
> There would be many smaller zombie farms that are not big enough to
> overpower the network, and they could still make money by generating
> bitcoins. The smaller farms are then the "honest nodes". (I need a better
> term than "honest") The more smaller farms resort to generating bitcoins,
> the higher the bar gets to overpower the network, making larger farms also
> too small to overpower it so that they may as well generate bitcoins too.
> According to the "long tail" theory, the small, medium and merely large
> farms put together should add up to a lot more than the biggest zombie farm.
> Even if a bad guy does overpower the network, it's not like he's instantly
> rich. All he can accomplish is to take back money he himself spent, like
> bouncing a check. To exploit it, he would have to buy something from a
> merchant, wait till it ships, then overpower the network and try to take
> his money back. I don't think he could make as much money trying to pull a
> carding scheme like that as he could by generating bitcoins. With a zombie
> farm that big, he could generate more bitcoins than everyone else combined.
> The Bitcoin network might actually reduce spam by diverting zombie farms
> to generating bitcoins instead.
> Satoshi Nakamoto



There is clearly a notion that Satoshi categorizes good guys / bad guys as
people interested in double spending and people who aren't.

Sure, Satoshi's writings don't *really* matter in the context of what
Bitcoin is / can be, and I've acknowledged that repeatedly. For you to call
it misleading is more misleading than for me to quote from it!

There's a reason I'm citing it. To not read the original source material
that pulled the community together is to make one ignorant around why there
is resistance to something like RBF. This is because there are still
elements of the community who expect the rules that good-phenotype node
operators run to be the ones maximally friendly to resolving transactions
on the first seen basis, so that there aren't double spends. This is a view
which you can directly derive from these early writings around what one
should expect of node operators.

The burden rests on the community, who has undertaken a project to adopt a
different security model from the original "social contract" generated by
the early writings of Satoshi, to demonstrate why damaging one group's
reliance interest on a property derived from the honest majority assumption
is justified.

I do think the case can be fairly made for full RBF, but if you don't grok
the above maybe you won't have as much empathy for people who built a
business around particular aspects of the Bitcoin network that they feel
are now being changed. They have every right to be mad about that and make
disagreements known and argue for why we should preserve these properties.
As someone who wants for Bitcoin to be a system which doesn't arbitrarily
change rules based on the whims of others, I think it important that we can
steelman and provide strong cases for why our actions might be in the
wrong, so that we make sure our justifications are not only well-justified,
but that we can communicate them clearly to all participants in a global
value network.

--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Thu, Oct 20, 2022 at 3:28 PM Peter Todd <pete@petertodd.org> wrote:

> On Sun, Oct 16, 2022 at 01:35:54PM -0400, Jeremy Rubin via bitcoin-dev
> 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.
>
> Satoshi also made a very fundamental mistake: the whitepaper and initial
> Bitcoin release chooses the *longest* chain, rather than the most work
> chain.
> Longest chain is totally broken.
>
> What Satoshi said in the whitepaper is completely irrelevant and quoting
> it in
> circumstances like this is IMO misleading.
>
>
> Anyway, obviously we should always try to make systems that work properly
> with
> an economically rational majority, rather than the much more risky honest
> majority. Economically rational is a better security guarantee. And
> whenever
> possible we should go even further, using the standard computationally
> infeasible guarantees (as seen in our EC signature schems), or even,
> mathematically impossible (1+1=2).
>
> It's notable how in ethereum land, their smart contract schemes have lead
> to
> significant effort in economically rational MEV optimization, at a
> significant
> cost to decentralization (eg majority of blocks are now OFAC compliant).
> There's no reason why Bitcoin should be fundamentally any different in the
> long
> run.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--000000000000beb27c05eb800a8a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The difference <span class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">betwee=
n honest majority and longest chain </span>is that the longest <span class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">chain</span>=C2=A0bug was something acknowledged =
by Satoshi &amp; patched <a href=3D"https://github.com/bitcoin/bitcoin/comm=
it/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496=
747b31R420">https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385=
950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420</a>.<br><br><=
br>OTOH, we have more explicit references that the honest majority really s=
hould be thought of as good guys vs bad guys... e.g.<blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span =
style=3D"color:rgb(33,37,41);font-family:monospace;font-size:10.52999973297=
1191px">Thanks for bringing up that point.</span><br style=3D"box-sizing:bo=
rder-box;color:rgb(33,37,41);font-family:monospace;font-size:10.52999973297=
1191px"><span style=3D"color:rgb(33,37,41);font-family:monospace;font-size:=
10.529999732971191px">I didn&#39;t really make that statement as strong as =
I could have. The requirement is that the good guys collectively have more =
CPU power than any single attacker.<span class=3D"gmail-Apple-converted-spa=
ce">=C2=A0</span></span><br style=3D"box-sizing:border-box;color:rgb(33,37,=
41);font-family:monospace;font-size:10.529999732971191px"><span style=3D"co=
lor:rgb(33,37,41);font-family:monospace;font-size:10.529999732971191px">The=
re would be many smaller zombie farms that are not big enough to overpower =
the network, and they could still make money by generating bitcoins. The sm=
aller farms are then the &quot;honest nodes&quot;. (I need a better term th=
an &quot;honest&quot;) The more smaller farms resort to generating bitcoins=
, the higher the bar gets to overpower the network, making larger farms als=
o too small to overpower it so that they may as well generate bitcoins too.=
 According to the &quot;long tail&quot; theory, the small, medium and merel=
y large farms put together should add up to a lot more than the biggest zom=
bie farm.</span><br style=3D"box-sizing:border-box;color:rgb(33,37,41);font=
-family:monospace;font-size:10.529999732971191px"><span style=3D"color:rgb(=
33,37,41);font-family:monospace;font-size:10.529999732971191px">Even if a b=
ad guy does overpower the network, it&#39;s not like he&#39;s instantly ric=
h. All he can accomplish is to take back money he himself spent, like bounc=
ing a check. To exploit it, he would have to buy something from a merchant,=
 wait till it ships, then overpower the network and try to take his money b=
ack. I don&#39;t think he could make as much money trying to pull a carding=
 scheme like that as he could by generating bitcoins. With a zombie farm th=
at big, he could generate more bitcoins than everyone else combined.</span>=
<br style=3D"box-sizing:border-box;color:rgb(33,37,41);font-family:monospac=
e;font-size:10.529999732971191px"><span style=3D"color:rgb(33,37,41);font-f=
amily:monospace;font-size:10.529999732971191px">The Bitcoin network might a=
ctually reduce spam by diverting zombie farms to generating bitcoins instea=
d.</span><br style=3D"box-sizing:border-box;color:rgb(33,37,41);font-family=
:monospace;font-size:10.529999732971191px"><span style=3D"color:rgb(33,37,4=
1);font-family:monospace;font-size:10.529999732971191px">Satoshi Nakamoto</=
span></blockquote><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:#000000"><span style=3D"color:rgb=
(33,37,41);font-family:monospace;font-size:10.529999732971191px"><br></span=
></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000"><span style=3D"color:rgb(33,37,41);=
font-family:monospace;font-size:10.529999732971191px"><br></span></div>Ther=
e is clearly a notion that Satoshi categorizes good guys / bad guys as peop=
le interested in double spending and people who aren&#39;t.<div><br></div><=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)">Sure, Satoshi&#39;s writings don&#3=
9;t <i>really</i>=C2=A0matter in the context of what Bitcoin is / can be, a=
nd I&#39;ve acknowledged that repeatedly. For you to call it misleading is =
more misleading than for me to quote from it!</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">There&#39;s a rea=
son I&#39;m citing it. To not read the original source material that pulled=
 the community together is to make one ignorant around why there is resista=
nce to something like RBF. This is because there are still elements of the =
community who expect the rules that good-phenotype node operators run to be=
 the ones maximally friendly to resolving transactions on the first seen ba=
sis, so that there aren&#39;t double spends. This is a view which you can d=
irectly derive from these early writings around what one should expect of n=
ode operators.</div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)">The burden rests on the community, who has under=
taken a project to adopt a different security model from the original &quot=
;social contract&quot; generated by the early writings of Satoshi, to demon=
strate why damaging one group&#39;s reliance interest on a property derived=
 from the honest majority assumption is justified.</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I do think t=
he case can be fairly made for full RBF, but if you don&#39;t grok the abov=
e maybe you won&#39;t have as much empathy for people who built a business =
around particular aspects of the Bitcoin network that they feel are now bei=
ng changed. They have every right to be mad about that and make disagreemen=
ts known and argue for why we should preserve these properties. As someone =
who wants for Bitcoin to be a system which doesn&#39;t arbitrarily change r=
ules based on the whims of others, I think it important that we can steelma=
n and provide strong cases for why our actions might be in the wrong, so th=
at we make sure our justifications are not only well-justified, but that we=
 can communicate them clearly to all participants in a global value network=
.</div><br><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=
=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/=
JeremyRubin" target=3D"_blank">@JeremyRubin</a><br></div></div></div><br></=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Thu, Oct 20, 2022 at 3:28 PM Peter Todd &lt;<a href=3D"mailto:pete@p=
etertodd.org">pete@petertodd.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
On Sun, Oct 16, 2022 at 01:35:54PM -0400, Jeremy Rubin via bitcoin-dev wrot=
e:<br>
&gt; The Bitcoin white paper says:<br>
&gt; <br>
&gt; The proof-of-work also solves the problem of determining representatio=
n in<br>
&gt; majority decision<br>
&gt; making. If the majority were based on one-IP-address-one-vote, it coul=
d be<br>
&gt; subverted by anyone<br>
&gt; able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vo=
te.<br>
&gt; The majority<br>
&gt; decision is represented by the longest chain, which has the greatest<b=
r>
&gt; proof-of-work effort invested<br>
&gt; in it. If a majority of CPU power is controlled by honest nodes, the h=
onest<br>
&gt; chain will grow the<br>
&gt; fastest and outpace any competing chains. To modify a past block, an<b=
r>
&gt; attacker would have to<br>
&gt; redo the proof-of-work of the block and all blocks after it and then c=
atch<br>
&gt; up with and surpass the<br>
&gt; work of the honest nodes. We will show later that the probability of a=
<br>
&gt; slower attacker catching up<br>
&gt; diminishes exponentially as subsequent blocks are added.<br>
&gt; <br>
&gt; <br>
&gt; This, Satoshi (who doesn&#39;t really matter anyways I guess?) claimed=
 that for<br>
&gt; Bitcoin to function properly you need a majority honest nodes.<br>
<br>
Satoshi also made a very fundamental mistake: the whitepaper and initial<br=
>
Bitcoin release chooses the *longest* chain, rather than the most work chai=
n.<br>
Longest chain is totally broken.<br>
<br>
What Satoshi said in the whitepaper is completely irrelevant and quoting it=
 in<br>
circumstances like this is IMO misleading.<br>
<br>
<br>
Anyway, obviously we should always try to make systems that work properly w=
ith<br>
an economically rational majority, rather than the much more risky honest<b=
r>
majority. Economically rational is a better security guarantee. And wheneve=
r<br>
possible we should go even further, using the standard computationally<br>
infeasible guarantees (as seen in our EC signature schems), or even,<br>
mathematically impossible (1+1=3D2).<br>
<br>
It&#39;s notable how in ethereum land, their smart contract schemes have le=
ad to<br>
significant effort in economically rational MEV optimization, at a signific=
ant<br>
cost to decentralization (eg majority of blocks are now OFAC compliant).<br=
>
There&#39;s no reason why Bitcoin should be fundamentally any different in =
the long<br>
run.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>

--000000000000beb27c05eb800a8a--