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
|
Return-Path: <mruddybtc@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C2C333EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Aug 2015 10:53:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f179.google.com (mail-io0-f179.google.com
[209.85.223.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A0FEFFD
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Aug 2015 10:53:20 +0000 (UTC)
Received: by ioeg141 with SMTP id g141so122072176ioe.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 02 Aug 2015 03:53:20 -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:to
:cc:content-type;
bh=EpBIXq2V6sCM5Pt6S9Bm/+Xpa6lGuX6PIPDdR8DH2N8=;
b=mtzeLQ0ku6CTczbuZ9o3mhmjHh11/joDGljZlUNnaon+MQqlQC1yvL89pyiclxwpDh
tOhYLgMeMZBMFI19WCC8+59Q596wMgfVbapqvkDLG2Bo1f7RBQx4XYCnYw8/UI9AJ66K
rqOYe0iUYyr6oq7a1I7X9mm0DpTuxRsz4HFiXUL3sRGt+rNsoDeUFzDngaJhEcblNlY3
gmqR3OF81REr7MXVzl3I533vm6zp+NdjdRnNTlYR+vQ7IxziMkZxc5J7dkmPfa5bZi6g
fn9hWxkPYfIfoI0xiXijHUM821nzxxxzZqhhVb6unZgtaSl9/xm/gAsBsxJrPmuu1GY3
ceKA==
MIME-Version: 1.0
X-Received: by 10.107.32.146 with SMTP id g140mr15010853iog.23.1438512800191;
Sun, 02 Aug 2015 03:53:20 -0700 (PDT)
Received: by 10.107.24.198 with HTTP; Sun, 2 Aug 2015 03:53:20 -0700 (PDT)
In-Reply-To: <2c9dd1c02fc550438d4bbab29e052f34@xbt.hk>
References: <20150723162321.Horde.bphh__8AhyXa_m-YAYpiyw1@server47.web-hosting.com>
<CAE-z3OWZGsSS2s1OZU5ScH7C4BcOtCb9mcz62TA7HZQe_=y0uA@mail.gmail.com>
<20150723192633.Horde.cGMZGo9Ji0-_9HZhcSUpww5@server47.web-hosting.com>
<CABFP+yNgzNBtsfgHMNSJKpJmgD8jK13KRFP_P9+50ekiBoHfmQ@mail.gmail.com>
<2c9dd1c02fc550438d4bbab29e052f34@xbt.hk>
Date: Sun, 2 Aug 2015 06:53:20 -0400
Message-ID: <CABFP+yOd2ssjuBW3VQPYMCVepeVSMZp3C7w3-fkPW1pmGChAWA@mail.gmail.com>
From: Michael Ruddy <mruddybtc@gmail.com>
To: jl2012@xbt.hk
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP draft: Hardfork bit
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: Sun, 02 Aug 2015 10:53:21 -0000
I think your "hardfork bit" proposal is clever.
It addresses the particular valid concern of re-org facing users of a
fork that a small/near/fluctuating majority, or less, of mining power
supported.
While the "economic majority" argument may be enough on its own in
that case, it still has some aspect of being a hand wave.
This proposal adds support to those economic actors, which makes it
easier for them to switch if/when they choose. That is, it provides a
good fallback mechanism that allows them to make a decision and say,
"we're doing this".
Do you have the latest version up on github, or someplace where it
would be easier to collaborate on the specific text?
On Sat, Aug 1, 2015 at 4:23 PM, <jl2012@xbt.hk> wrote:
> Although the chance is very slim, it is possible to have multiple hardforks
> sharing the same flag block. For example, different proposals may decide the
> flag time based on voting result and 2 proposals may have the same flag time
> just by chance. The coinbase message is to preclude any potential ambiguity.
> It also provides additional info to warning system of non-upgrading nodes.
>
> If we are pretty sure that there won't be other hardfork proposal at the
> same time, the coinbase message may not be necessary. With some prior
> collaboration, this may also be avoided (e.g. no sharing flag block allowed
> as consensus rules of the hardforks)
>
> The "version 0" idea is not compatible with the version bits voting system,
> so I have this hardfork bit BIP after thinking more carefully. Otherwise
> they are technically similar.
|
