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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
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 1V7laf-0000xV-7e
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Aug 2013 12:14:45 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.43 as permitted sender)
client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f43.google.com;
Received: from mail-oa0-f43.google.com ([209.85.219.43])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V7lab-0003Fa-OG
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Aug 2013 12:14:45 +0000
Received: by mail-oa0-f43.google.com with SMTP id i10so6853578oag.30
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 Aug 2013 05:14:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.95.198 with SMTP id dm6mr295887oeb.44.1376050476339; Fri,
09 Aug 2013 05:14:36 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.84.231 with HTTP; Fri, 9 Aug 2013 05:14:36 -0700 (PDT)
In-Reply-To: <CANEZrP24P_m_eWbcs3PJNomG4kFDPUyGE2uQjod9qPmpBS+1mg@mail.gmail.com>
References: <B4D8D241-E758-4806-8B12-C9A78BF1470B@grabhive.com>
<CANEZrP2c6nsf2z5_hKDfHdO1HEJ+Y+aoiSdfYPMxK_jzrvLEow@mail.gmail.com>
<54F09675-D6A7-4415-82F1-920248E8188D@grabhive.com>
<CANEZrP24P_m_eWbcs3PJNomG4kFDPUyGE2uQjod9qPmpBS+1mg@mail.gmail.com>
Date: Fri, 9 Aug 2013 14:14:36 +0200
X-Google-Sender-Auth: 0zeyDVz2mt88_mOf_6LY5oVqNSY
Message-ID: <CANEZrP1XYyO0aspJ-A-0+_pRDKrtaHZrNTjfOnxBGX8Beiw2Xw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Wendell <w@grabhive.com>
Content-Type: multipart/alternative; boundary=089e011606f4d5dcd804e382b78d
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: 1V7lab-0003Fa-OG
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SPV client in pure JavaScript?
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: Fri, 09 Aug 2013 12:14:45 -0000
--089e011606f4d5dcd804e382b78d
Content-Type: text/plain; charset=UTF-8
Oh, I forgot to make it clear - Chrome apps/extensions can make raw TCP
socket connections:
http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.html
You would do it as a packaged app:
http://developer.chrome.com/apps/about_apps.html because then they're a
lot more similar to native apps (they get their own windows, run offline,
etc).
But these aren't standard APIs. They're all Chrome extensions. I doubt
HTML5 will support USB access anytime soon, for instance, but packaged apps
do.
On Fri, Aug 9, 2013 at 2:10 PM, Mike Hearn <mike@plan99.net> wrote:
> Code that runs inside NativeClient has the same access level as JavaScript
> does. It's just a way to do things faster.
>
> Distribution as a Chrome app via the Chrome store is a fine approach, as
> long as people understand it's just an app platform like any other. It has
> pros and cons that must be weighed up. For instance, Chrome for mobile
> doesn't really do apps, at least not at the moment. Also, you're still
> limited by what APIs Chrome exposes, which are a strict subset of what a
> real OS provides.
>
>
> On Fri, Aug 9, 2013 at 2:05 PM, Wendell <w@grabhive.com> wrote:
>
>> Right, I'm not suggesting that we have this wallet in a web app, but
>> rather precisely what you are talking about: using special browser
>> features, and bundling it. I am fundamentally monoculture-opposed, but
>> given Chrome's present installed base, that initial target makes sense to
>> me, provided that we could have a one-click installation (as per normal,
>> via the Chrome Store).
>>
>> Chrome also has this "Native Client" plug-in: I know next to nothing
>> about it, and this goes off the rails of the Subject, but perhaps an SPV
>> implementation there could be a solution to the concerns you expressed?
>>
>> -wendell
>>
>> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>>
>> On Aug 9, 2013, at 1:48 PM, Mike Hearn wrote:
>>
>> > JavaScript is turing complete so of course it can be done. The real
>> question you're asking is, can it be done in a web app? I think the answer
>> is I think "no" because web apps aren't allowed to make raw TCP socket
>> connections.
>> >
>> > Now there may be a way around that by using browser-specific things
>> like extensions or "installable apps" which give your code greater access
>> permissions. This approach means you essentially use Chrome as your app
>> platform instead of a JVM, the assumption presumably being that more users
>> have Chrome than a JVM. The flip side is that users who don't would
>> probably balk at the idea of installing an entire browser in order to run a
>> wallet app, whereas a JVM can be bundled and the resulting app acts like
>> any other. I don't know of a convenient way to "statically link" Chrome
>> into a regular-looking application.
>> >
>> > I personally wouldn't find such a design compelling. Whilst Java isn't
>> exactly a great language, JavaScript is significantly worse in virtually
>> all aspects. I don't understand why anyone would want to use JavaScript
>> outside the browser - you get less safety, less performance, fewer
>> features, less mature tools and so on. If the end result is an installable
>> app like any other, all you did is cripple yourself vs the competition
>> that's using languages/platforms designed for it.
>>
>
>
--089e011606f4d5dcd804e382b78d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Oh, I forgot to make it clear - Chrome apps/extensions can=
make raw TCP socket connections:<div><br></div><div>=C2=A0 =C2=A0<a href=
=3D"http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.htm=
l">http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.html=
</a><br>
</div><div><br></div><div>You would do it as a packaged app:=C2=A0<a href=
=3D"http://developer.chrome.com/apps/about_apps.html">http://developer.chro=
me.com/apps/about_apps.html</a>=C2=A0 because then they're a lot more s=
imilar to native apps (they get their own windows, run offline, etc).=C2=A0=
</div>
<div><br></div><div>But these aren't standard APIs. They're all Chr=
ome extensions. I doubt HTML5 will support USB access anytime soon, for ins=
tance, but packaged apps do.</div><div><br></div></div><div class=3D"gmail_=
extra">
<br><br><div class=3D"gmail_quote">On Fri, Aug 9, 2013 at 2:10 PM, Mike Hea=
rn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blan=
k">mike@plan99.net</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Code that runs inside NativeClient has the same access lev=
el as JavaScript does. It's just a way to do things faster.<div><br></d=
iv><div>Distribution as a Chrome app via the Chrome store is a fine approac=
h, as long as people understand it's just an app platform like any othe=
r. It has pros and cons that must be weighed up. For instance, Chrome for m=
obile doesn't really do apps, at least not at the moment. Also, you'=
;re still limited by what APIs Chrome exposes, which are a strict subset of=
what a real OS provides.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Fri, Aug 9, 2013 at 2:05 PM, Wendell <s=
pan dir=3D"ltr"><<a href=3D"mailto:w@grabhive.com" target=3D"_blank">w@g=
rabhive.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Right, I'm not suggesting that we have this wallet in a web app, but ra=
ther precisely what you are talking about: using special browser features, =
and bundling it. I am fundamentally monoculture-opposed, but given Chrome&#=
39;s present installed base, that initial target makes sense to me, provide=
d that we could have a one-click installation (as per normal, via the Chrom=
e Store).<br>
<br>
Chrome also has this "Native Client" plug-in: I know next to noth=
ing about it, and this goes off the rails of the Subject, but perhaps an SP=
V implementation there could be a solution to the concerns you expressed?<b=
r>
<div><br>
-wendell<br>
<br>
<a href=3D"http://grabhive.com" target=3D"_blank">grabhive.com</a> | <a hre=
f=3D"http://twitter.com/grabhive" target=3D"_blank">twitter.com/grabhive</a=
> | gpg: 6C0C9411<br>
<br>
</div><div><div>On Aug 9, 2013, at 1:48 PM, Mike Hearn wrote:<br>
<br>
> JavaScript is turing complete so of course it can be done. The real qu=
estion you're asking is, can it be done in a web app? I think the answe=
r is I think "no" because web apps aren't allowed to make raw=
TCP socket connections.<br>
><br>
> Now there may be a way around that by using browser-specific things li=
ke extensions or "installable apps" which give your code greater =
access permissions. This approach means you essentially use Chrome as your =
app platform instead of a JVM, the assumption presumably being that more us=
ers have Chrome than a JVM. The flip side is that users who don't would=
probably balk at the idea of installing an entire browser in order to run =
a wallet app, whereas a JVM can be bundled and the resulting app acts like =
any other. I don't know of a convenient way to "statically link&qu=
ot; Chrome into a regular-looking application.<br>
><br>
> I personally wouldn't find such a design compelling. Whilst Java i=
sn't exactly a great language, JavaScript is significantly worse in vir=
tually all aspects. I don't understand why anyone would want to use Jav=
aScript outside the browser - you get less safety, less performance, fewer =
features, less mature tools and so on. If the end result is an installable =
app like any other, all you did is cripple yourself vs the competition that=
's using languages/platforms designed for it.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
--089e011606f4d5dcd804e382b78d--
|
