From: Gregory Maxwell <greg@xiph•org>
To: Luke Dashjr <luke@dashjr•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments
Date: Wed, 14 Feb 2018 22:20:31 +0000 [thread overview]
Message-ID: <CAAS2fgRBCCsosSxN9UDXmPoO3fJX1etbwtsOGd5BfkZTAo4wjA@mail.gmail.com> (raw)
In-Reply-To: <201802142211.44293.luke@dashjr.org>
On Wed, Feb 14, 2018 at 10:11 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Wednesday 14 February 2018 10:01:46 PM Marco Falke via bitcoin-dev wrote:
>> BIP 123 suggests that BIPs in the consensus layer should be assigned a
>> label "soft fork" or "hard fork". However, I think the differentiation
>> into soft fork or hard fork should not be made for BIPs that document
>> buried deployments. In contrast to soft forks and hard forks, buried
>> deployments do not require community and miner coordination for a safe
>> deployment.
>
> They also do not require software coordination. Therefore, why should there be
> BIPs at all? Seems to me that we should instead add these documents to
> https://github.com/bitcoin-core/docs
In that sense, no but they help people understand the system (e.g. so
they don't go look at implementations and confuse that the activations
they expect are simply not there); and they aid other implementations
in understanding what other people have already analyzed and concluded
was safe. You could certainly get an analysis wrong for one of these
things.
next prev parent reply other threads:[~2018-02-14 22:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-14 22:01 Marco Falke
2018-02-14 22:11 ` Luke Dashjr
2018-02-14 22:20 ` Gregory Maxwell [this message]
2018-02-14 23:57 ` Eric Voskuil
2018-02-18 18:57 ` Marco Falke
2018-02-21 17:27 ` Eric Voskuil
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=CAAS2fgRBCCsosSxN9UDXmPoO3fJX1etbwtsOGd5BfkZTAo4wjA@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(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