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? _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
