Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-05 📝 Original message:"Consensus" it's a term we ...
📅 Original date posted:2015-10-05
📝 Original message:"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).
📝 Original message:"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).