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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <s7r@sky-ip.org>) id 1Yyzbj-0004G3-2W
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 09:32:39 +0000
Received-SPF: neutral (sog-mx-1.v43.ch3.sourceforge.com: 162.222.225.25 is
neither permitted nor denied by domain of sky-ip.org)
client-ip=162.222.225.25; envelope-from=s7r@sky-ip.org;
helo=outbound.mailhostbox.com;
Received: from outbound.mailhostbox.com ([162.222.225.25])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Yyzbd-0003kl-PE for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 09:32:39 +0000
Received: from [0.0.0.0] (wannabe.torservers.net [96.47.226.22])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: s7r@sky-ip.org)
by outbound.mailhostbox.com (Postfix) with ESMTPSA id ECAEE360DC9;
Sun, 31 May 2015 09:32:11 +0000 (GMT)
Message-ID: <556AD518.6030207@sky-ip.org>
Date: Sun, 31 May 2015 12:32:08 +0300
From: s7r <s7r@sky-ip.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Matt Whitlock <bip@mattwhitlock.name>,
Gregory Maxwell <gmaxwell@gmail.com>,
Pieter Wuille <pieter.wuille@gmail.com>, Jeff Garzik <jgarzik@bitpay.com>,
"Wladimir J. van der Laan" <laanwj@gmail.com>,
Peter Todd <pete@petertodd.org>
References: <3698747.VeHb3lFFLZ@crushinator>
In-Reply-To: <3698747.VeHb3lFFLZ@crushinator>
Content-Type: text/plain; charset=windows-1252
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=Rpo4V3SK c=1 sm=1 tr=0
a=IDjeRzmlOBd3L0IU5xujrg==:117 a=IDjeRzmlOBd3L0IU5xujrg==:17
a=ZDnEzkWgAAAA:8 a=-NIMs_s3AAAA:8 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10
a=bvjBBkZ6AAAA:8 a=FP58Ms26AAAA:8 a=-E-tod9gr8kuDzg9JhwA:9
a=pILNOxqGKmIA:10
X-CTCH-RefID: str=0001.0A020206.556AD51E.0092, ss=1, re=0.000, recu=0.000,
reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: s7r@sky-ip.org
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.8 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [162.222.225.25 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral)
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Headers-End: 1Yyzbd-0003kl-PE
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Proposal: A measured response to save
Bitcoin Core
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: s7r@sky-ip.org
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: Sun, 31 May 2015 09:32:39 -0000
Hi,
For the less crypto engineering experts but highly interested in Bitcoin
and working with Bitcoin on daily basis reading the list, what would be
an easy to understand explanation about how does this solution represent
a good fix?
So, we have a hard cap of 1 MB block currently. This is not enough
because more and more people use Bitcoin and the transaction volume
increased (yeey, good news). So, rather than fixing the issue for good,
we just increase the block size hard cap to 20 MB. I will not discuss if
this causes problems or not. But what are the future plans, when the 20
MB hard cap will be reached? Increase it again? This doesn't sound like
a fix, it sounds more like pushing the can down the road. Obviously if 1
MB is not enough now, we have the reasonable suspicion that 20 MB could
not be enough in few years.
What is the explanation that 20 MB blocks will be sufficient for life
time? Is it because 'probably other solutions will appear, such as
micropayment channels and offchain transactions'? If this is the case,
those can easily function with 1 MB blocks as well, and we should see
those in action sooner rather than later.
I run multiple full nodes, including one with Bitcoin XT and I don't
want to see Bitcoin XT and Bitcoin Core divide into different consensus
and create 2 altcoins instead of one Bitcoin.
On 5/31/2015 3:29 AM, Matt Whitlock wrote:
> Greg, Pieter, Jeff, and Wladimir,
>=20
> I'll try to be brief to respect your time.
>=20
> 1. I don't want to see Bitcoin die.
>=20
> 2. As has been discussed on this list and elsewhere: Bitcoin could pote=
ntially die due to economic and/or game-theoretic complications arising f=
rom raising the block size limit, but Bitcoin could also die due to usabi=
lity complications arising from NOT raising the block size limit. Strong,=
personally held opinions by various members of this community notwithsta=
nding, it is not clear which of these scenarios is more likely.
>=20
> 3. What *is* clear at this point is that Gavin will move ahead with his=
proposal, regardless of whether the remainder of the Bitcoin Core commit=
ters agree with him. If he has to commit his changes to Bitcoin XT and th=
en rally the miners to switch, then that's what he'll do. He believes tha=
t he is working in the best interests of Bitcoin (as I would hope we all =
do), and so I do not fault him for his intentions. However, I think his p=
roposal is too risky.
>=20
> 4. I also think that ignoring the immediate problem is too risky. If al=
lowing significantly larger blocks will cause a serious problem for Bitco=
in (which is a possibility that we cannot rule out, as we lack omniscienc=
e), then NOT making any change to Bitcoin Core will virtually *assure* th=
at we cause exactly this problem, as the popular (non-technical) consensu=
s appears to be in favor of Bitcoin XT and a larger block size limit. If =
we do nothing, then there's a very real chance that Bitcoin XT takes over=
, for better or worse.
>=20
> 5. I'd like to propose a way that we can have our cake and eat it too. =
My proposal attempts to satisfy both those who want larger blocks AND tho=
se who want to be extremely cautious about changing the fundamental econo=
mic parameters of Bitcoin.
>=20
> 6. Something I've never understood about Gavin's (et al.) proposal is w=
hy there is a massive step right up front. Assuming we accept his argumen=
t that we're critically close to running out of capacity, I still must as=
k: why do we need a 20x increase all at once?
>=20
> 7. It's not a given that blocks will immediately expand to meet the har=
d limit. In fact, there are strong and compelling arguments why this will=
NOT happen. But in any software system, if a given scenario is *possible=
*, then one MUST assume that it will happen and must have a plan to handl=
e it.
>=20
> 8. My primary objection is not to raising the block size limit; my obje=
ction is to raising it *suddenly*. You can argue that, because we'll have=
plenty of time before March 2016, it's not "sudden," but, whether we do =
it now or a year from now or a decade from now, a step function is, by de=
finition, sudden.
>=20
> 9. My proposal is that we raise the block size limit *gradually*, using=
an approximately smooth function, without a step discontinuity. We can e=
mploy a linear growth function to adjust the block size limit *smoothly* =
from 1 MB to 20 MB over the course of several years, beginning next March=
.
>=20
> 10. This is the difference between cannonballing into the deep end of t=
he pool and walking gingerly down the steps into the shallow end. Both ge=
t you to the eventual goal, but one is reckless while the other is measur=
ed and deliberate. If there's a problem that larger blocks will enable, t=
hen I'd prefer to see the problem crop up gradually rather than all at on=
ce. If it's gradual, then we'll have time to discuss and fix it without p=
anicking.
>=20
> 11. I am offering to implement this proposal and submit a pull request =
to Bitcoin Core. However, if another dev who is more familiar with the in=
ternals would like to step forward, then that would be superior.
>=20
> Respectfully submitted,
> Matt Whitlock
>=20
> -----------------------------------------------------------------------=
-------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
|
