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
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6C23B1AB8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 15:55:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com
[209.85.212.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA826254
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 15:55:53 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so68720423wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 08:55:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=Vft51jEEZ9T+beicKEmSODX5UVlGWvSLaQkHueRIIIU=;
b=Gd2jwxNqgDbCK8t6ANlFSizjhUNINZKS19iPZE5kXjEontpeai7ez0sMwzCnZkAh0Z
XdiBghtKDCuB6bLvzCrkMgbPpaPsC8OexlMt0G1JJEf3YyhZkSiZzmplsbooUNJ2DZY2
0c+leB/LNTVTlQ0owDPqJ2qG3vA63L756Odl84yTFUG8YbBnk4TPV+y2jgkTgH9NwMa0
N/EMKWPG+ufn0JqISapD/Xo8lP6D8LW4C/BuGJ3nGgV80lDZXL6/ovIOMSHwPIWs5oS0
JGCdXjGldnE/97vrxzB9rUeMYkQDxPV40Io10AQfd25v/sdFpMxzj+uJ520oiMLwcEdV
oDew==
X-Gm-Message-State: ALoCoQkL9ULiO7mb88hr/qlxjU3ucFHz6xfKM92zI6L5Ln4QHRXUwHMMCSDPb3VbeZkhJDhdbcod
MIME-Version: 1.0
X-Received: by 10.180.8.106 with SMTP id q10mr5297659wia.92.1443628552474;
Wed, 30 Sep 2015 08:55:52 -0700 (PDT)
Received: by 10.194.114.199 with HTTP; Wed, 30 Sep 2015 08:55:52 -0700 (PDT)
In-Reply-To: <CA+w+GKRd69kOiDKE_56vnbZ=Hx4hhXqtzpsVT6Z+fx005zW_MQ@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<20150929200302.GA5051@amethyst.visucore.com>
<87wpv8ft61.fsf@rustcorp.com.au>
<CALqxMTGOmU76NHP8o7TyLq2t3EJTTyMoz4zCZQFczJX5+O=bOQ@mail.gmail.com>
<CA+w+GKRd69kOiDKE_56vnbZ=Hx4hhXqtzpsVT6Z+fx005zW_MQ@mail.gmail.com>
Date: Wed, 30 Sep 2015 17:55:52 +0200
Message-ID: <CABm2gDqkTizK1TtGGM4fFp4xWMUhAstVOvnJ4_3VKaGNoSX0eg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: text/plain; charset=UTF-8
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
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: Wed, 30 Sep 2015 15:55:54 -0000
On Tue, Sep 29, 2015 at 2:07 PM, Mike Hearn <hearn@vinumeris.com> wrote:
> Hi Jorge,
>
>> Yes, there is a difference. Assuming the hashrate majority upgrades, in
>> the case of a softfork [snip] ...... In the case of a hardfork [snip]
>
> Yes, I know what the difference between them is at a technical level. You
> didn't explain why this would make any difference to how fast miners
> upgrade. The amount of money they lose in both cases is identical: they are
> equally incentivised to upgrade with both fork types.
>
> Additionally, you say in a hard fork the other chain may "continue forever".
> Why do you think this is not true for miners building invalid blocks on top
> of the main chain? Why would that not continue forever?
I didn't talked about how fast miners would upgrade, please read again
because I believe I was extremely precise.
In both cases I'm assuming there's a minority of the hasrate which
doesn't upgrade.
In the softfork case, the minority will always build on top of the
longest chain (which is valid to them). There may be many little
alternative chains that are ignored (and orphaned) by the upgraded
miners, but non-upgraded miners will always build on top of the
longest chain.
In the hardfork case, non-upgraded miners will reject the upgraded
chain because it is invalid to them, so they will build on top of the
longest non-upgraded chains.
Two alternative chains will continue growing forever unless the
non-upgraded miners eventually upgrade.
In contrast, there won't be 2 alternative chains growing forever in
the softfork case even if the minority miners never upgrade.
> There just isn't any difference between the two fork types in terms of how
> fast miners would upgrade. Heck if anything, a hard fork should promote
> faster upgrades, because if a miner isn't paying attention to their
> debug.log they might miss the warnings. A soft fork would then look
> identical to a run of really bad luck, which can legitimately happen from
> time to time. A hard fork results in your node having a different height to
> everyone else, which is easily detectable by just checking a block explorer.
>>
>> This discussion about the general desirability of softforks seems offtopic
>> for the concrete cltv deployment discussion, which assumes softforks as
>> deployment mechanism (just like bip66 assumed it).
>
> Isn't that circular? This thread is about deployment of CLTV, but the BIP
> assumes a particular mechanism, so pointing out problems with it is off
> topic? Why have a thread at all?
BIP99 recommends an uncontroversial softfork for this kind of case.
You seem to be contradicting BIP99 in many other places. Maybe you
want to complain about some of the recommendations in BIP99 (instead
of everywhere else):
https://github.com/bitcoin/bips/pull/181
On Wed, Sep 30, 2015 at 2:30 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> This will not change the fact that the rollout strategy is bad and nobody
> has answered my extremely basic question: why is it being done in this way,
> given the numerous downsides?
You seem to be the only one who thinks that softforks have "numerous
downsides" over hardforks.
So everybody just basically disagrees with the assumption in your
question and thus nobody can answer it.
|
