public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Anthony Towns <aj@erisian.com.au>
To: "Jorge Timón" <jtimon@jtimon.cc>,
	"Bitcoin Protocol Discussion"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Speedy Trial
Date: Sat, 26 Mar 2022 11:45:46 +1000	[thread overview]
Message-ID: <20220326014546.GA12225@erisian.com.au> (raw)
In-Reply-To: <CABm2gDoC5Y=o6Vu7urzBoioVmXBf+YBLg95w-kupx9nidRDBPg@mail.gmail.com>

On Thu, Mar 24, 2022 at 07:30:09PM +0100, Jorge Timón via bitcoin-dev wrote:
> Sorry, I won't answer to everything, because it's clear you're not listening.

I'm not agreeing with you; that's different to not listening to you.

> In the HYPOTHETICAL CASE that there's an evil for, the fork being evil
> is a PREMISE of that hypothetical case, a GIVEN.

Do you really find people more inclined to start agreeing with you when
you begin yelling at them? When other people start shouting at you,
do you feel like it's a discussion that you're engaged in?

> Your claim that "if it's evil, good people would oppose it" is a NON
> SEQUITUR, "good people" aren't necessarily perfect and all knowing.
> good people can make mistakes, they can be fooled too.
> In the hypothetical case that THERE'S AN EVIL FORK, if "good people"
> don't complain, it is because they didn't realize that the given fork
> was evil. Because in our hypothetical example THE EVIL FORK IS EVIL BY
> DEFINITION, THAT'S THE HYPOTHETICAL CASE I WANT TO DISCUSS, not the
> hypothetical case where there's a fork some people think it's evil but
> it's not really evil.

The problem with that approach is that any solution we come up with
doesn't only have to deal with the hypotheticals you want to discuss.

In particular, any approach that allows you to block an evil fork,
even when everyone else doesn't agree that it's evil, would also allow
an enemy of bitcoin to block a good fork, that everyone else correctly
recognises is good. A solution that works for an implausible hypothetical
and breaks when a single attacker decides to take advantage of it is
not a good design.

And I did already address what to do in exactly that scenario:

> > But hey what about the worst case: what if everyone else in bitcoin
> > is evil and supports doing evil things. And maybe that's not even
> > implausible: maybe it's not an "evil" thing per se, perhaps [...]
> >
> > In that scenario, I think a hard fork is the best choice: split out a new
> > coin that will survive the upcoming crash, adjust the mining/difficulty
> > algorithm so it works from day one, and set it up so that you can
> > maintain it along with the people who support your vision, rather than
> > having to constantly deal with well-meaning attacks from "bitcoiners"
> > who don't see the risks and have lost the plot.
> >
> > Basically: do what Satoshi did and create a better system, and let
> > everyone else join you as the problems with the old one eventually become
> > unavoidably obvious.

> Once you understand what hypothetical case I'm talking about, maybe
> you can understand the rest of my reasoning.

As I understand it, your hypothetical is:

 0) someone has come up with a bad idea
 1) most of bitcoin is enthusiastically behind the idea
 2) you are essentially alone in discovering that it's a bad idea
 3) almost everyone remains enthusiastic, despite your explanations that
    it's a bad idea
 4) nevertheless, you and your colleagues who are aware the idea is bad
    should have the power to stop the bad idea
 5) bip8 gives you the power to stop the bad idea but speedy trial does not

Again given (0), I think (1) and (2) are already not very likely, and (3)
is simply not plausible. But in the event that it does somehow occur,
I disagree with (4) for the reasons I describe above; namely, that any
mechanism that did allow that would be unable to distinguish between the
"bad idea" case and something along the lines of:

 0') someone has come up with a good idea (yay!)
 1') most of bitcoin is enthusiastically behind the idea
 2') an enemy of bitcoin is essentially alone in trying to stop it
 3') almost everyone remains enthusiastic, despite that guy's incoherent
     raving
 4') nevertheless, the enemies of bitcoin should have the power to stop
     the good idea

And, as I said in the previous mail, I think (5) is false, independently
of any of the other conditions.

> But if you don't understand the PREMISES of my example, 

You can come up with hypothetical premises that invalidate bitcoin,
let alone some activation method. For example, imagine if the Federal
Reserve Board are full of geniuses and know exactly when to keep issuance
predictable and when to juice the economy? Having flexibility gives more
options than hardcoding "21M" somewhere, so clearly the USD's approach
is the way to go, and everything is just a matter of appointing the
right people to the board, not all this decentralised stuff. 

The right answer is to reject bad premises, not to argue hypotheticals
that have zero relationship to reality.

Cheers,
aj



  reply	other threads:[~2022-03-26  1:46 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11  0:12 [bitcoin-dev] Speedy Trial Russell O'Connor
2022-03-11  0:28 ` Luke Dashjr
2022-03-11  5:41   ` Billy Tetrud
2022-03-11 12:19 ` Jorge Timón
2022-03-11 13:47   ` Russell O'Connor
2022-03-11 14:04     ` Jorge Timón
2022-03-12 13:34       ` Russell O'Connor
2022-03-12 17:52         ` Billy Tetrud
2022-03-17 12:18           ` Jorge Timón
2022-03-23 22:34           ` Kate Salazar
2022-03-15 17:21         ` Jeremy Rubin
2022-03-17  4:17           ` Billy Tetrud
2022-03-18 18:36           ` Jorge Timón
2022-03-17 12:08         ` Jorge Timón
2022-03-17 15:38           ` Billy Tetrud
2022-03-18 23:01             ` ZmnSCPxj
2022-03-21  3:41               ` Billy Tetrud
2022-03-21 15:56                 ` vjudeu
2022-03-22 15:19                   ` Billy Tetrud
2022-03-22 15:45                     ` Eric Voskuil
2022-03-22 16:37                     ` vjudeu
2022-03-19 16:43             ` vjudeu
2022-03-15 15:45       ` Anthony Towns
2022-03-17 14:04         ` Jorge Timón
2022-03-22 23:49           ` Anthony Towns
2022-03-24 18:30             ` Jorge Timón
2022-03-26  1:45               ` Anthony Towns [this message]
2022-03-28  8:31                 ` Jorge Timón
2022-03-30  4:21                   ` Anthony Towns
2022-04-08  9:58                     ` Jorge Timón
2022-04-11 13:05                       ` Anthony Towns
2022-04-24 11:13                         ` Jorge Timón
2022-04-24 12:14                           ` Anthony Towns
2022-04-24 12:44                             ` Jorge Timón
2022-04-25 16:11                               ` Keagan McClelland
2022-04-25 17:00                                 ` Anthony Towns
2022-04-25 17:26                                   ` Keagan McClelland
2022-04-26  5:42                                     ` Anthony Towns
2022-04-26 13:05                                       ` Erik Aronesty
2022-04-27  2:35                                         ` Billy Tetrud
2022-03-11 16:26     ` Billy Tetrud
2022-03-17 11:32       ` Jorge Timón
2022-03-11 11:14 pushd
2022-03-12 17:11 pushd
2022-03-17 14:34 pushd
2022-03-26 12:59 pushd
2022-03-30 10:34 pushd
2022-03-30 20:10 ` Billy Tetrud
2022-03-30 21:14   ` pushd
2022-03-31  4:31     ` Billy Tetrud
2022-03-31 14:19       ` pushd
2022-03-31 15:34         ` Billy Tetrud
2022-03-31 15:55           ` pushd

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=20220326014546.GA12225@erisian.com.au \
    --to=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jtimon@jtimon.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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