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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from
<SRS0=jOMUSZ=FS=thelibertyportal.com=matthewmitchell@eigbox.net>)
id 1YqOBu-0002Lk-6n for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 15:58:26 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of eigbox.net
designates 66.96.185.6 as permitted sender)
client-ip=66.96.185.6;
envelope-from=SRS0=jOMUSZ=FS=thelibertyportal.com=matthewmitchell@eigbox.net;
helo=bosmailout06.eigbox.net;
Received: from bosmailout06.eigbox.net ([66.96.185.6])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YqOBt-0006CT-15 for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 15:58:26 +0000
Received: from bosmailscan08.eigbox.net ([10.20.15.8])
by bosmailout06.eigbox.net with esmtp (Exim) id 1YqOBn-0001b9-Qu
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 11:58:19 -0400
Received: from [10.115.3.31] (helo=bosimpout11)
by bosmailscan08.eigbox.net with esmtp (Exim) id 1YqOBn-0008Es-PQ
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 11:58:19 -0400
Received: from bosauthsmtp02.yourhostingaccount.com ([10.20.18.2])
by bosimpout11 with
id R3yG1q00p02gpmq013yKpe; Thu, 07 May 2015 11:58:19 -0400
X-Authority-Analysis: v=2.1 cv=SLLMVYfH c=1 sm=1 tr=0
a=9MP9vxlQrmnoeofDS6o88g==:117 a=z3zsPO1EquuvJlEroHUibA==:17
a=pq4jwCggAAAA:8
a=QPcu4mC3AAAA:8 a=kb-7UQSq9zUA:10 a=FurB0epzNeMA:10 a=82ocvhqlAAAA:8
a=0Bzu9jTXAAAA:8 a=h1PgugrvaO0A:10 a=13zjGPudsaEWiJwPRgMA:9
a=WbPmnYzAfxEA:10
a=i4fd7TR6sGcA:10 a=h5x1KQqIZxoA:10 a=ahaM9nHAOhcA:10 a=4EGDMaEJAAAA:8
a=JcT1meiOAAAA:8 a=FP58Ms26AAAA:8 a=2l2baNGuI3IKiMFzMzAA:9
a=xhZxMCq19Zz7_ydE:21 a=fTP1jCtzr5Kp_PAR:21 a=pILNOxqGKmIA:10
a=-AooqXFOzdtTlpPu1EAA:9
Received: from 56.47.112.87.dyn.plus.net ([87.112.47.56]:55523
helo=[192.168.1.75]) by bosauthsmtp02.eigbox.net with esmtpsa
(TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim) id 1YqOBk-0007Ib-Ei
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 11:58:16 -0400
Message-ID: <554B8B95.60905@thelibertyportal.com>
Date: Thu, 07 May 2015 16:58:13 +0100
From: Matthew Mitchell <matthewmitchell@thelibertyportal.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
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>
In-Reply-To: <CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="UD6AuKl94tuCcaE5joU1CsxEqI09mWr4s"
X-EN-UserInfo: 3f46a65fee631b45f0f295c1b6eb286c:931c98230c6409dcc37fa7e93b490c27
X-EN-AuthUser: cbitcoin@thelibertyportal.com
Sender: Matthew Mitchell <matthewmitchell@thelibertyportal.com>
X-EN-OrigIP: 87.112.47.56
X-EN-OrigHost: 56.47.112.87.dyn.plus.net
X-Spam-Score: -1.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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [66.96.185.6 listed in list.dnswl.org]
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1YqOBt-0006CT-15
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 15:58:26 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UD6AuKl94tuCcaE5joU1CsxEqI09mWr4s
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
In my personal opinion, this does make some sense to me, assuming I
understood Gavin.
I suppose it could be done with a new flag (like the P2SH flag) which
displays miner support for larger blocks. The new rules would apply when
a large majority of miners support the new rules by counting the number
of flagged blocks over a certain number of blocks on the network in a
deterministic fashion.
This way miners can continue to produce blocks which are supported by
both old and new clients. When it appears most people have migrated to
the new client, miners can start flagging support for the new rules, and
when a large majority of miners agree, the new rules would kick in for
all miners/clients running the new software. Miners could therefore glue
together the network during the migration phase until enough people have
updated to avoid severe fork scenarios. The only problem is ensuring
that miners will continue to support both networks for long enough to
enable successful migration.
And if too many people disagree to make a clean hard fork (too many
people stubbornly stick to the old rules), then it could be that the
hard fork is aborted and everyone goes back to the old rules, or quite
simply that the miners never give support for the new rules despite the
mechanism being included in the new client. In those cases it would be
as if nothing changed.
This way the hard fork would be determined by user participation as
judged by the miners.
If it is done, I can't think of a fairer way.
Matthew Mitchell
On 07/05/15 15:52, Gavin Andresen wrote:
> For reference: the blog post that (re)-started this debate, and which
> links to individual issues, is here:
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>=20
> In it, I asked people to email me objections I might have missed. I
> would still appreciate it if people do that; it is impossible to keep u=
p
> with this mailing list, /r/bitcoin posts and comments, and
> #bitcoin-wizards and also have time to respond thoughtfully to the
> objections raised.
>=20
> I would very much like to find some concrete course of action that we
> can come to consensus on. Some compromise so we can tell entrepreneurs
> "THIS is how much transaction volume the main Bitcoin blockchain will b=
e
> able to support over the next eleven years."
>=20
> I've been pretty clear on what I think is a reasonable compromise (a
> one-time increase scheduled for early next year), and I have tried to
> explain why I think it it is the right set of tradeoffs.
>=20
> There ARE tradeoffs here, and the hard question is what process do we
> use to decide those tradeoffs? How do we come to consensus? Is it wort=
h
> my time to spend hours responding thoughtfully to every new objection
> raised here, or will the same thing happen that happened last year and
> the year before-- everybody eventually gets tired of arguing
> angels-dancing-on-the-head-of-a-pin, and we're left with the status quo=
?
>=20
> I AM considering contributing some version of the bigger blocksize-limi=
t
> hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist
> with a fast Internet connection, and assume Nelson's law to increase
> over time), and then encouraging merchants and exchanges and web wallet=
s
> and individuals who think it strikes a reasonable balance to run it.
>=20
> And then, assuming it became a super-majority of nodes on the network,
> encourage miners to roll out a soft-fork to start producing bigger
> blocks and eventually trigger the hard fork.
>=20
> Because ultimately consensus comes down to what software people choose
> to run.
>=20
> --=20
> --
> Gavin Andresen
>=20
>=20
>=20
> -----------------------------------------------------------------------=
-------
> One dashboard for servers and applications across Physical-Virtual-Clou=
d=20
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insight=
s
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>=20
>=20
>=20
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
--UD6AuKl94tuCcaE5joU1CsxEqI09mWr4s
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJVS4uVAAoJEJHLtcap76MQiF8P/iV0y9veG64Bxxnx5T1ItpTu
1xSeDwHAeizCKzDr+z69ihAYhJTyxWEhVZsOQ1YHQhYe0f5RLYwEZXOj8h2B4+OL
x0eHF+9oMGy/4ukRFE1kSQGpjzjftfLPBP7yz4dO/1bnQGfwQyFH80752tfqQKEZ
ECOKc5w7jZHO9ftUWmkreUyToC8L7oIX8bNGhlTjaiajUpR4LGaSptarTxlfR9Qt
id/X/CEF1yhwfncVFXVG6gmPxi4Cq/eqXFH7pAVngbOYIY7qIyJklRGHj+09VlRz
O/LmSbxOOCQAOYVS74GUAwk13acFJTq54sRrNSFmCyWWCMbViK/CWcWEZ4LvvCyb
n7eQFEEITn4DmaBslwFil6CJVyE0/ry5jeP4RRgZqwq5G5w4/ghhzFcmX9jIhtQI
Xg+1WZQFcf5PbYvB44q/sI/epfX0qLlmvnAkFvAw9EknwEKImnA5cZNtt6Zd3U6C
4MFkg6UrCFFXv/+YbgbH2uVsok0FY7gfrhqy9opb37ehyXfCBeJ11JA3sLeV5AHG
qhaW7sv3s9F3kryb0xG3OgFqK+4SpE2Gfggc8lp7RlLMReP91A0rOxMjAzvSrdQb
kiIFOKLyAN13JfCnN1SWKUB2Ge4mF80Jvf5DXbx+ddxwPz5W0qdU3Szhgivis2Ug
bDVsLe0bdstsrT4MqIIU
=ym4V
-----END PGP SIGNATURE-----
--UD6AuKl94tuCcaE5joU1CsxEqI09mWr4s--
|
