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
146
147
148
149
150
151
152
153
154
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C4356DA5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 16:44:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f174.google.com (mail-io0-f174.google.com
[209.85.223.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 297F6EC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 16:44:42 +0000 (UTC)
Received: by mail-io0-f174.google.com with SMTP id e126so276693186ioa.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 08:44:42 -0800 (PST)
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:to
:cc:content-type;
bh=BftQBZ//eLuul3vR+XVOoYuvc0/hmC3mkOh9O9Ig4n8=;
b=Ewpyowdfqjl8IoJu/FGfR59jmowL55XJjOUaOmQ2m6xxU3ckQLPizjVylbu/ao1ItU
Qw73MatZFICII1bEeuQjSzZu2jOluS48cgzDxn+SZ9zuTypiRBRstKVjTfKNBcqsyf5j
NGXuvwxwQPcLYVMXXhwtOlJ+zBdMgbrNq9/5x6djUo7JStxLoPXQNLYSoGSoMq0LRQsq
oGNEW1lSast2rfSuKkqdszSs45z74noA3eZP9u1b1L0PKG1dKboX2+R6mShBdh2h+EEl
TdUbHuqWZUVo3PiNjWW4zLVyTXiIfRr9FI3SoQ8jHOb7ZG15N8vcH8HC2xPDIp7YNXAi
q2Ig==
MIME-Version: 1.0
X-Received: by 10.107.165.197 with SMTP id o188mr45867908ioe.132.1451148281620;
Sat, 26 Dec 2015 08:44:41 -0800 (PST)
Received: by 10.36.80.6 with HTTP; Sat, 26 Dec 2015 08:44:41 -0800 (PST)
Received: by 10.36.80.6 with HTTP; Sat, 26 Dec 2015 08:44:41 -0800 (PST)
In-Reply-To: <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
<CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
<CADm_WcbrMyk-=OnQ-3UvnF_8brhn+X2NqRPbo5xUXsbcZpc0=Q@mail.gmail.com>
<CAPg+sBjbATqf8DXGF7obw9a=371zQ_S0EgTapnUmukAVenTneQ@mail.gmail.com>
<CA+c4Zozac8=aMrAJ1N_6SR9eBD+w0e70cEnk9CG_2oZ72AS-8g@mail.gmail.com>
<CAPg+sBhsKD8jd9Y9+ngXY5tKUheO3d4P1b47eYL=Uzpat+KJ2w@mail.gmail.com>
<751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
Date: Sat, 26 Dec 2015 17:44:41 +0100
Message-ID: <CAPg+sBiT5=ss9e=iac6J-A=85okF0zxMeV7H4z9-Qfx3CAWHXA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: digitsu <jerry.d.chan@bittoku.co.jp>
Content-Type: multipart/alternative; boundary=001a11350734d7aff90527cfc98f
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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] Block size: It's economics & user preparation &
moral hazard
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: Sat, 26 Dec 2015 16:44:42 -0000
--001a11350734d7aff90527cfc98f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
That's exactly the point: a hard fork does not just affect miners, and
cannot just get decided by miners. All full nodes must have accepted the
new rules, or they will be forked off when the hashrate percentage triggers=
.
Furthermore, 75% is pretty terrible as a switchover point, as it guarantees
that old nodes will still see a 25% forked off chain temporarily.
My opinion is that the role of Bitcoin Core maintainers is judging whether
consensus for a hard fork exists, and is technically necessary and safe. We
don't need a hashpower vote to decide whether a hardfork is accepted or
not, we need to be sure that full noded will accept it, and adopt it in
time. A hashpower vote can still be used to be sure that miners _also_
agree.
Currently, a large amount of developers and others believe that the
treshhold for a hardfork is not reached, especially given the fact that we
scale in the short term, as well as make many changes that long-term
benefit scalability, with just a softfork (which does not require forking
off nodes that don't adopt the new rules, for whatever reason).
--=20
Pieter
On Dec 26, 2015 17:25, "digitsu" <jerry.d.chan@bittoku.co.jp> wrote:
> So it seems that everyone is in agreement then, since a hard fork to 2M i=
s
> orthogonal to SW, and also that core should not be involved in dictating
> what the consensus rules should be, then why not put BIP102 into play wit=
h
> a 75% mining majority activation and let the market decide.
>
> As it=E2=80=99s activation only involves the miners, and its implementati=
on
> doesn=E2=80=99t affect users or exchanges, then it poses no complication =
to SW
> which can do done in parallel.
>
>
>
>
--001a11350734d7aff90527cfc98f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">That's exactly the point: a hard fork does not just affe=
ct miners, and cannot just get decided by miners. All full nodes must have =
accepted the new rules, or they will be forked off when the hashrate percen=
tage triggers.</p>
<p dir=3D"ltr">Furthermore, 75% is pretty terrible as a switchover point, a=
s it guarantees that old nodes will still see a 25% forked off chain tempor=
arily.</p>
<p dir=3D"ltr">My opinion is that the role of Bitcoin Core maintainers is j=
udging whether consensus for a hard fork exists, and is technically necessa=
ry and safe. We don't need a hashpower vote to decide whether a hardfor=
k is accepted or not, we need to be sure that full noded will accept it, an=
d adopt it in time. A hashpower vote can still be used to be sure that mine=
rs _also_ agree.</p>
<p dir=3D"ltr">Currently, a large amount of developers and others believe t=
hat the treshhold for a hardfork is not reached, especially given the fact =
that we scale in the short term, as well as make many changes that long-ter=
m benefit scalability, with just a softfork (which does not require forking=
off nodes that don't adopt the new rules, for whatever reason).</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
<div class=3D"gmail_quote">On Dec 26, 2015 17:25, "digitsu" <<=
a href=3D"mailto:jerry.d.chan@bittoku.co.jp">jerry.d.chan@bittoku.co.jp</a>=
> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So it se=
ems that everyone is in agreement then, since a hard fork to 2M is orthogon=
al to SW, and also that core should not be involved in dictating what the c=
onsensus rules should be, then why not put BIP102 into play with a 75% mini=
ng majority activation and let the market decide.<br>
<br>
As it=E2=80=99s activation only involves the miners, and its implementation=
doesn=E2=80=99t affect users or exchanges, then it poses no complication t=
o SW which can do done in parallel.<br>
<br>
<br>
<br>
</blockquote></div>
--001a11350734d7aff90527cfc98f--
|
