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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 85F9E1DB7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2015 12:07:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com
[209.85.213.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9B42138
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2015 12:07:24 +0000 (UTC)
Received: by igbkq10 with SMTP id kq10so74974673igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2015 05:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=vinumeris.com; s=google;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=kGeyenhX23BguyxUgYiOoaajHaWAyg9HnVF0iBXpw2M=;
b=XFqr5BYSzizCh8bkR6o7vjxccOTpuh3zrsRJg3xYxedw8KjsOtDBVSmr6YqAlgaJ6P
W6sSr5TSW7Cj4Pv93kCwXvjX6mpCNRdB/3k0mXgqsPKKT6zFli99ZKunId8DDpIX7rvH
VSCQEWceDmHPTuuV/Ui96g09ROdKjDhoX4dPI=
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=kGeyenhX23BguyxUgYiOoaajHaWAyg9HnVF0iBXpw2M=;
b=BabOs4+IGd+EDcSFXf86Y+sDaE1cBANTGaUrOtNMkwHcGV9sptD7LOHe8ASABZRxVW
eRMUC5fqJ5cY665rxQUleljT5I1SYxxEHh9k3uy2B1ZjS8kEM6cmBwDjOlAyBHCG7+p9
riXoa1x9oPzldKZQox7kLVrubEDXCIulKfm/60vxMimQAS1PSF6WEfc8M9GinyWQH55b
QIkvrVyqqJgN5ROuTIu0cgdeNtjiGfU6sWXMXlFUkP9znzuzq0ZBzXZL3jgcjPk/ncrI
y/cf32bVLh+rQ9lDynrZyP5icVy276MtmYN0FrAnVu0AN+6XfoGXr+UKVizu/BFUKSDJ
soKA==
X-Gm-Message-State: ALoCoQnlViGCBImgUhj9KCWYL2C2eZSCB/pxoaMVWuePFYBtLyDlCdOD+TjkIbfGWP/JWHjNaaMh
MIME-Version: 1.0
X-Received: by 10.50.17.4 with SMTP id k4mr22795549igd.34.1443528444182; Tue,
29 Sep 2015 05:07:24 -0700 (PDT)
Received: by 10.50.226.144 with HTTP; Tue, 29 Sep 2015 05:07:24 -0700 (PDT)
In-Reply-To: <CABm2gDrcrtZLQE8Q9ZuxsWEfD_mFhdBz36x3RCPrQtbBi1455A@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<20150928132127.GA4829@savin.petertodd.org>
<CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com>
<20150928142953.GC21815@savin.petertodd.org>
<CA+w+GKTUz2eVJOpixSebWiQ59ovoELNhsZWSsbLHXWqk2eCn0A@mail.gmail.com>
<20150928144318.GA28939@savin.petertodd.org>
<CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com>
<20150928150543.GB28939@savin.petertodd.org>
<CA+w+GKTPKxGWWN28_hzR8BoCh11exvgZm4s-_=5oFWd-R62uyA@mail.gmail.com>
<8461c6195ca65ce7355f693fa24bb177@xbt.hk>
<CA+w+GKRcUYsKzG8n5ut-ObD1MM9bs0OD-jdHe1+cLkcO6B7wKg@mail.gmail.com>
<CABm2gDrcrtZLQE8Q9ZuxsWEfD_mFhdBz36x3RCPrQtbBi1455A@mail.gmail.com>
Date: Tue, 29 Sep 2015 14:07:24 +0200
Message-ID: <CA+w+GKSTC_4Ugpvcb88QxusyBixmzXaTckq0Fx5v3NpgBzjMwg@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=089e011767bf23e9a90520e1a8d3
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,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: Tue, 29 Sep 2015 12:07:25 -0000
--089e011767bf23e9a90520e1a8d3
Content-Type: text/plain; charset=UTF-8
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?
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?
--089e011767bf23e9a90520e1a8d3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Jorge,<br><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Yes, there is a =
difference. Assuming the hashrate majority upgrades, in the case of a softf=
ork [snip] ...... In the case of a hardfork [snip]<br></p></blockquote><div=
>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 up=
grade. The amount of money they lose in both cases is identical: they are e=
qually incentivised to upgrade with both fork types.</div><div><br></div><d=
iv>Additionally, you say in a hard fork the other chain may "continue =
forever". Why do you think this is not true for miners building invali=
d blocks on top of the main chain? Why would that not continue forever?</di=
v><div><br></div><div>There just isn't any difference between the two f=
ork types in terms of how fast miners would upgrade. Heck if anything, a ha=
rd 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 wou=
ld 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 differe=
nt height to everyone else, which is easily detectable by just checking a b=
lock explorer.</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">This disc=
ussion about the general desirability of softforks seems offtopic for the c=
oncrete cltv deployment discussion, which assumes softforks as deployment m=
echanism (just like bip66 assumed it).<br></p>
</blockquote></div>Isn't that circular? This thread is about deployment=
of CLTV, but the BIP assumes a particular mechanism, so pointing out probl=
ems with it is off topic? Why have a thread at all?</div></div>
--089e011767bf23e9a90520e1a8d3--
|
