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
158
159
160
161
162
163
164
165
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YqRYg-0005tz-AM
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 19:34:10 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.181 as permitted sender)
client-ip=209.85.212.181; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f181.google.com;
Received: from mail-wi0-f181.google.com ([209.85.212.181])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqRYe-00030y-TJ
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 19:34:10 +0000
Received: by wicmx19 with SMTP id mx19so21223975wic.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 12:34:02 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.9.161 with SMTP id a1mr343707wjb.39.1431027242887; Thu,
07 May 2015 12:34:02 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.90.114 with HTTP; Thu, 7 May 2015 12:34:02 -0700 (PDT)
In-Reply-To: <554BB718.6070104@bluematt.me>
References: <554A91BE.6060105@bluematt.me>
<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
<CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>
<554BA032.4040405@bluematt.me>
<CANEZrP3yM9wsSPNgpOsXDk-DjUy5PW2XuRTvK2AyCNbVJ5hZHw@mail.gmail.com>
<554BB718.6070104@bluematt.me>
Date: Thu, 7 May 2015 21:34:02 +0200
X-Google-Sender-Auth: 8e1cUaKoC1YIIg1Oxke485OCndo
Message-ID: <CANEZrP1N-wJNNHU+73FZu_CBvriXn4n+BgG=G1g-dAnEyw4BUQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=047d7b5d34fa79f067051582fed5
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YqRYe-00030y-TJ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2015 19:34:10 -0000
--047d7b5d34fa79f067051582fed5
Content-Type: text/plain; charset=UTF-8
>
> The appropriate method of doing any fork, that we seem to have been
> following for a long time, is to get consensus here and on IRC and on
> github and *then* go pitch to the general public
So your concern is just about the ordering and process of things, and not
about the change itself?
I have witnessed many arguments in IRC about block sizes over the years.
There was another one just a few weeks ago. Pieter left the channel for his
own sanity. IRC is not a good medium for arriving at decisions on things -
many people can't afford to sit on IRC all day and conversations can be
hard to follow. Additionally, they tend to go circular.
That said, I don't know if you can draw a line between the "ins" and "outs"
like that. The general public is watching, commenting and deciding no
matter what. Might as well deal with that and debate in a format more
accessible to all.
> If, instead, there had been an intro on the list as "I think we should
> do the blocksize increase soon, what do people think?"
There have been many such discussions over time. On bitcointalk. On reddit.
On IRC. At developer conferences. Gavin already knew what many of the
objections would be, which is why he started answering them.
But alright. Let's say he should have started a thread. Thanks for starting
it for him.
Now, can we get this specific list of things we should do before we're
prepared?
> A specific credible alternative to what? Committing to blocksize
> increases tomorrow? Yes, doing more research into this and developing
> software around supporting larger block sizes so people feel comfortable
> doing it in six months.
Do you have a specific research suggestion? Gavin has run simulations
across the internet with modified full nodes that use 20mb blocks, using
real data from the block chain. They seem to suggest it works OK.
What software do you have in mind?
--047d7b5d34fa79f067051582fed5
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:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">The appropriate method of doing any fork, that w=
e seem to have been<br>
following for a long time, is to get consensus here and on IRC and on<br>
github and *then* go pitch to the general public</blockquote><div><br></div=
><div>So your concern is just about the ordering and process of things, and=
not about the change itself?</div><div><br></div><div>I have witnessed man=
y arguments in IRC about block sizes over the years. There was another one =
just a few weeks ago. Pieter left the channel for his own sanity. IRC is no=
t a good medium for arriving at decisions on things - many people can't=
afford to sit on IRC all day and conversations can be hard to follow. Addi=
tionally, they tend to go circular.</div><div><br></div><div>That said, I d=
on't know if you can draw a line between the "ins" and "=
outs" like that. The general public is watching, commenting and decidi=
ng no matter what. Might as well deal with that and debate in a format more=
accessible to all.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If=
, instead, there had been an intro on the list as "I think we should<b=
r>
do the blocksize increase soon, what do people think?"</blockquote><di=
v><br></div><div>There have been many such discussions over time. On bitcoi=
ntalk. On reddit. On IRC. At developer conferences. Gavin already knew what=
many of the objections would be, which is why he started answering them.</=
div><div><br></div><div>But alright. Let's say he should have started a=
thread. Thanks for starting it for him.</div><div><br></div><div>Now, can =
we get this specific list of things we should do before we're prepared?=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A specific credible a=
lternative to what? Committing to blocksize<br>
increases tomorrow? Yes, doing more research into this and developing<br>
software around supporting larger block sizes so people feel comfortable<br=
>
doing it in six months. </blockquote><div><br></div><div>Do you have a spec=
ific research suggestion? Gavin has run simulations across the internet wit=
h modified full nodes that use 20mb blocks, using real data from the block =
chain. They seem to suggest it works OK.</div><div><br></div><div>What soft=
ware do you have in mind?</div></div></div></div>
--047d7b5d34fa79f067051582fed5--
|
