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: Mon, 11 Apr 2022 23:05:22 +1000 [thread overview]
Message-ID: <20220411130522.GA3633@erisian.com.au> (raw)
In-Reply-To: <CABm2gDrsZ9ZimFTkNrdj+wr7328h2N2GmRCawq8xYv3BqyHNow@mail.gmail.com>
On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Timón via bitcoin-dev wrote:
> On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns <aj@erisian•com.au> wrote:
> > > Let's discuss those too. Feel free to point out how bip8 fails at some
> > > hypothetical cases speedy trial doesn't.
> > Any case where a flawed proposal makes it through getting activation
> > parameters set and released, but doesn't achieve supermajority hashpower
> > support is made worse by bip8/lot=true in comparison to speedy trial
> I disagree. Also, again, not the hypothetical case I want to discuss.
You just said "Let's discuss those" and "Feel free to point out how bip8
fails at some hypothetical cases speedy trial doesn't", now you're
saying it's not what you want to discuss?
But the above does include your "evil soft fork" hypothetical (I mean,
unless you think being evil isn't a flaw?). The evil soft fork gets
proposed, and due to some failure in review, merged with activation
parameters set (via either speedy trial or bip8), then:
a) supermajority hashpower support is achieved quickly:
- both speedy trial and bip8+lot=true activate the evil fork
b) supermajority hashpower support is achieved slowly:
- speedy trial does *not* activate the evil fork, as it times out
quickly
- bip8 *does* activate the fork
c) supermajority hashpower support support is never achieved:
- speedy trial does *not* activate the evil fork
- bip8+lot=false does *not* activate the evil fork, but only after a
long timeout
- bip8+lot=true *does* activate the evil fork
In case (a), they both do the same thing; in case (b) speedy trial is
superior to bip8 no matter whether lot=true/false since it blocks the
evil fork, and in case (c) speedy trial is better than lot=false because
it's quicker, and much better than lot=true because lot=true activates
the evil fork.
> > > > 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
> > > "That guy's incoherent raving"
> > > "I'm just disagreeing".
> >
> > Uh, you realise the above is an alternative hypothetical, and not talking
> > about you? I would have thought "that guy" being "an enemy of bitcoin"
> > made that obvious... I think you're mistaken; I don't think your emails
> > are incoherent ravings.
> Do you realize IT IS NOT the hypothetical case I wanted to discuss.
Yes, that's what "alternative" means: a different one.
> I'm sorry, but I'm tired of trying to explain. and quite, honestly, you
> don't seem interested in listening to me and understanding me at all, but
> only in "addressing my concerns". Obviously we understand different things
> by "addressing concerns".
> Perhaps it's the language barrier or something.
My claim is that for *any* bad (evil, flawed, whatever) softfork, then
attempting activation via bip8 is *never* superior to speedy trial,
and in some cases is worse.
If I'm missing something, you only need to work through a single example
to demonstrate I'm wrong, which seems like it ought to be easy... But
just saying "I disagree" and "I don't want to talk about that" isn't
going to convince anyone.
I really don't think the claim above should be surprising; bip8 is meant
for activating good proposals, bad ones need to be stopped in review --
as "pushd" has said in this thread: "Flawed proposal making it through
activation is a failure of review process", and Luke's said similar things
as well. The point of bip8 isn't to make it easier to reject bad forks,
it's to make it easier to ensure *good* forks don't get rejected. But
that's not your hypothetical, and you don't want to talk about all the
ways to stop an evil fork prior to an activation attempt...
Cheers,
aj
next prev parent reply other threads:[~2022-04-11 13:05 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-11 0:12 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
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 [this message]
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=20220411130522.GA3633@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/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