Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4AD9E1396 for ; Wed, 16 Sep 2015 20:32:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D63B5176 for ; Wed, 16 Sep 2015 20:32:16 +0000 (UTC) Received: by vkgd64 with SMTP id d64so109472418vkg.0 for ; Wed, 16 Sep 2015 13:32:16 -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=+zl2h/3rb6H7muisH9VCvEZqCj7XcxG9+XxuoA+28l0=; b=OrxkG91QPA7uOkN0JO0fc7MqewrJrqViMMGEOOJTjryly4Dz4Ea01/T3Ri+En8Mp/b RLlqdb5AD0aPan2QVlzqmuwIKS2qoMk/DEb1yll7Vnm2e+cuEva0DiXsi0dggtyOCg/k yZ8nZgZkQDYTpXX/AzP9I0v9gvBlkq+Lb0y3HoL43W9NlNYd+C0zpkO3t14h2VgRtNGW PDSimKe7XzfRJy750UIgcWFlk5VzD4MQ96Onh8VnY/Cf/fUvQUHU9Rq2T/DagJbQemz+ 98qtUP3urfYuD6JPWM/7mJ5VwiSStsuzZRCTvBzleeUvfKzxlKgV3FIerABKEo4p74qM MFNA== MIME-Version: 1.0 X-Received: by 10.31.166.206 with SMTP id p197mr6863716vke.52.1442435536228; Wed, 16 Sep 2015 13:32:16 -0700 (PDT) Received: by 10.103.65.204 with HTTP; Wed, 16 Sep 2015 13:32:16 -0700 (PDT) In-Reply-To: References: <87mvwqb132.fsf@rustcorp.com.au> <87r3lyjewl.fsf@rustcorp.com.au> Date: Wed, 16 Sep 2015 21:32:16 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1141664cbf9659051fe331cc X-Spam-Status: No, score=0.3 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] [BIP Proposal] Version bits with timeout and delay. 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, 16 Sep 2015 20:32:17 -0000 --001a1141664cbf9659051fe331cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 16, 2015 at 9:27 PM, Jorge Tim=C3=B3n wrote: > For enforcing new restrictions on your own blocks (thus at the policy > level, not consensus) you don't need to wait for 75%. You can do it from > the start (this way all miners setting the bit will enforce the new > restrictions. > At 75%, you have a pretty solid super-majority. You can safely reject blocks that have the bit set but are invalid according to the new rule (as long as everyone who sets the bit does it too). --001a1141664cbf9659051fe331cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 16, 2015 at 9:27 PM, Jorge Tim=C3=B3n <= ;jtimon@jtimon.cc= > wrote:

For enf= orcing new restrictions on your own blocks (thus at the policy level, not c= onsensus) you don't need to wait for 75%. You can do it from the start = (this way all miners setting the bit will enforce the new restrictions.

=
At 75%, you have a pretty solid super-majority.=C2=A0
You can safely reject blocks that have the bit set but are invalid acc= ording to the new rule (as long as everyone who sets the bit does it too).<= br>
--001a1141664cbf9659051fe331cc--