Re: [bitcoin-dev] [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

["Jorge Timón" <jtimon@jtimon.cc>]

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?