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 0AC48BC5 for ; Thu, 13 Apr 2017 17:30:10 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DBACA10C for ; Thu, 13 Apr 2017 17:30:08 +0000 (UTC) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by relay8-d.mail.gandi.net (Postfix) with ESMTPS id B31DE406DB for ; Thu, 13 Apr 2017 19:30:07 +0200 (CEST) Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 9D53041C091 for ; Thu, 13 Apr 2017 19:30:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter36-d.gandi.net (mfilter36-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ijLq51D4Z9Su for ; Thu, 13 Apr 2017 19:30:06 +0200 (CEST) X-Originating-IP: 134.60.149.33 Received: from [134.60.149.33] (wlan149-033.wlan.uni-ulm.de [134.60.149.33]) (Authenticated sender: thomasv@electrum.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 4633541C08F for ; Thu, 13 Apr 2017 19:30:06 +0200 (CEST) References: <0a38c993-9269-efb5-7790-e49cd4f7987f@electrum.org> <4TcKFXkLsQaPwHnC7YdEyVnmeMWN9KFx1HriXCYsScr4t4QotNpiUr61XFVzEKicFfQzc3iF_N4wo6qKbi6xanv_GZTFTCQ0DQnYHh_WukY=@protonmail.com> <319af712-7d95-d496-55d9-d3ce16e1d075@electrum.org> <7uA8OvV5lg5Ug8_x4i6kdl9mUk7uNNa04cOc74tWIDBLA7zNNLZ3FOdML0bMoOBUMggpvXyWESZOuX-Sa21J-uZyWnujBLAEtKpsLwTwTSM=@protonmail.com> From: Thomas Voegtlin To: "bitcoin-dev@lists.linuxfoundation.org" Message-ID: <1a135cbb-9e24-1448-e102-98a3cd3fdcd0@electrum.org> Date: Thu, 13 Apr 2017 19:30:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7uA8OvV5lg5Ug8_x4i6kdl9mUk7uNNa04cOc74tWIDBLA7zNNLZ3FOdML0bMoOBUMggpvXyWESZOuX-Sa21J-uZyWnujBLAEtKpsLwTwTSM=@protonmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Subject: Re: [bitcoin-dev] Proposal: Soft Fork Threshold Signaling 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: Thu, 13 Apr 2017 17:30:10 -0000 I think it is better not to use the coinbase, because it might collide with other proposals, and because coinbase is not part of the block header. I agree that a small set of standard threshold may be sufficient; a one percent resolution is probably not needed. If we use 4 bits we can encode 15 different thresholds + zero (meaning no support). For example we can have all thresholds between 25% and 95% separated by 5%. Using 4 bits per soft-fork proposal leaves enough room to fit 7 simultaneous proposals in version bits. That should be plenty. > > I still like the coinbase idea though - more than using up the BIP9 versionbits range for verbose signaling. > > BIP9 (and other proposals which use those 29 versionbits) currently assume that the participants on the network will coordinate in some form or other, to agree on what the bits mean (in terms of change deployments). > > It would be very easy to also agree on a set of "standard" threshold levels and map those onto e.g. 1 byte. > > Then, in the coinbase, one could have pairs of bit numbers and bytes, e.g. "/1A/2B/3C/" where the bytes values corresponding to 'A', 'B', 'C', ... are standardized deployment schedules that people find useful. > So a BIP9 conformant schedule could be A = 95% / 2016 window, > while B = 75%/2016, etc. > > This would be quite a compact yet still readable signaling. The space of values is large enough that I doubt we'd see much contention. > > Regards > Sancho >