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 CB92FB6C for ; Tue, 4 Apr 2017 11:16:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out02.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A93E01AA for ; Tue, 4 Apr 2017 11:16:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101]) by mx-out02.mykolab.com (Postfix) with ESMTPS id CA2FD617C2; Tue, 4 Apr 2017 13:16:10 +0200 (CEST) From: Tom Zander To: "bitcoin-dev@lists.linuxfoundation.org" Date: Tue, 04 Apr 2017 13:16:08 +0200 Message-ID: <4095148.TDyWagoPAR@strawberry> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 04 Apr 2017 11:16:53 +0000 Subject: Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 11:16:15 -0000 On Monday, 3 April 2017 11:06:02 CEST Sancho Panza wrote: > =3D=3DSpecification=3D=3D >=20 > To be elaborated. Please do elaborate :) The meat of the proposal is missing. =20 > It is thought that only cosmetic changes are needed to generalize from > only soft forks to 'soft or hard forks', and to add the additional > per-bit parameters 'threshold' and 'windowsize' I agree that the type of forks are rather irrelevant to the voting=20 mechanism. As we remember that BIP109 used a voting bit too. The per-bit (lets call that per-proposal) parameter threshold and windowsiz= e=20 are a different matter though, based on the next paragraph you wrote; > The design of the state machine is envisioned to remain unchanged. The entire point of BIP9 is to allow nodes that do not know about an upgrad= e=20 to still have a functional state machine. But I don=E2=80=99t see how you c= an have a=20 state machine if the two basic variables that drive it are not specified. Now, to be clear, I am a big fan of making the window size and the threshol= d=20 more flexible. But in my opinion we would not be able to have a state machine without thos= e=20 variables in the actual BIP because old nodes would miss the data to=20 transition to certain states. Maybe an idea; we have 30 bits. 2 currently in use (although we could reuse= =20 the CSV one). Maybe we can come up with 3 default sets of properties and=20 when a proposal starts to use bit 11 it behaves differently than if it uses= =20 22. =2D-=20 Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel