From: "Jorge Timón" <jtimon@jtimon•cc>
To: NotMike Hearn <not.mike.hearn@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Date: Mon, 5 Oct 2015 15:24:54 +0200 [thread overview]
Message-ID: <CABm2gDoxzYWM2VSq1WLRSD61LaVNkQ2puwOEEuRP78s6+WRYCA@mail.gmail.com> (raw)
In-Reply-To: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
"Consensus" it's a term we use for consensus critical code and we
refer to different machines (potentially with different software)
validating in exactly the same way.
I think also using the term for people agreeing on what those
consensus rules is confusing, so in BIP99 I used the term
"uncontroversial" instead.
From BIP99 current's content (improvements welcomed):
"
Uncontroversial consensus upgrades
"Uncontroversial" is something though to define in this context. What
if a single user decides he won't upgrade no matter what and he
doesn't even attempt to explain his decision? Obviously, such a user
should be just ignored. But what if the circumstances are slightly
different? What if they're 2, 10 users? Where's the line? It is
possible that we can never have a better definition than "I know it
when I see it" [citation].
"
The fact that there's at least 3 different proposals for a blocksize
increase, that there's not a lot of data comparing different possible
block sizes and its potential effects on block propagation and that
the development progress has enormously slowed down during months of
discussion are, in my opinion, clear signs that none of the current
proposals are "uncontroversial", even by this vague definition.
I believe BIP65 is uncontroversial since no reasonable objections to
the feature itself have been raised, it has been widely reviewed and
tested. The only complain is about it is it's softfork deployment
mechanism.
Was deployment of bip16, bip30 or bip66 controversial (which were
deployed via softforks, some of them even with people [ie Mike Hearn]
preferring always hardforks over softforks) uncontroversial?
I believe they were all (maybe with the exception of bip16)
uncontroversial. That's the story bip99 is telling, but bip99 is not
finished so we can change that if it makes sense.
We could say that they have been "Unilateral softforks", but I don't
think that would be fair for the miners who helped deploy it. Or we
could always create a new category in bip99 (please, propose a new
category of softforks if you think there's some potential case that's
not covered).
This is not about Mike Hearn or you or any person in particular.
"Uncontroversial" is so far defined in a vague way, if you think you
can put a more formal definition forward, please do so (provided that
it's not an absurd definition which allows any individual to block
everything without reasonable arguments). I'm more than happy
improving bip99 before we move it from its current "draft" status.
If Mike Hearn (and you) are right, I should update bip99 to NEVER
recommend softforks for consensus rule changes.
But I still believe it is uncontroversial that softforks have great
advantages in many cases (even if not everybody understand this).
I want bip99 itself to be uncontroversial, so please nit/nack fast,
nit/nack often and please please please nit/nack on time (while bip99
is still a draft).
next prev parent reply other threads:[~2015-10-05 13:24 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 1:57 NotMike Hearn
2015-10-02 2:12 ` GC
2015-10-05 10:59 ` Mike Hearn
2015-10-05 11:23 ` Jeff Garzik
2015-10-05 11:28 ` Mike Hearn
2015-10-05 12:04 ` Jorge Timón
2015-10-05 12:08 ` Clément Elbaz
2015-10-05 12:16 ` Jorge Timón
2015-10-05 12:29 ` Clément Elbaz
2015-10-05 15:42 ` Jorge Timón
2015-10-05 12:10 ` Mike Hearn
2015-10-05 15:33 ` Jorge Timón
2015-10-05 16:46 ` Mike Hearn
2015-10-06 6:20 ` Anthony Towns
2015-10-07 6:13 ` Micha Bailey
2015-10-05 13:29 ` Jorge Timón
2015-10-05 13:24 ` Jorge Timón [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-09-27 18:50 Peter Todd
2015-09-27 20:26 ` jl2012
2015-09-27 20:27 ` Peter Todd
2015-09-27 20:27 ` Mark Friedenbach
2015-09-27 20:41 ` Btc Drak
2015-09-28 10:10 ` s7r
2015-09-28 10:48 ` Mike Hearn
2015-09-28 11:00 ` Adam Back
2015-09-28 11:40 ` Mike Hearn
2015-09-28 12:20 ` Eric Lombrozo
2015-09-28 12:26 ` Mike Hearn
2015-09-28 12:44 ` Eric Lombrozo
2015-09-28 12:54 ` Mike Hearn
2015-09-29 6:17 ` Eric Lombrozo
2015-09-29 12:02 ` Mike Hearn
2015-09-28 14:05 ` Btc Drak
2015-09-28 14:17 ` Mike Hearn
2015-09-28 21:12 ` odinn
2015-09-28 22:16 ` Dave Scotese
2015-09-28 11:04 ` Eric Lombrozo
2015-09-28 12:47 ` Tier Nolan
2015-09-28 13:01 ` Gavin Andresen
2015-09-28 13:28 ` Peter Todd
2015-09-28 13:43 ` Gavin Andresen
2015-09-28 14:14 ` Peter Todd
2015-09-28 13:21 ` Peter Todd
2015-09-28 13:41 ` Mike Hearn
2015-09-28 14:29 ` Peter Todd
2015-09-28 14:33 ` Mike Hearn
2015-09-28 14:43 ` Peter Todd
2015-09-28 14:51 ` Mike Hearn
2015-09-28 15:05 ` Peter Todd
2015-09-28 15:38 ` Mike Hearn
2015-09-28 16:52 ` jl2012
2015-09-28 17:14 ` Mike Hearn
2015-09-28 23:17 ` Jorge Timón
2015-09-29 12:07 ` Mike Hearn
2015-09-29 13:30 ` Jonathan Toomim (Toomim Bros)
2015-09-29 15:59 ` jl2012
2015-09-29 19:54 ` odinn
2015-09-29 18:31 ` Gregory Maxwell
2015-09-30 17:11 ` Mike Hearn
2015-09-30 17:58 ` Jorge Timón
2015-10-01 14:23 ` Tom Harding
2015-09-30 18:15 ` Adam Back
2015-09-30 19:26 ` Jeff Garzik
2015-09-30 19:56 ` Mike Hearn
2015-09-30 20:37 ` Jorge Timón
2015-09-30 21:06 ` Mike Hearn
2015-09-30 22:14 ` Jorge Timón
2015-10-01 0:11 ` Jorge Timón
2015-09-30 22:17 ` Jeff Garzik
2015-09-30 23:25 ` Gregory Maxwell
2015-09-30 20:15 ` Gregory Maxwell
2015-09-30 21:01 ` Mike Hearn
2015-09-30 22:59 ` Gregory Maxwell
2015-10-07 15:00 ` Anthony Towns
2015-10-07 15:46 ` Jonathan Toomim (Toomim Bros)
2015-10-07 16:02 ` Eric Lombrozo
2015-10-07 16:25 ` Eric Lombrozo
2015-10-07 16:26 ` Jonathan Toomim (Toomim Bros)
2015-10-07 16:38 ` Anthony Towns
2015-10-10 7:23 ` Anthony Towns
2015-10-12 7:02 ` digitsu
2015-10-12 16:33 ` Anthony Towns
2015-10-12 17:06 ` Anthony Towns
2015-10-13 0:08 ` digitsu
2015-09-29 20:03 ` Wladimir J. van der Laan
2015-09-30 4:05 ` Rusty Russell
2015-09-30 6:19 ` Adam Back
2015-09-30 12:30 ` Mike Hearn
2015-09-30 15:55 ` Jorge Timón
2015-09-30 19:17 ` John Winslow
2015-10-01 0:06 ` Rusty Russell
2015-09-30 17:14 ` Adam Back
2015-10-01 0:04 ` Rusty Russell
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=CABm2gDoxzYWM2VSq1WLRSD61LaVNkQ2puwOEEuRP78s6+WRYCA@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=not.mike.hearn@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