From: "Jorge Timón" <jtimon@jtimon•cc>
To: Thomas Kerin <thomas.kerin@gmail•com>,
Andy Chase <theandychase@gmail•com>,
Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)
Date: Sat, 29 Aug 2015 23:21:05 +0200 [thread overview]
Message-ID: <CABm2gDoGGLAoYpO5LiBnL6ba_4A1LLKOA4iULT8CT_=_Vhg79A@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDo=LKLhEh0AXBzifR8QDc2epQ8=uObBdskRyf0shShPzw@mail.gmail.com>
On Wed, Aug 26, 2015 at 1:20 AM, Andy Chase via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> As I understand Github is not to be used for the high-level discussion
> of a draft BIP so I will post my thoughts here (is this specified
> somewhere? Can we specify this in BIP-0001?).
As specified in BIP001, there's an optional field to link to the
discussion on the mailing list, which in this case links to this
thread (that's why I'm replying here):
https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR8
> - I have some concerns about the structure and the wording of this
> proposal. I think both the structure and the internal wording can be
> slimmed down and simplified
You are probably right, but that is too vague for me to take any action.
Can you propose something more concrete as a PR to my branch?
https://github.com/jtimon/bips/tree/bip-forks
> - I also believe the "history lessons" should be trimmed out,
> mentioned at best
Can you explain why?
I think they're helpful as examples for the explanations (even though
the concrete texts can probably improved/summarized).
> - There's separate BIP for at least one of the code forks
I'm not sure I understand this.
What do you mean by "code forks"?
If you mean "software fork" (like libcoin or bitcoin xt
[pre-controversial-bip101]) those are completely fine and out of scope
for this BIP, since they don't require coordination by the different
users/implementations to upgrade/re-implement the consensus changes.
> - BIP-001 specifies that BIP proposals should not be given a BIP
> number until after they have been spelled checked and approved by an
> editor. Greg Maxwell: was this followed?
I don't think the spell checking had been followed at all for this or
any other BIP, but yes, Greg assigned the number 99 (he did so
privately instead of here on this thread, which I find very annoying
because you are the second person who complains about this).
> - What kind of proposal is this? Informational, Process or Standards
> track?
>
> - I believe it should be Standards Track. Include the proposed
> upgrade path as a patch into core as a module that hard forks
> can use in the future. This will also give us some space to work
> through some of the complexities of forks in a definite way.
> - Alternatively maybe we can split up this BIP into a Standards
> track and a separate Informational BIP?
That is a good question. The proposal currently says "informational |
process": https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR6
But I wasn't really convinced about this so I'm happy to change it to
whatever it's more appropriate.
The contained code is an example of an uncontroversial hardfork to
create a precedent. I'm not sure I understand your proposal for a
"patch into core as a module that hard forks can use in the future".
Can you elaborate what would go in that patch?
prev parent reply other threads:[~2015-08-29 21:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-20 21:22 Jorge Timón
2015-06-20 22:08 ` Tier Nolan
2015-06-21 10:31 ` Jorge Timón
2015-06-21 10:54 ` Tier Nolan
2015-07-23 11:10 ` [bitcoin-dev] " Jorge Timón
2015-07-31 17:40 ` Thomas Kerin
2015-07-31 20:37 ` Jorge Timón
2015-08-29 21:21 ` Jorge Timón [this message]
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='CABm2gDoGGLAoYpO5LiBnL6ba_4A1LLKOA4iULT8CT_=_Vhg79A@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmaxwell@gmail$(echo .)com \
--cc=theandychase@gmail$(echo .)com \
--cc=thomas.kerin@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