From: "Jorge Timón" <jtimon@jtimon•cc>
To: Eric Voskuil <eric@voskuil•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
Date: Thu, 17 Nov 2016 00:48:02 +0100 [thread overview]
Message-ID: <CABm2gDr5iLWD5vzzi-MyHV235CgqtXb-fNThM9agx0T64m+t-Q@mail.gmail.com> (raw)
In-Reply-To: <A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
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?
next prev parent reply other threads:[~2016-11-16 23:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 18:17 Suhas Daftuar
2016-11-14 18:47 ` Eric Voskuil
2016-11-15 14:42 ` Suhas Daftuar
2016-11-15 17:45 ` Btc Drak
2016-11-15 22:42 ` Eric Voskuil
2016-11-16 13:29 ` Jameson Lopp
2016-11-16 13:58 ` Eric Voskuil
2016-11-16 14:18 ` Tier Nolan
2016-11-16 14:32 ` Alex Morcos
2016-11-16 21:01 ` Peter Todd
2016-11-16 22:21 ` Eric Voskuil
2016-11-17 3:06 ` Luke Dashjr
2016-11-16 14:18 ` Thomas Kerin
2016-11-16 23:58 ` Jorge Timón
2016-11-17 0:00 ` Eric Voskuil
2016-11-17 1:24 ` Alex Morcos
2016-11-17 1:41 ` Eric Voskuil
2016-11-17 0:13 ` Eric Voskuil
2016-11-16 23:48 ` Jorge Timón [this message]
2016-11-17 1:50 ` Pieter Wuille
2016-11-17 2:16 ` Eric Voskuil
2016-11-17 2:47 ` Pieter Wuille
2016-11-17 10:10 ` Eric Voskuil
2016-11-16 14:38 ` Tom Zander
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=CABm2gDr5iLWD5vzzi-MyHV235CgqtXb-fNThM9agx0T64m+t-Q@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)org \
/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