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
155
156
157
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 43E545AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 17:45:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com
[209.85.223.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93089143
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 17:45:31 +0000 (UTC)
Received: by iehx8 with SMTP id x8so93226707ieh.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 10:45:31 -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:to
:cc:content-type;
bh=CstGkpa0P5IpBs25RnFcnDRYD3Wsp9q93/aM6EnWdoQ=;
b=eDkzlecgI0xf2peHcgg71SPHOdJeHO/Uab6cWHg195VxX3s3knJ9yMdSsji76+oZFN
wHDCeyO/2o27ZfoLSkkhwXNZsDruOPbVoZdm9Whay6V50l8FJjJryTT4S6QVW+XfCS7K
FbaC/bZuM9IjQ4Oi1AJ9Y8YSpwv6V7bW+WSCWtLYRgFXEP+sT47iTSOJXV/i5YEXCYYU
jxuqG+0EJvhJn9ZsuvOmaBLPmlkJPnM/X6DqjLlQLvJ+eHFCTg2+N9nVdcwhR3c/Vjvq
VNzz+h4YRwpU6Hxu+WSCYo8b49bNZ7b/r1V7GJz2u9njCtIzXh/vcn5uMRin1Y41Kt4s
fNjQ==
MIME-Version: 1.0
X-Received: by 10.50.3.6 with SMTP id 6mr34227211igy.28.1437586999381; Wed, 22
Jul 2015 10:43:19 -0700 (PDT)
Received: by 10.79.38.79 with HTTP; Wed, 22 Jul 2015 10:43:19 -0700 (PDT)
In-Reply-To: <20150721135846.GB13429@savin.petertodd.org>
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
<55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk>
<CABm2gDr6qXzvcpX_To39kCEsnQNTQS4M5Y40Yk_Lw481rjvSag@mail.gmail.com>
<20150721130412.GA4551@savin.petertodd.org>
<20150721135846.GB13429@savin.petertodd.org>
Date: Wed, 22 Jul 2015 10:43:19 -0700
Message-ID: <CADm_WcZDLfAwCJn8qc1Myp-OQhgPzx+A7b6nw8u9Z7mgQ6hveg@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e0122aa626ed54e051b7a4eb9
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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
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: Wed, 22 Jul 2015 17:45:32 -0000
--089e0122aa626ed54e051b7a4eb9
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I don't agree with you at all.
>
> This is a case where if Jeff doesn't understand that issue, he's
> proposing changes that he's not competent enough to understand, and it'd
> save us a lot of review effort if he left that discussion. Equally, Jeff
> is in a position in the dev community where he should be that competent;
> if he actually isn't it does a lot of good for the broader community to
> change that opinion.
>
> I personally *don't* think he's doing that, rather I believe he knows
> full well it's a bad patch and is proposing it because he wants to push
> discussion towards a solution. Often trolling the a audience with bad
> patches is an effective way to motivate people to respond by writing
> better ones; Jeff has told me he often does exactly that.
>
>
mmmm kay. Let's try to keep it technical, please.
2MB is a limit that has been discussed as a viable next-step, meeting with
the most consensus.
2MB gets beyond the 1MB hard fork issue, while still remaining within a
safety cap that should ensure the system does not go "off the rails" as
some has predicted.
Security, privacy and centralization are not going to disappear at 2MB.
Further, a limited step gains valuable field data for judging whether
further steps are warranted - thus informing the "better block size
solution" development process.
Finally, as stated in the initial PR, it is intended as a viable fallback
should we reach a point of criticality where the user community feels a
block size increase is warranted, yet cannot reach consensus on a fancy,
all-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc.
I am open to suggestions for improving BIP 102. The goal is a minimum
complexity fallback that others have previously agreed was a useful
kick-the-can compromise - a static 2MB cap.
--089e0122aa626ed54e051b7a4eb9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-de=
v <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span=
> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">I don't agree with you at all.<br>
<br>
This is a case where if Jeff doesn't understand that issue, he's<br=
>
proposing changes that he's not competent enough to understand, and it&=
#39;d<br>
save us a lot of review effort if he left that discussion. Equally, Jeff<br=
>
is in a position in the dev community where he should be that competent;<br=
>
if he actually isn't it does a lot of good for the broader community to=
<br>
change that opinion.<br>
<br>
I personally *don't* think he's doing that, rather I believe he kno=
ws<br>
full well it's a bad patch and is proposing it because he wants to push=
<br>
discussion towards a solution. Often trolling the a audience with bad<br>
patches is an effective way to motivate people to respond by writing<br>
better ones; Jeff has told me he often does exactly that.<br><br></blockquo=
te><div><br></div><div>mmmm kay.=C2=A0 Let's try to keep it technical, =
please.</div><div><br></div><div>2MB is a limit that has been discussed as =
a viable next-step, meeting with the most consensus.</div><div><br></div><d=
iv>2MB gets beyond the 1MB hard fork issue, while still remaining within a =
safety cap that should ensure the system does not go "off the rails&qu=
ot; as some has predicted.</div><div><br></div><div>Security, privacy and c=
entralization are not going to disappear at 2MB.</div><div><br></div><div>F=
urther, a limited step gains valuable field data for judging whether furthe=
r steps are warranted - thus informing the "better block size solution=
" development process.</div><div><br></div><div>Finally, as stated in =
the initial PR, it is intended as a viable fallback should we reach a point=
of criticality where the user community feels a block size increase is war=
ranted, yet cannot reach consensus on a fancy, all-consuming solution be it=
20MB, flexcap, BIP 100, BIP 102, etc.</div><div><br></div><div>I am open t=
o suggestions for improving BIP 102.=C2=A0 The goal is a minimum complexity=
fallback that others have previously agreed was a useful kick-the-can comp=
romise - a static 2MB cap.</div><div><br></div><div><br></div></div><br></d=
iv></div>
--089e0122aa626ed54e051b7a4eb9--
|
