Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6CABC1CBB for ; Mon, 5 Oct 2015 13:24:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DE557299 for ; Mon, 5 Oct 2015 13:24:55 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so114513291wic.1 for ; Mon, 05 Oct 2015 06:24:54 -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=8r205dXrB4KFzGsIzG2ogngQeJhp3Z7eov3bkE+Kngk=; b=Nb4UhLBwSjItNH+lHZ7ahiRuEyE6z/BrOaBYJU/vbuahTYAg3mmh6E7FN8GNpOD8s3 3jLjcmB5PGv9XcxvQSbgr74idDS6oF9fPERKOWbbrXJG+uUxuJ5GHAXnS/SEtRx+4FrZ zcsSobHH2BpdG69PNjZILB3lIhNNhwpBg9rpoCHW6e9e9U7kx8zI786bm2kKjiojtN20 kzWLLoMc7pG7959NgHXwK3ELvdr1tJw8D0rIEeZCPGt4CaVpqAI0loTdmZECf9nadTQe 9Atqz98FSm6wTwHbcj3vyCK7FHQ9d/nPWHWzveA3v2ExKCjNv3fX50BKbKql3UC7FV4f 1xyg== X-Gm-Message-State: ALoCoQkIkvBGibZmXx0OQrYVug7LUODvb6/QrwK3eGN5hRjVlTzXKAvE22BB7uemR0w6s5UbTUrt MIME-Version: 1.0 X-Received: by 10.194.77.240 with SMTP id v16mr29192074wjw.109.1444051494308; Mon, 05 Oct 2015 06:24:54 -0700 (PDT) Received: by 10.194.114.199 with HTTP; Mon, 5 Oct 2015 06:24:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Oct 2015 15:24:54 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: NotMike Hearn 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] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! 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: Mon, 05 Oct 2015 13:24:56 -0000 "Consensus" it's a term we use for consensus critical code and we refer to different machines (potentially with different software) validating in exactly the same way. I think also using the term for people agreeing on what those consensus rules is confusing, so in BIP99 I used the term "uncontroversial" instead. From BIP99 current's content (improvements welcomed): " Uncontroversial consensus upgrades "Uncontroversial" is something though to define in this context. What if a single user decides he won't upgrade no matter what and he doesn't even attempt to explain his decision? Obviously, such a user should be just ignored. But what if the circumstances are slightly different? What if they're 2, 10 users? Where's the line? It is possible that we can never have a better definition than "I know it when I see it" [citation]. " The fact that there's at least 3 different proposals for a blocksize increase, that there's not a lot of data comparing different possible block sizes and its potential effects on block propagation and that the development progress has enormously slowed down during months of discussion are, in my opinion, clear signs that none of the current proposals are "uncontroversial", even by this vague definition. I believe BIP65 is uncontroversial since no reasonable objections to the feature itself have been raised, it has been widely reviewed and tested. The only complain is about it is it's softfork deployment mechanism. Was deployment of bip16, bip30 or bip66 controversial (which were deployed via softforks, some of them even with people [ie Mike Hearn] preferring always hardforks over softforks) uncontroversial? I believe they were all (maybe with the exception of bip16) uncontroversial. That's the story bip99 is telling, but bip99 is not finished so we can change that if it makes sense. We could say that they have been "Unilateral softforks", but I don't think that would be fair for the miners who helped deploy it. Or we could always create a new category in bip99 (please, propose a new category of softforks if you think there's some potential case that's not covered). This is not about Mike Hearn or you or any person in particular. "Uncontroversial" is so far defined in a vague way, if you think you can put a more formal definition forward, please do so (provided that it's not an absurd definition which allows any individual to block everything without reasonable arguments). I'm more than happy improving bip99 before we move it from its current "draft" status. If Mike Hearn (and you) are right, I should update bip99 to NEVER recommend softforks for consensus rule changes. But I still believe it is uncontroversial that softforks have great advantages in many cases (even if not everybody understand this). I want bip99 itself to be uncontroversial, so please nit/nack fast, nit/nack often and please please please nit/nack on time (while bip99 is still a draft).