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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3C97A10A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Feb 2016 17:09:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com
[209.85.213.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ADB0013E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Feb 2016 17:09:22 +0000 (UTC)
Received: by mail-vk0-f46.google.com with SMTP id k196so7331848vka.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 06 Feb 2016 09:09:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=JiaQ5FIs3J2oI8E0pSMfnmp//v4ujE4AZF6P7Jz3JCM=;
b=XIWml1shD7Ie5g02qQ1QG3BMNcWXOd+zvM/h8ZdFrrvJb6HNP/hDFwMwLzWFzd2TTm
apVIa0StFabAO179v8dUK9FA0gEzVz/0/Akw7yivDtoNtgYaUtUh0Q8F3Zj9GgA39sUe
GjGaBUZCjaOx27ENrrweFSjUR/itIsafH89QcFAFLzKVj6y7jxCKCm4M3Y+S1JbBz/S8
tX6FNw0U2nE93CXweEOKrnaFxyHcSOxnhDIZ8bYFEatORuZ7/HxCfA0RGAnEtehcJYLh
s0SV7TG4lClPmg6RQaBWoy7aPYx2mEeC2Ccy88op0SMHPz32wgmprreexUEX9xDERzTW
fWAg==
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=JiaQ5FIs3J2oI8E0pSMfnmp//v4ujE4AZF6P7Jz3JCM=;
b=IdxX47OtSyEZ62sDGRaSJoYb/GhUG03FtEskhxRc430Z044tfQmjOgeGyr5YI0wMVd
4VieCyKm3whwAtzwmu4pLlHWsaA1eY+keMZHhIVXZBUEZQV7Esk3kwuPL9X92+z0Uhm3
voa4dqRzNNQFalEdxP06pH5zThKlZbewfMe/2SVDfz1UxBSsX2wACdc7blGJbKmeWY8t
rNxbd00fr1Wx7X06r5LT84i20xq0a9HrdxsPq+7GJw1czzvnF5fsCL/3q5RJmT/Y6KtH
30EME1AjyQjkk7yopGCu1r0tpZASySHk8WKsRA8dYv0yYwRUgx/1ajqJg2Pxf++yKOKh
bi9g==
X-Gm-Message-State: AG10YOSJIaw/oMC34cHkPek31RATqiECtS/yWv24yGF7pTztVvg2ZKMonqtItp78/XFWEFUtgzVIsRs03g8cwA==
MIME-Version: 1.0
X-Received: by 10.31.16.153 with SMTP id 25mr13491501vkq.143.1454778561871;
Sat, 06 Feb 2016 09:09:21 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Sat, 6 Feb 2016 09:09:21 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Sat, 6 Feb 2016 09:09:21 -0800 (PST)
In-Reply-To: <CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
<201602060012.26728.luke@dashjr.org>
<CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
<CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
Date: Sat, 6 Feb 2016 18:09:21 +0100
Message-ID: <CABm2gDoungCbB22_SKHcedBKegWEPpjeM2woxLGchC4=om8BrA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a11433b906855b1052b1d07df
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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] BIP proposal: Increase block size limit to 2
megabytes
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, 06 Feb 2016 17:09:23 -0000
--001a11433b906855b1052b1d07df
Content-Type: text/plain; charset=UTF-8
On Feb 6, 2016 16:37, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
> Responding to "28 days is not long enough" :
Any thoughts on the "95% better than 75%" and "grace period before miner
coordination instead of after" comments ?
> I suspect there ARE a significant percentage of un-maintained full
nodes-- probably 30 to 40%. Losing those nodes will not be a problem, for
three reasons:
None of the reasons you list say anything about the fact that "being lost"
(kicked out of the network) is a problem for those node's users.
> I strongly disagree with the statement that there is no cost to a longer
grace period.
I didn't say that.
> To bring it back to bitcoin-dev territory: are there any TECHNICAL
arguments why an upgrade would take a business or individual longer than 28
days?
Their own software stack may require more work to integrate the new rules
or their resources may not be immediately available to focus on this within
28 days they hadn't planned.
I believe it wold be less controversial to chose something that nobody can
deny is more than plenty of time for everyone to implement the changes
like, say, 1 year. I wouldn't personally oppose to something shorter like 6
months for really simple changes, but I don't see how 28 can ever be
considered uncontroversial and safe for everyone. Just trying to help in
removing controversy from the PR, but if you still think 28 can be safe and
uncontroversial, feel free to ignore these comments on the concrete length
and please let me know what you think about the other points I raised.
--001a11433b906855b1052b1d07df
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Feb 6, 2016 16:37, "Gavin Andresen" <<a href=3D"mailto:gavi=
nandresen@gmail.com">gavinandresen@gmail.com</a>> wrote:<br>
><br>
> Responding to "28 days is not long enough" :</p>
<p dir=3D"ltr">Any thoughts on the "95% better than 75%" and &quo=
t;grace period before miner coordination instead of after" comments ?<=
/p>
<p dir=3D"ltr">> I suspect there ARE a significant percentage of un-main=
tained full nodes-- probably 30 to 40%. Losing those nodes will not be a pr=
oblem, for three reasons:</p>
<p dir=3D"ltr">None of the reasons you list say anything about the fact tha=
t "being lost" (kicked out of the network) is a problem for those=
node's users.</p>
<p dir=3D"ltr">> I strongly disagree with the statement that there is no=
cost to a longer grace period.</p>
<p dir=3D"ltr">I didn't say that.</p>
<p dir=3D"ltr">> To bring it back to bitcoin-dev territory: =C2=A0are th=
ere any TECHNICAL arguments why an upgrade would take a business or individ=
ual longer than 28 days?</p>
<p dir=3D"ltr">Their own software stack may require more work to integrate =
the new rules or their resources may not be immediately available to focus =
on this within 28 days they hadn't planned.</p>
<p dir=3D"ltr">I believe it wold be less controversial to chose something t=
hat nobody can deny is more than plenty of time for everyone=C2=A0 to imple=
ment the changes like, say, 1 year. I wouldn't personally oppose to som=
ething shorter like 6 months for really simple changes, but I don't see=
how 28 can ever be considered uncontroversial and safe for everyone. Just =
trying to help in removing controversy from the PR, but if you still think =
28 can be safe and uncontroversial, feel free to ignore these comments on t=
he concrete length and please let me know what you think about the other po=
ints I raised.<br>
</p>
--001a11433b906855b1052b1d07df--
|
