Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

["Jorge Timón" <jtimon@jtimon.cc>]

On Wed, Nov 16, 2016 at 2:58 PM, Eric Voskuil via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> This sort of statement represents one consequence of the aforementioned bad
> precedent.
>
> Are checkpoints good now?

Checkpoints are not necessary for consensus and work is being done to
remove them completely from Bitcoin Core in particular.

> Are hard forks okay now?

I personally think uncontroversial hardforks are ok.

> What is the maximum depth of a reorg allowed by this non-machine consensus?

Good question, specially if we plan to do this with future buried
deployments. What about 1 year reorg?

> Shouldn't we just define a max depth so that all cruft deeper than that can
> just be discarded on a regular basis?

Not sure I understand this question.

> Why are there activation heights defined by this hard fork if it's not
> possible to reorg back to them?

If this is a hardfork, it is one that will only be visible if/when
there's a very deep reorg , one of the kind where we can practically
consider Bitcoin done (and only if some nodes keep the ISM code).
But I could accept that definition. Another way to see it (even though
other said the optimization part was not important) as such an
optimization and simplification.
The way I see it, ISM and BIP9 are just coordination mechanisms for
uncontroversial rule changes.
Once the coordination happened and is long in the past, I really don't
see the problem with replacing the mechanism with a simpler height.

> The "BIP" is neither a Proposal (it's been decided, just documenting for
> posterity), nor an Improvement (there is no actual benefit, just some
> tidying up in the notoriously obtuse satoshi code base), nor Bitcoin (a hard
> fork defines an alt coin, so from Aug 4 forward it has been CoreCoin).

Mhmm, I disagree on the notion that any hardfork necessarily
represents an altcoin.
It is certainly an improvement in the sense that it simplifies
implementations and optimizes validation. You may argue that you don't
consider the improvement important though.
These changes to Bitcoin Core could be rolled back (and obviously
other implementations don't need to adopt them unless they want to
benefit from the simplification/optimization or fear such a long
reaorg), but I really hope we don't.

Trying to understand you better...
Accepting your definition of this as a hardfork, do you oppose to it
simply because it is a hardfork, or because you consider this
"hardfork" a bad idea for some reason I am missing?