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
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
|
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 1Z4Qfz-0000tN-S3
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 09:27:31 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.169 as permitted sender)
client-ip=209.85.212.169; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f169.google.com;
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4Qfy-0004GE-En
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 09:27:31 +0000
Received: by wicnd19 with SMTP id nd19so18431602wic.1
for <bitcoin-development@lists.sourceforge.net>;
Mon, 15 Jun 2015 02:27:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.59.98 with SMTP id y2mr7148982wjq.42.1434360444389; Mon,
15 Jun 2015 02:27:24 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Mon, 15 Jun 2015 02:27:24 -0700 (PDT)
In-Reply-To: <CALqxMTENbj+E7ypJASrM1r04eW3kYe+afwy+Rt3i9ubeT-=2mA@mail.gmail.com>
References: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
<CANEZrP1nx9rNf1q-nubP77U8RMABuLtmEB_P7UpY2zyFf-Ns-w@mail.gmail.com>
<CALqxMTENbj+E7ypJASrM1r04eW3kYe+afwy+Rt3i9ubeT-=2mA@mail.gmail.com>
Date: Mon, 15 Jun 2015 11:27:24 +0200
X-Google-Sender-Auth: lGU3UAhrv2UjL9X_DE4uBTf9r7M
Message-ID: <CANEZrP0Z_EOmVgbvVmYDvegm6jfd1cKB52acXHocjRuM-qGEog@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=047d7ba978a0c48e3305188b1004
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: 1Z4Qfy-0004GE-En
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
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, 15 Jun 2015 09:27:31 -0000
--047d7ba978a0c48e3305188b1004
Content-Type: text/plain; charset=UTF-8
>
> That was probably insufficiently specific, let me rephrase: I am
> referring to the trend that much of the industry is built on web2.0
> technology using bitcoin via a library in a web scripting language
OK, good to hear that. I'm not happy about the use of web technologies in
wallets/services either, but the causes of that trend are nothing to do
with block chain sizes. It's more because there's a generation of
developers who see no alternatives.
With projects like Lighthouse, I'm trying to show people that they can
blend the good bits of the web with the good bits of more traditional
client side development, at a cost they can afford.
Unfortunately, as you know, one of the reasons that developers turn to
outsourced services is that those services actually like developers and
give them the features they need. Whereas any attempt to add protocol
features for app/wallet developers to Bitcoin Core becomes controversial
due to some perceived or real lack of perfection.
I persevered for several months to add a very small "API" I needed for my
app to Bitcoin Core, and it was in the end a waste of time. There are no
actionable items left for the getutxo patch, regardless, I had to fork
Bitcoin to get it out there. It would have been *much* easier to just say,
fuck it, I'll use blockchain.info and in fact some in this community told
me to do exactly that. But, the approach I chose has been working fine for
months now.
Compare this experience to companies like chain.com, blockcypher etc - when
developers say jump, they say "how high?"
So It's unreasonable for the Bitcoin Core developer group to constantly
call developers building apps idiots or "non technical" (as I see so often
in this block size debate), and then complain that people don't write apps
in their preferred way! Just accept that decentralised app dev is already
hard, and the way Core is run makes it much harder still.
As I said I dont think we can expect Bitcoin to scale with no further
> algorithmic improvements.
A big part of the debate around this change is showing that this statement
is wrong. "Scaling" is not some kind of binary yes/no thing. It's a
continuous effort. You write a system that scales a certain amount, and
then if you find you need more capacity, you scale it again. Maybe that
involves rewriting the existing code or maybe it just means improving what
you've got.
Or maybe (painful truth coming up) your product is not that compelling, or
times change and your users leave, and you discover you never actually need
to scale to the giddy heights originally envisioned.
A big part of the reason modern web dev is so messed up is that lots of
developers starting thinking every app they built needed to be "web scale"
from day one. SQL databases? Pah. Doesn't scale. Think big. We gotta no
NoSQL sharded key/value store from the start! Otherwise we're just showing
lack of confidence in our own product.
Then when they used up all their budget solving consistency bugs a
relational database would have avoided, they notice their competitors
sailing past them on a not-fully-scalable but certainly-scalable-enough
architecture that let them focus on features and making users happy.
> I am referring to global bandwidth O(n^2) with n=users
OK. O() notation normally refers to computational complexity, but ... I
still don't get it - the vast majority of users don't run relaying nodes
that take part in gossiping. They run web or SPV wallets. And the nodes
that do take part don't connect to every other node.
> There can be a case for some increase to create some breathing room to
> work on scaling and decentralising tech, I just mean to say that if we
> do it in isolation, we're not focussing on the big picture.
Alright - let's agree that we disagree on a few areas, like the relative
desirability of alternative non-blockchain designs - but we do seem to
agree that there is a case for an increase in the block size limit. That
seems like progress.
As you agree with that, what sort of schedule and time are you thinking of?
(well, by "you" I really mean blockstream because it's taking forever to
try and negotiate with every single person individually).
--047d7ba978a0c48e3305188b1004
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">That was probably insufficiently specific, let m=
e rephrase: I am<br>
referring to the trend that much of the industry is built on web2.0<br>
technology using bitcoin via a library in a web scripting language</blockqu=
ote><div><br></div><div>OK, good to hear that. I'm not happy about the =
use of web technologies in wallets/services either, but the causes of that =
trend are nothing to do with block chain sizes. It's more because there=
's a generation of developers who see no alternatives.</div><div><br></=
div><div>With projects like Lighthouse, I'm trying to show people that =
they can blend the good bits of the web with the good bits of more traditio=
nal client side development, at a cost they can afford.</div><div><br></div=
><div>Unfortunately, as you know, one of the reasons that developers turn t=
o outsourced services is that those services actually like developers and g=
ive them the features they need. Whereas any attempt to add protocol featur=
es for app/wallet developers to Bitcoin Core becomes controversial due to s=
ome perceived or real lack of perfection.</div><div><br></div><div>I persev=
ered for several months to add a very small "API" I needed for my=
app to Bitcoin Core, and it was in the end a waste of time. There are no a=
ctionable items left for the getutxo patch, regardless, I had to fork Bitco=
in to get it out there. It would have been <b>much</b>=C2=A0easier to just =
say, fuck it, I'll use <a href=3D"http://blockchain.info">blockchain.in=
fo</a> and in fact some in this community told me to do exactly that. But, =
the approach I chose has been working fine for months now.</div><div><br></=
div><div>Compare this experience to companies like <a href=3D"http://chain.=
com">chain.com</a>, blockcypher etc - when developers say jump, they say &q=
uot;how high?"</div><div><br></div><div>So It's unreasonable for t=
he Bitcoin Core developer group to constantly call developers building apps=
idiots or "non technical" (as I see so often in this block size =
debate), and then complain that people don't write apps in their prefer=
red way! Just accept that decentralised app dev is already hard, and the wa=
y Core is run makes it much harder still.</div><div><br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">As I said I dont think we can expect Bitco=
in to scale with no further<br>
algorithmic improvements.=C2=A0</blockquote><div><br></div><div>A big part =
of the debate around this change is showing that this statement is wrong. &=
quot;Scaling" is not some kind of binary yes/no thing. It's a cont=
inuous effort. You write a system that scales a certain amount, and then if=
you find you need more capacity, you scale it again. Maybe that =C2=A0invo=
lves rewriting the existing code or maybe it just means improving what you&=
#39;ve got.</div><div><br></div><div>Or maybe (painful truth coming up) you=
r product is not that compelling, or times change and your users leave, and=
you discover you never actually need to scale to the giddy heights origina=
lly envisioned.</div><div><br></div><div>A big part of the reason modern we=
b dev is so messed up is that lots of developers starting thinking every ap=
p they built needed to be "web scale" from day one. SQL databases=
? Pah. Doesn't scale. Think big. We gotta no NoSQL sharded key/value st=
ore from the start! Otherwise we're just showing lack of confidence in =
our own product.</div><div><br></div><div>Then when they used up all their =
budget solving consistency bugs a relational database would have avoided, t=
hey notice their competitors sailing past them on a not-fully-scalable but =
certainly-scalable-enough architecture that let them focus on features and =
making users happy.</div><div><br></div><div><br></div><div>=C2=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">I am referring to global bandwidth O(n^2) w=
ith n=3Dusers</blockquote><div><br></div><div>OK. O() notation normally ref=
ers to computational complexity, but ... I still don't get it - the vas=
t majority of users don't run relaying nodes that take part in gossipin=
g. They run web or SPV wallets. And the nodes that do take part don't c=
onnect to every other node.</div><div><br></div><div><br></div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">There can be a case for some increase t=
o create some breathing room to<br>
work on scaling and decentralising tech, I just mean to say that if we<br>
do it in isolation, we're not focussing on the big picture.</blockquote=
><div><br></div><div>Alright - let's agree that we disagree on a few ar=
eas, like the relative desirability of alternative non-blockchain designs -=
but we do seem to agree that there is a case for an increase in the block =
size limit. That seems like progress.</div><div><br></div><div>As you agree=
with that, what sort of schedule and time are you thinking of? (well, by &=
quot;you" I really mean blockstream because it's taking forever to=
try and negotiate with every single person individually).</div><div><br></=
div></div></div></div>
--047d7ba978a0c48e3305188b1004--
|
