1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
Return-Path: <thomasv@electrum.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E904B8D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 14:55:32 +0000 (UTC)
X-Greylist: delayed 03:18:54 by SQLgrey-1.7.6
Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net
[217.70.183.200])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 62711AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 14:55:32 +0000 (UTC)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net
[217.70.183.195])
by relay7-d.mail.gandi.net (Postfix) with ESMTPS id ADD73D37
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 16:55:30 +0200 (CEST)
Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162])
by relay3-d.mail.gandi.net (Postfix) with ESMTP id 086D4A80F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 16:55:30 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195])
by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180])
(amavisd-new, port 10024) with ESMTP id 00HxL2ovq9qM
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 16:55:27 +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 relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B502EA80D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 16:55:27 +0200 (CEST)
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
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM 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 <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: Thu, 13 Apr 2017 14:55:33 -0000
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
>
|
