From: Peter Todd <pete@petertodd•org>
To: Jeremy Rubin <jeremy.l.rubin@gmail•com>,
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)
Date: Thu, 20 Oct 2022 18:28:16 -0400 [thread overview]
Message-ID: <Y1HLgLkCmVJQtqT+@petertodd.org> (raw)
In-Reply-To: <CAD5xwhjXh33AdK96eToHtDP3t_Zx5JbxCqJFbAQRRRKy6rFC2Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2245 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-10-20 22:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-16 17:35 Jeremy Rubin
2022-10-16 19:03 ` email
2022-10-17 19:10 ` Jeremy Rubin
2022-10-17 22:31 ` email
2022-10-18 3:34 ` Jeremy Rubin
2022-10-18 14:30 ` Russell O'Connor
2022-10-18 16:27 ` Jeremy Rubin
2022-10-18 17:33 ` Erik Aronesty
2022-10-18 18:57 ` email
2022-10-20 19:21 ` email
2022-10-20 22:19 ` Peter Todd
2022-10-17 15:51 ` Russell O'Connor
2022-10-17 19:02 ` Jeremy Rubin
2022-10-20 22:28 ` Peter Todd [this message]
2022-10-20 23:54 ` Jeremy Rubin
2022-10-21 0:26 ` Peter Todd
2022-10-21 8:47 ` email
2022-10-21 13:17 ` S kang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1HLgLkCmVJQtqT+@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jeremy.l.rubin@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox