summaryrefslogtreecommitdiff
path: root/45/73334b5e99b1f570bce39fa73578272d483327
blob: 340d0e63c538865ee7db8894300d761138286a40 (plain)
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
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 B986D183B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 17:14:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f176.google.com (mail-io0-f176.google.com
	[209.85.223.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 95A682CD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 17:14:16 +0000 (UTC)
Received: by iofb144 with SMTP id b144so183376177iof.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 10:14:16 -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=T1GedvRr1tX3d1HrZe08FuiciTYlt0IafWOSnh/PrZo=;
	b=VPOxAbAw+t6ERj212gdoHj9yAiLcbrEEGN/8qa4cBYJCsnKJNimXfTefMDlqimeFb5
	B/ksMAgS2+4/1na1SZh762lq53ah1shs0M7iypNb3B21J3jpycpG0NbvqXhSkV0IbUQn
	ws9DUWzs47qikuNZ1WW2WFAAHjOHUsZ7Z3hlc=
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=T1GedvRr1tX3d1HrZe08FuiciTYlt0IafWOSnh/PrZo=;
	b=HChiza4se1G3qYDLxfY14PNRRZiy7x68a0uA5FkQ4AW4hJJ2TOqBhfWpvUGPPXBxKI
	BNnNv5mG9yM+i7ZnjmrhaIeSP8TJ36XgKAUNKbYnlsz+02GSAIjzySME1wnt//XOnlXB
	wN4GpY+MV7ZVG761pwhNnurtp+YzbhRO+h95EjgTN6l5Wsi2nSXYwMEWIu4pNynMycSD
	bnWN+Yvdn0yGpGUyffLu2L/8RZpyvJ1Q9f4PaFrWQCzVfW/uFEdBGWV76B3atnNjT2N2
	rpl2F1GhXg52LJEdjyuBpHWJgOf6ZAsQZchfkM7U0cZ1ChWfBY7wFUpr6fDEU5E7krhR
	LCsw==
X-Gm-Message-State: ALoCoQmpOoql+7gNpsSKDW+5J2Cly/iX8o9ewrDxO4anCIs0kZhGX2qNe5aoS5/Yevkxs862FHRV
MIME-Version: 1.0
X-Received: by 10.107.137.144 with SMTP id t16mr20860560ioi.102.1443460455869; 
	Mon, 28 Sep 2015 10:14:15 -0700 (PDT)
Received: by 10.50.226.144 with HTTP; Mon, 28 Sep 2015 10:14:15 -0700 (PDT)
In-Reply-To: <8461c6195ca65ce7355f693fa24bb177@xbt.hk>
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>
Date: Mon, 28 Sep 2015 19:14:15 +0200
Message-ID: <CA+w+GKRcUYsKzG8n5ut-ObD1MM9bs0OD-jdHe1+cLkcO6B7wKg@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=001a113fb1e4b84bd20520d1d37e
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: Mon, 28 Sep 2015 17:14:17 -0000

--001a113fb1e4b84bd20520d1d37e
Content-Type: text/plain; charset=UTF-8

>
> Let me try to answer this question. Softfork is beneficial to non-mining
> full nodes as they will follow the majority chain.


That is not a benefit. That is a description of what the software will do,
but not why you would want it.

In case this seems like a pedantic point, consider the consequences of
following a chain you aren't checking properly. You get SPV level security
and might calculate a corrupted ledger.

In the case of P2SH, I could make a transaction that spends someone elses
money to myself. In the case of CLTV, I could ignore the locktime
requirement.

Now yes, eventually, the miner majority will correct and uncorrupt your
ledger for you. But by then it might be too late, you may have already
acted upon the incorrect data by e.g. selling me lots of stuff that I paid
for with somebody else's coins. If you don't care about that risk, hey,
switch to an SPV wallet and save yourself a lot of disk space.


> In a hardfork, however, there is no mechanism to stop the old fork and we
> may have 2 chains co-exist for a long time.
>

There isn't any difference in how long the divergent state exists for. That
depends only on how fast people upgrade, which is unaffected by the rollout
strategy used.

--001a113fb1e4b84bd20520d1d37e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">Let me try to answer this question. Softfork is beneficial to =
non-mining full nodes as they will follow the majority chain. </blockquote>=
<div><br></div><div>That is not a benefit. That is a description of what th=
e software will do, but not why you would want it.</div><div><br></div><div=
>In case this seems like a pedantic point, consider the consequences of fol=
lowing a chain you aren&#39;t checking properly. You get SPV level security=
 and might calculate a corrupted ledger.=C2=A0</div><div><br></div><div>In =
the case of P2SH, I could make a transaction that spends someone elses mone=
y to myself. In the case of CLTV, I could ignore the locktime requirement.<=
/div><div><br></div><div>Now yes, eventually, the miner majority will corre=
ct and uncorrupt your ledger for you. But by then it might be too late, you=
 may have already acted upon the incorrect data by e.g. selling me lots of =
stuff that I paid for with somebody else&#39;s coins. If you don&#39;t care=
 about that risk, hey, switch to an SPV wallet and save yourself a lot of d=
isk space.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex">In a hardfork, however, t=
here is no mechanism to stop the old fork and we may have 2 chains co-exist=
 for a long time.<br></blockquote><div><br></div><div>There isn&#39;t any d=
ifference in how long the divergent state exists for. That depends only on =
how fast people upgrade, which is unaffected by the rollout strategy used.<=
/div></div></div></div>

--001a113fb1e4b84bd20520d1d37e--