summaryrefslogtreecommitdiff
path: root/b2/fb1b12e44898682665edf3889a248de893e9b0
blob: 504a0d82a1b41f49d070baebcd72efbcf6401dfd (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
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 288811846
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 12:47:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com
	[209.85.160.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B7E711C8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 12:47:26 +0000 (UTC)
Received: by ykdz138 with SMTP id z138so177012850ykd.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Sep 2015 05:47:26 -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:cc
	:content-type; bh=/NG7Bcc2SP6JJM9uS88fiBwkTs9+91wJlSpxY26ORhY=;
	b=TauPfVyvOgBORlZAMxAfhLE71gICvoZ8fimpQhsaI2AVGhU0d/JNeFpCfo1bXdTCSy
	+GX9ZF+rl7pBuIcblmTFAzbyNk1x9ggXsd5n669wmA1BTOno/w96Y4jOrCkKeo6oYmgg
	RSEb5l4g34bJfJfsKjgK92mLXf10CxWef66NYhtiTiJnEH8wf3yO/TqjmrkLI2b/k4vF
	StVa7Uwyp528aZmne8RSRz/OsMpiSVpaEmg3ranA3Ik72X+dMj/zAZcc4QEY+UuvkbiA
	vySIgUcp6PcQjY2mGLPCdRMPzHLAOCPOzqK1n0OMY+7A6BW6iKDC+aJUGduMswZp9nRJ
	b8RA==
MIME-Version: 1.0
X-Received: by 10.31.0.215 with SMTP id 206mr12247891vka.105.1443444445879;
	Mon, 28 Sep 2015 05:47:25 -0700 (PDT)
Received: by 10.103.65.204 with HTTP; Mon, 28 Sep 2015 05:47:25 -0700 (PDT)
In-Reply-To: <CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
Date: Mon, 28 Sep 2015 13:47:25 +0100
Message-ID: <CAE-z3OVAVdOPAypOA0gndcRGbd74TChtsLW6u77Muxk6DJK16g@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113da7c87326910520ce19e0
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	MALFORMED_FREEMAIL, 
	MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.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:47:27 -0000

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

On Mon, Sep 28, 2015 at 11:48 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 1) Drop the "everyone must agree to make changes" idea that people here
> like to peddle, and do it loudly, so everyone in the community is correctly
> informed
>

There never was a rule that soft-forks require total consensus.  It is
desirable but not mandatory.

A majority of miners can inherently implement a soft fork against the
wishes of the rest of the users.

Merchant/exchange/user checkpointing is the defense and therefore is a
perfectly valid response to miners taking such an action.  If a soft fork
is opposed by a large section of the users, then threatening (and
implementing) a checkpoint is the correct response.

No group can force through a hard fork, it inherently requires buy-in from
a large portion of the userbase.  That is where the "total consensus"
requirement comes from.  Naturally, absolute total consensus isn't actually
required but you do need very large consensus and also consensus across the
various sub-groups.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Sep 28, 2015 at 11:48 AM, Mike Hearn via bitcoin-dev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
>1) Drop the &quot;everyone must agree to make changes&quot; idea that peop=
le here like to peddle, and do it loudly, so everyone in the community is c=
orrectly informed</div></div></blockquote><div><br></div><div>There never w=
as a rule that soft-forks require total consensus.=C2=A0 It is desirable bu=
t not mandatory.=C2=A0 <br><br></div><div>A majority of miners can inherent=
ly implement a soft fork against the wishes of the rest of the users.<br><b=
r></div><div>Merchant/exchange/user checkpointing is the defense and theref=
ore is a perfectly valid response to miners taking such an action.=C2=A0 If=
 a soft fork is opposed by a large section of the users, then threatening (=
and implementing) a checkpoint is the correct response.<br><br></div><div>N=
o group can force through a hard fork, it inherently requires buy-in from a=
 large portion of the userbase.=C2=A0 That is where the &quot;total consens=
us&quot; requirement comes from.=C2=A0 Naturally, absolute total consensus =
isn&#39;t actually required but you do need very large consensus and also c=
onsensus across the various sub-groups. <br></div></div></div></div>

--001a113da7c87326910520ce19e0--