public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: Jeremy Rubin <jeremy.l.rubin@gmail•com>
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 20:26:14 -0400	[thread overview]
Message-ID: <Y1HnJnpW9Al1W8cP@petertodd.org> (raw)
In-Reply-To: <CAD5xwhhiOReFJq2gOk2n5tJpD-X-x8aKGrdkdrwi1yJCis0y4g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2578 bytes --]

On Thu, Oct 20, 2022 at 04:54:00PM -0700, Jeremy Rubin wrote:
> 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.

The point is Satoshi got a lot of very fundamental stuff wrong. Bringing up
what Satoshi wrote now, almost 14 years later, misleads less-technical readers
into thinking our understanding of Bitcoin is still based on that early,
incorrect, understanding.

Incidentally, you realize that it was _Satoshi_ who added RBF to Bitcoin with
nSequence replacements. My contribution was to fix that obviously broken design
with fee-based RBF (with nSequence a transaction could be replaced up to 4
billion times, using essentially unlimited P2P bandwidth; it was a terrible
idea).

> 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.

Those people run mild sybil attacks on the network in their efforts to
"mitigate risk" by monitoring propagation; fundamentally doing so is
centralizing and unfair, as only a small number of companies can do that
without DoS attacking the P2P network. It's pretty obvious that reliance to
zeroconf is harmful to Bitcoin, and people trying to do that have repeatedly
taken big losses when their risk mitigations turned out to not work. Their only
right to be mad comes from the 1st Ammendment.

> 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.

...and the easiest way to avoid Bitcoin being a system that doesn't arbitrarily
change rules, is to rely on economically rational rules that aren't likely to
change!

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-10-21  0:26 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
2022-10-21  0:26     ` Peter Todd [this message]
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=Y1HnJnpW9Al1W8cP@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