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 4C951D8E for ; Wed, 30 Sep 2015 02:57:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9028713F for ; Wed, 30 Sep 2015 02:57:53 +0000 (UTC) Received: by igbkq10 with SMTP id kq10so95194596igb.0 for ; Tue, 29 Sep 2015 19:57:53 -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:to :cc:content-type; bh=++Mc21nd2k8DUAgZkz2ZM73eFx6L1CJfHFGPUyNVvF0=; b=0fQC7tCldJ7ucE1gvmBTzZn5zv5GbbxH9HYmGrWEb0PVm1KuK0pM3nIJET3tddXf01 zbTciFKzLiVZ2j/1yredlKvH0lDFezv8n0aiuBizRNEQySNSKHwmlUl0RyvMBgdA5Xyv gL7y7j2rOrmxYFyze8BXlqPvWAxYeJnZExI+ojtgRuatWZgIjwImGdT5s94kWxIub62P r4c+BGpjJ6iV2tB/Vtj1CHZxnurq0sWAhlNPCFEFDIXyTj43b8Tx2HDoqqxbSHdth4ih PZYtF4X7GC3/PSoxpC7mIxXcOt6SE7eBNE6WgcQ+V7jfZOudQWewrQlB29NGbsJTQ/fA PNiQ== MIME-Version: 1.0 X-Received: by 10.50.142.7 with SMTP id rs7mr26563619igb.62.1443581873012; Tue, 29 Sep 2015 19:57:53 -0700 (PDT) Received: by 10.107.19.30 with HTTP; Tue, 29 Sep 2015 19:57:52 -0700 (PDT) In-Reply-To: <87zj04fxkw.fsf@rustcorp.com.au> References: <87zj04fxkw.fsf@rustcorp.com.au> Date: Wed, 30 Sep 2015 02:57:52 +0000 Message-ID: From: Gregory Maxwell To: Rusty Russell Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 , Pieter Wuille Subject: Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal. 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: Wed, 30 Sep 2015 02:57:54 -0000 On Wed, Sep 30, 2015 at 2:30 AM, Rusty Russell wrote: > Hi all, > > Pieter and Eric pointed out that the current BIP has miners > turning off the bit as soon as it's locked in (75% testnet / 95% > mainnet). It's better for them to keep setting the bit until activation > (2016 blocks later), so network adoption is visible. > > I'm not proposing another suggestion, though I note it for future: > miners keep setting the bit for another 2016 blocks after activation, > and have a consensus rule that rejects blocks without the bit. That > would "force" upgrades on those last miners. I feel we should see how > this works first. Actually getting rid of the immediate bit forcing was something I considered to be an advantage of versionbits over prior work. Consider, where possible we carve soft fork features out from non-standard behavior. Why do we do this? Primarily so that non-upgraded miners are not mining invalid transactions which immediately cause short lived forks once the soft-fork activates. (Secondarily to protect wallets from unconfirmed TX that won't ever confirm). The version forcing, however, guarantees existence of the same forks that the usage of non-standard prevented! I can, however, argue it the other way (and probably have in the past): The bit is easily checked by thin clients, so thin clients could use it to reject potentially ill-fated blocks from non-upgraded miners post switch (which otherwise they couldn't reject without inspecting the whole thing). This is an improvement over not forcing the bit, and it's why I was previously in favor of the way the versions were enforced. But, experience has played out other ways, and thin clients have not done anything useful with the version numbers. A middle ground might be to require setting the bit for a period of time after rule enforcing begins, but don't enforce the bit, just enforce validity of the block under new rules. Thus a thin client could treat these blocks with increased skepticism.