Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 294461392 for ; Wed, 16 Sep 2015 20:38:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 98C93176 for ; Wed, 16 Sep 2015 20:38:21 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so90003726wic.1 for ; Wed, 16 Sep 2015 13:38:20 -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=ymBQCkpK1e9ibQC1DuwPEk7x7vtjp8O4yXpqAYuOrek=; b=FcnVnnYAnrTDAj5/H08MAlvzqN9Y/ekmd4gB+801LT1U86l7F1UZJ1lNJjfu8Zy4q1 1TSO3/GcwVT2W1kU4Wr5pr6xhASCOW6yQJj5UN+svIxkvnj6PLLwc9Oor0rpDs+/g60D sbfLCaz0iYBw5RHndZxkfdJ4HjeB9kaJ/wHB9maiGyU4//WBKml/lf8KQuxnqKL5H5Jt wiZrJPIHUkb6mCwXoHHEuPPo8XnI3Scmg8yueYo59sdWGTPNPkzBpH7iupC4MZL6D52q P0N0vAETxTgNq2OZNIQQPpqnleEHgUDlZTbbZ8cCmRq7sHzEmjGi9yfQg2Ch9ye+1+57 5pgg== X-Gm-Message-State: ALoCoQk9XNDzDmxSdvbFoVxOTJZ+JwGxbkmSuLttCdGHNiBSz+l3bS2bUkwSzsZ0Xsn9a+v03/lo MIME-Version: 1.0 X-Received: by 10.194.238.39 with SMTP id vh7mr54092509wjc.109.1442435900251; Wed, 16 Sep 2015 13:38:20 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Wed, 16 Sep 2015 13:38:20 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Wed, 16 Sep 2015 13:38:20 -0700 (PDT) In-Reply-To: References: <87mvwqb132.fsf@rustcorp.com.au> <87r3lyjewl.fsf@rustcorp.com.au> Date: Wed, 16 Sep 2015 22:38:20 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Tier Nolan Content-Type: multipart/alternative; boundary=089e0141aa1a7239ea051fe3474e X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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] [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:38:22 -0000 --089e0141aa1a7239ea051fe3474e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, 95% is safer and will produce less orphaned blocks. 0%is fine to do it in your own blocks. I agree on using height vs time. Rusty, what do you mean by being easier for bip writers? How is writing "block x" any harder than writing "date y". On Sep 16, 2015 4:32 PM, "Tier Nolan via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Wed, Sep 16, 2015 at 9:27 PM, Jorge Tim=C3=B3n wrot= e: > >> 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). > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --089e0141aa1a7239ea051fe3474e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

No, 95% is safer and will produce less orphaned blocks.
0%is fine to do it in your own blocks.

I agree on using height vs time. Rusty, what do you mean by = being easier for bip writers? How is writing "block x" any harder= than writing "date y".

On Sep 16, 2015 4:32 PM, "Tier Nolan via bi= tcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:


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

For enforcing new restrictions on your own blo= cks (thus at the policy level, not consensus) you don't need to wait fo= r 75%. You can do it from the start (this way all miners setting the bit wi= ll enforce the new restrictions.

At 75%, you have a pr= etty solid super-majority.=C2=A0

You can safely reject blocks that = have the bit set but are invalid according to the new rule (as long as ever= yone who sets the bit does it too).

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e0141aa1a7239ea051fe3474e--