summaryrefslogtreecommitdiff
path: root/47/119117936e90ae75f933867f57767f8f66478c
blob: b02785f3214ab8fc5282162b85d6bcd2f4e1db14 (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
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 E9EE81AED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 12:26:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com
	[209.85.213.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7A1FA11D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 12:26:18 +0000 (UTC)
Received: by igxx6 with SMTP id x6so48489402igx.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 05:26:18 -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=7ChXvpHVyiIJkZzeJhRTNCJYNxVJmuezVcrXb8mBc00=;
	b=LHIq1U4YAwY3ORlnociUZNqqjJGYO+EvJyCEuD9HItjW+2ecpKuTQb9sO9RPj8PFhG
	16owEFMHhb2rRXfc3hBABf66ipaX2mTA4nqjwR/7LtD43AoDUWWgsGekm11dVZMLfhIy
	t2zZl8Eo9IEqpIGJbqoeoJBcLPBOwyIBEgCYw=
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=7ChXvpHVyiIJkZzeJhRTNCJYNxVJmuezVcrXb8mBc00=;
	b=U/V+YLfFNpBW+dGfKe53ioDCKXRc0wYjyCmCiZmjwfyGDOmLbNyxxqHWyAUiBACMvR
	vY/JG1r+BhCGCRtUCXdIIf1meoiIyJd+IvEXUwaN7+s5sZG/9MC7ZfcxFbFvgKMxesVd
	IlVeqep7N0h0Y0vrXpfBdsSbOHG4UhWVFJsWuMThyOjgI/uZeTHmSzCIdlDrW8kQcSm6
	2KHNWn4pbk0kQzDBj8dR7xkan3LX+NdNeON37iu5TMuY9nE1hTnWjjKQKYVFgi2ifMrs
	p4Q9PlYxWKcoUXYyHtmG0UaYedmB3L2pmM5Boc7fss+VTzWVlTsT+4fvlO/inHN4+hRq
	gAMA==
X-Gm-Message-State: ALoCoQlCWwJSJUtMmVs9/IWZoxvI58sVO5ahirerp8/MsAUfABrQ4VLJBdCv89+tbobZ2d5CIxxj
MIME-Version: 1.0
X-Received: by 10.50.30.130 with SMTP id s2mr11595645igh.69.1443443177942;
	Mon, 28 Sep 2015 05:26:17 -0700 (PDT)
Received: by 10.50.226.144 with HTTP; Mon, 28 Sep 2015 05:26:17 -0700 (PDT)
In-Reply-To: <4965E9A0-0FF1-4A3F-9165-A21AF976E229@gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
	<CALqxMTFEme9gYHTAVVLtFc4JCK4hoBLXEhMCRdEXK9cWso_pUA@mail.gmail.com>
	<CA+w+GKQ8xos6S_BBMqZy6wieFCG=eNxahKXrx3mVKuZcxzjruw@mail.gmail.com>
	<4965E9A0-0FF1-4A3F-9165-A21AF976E229@gmail.com>
Date: Mon, 28 Sep 2015 14:26:17 +0200
Message-ID: <CA+w+GKSm2Np92+NA77nNMB5LqSyO0=W8dziiMtGO=Jf+7KidHQ@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bdc0d9ce040170520cdcd00
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: Mike Hearn via 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 12:26:19 -0000

--047d7bdc0d9ce040170520cdcd00
Content-Type: text/plain; charset=UTF-8

>
> Go ahead and object to soft forks...but at least try not to make arguments
> based on changing the definitions of terms we all generally agree upon.
>

I don't intend to do that, and I don't think I am - I know what the
difference between a soft and hard fork is and am not trying to confuse or
blur the two.

To reiterate: this current BIP implements a soft fork. I am not debating
that. I am saying it should use a hard fork instead. This will ensure no
repeat of the P2SH case where invalid blocks were being found for weeks (or
was it months?) after the new rules kicked in, thus exposing SPV wallets
and old nodes to unnecessary risk for no benefit.

Additionally, I am making it clear that there's no consensus for rolling
out the new opcode in this way. As you say, the mechanism has issues. If
you read the comments when I wrote my article, you can see that others
share the same concerns:

https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_hearn

--047d7bdc0d9ce040170520cdcd00
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"><div>Go ahead and object to soft forks...but at least try not =
to make arguments based on changing the definitions of terms we all general=
ly agree upon.</div></blockquote><div><br></div><div>I don&#39;t intend to =
do that, and I don&#39;t think I am - I know what the difference between a =
soft and hard fork is and am not trying to confuse or blur the two.</div><d=
iv><br></div><div>To reiterate: this current BIP implements a soft fork. I =
am not debating that. I am saying it should use a hard fork instead. This w=
ill ensure no repeat of the P2SH case where invalid blocks were being found=
 for weeks (or was it months?) after the new rules kicked in, thus exposing=
 SPV wallets and old nodes to unnecessary risk for no benefit.</div><div><b=
r></div><div>Additionally, I am making it clear that there&#39;s no consens=
us for rolling out the new opcode in this way. As you say, the mechanism ha=
s issues. If you read the comments when I wrote my article, you can see tha=
t others share the same concerns:</div><div><br></div><div><a href=3D"https=
://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_=
hearn">https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_fo=
rks_by_mike_hearn</a><br></div><div><br></div><div><br></div></div></div></=
div>

--047d7bdc0d9ce040170520cdcd00--