SPV client in pure JavaScript?
10 messages, 9 to 13 Aug 2013. Started by Wendell.
Wendell (4), Mike Hearn (3), Jeff Garzik (2), Chris Double
To those of you in the know about modern browser tech:
Does it seem at all conceivable that an SPV wallet could be built entirely in JavaScript? And if indeed it is within the realm of the possible, how would such a thing be safely distributed for use? Would a signed Chrome Plugin be an ideal vehicle?
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
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.
On Fri, Aug 9, 2013 at 1:32 PM, Wendell <w@grabhive•com> wrote:
Quoted text (25 lines)
> To those of you in the know about modern browser tech: > > Does it seem at all conceivable that an SPV wallet could be built entirely > in JavaScript? And if indeed it is within the realm of the possible, how > would such a thing be safely distributed for use? Would a signed Chrome > Plugin be an ideal vehicle? > > -wendell > > grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 > > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >
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:
Quoted text (5 lines)
> 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.
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:
Quoted text (40 lines)
> 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. >
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:
Quoted text (55 lines)
> 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. >> > >
"Packaged app pages always load locally. This allows apps to be less dependent on the network. Once a user installs an app, they have full control over the app's lifecycle. Apps open and close quickly, and the system can shut apps down at any time to improve performance. Users can fully uninstall apps."
Does this mean that upon install, a nice, icon-emblazoned package will drop into my /Applications folder on a Mac, or in my Windows Start menu, etc... Or are packaged apps always launched and maintained from within Chrome itself?
Provided that the technical stuff could be made to work within the context of the more limited API, this certainly seems like an interesting, user-friendly way to distribute a Bitcoin wallet!
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
On Aug 9, 2013, at 2:14 PM, Mike Hearn wrote:
Quoted text (7 lines)
> 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 7:32 AM, Wendell <w@grabhive•com> wrote:
Quoted text (3 lines)
> To those of you in the know about modern browser tech: > > Does it seem at all conceivable that an SPV wallet could be built entirely in JavaScript? And if indeed it is within the realm of the possible, how would such a thing be safely distributed for use? Would a signed Chrome Plugin be an ideal vehicle?
Certainly. BitPay is working on such a wallet: https://github.com/jgarzik/wally
wally uses node.js JavaScript, and not browser JavaScript, so not exactly what you're talking about...
No, it's not -- but that's certainly very cool to see Jeff.
How is BitPay going to put this to use?
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
On Aug 9, 2013, at 3:08 PM, Jeff Garzik wrote:
Quoted text (5 lines)
> Certainly. BitPay is working on such a wallet: > https://github.com/jgarzik/wally > > wally uses node.js JavaScript, and not browser JavaScript, so not > exactly what you're talking about...
On Fri, Aug 9, 2013 at 1:58 PM, Wendell <w@grabhive•com> wrote:
Quoted text (3 lines)
> No, it's not -- but that's certainly very cool to see Jeff. > > How is BitPay going to put this to use?
Well, "wally" is just a demo application, a command line client to prove a technology.
The main development is in places like "node-libcoin", where a wallet platform is being developed. While maintaining a strong commitment to the blockchain engine side of bitcoind, BitPay has enterprise wallet needs that do not necessarily mesh well with the standard bitcoind wallet. Multi-sig, P2SH and other advanced features are key to the future use of bitcoin in large enterprises. Managers, CEOs and other functionaries at a corporation may each have their own wallets / keyrings, and cooperate to sign large value, high security bitcoin multi-sig transactions, for example.
On Sat, Aug 10, 2013 at 12:14 AM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (4 lines)
> 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
There's a Raw Sockets proposal at the W3C that provides TCP sockets:
<http://www.w3.org/2012/sysapps/raw-sockets/>
Firefox OS has an API that is being discussed as part of that:
<https://developer.mozilla.org/en-US/docs/WebAPI/TCP_Socket>
So there's a possibility of a standardized approach in the future.
Chris.