From: Pieter Wuille <pieter.wuille@gmail•com>
To: Eric Voskuil <eric@voskuil•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
Date: Wed, 16 Nov 2016 18:47:33 -0800 [thread overview]
Message-ID: <CAPg+sBhYfoCtpzQAQXtQ4r2zVtC3Exwe55o-BF+=Eez1cb==4w@mail.gmail.com> (raw)
In-Reply-To: <0d66bf24-2ded-cd98-ec55-945e01b436d0@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 2988 bytes --]
On Wed, Nov 16, 2016 at 6:16 PM, Eric Voskuil <eric@voskuil•org> wrote:
> On 11/16/2016 05:50 PM, Pieter Wuille wrote:
>
> > So are checkpoints good now?
> > I believe we should get rid of checkpoints because they seem to be
> misunderstood as a security feature rather than as an optimization.
>
> Or maybe because they place control of the "true chain" in the hands of
> those selecting the checkpoints? It's not a great leap for the parties
> distributing the checkpoints to become the central authority.
>
Yes, they can be used to control the "true chain", and this has happened
with various forks. But developers inevitably have this possibility, if you
ignore review. If review is good enough to catch unintended consensus
changes, it is certainly enough to catch the introduction of an invalid
checkpoint. The risk you point out is real, but the way to deal with it is
good review and release practices.
I wish we had never used checkpoints the way we did, but here we are.
Because of this, I want to get rid of them. However, It's not because I
think they offer an excessive power to developers - but because they're
often perceived this way (partially as a result of how they've been abused
in other systems).
> I recommend users of our node validate the full chain without
> checkpoints and from that chain select their own checkpoints and place
> them into config. From that point forward they can apply the
> optimization. Checkpoints should never be hardcoded into the source.
>
Having users with the discipline you suggest would be wonderful to have. I
don't think it's very realistic, though, and I fear that the result would
be that everyone copies their config from one or a few websites "because
that's what everyone uses".
> I don't think buried softforks have that problem.
>
> I find "buried softfork" a curious name as you are using it. You seem to
> be implying that this type of change is itself a softfork as opposed to
> a hardfork that changes the activation of a softfork. It was my
> understanding that the term referred to the 3 softforks that were being
> "buried", or the proposal, but not the burial itself.
>
I do not consider the practice of "buried softforks" to be a fork at all.
It is a change that modifies the validity of a theoretically construable
chain from invalid to valid. However, a reorganization to that theoretical
chain itself is likely already impossible due to the vast number of blocks
to rewind, and economic damage that is far greater than chain divergence
itself.
> Nevertheless, this proposal shouldn't have "that problem" because it is
> clearly neither a security feature nor an optimization. That is the
> first issue that needs to be addressed.
It is clearly not a security feature, agreed. But how would you propose to
avoid the ISM checks for BIP34 and BIP66 all the time? I feel this approach
is a perfectly reasonable choice for code that likely won't ever affect the
valid chain again.
Cheers,
--
Pieter
[-- Attachment #2: Type: text/html, Size: 4278 bytes --]
next prev parent reply other threads:[~2016-11-17 2:47 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
2016-11-17 1:50 ` Pieter Wuille
2016-11-17 2:16 ` Eric Voskuil
2016-11-17 2:47 ` Pieter Wuille [this message]
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='CAPg+sBhYfoCtpzQAQXtQ4r2zVtC3Exwe55o-BF+=Eez1cb==4w@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--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