From: Jeremy Rubin <jeremy.l.rubin@gmail•com>
To: Peter Todd <pete@petertodd•org>
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)
Date: Thu, 20 Oct 2022 16:54:00 -0700 [thread overview]
Message-ID: <CAD5xwhhiOReFJq2gOk2n5tJpD-X-x8aKGrdkdrwi1yJCis0y4g@mail.gmail.com> (raw)
In-Reply-To: <Y1HLgLkCmVJQtqT+@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 6247 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 10064 bytes --]
next prev parent reply other threads:[~2022-10-20 23:54 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
2022-10-20 23:54 ` Jeremy Rubin [this message]
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=CAD5xwhhiOReFJq2gOk2n5tJpD-X-x8aKGrdkdrwi1yJCis0y4g@mail.gmail.com \
--to=jeremy.l.rubin@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/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