References: <0a38c993-9269-efb5-7790-e49cd4f7987f@electrum.org>
	<4TcKFXkLsQaPwHnC7YdEyVnmeMWN9KFx1HriXCYsScr4t4QotNpiUr61XFVzEKicFfQzc3iF_N4wo6qKbi6xanv_GZTFTCQ0DQnYHh_WukY=@protonmail.com>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
From: Thomas Voegtlin <thomasv@electrum.org>
Message-ID: <319af712-7d95-d496-55d9-d3ce16e1d075@electrum.org>
Date: Thu, 13 Apr 2017 16:55:29 +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: <4TcKFXkLsQaPwHnC7YdEyVnmeMWN9KFx1HriXCYsScr4t4QotNpiUr61XFVzEKicFfQzc3iF_N4wo6qKbi6xanv_GZTFTCQ0DQnYHh_WukY=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] Proposal: Soft Fork Threshold Signaling
Precedence: list

Hi Sancho,

I saw your proposal. However, my point is that the threshold should be
part of the signaling, and not fixed in the soft-fork proposal.

I agree that coinbase space might be a limitation.

To avoid this, I realize that the threshold could be encoded in the
version bits. We have 32 version bits, and the top 3 bits must be set to
001 in BIP9. In order to extend BIP9 in a backward compatible way, we
could set these 3 top bits to 010, and use the 29 remaining bits for
soft fork signaling.

If we use 7 bits per soft-fork proposal, we have enough space to encode
four simultaneous soft-fork proposals, and sub-percent granularity for
the threshold (2^7=128).


Le 13/04/2017 à 16:17, Sancho Panza a écrit :
> Thomas,
> 
> I wonder if you've seen my proposal on how to make BIP9 more configurable:
> https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki
> 
> This could be extended with a coinbase signaling feature as you suggest.
> This could include parameter information for forks which a miner is signaling, for coordination.
> 
> Currently I've not included something like this, but it might make a nice addition.
> One problem is the limited space in coinbase for embedding data on the large number of possible independent deployments.
> 
> Regards,
> Sancho
>