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 288811846 for ; Mon, 28 Sep 2015 12:47:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B7E711C8 for ; Mon, 28 Sep 2015 12:47:26 +0000 (UTC) Received: by ykdz138 with SMTP id z138so177012850ykd.2 for ; Mon, 28 Sep 2015 05:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=/NG7Bcc2SP6JJM9uS88fiBwkTs9+91wJlSpxY26ORhY=; b=TauPfVyvOgBORlZAMxAfhLE71gICvoZ8fimpQhsaI2AVGhU0d/JNeFpCfo1bXdTCSy +GX9ZF+rl7pBuIcblmTFAzbyNk1x9ggXsd5n669wmA1BTOno/w96Y4jOrCkKeo6oYmgg RSEb5l4g34bJfJfsKjgK92mLXf10CxWef66NYhtiTiJnEH8wf3yO/TqjmrkLI2b/k4vF StVa7Uwyp528aZmne8RSRz/OsMpiSVpaEmg3ranA3Ik72X+dMj/zAZcc4QEY+UuvkbiA vySIgUcp6PcQjY2mGLPCdRMPzHLAOCPOzqK1n0OMY+7A6BW6iKDC+aJUGduMswZp9nRJ b8RA== MIME-Version: 1.0 X-Received: by 10.31.0.215 with SMTP id 206mr12247891vka.105.1443444445879; Mon, 28 Sep 2015 05:47:25 -0700 (PDT) Received: by 10.103.65.204 with HTTP; Mon, 28 Sep 2015 05:47:25 -0700 (PDT) In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> Date: Mon, 28 Sep 2015 13:47:25 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113da7c87326910520ce19e0 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MALFORMED_FREEMAIL, MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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, 28 Sep 2015 12:47:27 -0000 --001a113da7c87326910520ce19e0 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 28, 2015 at 11:48 AM, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 1) Drop the "everyone must agree to make changes" idea that people here > like to peddle, and do it loudly, so everyone in the community is correctly > informed > There never was a rule that soft-forks require total consensus. It is desirable but not mandatory. A majority of miners can inherently implement a soft fork against the wishes of the rest of the users. Merchant/exchange/user checkpointing is the defense and therefore is a perfectly valid response to miners taking such an action. If a soft fork is opposed by a large section of the users, then threatening (and implementing) a checkpoint is the correct response. No group can force through a hard fork, it inherently requires buy-in from a large portion of the userbase. That is where the "total consensus" requirement comes from. Naturally, absolute total consensus isn't actually required but you do need very large consensus and also consensus across the various sub-groups. --001a113da7c87326910520ce19e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 28, 2015 at 11:48 AM, Mike Hearn via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
1) Drop the "everyone must agree to make changes" idea that peop= le here like to peddle, and do it loudly, so everyone in the community is c= orrectly informed

There never w= as a rule that soft-forks require total consensus.=C2=A0 It is desirable bu= t not mandatory.=C2=A0

A majority of miners can inherent= ly implement a soft fork against the wishes of the rest of the users.
Merchant/exchange/user checkpointing is the defense and theref= ore is a perfectly valid response to miners taking such an action.=C2=A0 If= a soft fork is opposed by a large section of the users, then threatening (= and implementing) a checkpoint is the correct response.

N= o group can force through a hard fork, it inherently requires buy-in from a= large portion of the userbase.=C2=A0 That is where the "total consens= us" requirement comes from.=C2=A0 Naturally, absolute total consensus = isn't actually required but you do need very large consensus and also c= onsensus across the various sub-groups.
--001a113da7c87326910520ce19e0--