From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C0CBBF66 for ; Sat, 29 Aug 2015 21:21:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4126A234 for ; Sat, 29 Aug 2015 21:21:07 +0000 (UTC) Received: by lbvd4 with SMTP id d4so9094763lbv.3 for ; Sat, 29 Aug 2015 14:21:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tRMMTMGZvXy0SMfgajaOz0dqoWib3yg9YIhaC4AhDBI=; b=ETEcvVLqCzp3mZFMh/08095JlKet/rXgMZYzb505oQ2iBp1lPCNHgIwSjignu7APfq 1zDxfA4kV1TXHeLXz2ktcQlm6SI1eU3hE9ydAu7ovtwC4lY6g4Q45I+yOd1XWNY9C1mM ekb7eqM1K81v4+b4R3Av6e+tfFfWTrEJK/D1ag3sMxnJa5eEHbmi5tRbouQeHPGob7kj 91lNRE6XQRRaa3DHcKIzMILNUrLXNsZ6r6t954ThhNzn5cXnkwnL1R2YuMYz/G+f4tft aNzos3eZZIJW3wZuEhkrgpMSqXxwDRzV74ithuSNyZk0lUyKN7hrpwPR2g6R6LRbIPWZ 7Y3w== X-Gm-Message-State: ALoCoQlNaJjMHAw4DAAoIoJqi/QrjSm4IYPreoSck7LrLAQyl6CT2FgKhJhBKhpgQboHPm1LjSaQ MIME-Version: 1.0 X-Received: by 10.152.21.196 with SMTP id x4mr7112244lae.117.1440883265553; Sat, 29 Aug 2015 14:21:05 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Sat, 29 Aug 2015 14:21:05 -0700 (PDT) In-Reply-To: References: <55BBB32B.3080802@gmail.com> Date: Sat, 29 Aug 2015 23:21:05 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Thomas Kerin , Andy Chase , Gregory Maxwell Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 21:21:08 -0000 On Wed, Aug 26, 2015 at 1:20 AM, Andy Chase via bitcoin-dev 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?