From: Eric Voskuil <eric@voskuil•org>
To: Pieter Wuille <pieter.wuille@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
Date: Wed, 16 Nov 2016 18:16:23 -0800 [thread overview]
Message-ID: <0d66bf24-2ded-cd98-ec55-945e01b436d0@voskuil.org> (raw)
In-Reply-To: <CAPg+sBiGwz23mm5fCKUrg7GpWwuJ=3Nf2DcN89KxG=g_Wz4vBw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]
On 11/16/2016 05:50 PM, Pieter Wuille wrote:
> If you were trying to point out that buried softforks are similar to
> checkpoints in this regard, I agree.
Yes, that was my point.
> 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.
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.
> 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.
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.
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2016-11-17 2:16 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 [this message]
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=0d66bf24-2ded-cd98-ec55-945e01b436d0@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/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