diff options
| author | Tier Nolan <tier.nolan@gmail.com> | 2015-09-16 21:30:27 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-09-16 20:30:29 +0000 |
| commit | 87d28d6fca13618f87bb9df9872ee4e958cd073e (patch) | |
| tree | f47996d6d777406d4dccbc094ac5deb18a2c67ba | |
| parent | 3cade97b8e1fb76311522759dcc8aff644a07f95 (diff) | |
| download | pi-bitcoindev-87d28d6fca13618f87bb9df9872ee4e958cd073e.tar.gz pi-bitcoindev-87d28d6fca13618f87bb9df9872ee4e958cd073e.zip | |
Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
| -rw-r--r-- | 54/ffae79e023dfb000ab99bf84fb0ca56d9f2ea8 | 141 |
1 files changed, 141 insertions, 0 deletions
diff --git a/54/ffae79e023dfb000ab99bf84fb0ca56d9f2ea8 b/54/ffae79e023dfb000ab99bf84fb0ca56d9f2ea8 new file mode 100644 index 000000000..90a9efb31 --- /dev/null +++ b/54/ffae79e023dfb000ab99bf84fb0ca56d9f2ea8 @@ -0,0 +1,141 @@ +Return-Path: <tier.nolan@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id EBD0911FB + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 16 Sep 2015 20:30:29 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com + [209.85.213.49]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33BA613C + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 16 Sep 2015 20:30:28 +0000 (UTC) +Received: by vkgd64 with SMTP id d64so109441279vkg.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 16 Sep 2015 13:30:27 -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=fEK9g60EiPzAi0cyvtCDA/KmRJ58azAIXuro71PPKoA=; + b=Qv17MI4j9fX4ujPgfILx9hP4y39AiTf4ewem9NKuJSNLOjupMb/DQir0rj9bdMxrdD + JFVYIPNWSWn52GfXwXwvPaT73S5Qg/ugiuAqrr4/OKLI4kO70YoaN8OUc8ctl4VlDGp6 + T1LYv+K6zHeZ6bMwJ9i2PpBdE3GLr6fgkFTFzXSkAVr1WO1ZWM0Pl/Mj4zE2UN8p10/4 + c8b5+ncrABzhfUweF8kWFfCatW5LGJevuvztOM5w2lBu6ADwq3GbshFXh0djj+ev2Qv0 + kdDHNfQa0HxzIxXZ/K/HUlxTK8kd63menUGfnQUcMSKyK8GxW+y6VuKNR2BbpPbm9GU1 + WdFw== +MIME-Version: 1.0 +X-Received: by 10.31.5.205 with SMTP id 196mr30497269vkf.88.1442435427590; + Wed, 16 Sep 2015 13:30:27 -0700 (PDT) +Received: by 10.103.65.204 with HTTP; Wed, 16 Sep 2015 13:30:27 -0700 (PDT) +In-Reply-To: <87r3lyjewl.fsf@rustcorp.com.au> +References: <87mvwqb132.fsf@rustcorp.com.au> + <CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com> + <87r3lyjewl.fsf@rustcorp.com.au> +Date: Wed, 16 Sep 2015 21:30:27 +0100 +Message-ID: <CAE-z3OW6BKHfx=wS9AYqb4+Ems6xM+SDqBKgGbNkXfPwuPqn8A@mail.gmail.com> +From: Tier Nolan <tier.nolan@gmail.com> +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=001a1143dda045ec3e051fe32b02 +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 16 Sep 2015 20:30:30 -0000 + +--001a1143dda045ec3e051fe32b02 +Content-Type: text/plain; charset=UTF-8 + +On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell <rusty@rustcorp.com.au> +wrote: + +> I couldn't see a use for it, since partial enforcement of a soft fork is +> pretty useless. +> + +It isn't useful for actually using the feature, but some miners might set +the bit but not actually create blocks that comply with the new rule. + +This would cause their blocks to be orphaned until they fixed it. + +OK, *that* variant makes perfect sense, and is no more complex, AFAICT. +> +> So, there's two weeks to detect bad implementations, then you everyone +> stops setting the bit, for later reuse by another BIP. +> + +It could be more than two weeks if the support stays between 80% and 90% +for a while. + +75%+ checks that blocks with the bit set follow the rule. + +95%+ enters lock-in and has the same rules as 75%+, but is irreversible at +that point. + + +> You need a timeout: an ancient (non-mining, thus undetectable) node +> should never fork itself off the network because someone reused a failed +> BIP bit. +> + +I meant if the 2nd bit was part of the BIP. One of the 2 bits is "FOR" and +the other is "AGAINST". If against hits 25%, then it is deemed a failure. + +The 2nd bit wouldn't be used normally. This means that proposals can be +killed quickly if they are obviously going to fail. + +--001a1143dda045ec3e051fe32b02 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= +te">On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell <span dir=3D"ltr"><<a= + href=3D"mailto:rusty@rustcorp.com.au" target=3D"_blank">rusty@rustcorp.com= +.au</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar= +gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I couldn't = +see a use for it, since partial enforcement of a soft fork is<br> +pretty useless.<span class=3D""><br></span></blockquote><div>=C2=A0<br></di= +v><div>It isn't useful for actually using the feature, but some miners = +might set the bit but not actually create blocks that comply with the new r= +ule.<br><br></div><div>This would cause their blocks to be orphaned until t= +hey fixed it.<br></div><div><br></div><blockquote class=3D"gmail_quote" sty= +le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span = +class=3D""> +</span>OK, *that* variant makes perfect sense, and is no more complex, AFAI= +CT.<br> +<br> +So, there's two weeks to detect bad implementations, then you everyone<= +br> +stops setting the bit, for later reuse by another BIP.<br></blockquote><div= +><br></div><div>It could be more than two weeks if the support stays betwee= +n 80% and 90% for a while.<br><br></div><div>75%+ checks that blocks with t= +he bit set follow the rule.<br><br></div><div>95%+ enters lock-in and has t= +he same rules as 75%+, but is irreversible at that point.<br></div><div>=C2= +=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= +order-left:1px #ccc solid;padding-left:1ex"><span class=3D""> +</span>You need a timeout: an ancient (non-mining, thus undetectable) node<= +br> +should never fork itself off the network because someone reused a failed<br= +> +BIP bit.<br></blockquote><div><br></div><div>I meant if the 2nd bit was par= +t of the BIP.=C2=A0 One of the 2 bits is "FOR" and the other is &= +quot;AGAINST".=C2=A0 If against hits 25%, then it is deemed a failure.= +<br><br></div><div>The 2nd bit wouldn't be used normally.=C2=A0 This me= +ans that proposals can be killed quickly if they are obviously going to fai= +l.<br></div></div></div></div> + +--001a1143dda045ec3e051fe32b02-- + |