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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ajriesgo@gmail.com>) id 1YzSEL-0008Na-JL
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 16:06:25 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.172 as permitted sender)
client-ip=209.85.223.172; envelope-from=ajriesgo@gmail.com;
helo=mail-ie0-f172.google.com;
Received: from mail-ie0-f172.google.com ([209.85.223.172])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YzSEF-0004dW-Ty
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 16:06:25 +0000
Received: by ieczm2 with SMTP id zm2so112702157iec.1
for <bitcoin-development@lists.sourceforge.net>;
Mon, 01 Jun 2015 09:06:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.56.104 with SMTP id z8mr14603538igp.45.1433174774566;
Mon, 01 Jun 2015 09:06:14 -0700 (PDT)
Received: by 10.107.129.226 with HTTP; Mon, 1 Jun 2015 09:06:14 -0700 (PDT)
In-Reply-To: <CANEZrP1OX4j=AoiHDQx10mSVY6D4Yu7rd9Lnq=RW-H+byhCnyw@mail.gmail.com>
References: <554BE0E1.5030001@bluematt.me>
<CAFzgq-xByQ1E_33_m3UpXQFUkGc78HKnA=7XXMshANDuTkNsvA@mail.gmail.com>
<CABsx9T0kbRe31LMwk499MQUw225f5GGd67GfhXBezHmDqxkioA@mail.gmail.com>
<CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
<CAFzgq-zTybEQyGz0nq90u5n5JZcJzxQS_XKaTpr5POJi-tHM6A@mail.gmail.com>
<CABsx9T2L5bi-c63-KqSifOMeNayUWSPo0_Hx8VjMR_4=kC3ixg@mail.gmail.com>
<CAE28kUT61qYxqV0mOqw5Dan=eMiCvnG2SnsAeWzOWTxwLydyeQ@mail.gmail.com>
<CABsx9T2hfpts5y_M6PdDcxmq9Q2smesJ0Nmp9a9iyPD_MoPC9g@mail.gmail.com>
<CAE28kUTZV3YsaSCX2d5YwLetnf=f+bOWGrwxLXdZFywTZ=+Pjg@mail.gmail.com>
<CALC81CNq-GK5q6R4bmgHL5_Ej2+cZrtQMMLVmuhvMxkZokM3hQ@mail.gmail.com>
<CAE28kUQr+kUPak67tcNQGGscUXtJiD1LiXfjdD8_LMUWyVdR5w@mail.gmail.com>
<CANEZrP12WAcUOJp5UYg4pfWL7_4WiAHWWZAoaxAb5xB+qAP4Xg@mail.gmail.com>
<CAFzgq-ykeMeWF-ndgSm9upHTe8j6ZFYhBQjFs_WSz1oVd29j7g@mail.gmail.com>
<CAFzgq-x+-s_Nbt4z-C4SWQbHdPr159AmL2JvpP0zg1axM+Vwcw@mail.gmail.com>
<CABsx9T2aEvPs68pQA-KrtaDQFcTTtiB36eqKAcJRkiOFQr6WsA@mail.gmail.com>
<CAFzgq-wzQaS5K1hQMz_TcbvKMKQbAde488bx4uDXhODNXpqtsA@mail.gmail.com>
<CANEZrP1OX4j=AoiHDQx10mSVY6D4Yu7rd9Lnq=RW-H+byhCnyw@mail.gmail.com>
Date: Mon, 1 Jun 2015 18:06:14 +0200
Message-ID: <CAKqjTbRU=xZ3XGf2naPm4R5T5gGdMvr=+pzNP4c-WVwmxDbjsw@mail.gmail.com>
From: =?UTF-8?Q?=C3=81ngel_Jos=C3=A9_Riesgo?= <ajriesgo@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e0158a84256db330517770199
X-Spam-Score: -0.6 (/)
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
(ajriesgo[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1YzSEF-0004dW-Ty
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
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: Mon, 01 Jun 2015 16:06:25 -0000
--089e0158a84256db330517770199
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi everyone,
I'm a long-time lurker of this mailing list but it's the first time I post
here, so first of all I'd like to thank all of the usual contributors for
the great insights and technical discussions that can be found here. As
this is such a momentous point in the history of Bitcoin, I'd just like to
throw in my opinion too.
First, I agree with Oliver Egginger's message that it's much more elegant
to keep the numbers as powers of 2 rather than introducing somewhat
arbitrary numbers like 20. This also makes it easier to count the level of
support for what would be a clear spectrum of discrete levels (1, 2, 4, ...
32, 64, ..., infinite). If a temporary peace accord can be reached with a
value like 8 or 16, this will buy us some time for both the user base to
continue growing without hitting the limit and for newer technologies like
the lightning network to be developed and tested. We will also see whether
the relatively small increase causes any unexpected harm or whether (as I
expect) everything continues to run smoothly.
Personally, I'd like to see Bitcoin grow and become what I think most
Bitcoin users like myself expect from it: that it should be a payment
network directly accessible to people all over the world. In my opinion, it
is the proposition of Bitcoin as a form of electronic money that
additionally makes it a good store of value. I don't believe in the idea
that it can exist as just some sort of digital gold for a geeky financial
elite. And I haven't been persuaded by those who claim the scarcity of
block space is an economic fundamental of Bitcoin either. It seems to me
there's a lot of batty economic ideas being bandied about regarding the
supposed long-term value of the cap without much justification. In this
sense, my sympathies are with those who want to remove the maximum block
size cap. This was after all the original idea, so it's not fair for the
1MB camp to claim that they're the ones preserving the essences of Bitcoin.
But, anyway, I also think that a consensus at this point would be much
better than a head-on confrontation between two incompatible pieces of
software competing to gain the favour of a majority of exchanges and
merchants. With this in mind, can't we accept the consensus that raising
the hard-coded limit to a value like 8MB buys us a bit of time and should
be at least palatable to everyone? This may not be what the staunch
supporters of the 1MB limit want, but it's also not what I and others would
want, so we're talking about finding some common ground here, and not about
one side getting their way to the detriment or humiliation of the other.
The problem with a compromise based on a one-off maximum-size increase, of
course, is that we're just kicking the can down the road and the discussion
will continue. It's not a solution I like, but how can we get people like
say Greg Maxwell or Pieter Wuille to accept something more drastic? If they
find a new maximum-size cap acceptable, then it could be a reasonable
compromise. A new cap will let us test the situation and see how the
Bitcoin environment reacts. The next time the discussion crops up (probably
very soon, I know...), we may all have a better understanding of the
implications.
=C3=81ngel Jos=C3=A9 Riesgo
--089e0158a84256db330517770199
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi everyone,</div><div><br></div><div>I'm a long-=
time lurker of this mailing list but it's the first time I post here, s=
o first of all I'd like to thank all of the usual contributors for the =
great insights and technical discussions that can be found here. As this is=
such a momentous point in the history of Bitcoin, I'd just like to thr=
ow in my opinion too.</div><div><br></div><div>First, I agree with Oliver E=
gginger's message that it's much more elegant to keep the numbers a=
s powers of 2 rather than introducing somewhat arbitrary numbers like 20. T=
his also makes it easier to count the level of support for what would be a =
clear spectrum of discrete levels (1, 2, 4, ... 32, 64, ..., infinite). If =
a temporary peace accord can be reached with a value like 8 or 16, this wil=
l buy us some time for both the user base to continue growing without hitti=
ng the limit and for newer technologies like the lightning network to be de=
veloped and tested. We will also see whether the relatively small increase =
causes any unexpected harm or whether (as I expect) everything continues to=
run smoothly.</div><div><br></div><div>Personally, I'd like to see Bit=
coin grow and become what I think most Bitcoin users like myself expect fro=
m it: that it should be a payment network directly accessible to people all=
over the world. In my opinion, it is the proposition of Bitcoin as a form =
of electronic money that additionally makes it a good store of value. I don=
't believe in the idea that it can exist as just some sort of digital g=
old for a geeky financial elite. And I haven't been persuaded by those =
who claim the scarcity of block space is an economic fundamental of Bitcoin=
either. It seems to me there's a lot of batty economic ideas being ban=
died about regarding the supposed long-term value of the cap without much j=
ustification. In this sense, my sympathies are with those who want to remov=
e the maximum block size cap. This was after all the original idea, so it&#=
39;s not fair for the 1MB camp to claim that they're the ones preservin=
g the essences of Bitcoin.</div><div><br></div><div>But, anyway, I also thi=
nk that a consensus at this point would be much better than a head-on confr=
ontation between two incompatible pieces of software competing to gain the =
favour of a majority of exchanges and merchants. With this in mind, can'=
;t we accept the consensus that raising the hard-coded limit to a value lik=
e 8MB buys us a bit of time and should be at least palatable to everyone? T=
his may not be what the staunch supporters of the 1MB limit want, but it=
9;s also not what I and others would want, so we're talking about findi=
ng some common ground here, and not about one side getting their way to the=
detriment or humiliation of the other.</div><div><br></div><div>The proble=
m with a compromise based on a one-off maximum-size increase, of course, is=
that we're just kicking the can down the road and the discussion will =
continue. It's not a solution I like, but how can we get people like sa=
y Greg Maxwell or Pieter Wuille to accept something more drastic? If they f=
ind a new maximum-size cap acceptable, then it could be a reasonable compro=
mise. A new cap will let us test the situation and see how the Bitcoin envi=
ronment reacts. The next time the discussion crops up (probably very soon, =
I know...), we may all have a better understanding of the implications.</di=
v><div><br></div><div>=C3=81ngel Jos=C3=A9 Riesgo</div><div><br></div></div=
>
--089e0158a84256db330517770199--
|
