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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YzU2E-0005fF-5h
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 18:02:02 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.172 as permitted sender)
client-ip=209.85.212.172; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f172.google.com;
Received: from mail-wi0-f172.google.com ([209.85.212.172])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YzU2B-00044G-PC
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 18:02:02 +0000
Received: by wifw1 with SMTP id w1so115273898wif.0
for <bitcoin-development@lists.sourceforge.net>;
Mon, 01 Jun 2015 11:01:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.74.210 with SMTP id w18mr22986274wiv.77.1433181713732;
Mon, 01 Jun 2015 11:01:53 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.143.9 with HTTP; Mon, 1 Jun 2015 11:01:53 -0700 (PDT)
In-Reply-To: <CALqxMTE57mEiG7VuEDSfBDswCeYPWRoa1DEY9iL=P0xLFu8YCA@mail.gmail.com>
References: <CALqxMTHfU5+1ezP-Jnn5obpd621EHwpstseFzTjAvOdhDkfj=g@mail.gmail.com>
<CANEZrP3SGdpSkpi-1eBiUMD74NPnAr7sW=eZ8WCz7PU6FVQaBA@mail.gmail.com>
<CALqxMTE57mEiG7VuEDSfBDswCeYPWRoa1DEY9iL=P0xLFu8YCA@mail.gmail.com>
Date: Mon, 1 Jun 2015 20:01:53 +0200
X-Google-Sender-Auth: pxRPj4qXo_lEfUxRzLljW4YgwhU
Message-ID: <CANEZrP0Ym7E6e5EASx-YeDRNPU=00804nPqeq1a0-fmxCpfmCA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=f46d043749fbf21f670517789ecb
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: 1YzU2B-00044G-PC
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] soft-fork block size increase (extension
blocks)
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 18:02:02 -0000
--f46d043749fbf21f670517789ecb
Content-Type: text/plain; charset=UTF-8
>
> (at reduced security if it has software that doesnt understand it)
Well, yes. Isn't that rather key to the issue? Whereas by simply
increasing the block size, SPV wallets don't care (same security and
protocol as before) and fully validating wallets can be updated with a very
small code change.
> A 1MB client wont even understand the difference between a 1MB and 8MB
> out payment.
Let's say an old client makes a payment that only gets confirmed in an
extension block. The wallet will think the payment is unconfirmed and show
that to the user forever, no?
Can you walk through the UX for each case?
> If I am not misremembering, I think you've sided typically
> with the huge block, big data center only end of the spectrum.
It would be Satoshi, that argued that.
I think there must be a communication issue here somewhere. I'm not sure
how this meme has taken hold amongst you guys, as I am the guy who wrote
the scalability page back in 2011:
https://en.bitcoin.it/wiki/Scalability
It says:
*The core Bitcoin network can scale to much higher transaction rates than
are seen today, assuming that nodes in the network are primarily running on
high end servers rather than desktops. *
By "much higher rates" I meant VISA scale and by "high end server" I meant
high end by today's standards not tomorrows. There's a big difference
between a datacenter and a single server! By definition a single server is
not a datacenter, although it would be conventional to place it in
one. But even
with the most wildly optimistic growth imaginable, I couldn't foresee a
time when you needed more than a single machine to keep up with the
transaction stream.
And we're not going to get to VISA scale any time soon: I don't think I've
ever argued we will. If it does happen it would presumably be decades away.
Again, short of some currently unimagined killer app.
So I don't believe I've ever argued this, and honestly I kinda feel people
are putting words in my mouth.
--f46d043749fbf21f670517789ecb
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:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">(at reduced security if it has software=C2=A0that doesnt under=
stand it) </blockquote><div><br></div><div>Well, yes. Isn't that rather=
key to the issue?=C2=A0 Whereas by simply increasing the block size, SPV w=
allets don't care (same security and protocol as before) and fully vali=
dating wallets can be updated with a very small code change.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">A 1MB client wont even understand the difference =
between a 1MB and 8MB<br>
out payment.=C2=A0</blockquote><div><br></div><div>Let's say an old cli=
ent makes a payment that only gets confirmed in an extension block. The wal=
let will think the payment is unconfirmed and show that to the user forever=
, no?</div><div>=C2=A0</div><div>Can you walk through the UX for each case?=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex">If I am not misremembering, I think=
you've sided typically<br>
with the huge block, big data center only end of the spectrum.=C2=A0 </bloc=
kquote><div><br></div><div>It would be Satoshi, that argued that.</div><div=
><br></div><div>I think there must be a communication issue here somewhere.=
I'm not sure how this meme has taken hold amongst you guys, as I am th=
e guy who wrote the scalability page back in 2011:</div><div><br></div><div=
><a href=3D"https://en.bitcoin.it/wiki/Scalability">https://en.bitcoin.it/w=
iki/Scalability</a><br></div><div><br></div><div>It says:</div><div><br></d=
iv></div></div><blockquote style=3D"margin:0px 0px 0px 40px;border:none;pad=
ding:0px"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><span =
style=3D"color:rgb(37,37,37);font-family:sans-serif;font-size:14px;line-hei=
ght:17.9200000762939px"><i>The core Bitcoin network can scale to much highe=
r transaction rates than are seen today, assuming that nodes in the network=
are primarily running on high end servers rather than desktops.=C2=A0</i><=
/span></div></div></div></blockquote><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div><span style=3D"color:rgb(37,37,37);font-family:sans-s=
erif;font-size:14px;line-height:17.9200000762939px"><br></span></div><div><=
font color=3D"#252525" face=3D"sans-serif"><span style=3D"line-height:17.92=
00000762939px">By "much higher rates" I meant VISA scale and by &=
quot;high end server" I meant high end by today's standards not to=
morrows. There's a big difference between a datacenter and a single ser=
ver!=C2=A0</span></font><span style=3D"color:rgb(37,37,37);font-family:sans=
-serif;line-height:17.9200000762939px">By definition a single server is not=
a datacenter, although it would be conventional to place it in one. But=C2=
=A0</span><span style=3D"line-height:17.9200000762939px;color:rgb(37,37,37)=
;font-family:sans-serif">even with the most wildly optimistic growth imagin=
able, I couldn't foresee a time when you needed more than a single mach=
ine to keep up with the transaction stream.=C2=A0</span></div><div><font co=
lor=3D"#252525" face=3D"sans-serif"><span style=3D"line-height:17.920000076=
2939px"><br></span></font></div><div><font color=3D"#252525" face=3D"sans-s=
erif"><span style=3D"line-height:17.9200000762939px">And we're not goin=
g to get to VISA scale any time soon: I don't think I've ever argue=
d we will. If it does happen it would presumably be decades away. Again, sh=
ort of some currently unimagined killer app.</span></font></div><div><font =
color=3D"#252525" face=3D"sans-serif"><span style=3D"line-height:17.9200000=
762939px"><br></span></font></div><div><font color=3D"#252525" face=3D"sans=
-serif"><span style=3D"line-height:17.9200000762939px">So I don't belie=
ve I've ever argued this, and honestly I kinda feel people are putting =
words in my mouth.</span></font></div></div></div></div>
--f46d043749fbf21f670517789ecb--
|
