Jolla Phone has arrived at doublethinkco!

I know I’m a bit late to the party, and that it is November 2015, not November 2013, but my Jolla Phone has arrived in Vancouver!



I had to order the phone indirectly, for delivery to my parent’s house in the UK, and then re-mailed from there.   I have heard some whispers of 3G working for people in Canada, and will report back on whether I can get that going with my Rogers provider, or if I’m tied to 2G.

The company could use some good news, and I hope my purchase and continuing intention to bring Ethereum to Sailfish will raise a faint smile on some weary faces.   A familiar name popped up to help with that process yesterday, with the arrival of Martin Brook (vgrade) who is trying a Sailfish native C++ build in parallel with our ongoing C++ cross-build efforts.  Great to have him helping!

Ironically, getting the Sailfish cross-build working on the Jolla Phone is likely my quickest route to a Tizen Gear S2 version.   Because the whole platform is built for developers, not for dumb consumers!   No GDB on the Gear S2, for example.

Best wishes, Jolla and sailors!

Mobile/wearable test farm takes shape

Laura Kalbag from did me a huge favor recently when she pointed me to the superb DeviceLab from Vanamco.   As a background task I have been putting together a home-based mobile Linux test farm, which I will be using for automated testing of our Ethereum ports.





And all of this is going to sit behind the pfSense box I built, when I finish the OS setup and cabling on that.    I might revisit my wireless router setup at the same time.

So what have I got racked up on those two boards right now?

Left hand board (mainly Tizen)

Form factor Device OS Version
Smartwatch Gear 2 Tizen 2.2.1
Smartwatch Gear S Tizen 2.3.0
Smartphone Samsung Z1 Tizen 2.3.0
Smartphone Samsung Z3 Tizen 2.4.0
Developer phone Samsung RD-PQ Tizen 2.3.0
Smartphone Nokia N9 MeeGo 1.2 (Harmattan)
Developer phone Nexus 4 Sailfish 1.??

Right hand board (a very random selection)

Form factor Device OS Version
Smartphone Nokia Lumia 920 Windows Phone 8.0
Smartphone Geeksphone Peak Firefox OS 1.0
Smartphone Blackberry Z10 BB10 10.0
Smartphone iPhone 3GS iOS 5.0
Smartphone iPhone 5 iOS 5.0
Smartwatch Samsung Gear Live Android Wear 4.4
Smartwatch Apple Watch Sport watchOS 1.0

And what else do I have which isn’t hooked up yet?

Form factor Device OS Version
Developer phone Samsung TM1 Tizen 2.4.0 Beta
Smartwatch Samsung Gear S2 Tizen 2.3.1
Smartphone Meizu MX4 Ubuntu Edition Ubuntu Touch ??.??
Smartphone Jolla Phone Sailfish 2.0
Tablet Jolla Tablet Sailfish 2.0
Tablet Nexus 7 Android  ?
Tablet Samsung Tab S Android  ?
Tablet iPad 3 iOS ?
SBC Raspberry Pi Raspbian ?
SBC Odroid-XU4 Tizen 3.0
SBC Intel NUC Tizen 3.0

And completely unrelated to this effort, I also have my Commodore 64 and Atari VCS to get connected!



We got on screen at #devcon1 on the final day

Many thanks to John Gerryts for crediting Anthony and myself as contributing to EthEmbedded project, as shown on the “DEVgrants Update” slides at the Ethereum devcon1 conference today.

We got on-screen!   Somewhat over-credited as part of the EthEmbedded team, but we’ll take it 🙂


It was fantastic to hear of the additional $100K funding from Omise.   We will be applying for a grant for our cross-compilation and porting work 🙂

Porting Ethereum – geth running on Samsung Gear S2 smartwatch. eth coming soon

Back in early June of this year I made a build of ethereumj-android on my Mac, ran it on my Samsung Galaxy S6 and made a video which was pretty popular on the Ethereum sub-reddit at the time:

That was just my first step on a journey towards a Light Client for the Samsung Gear S2 smartwatch (and various other mobile/wearable Linux devices).


That aim has come closer to fruition this week, with a working (full node) geth on device, and getting an eth executable on device.   We’re still working through runtime issues on the eth executable, but it’s very close now.

Nearly all of the credit for geth porting lies with Péter Szilágyi and his majestic xgo CGO cross-compilation solution.   We really didn’t have any work to do on geth itself.   There is still a sporadic crash to chase, but it’s workable.


The block-chain download is slow on the smartwatch, but the main issue is storage space, with only 4Gb of on-device storage.   The Morden test-network fits, but the Frontier main network is already too big.   There is no big surprise here.   The need for a Light Client is the motivator this whole project, but getting the full client working on device is a good step in that direction, because the infrastructure is now ready and waiting for the Light Client protocol to take shape.   Geth is particularly important to get working, because it is the Ethereum client which will get Light Client support first.

While it is great to see a working client on-device, the larger progress which we’ve made which is on the cusp of completion is adding cross-compilation support for eth, the C++ client.   Having C++ cross-compilation is critical for resource-constrained platforms which cannot support compilation on-device.   The performance and universal reach of C++ will also be very important in bringing Ethereum to the very smallest IoT and embedded platforms.

Anthony Cros is sub-contracting for doublethinkco, and has done 90%+ of the work.  The C++ side has been quite the battle!    I’d just like to publicly thank Anthony for all of the blood, sweat and tears he has poured into this work over the last couple of months.   I know he will be very happy and relieved when we get eth running 🙂


Tizen has been a test-case for us, because it doesn’t support native compilation even on mobile, let alone wearable.   We tried to get that working, but it was a dead-end.   So then we flipped to cross-builds, first on the TM1 developer phone, and then just in the last days on the Gear S2 itself.


The cross-compilation support consists of:

So it looks like this porting tangent has gone much as I expected it might when we started on it just under two months ago.   We will continue to work with EthEmbedded and SlockIt to ensure that the C++ cross-builds are working for all platforms of interest, and to get the cross-build support upstreamed.   We’ve not started on Sailfish OS and Ubuntu Phone ports, but they will be very similar to Tizen, and may even “just work”.

After that, I hope that we can make some more direct contributions towards the Light Client implementations, starting with geth as Zsolt described at devcon1 yesterday:

Screen Shot 2015-11-13 at 12.20.58 AM

When those come to fruition we can all go and build some cool DAPPS for smartwatches and the 50 billion smart-devices which allegedly will be making their way into the world by 2020.

For months, I have been trying to push in the direction which SlockIt teased and delighted us all with a devcon1 today – bringing block-chain technology to small Internet-connected devices:

Wearables, IoT, smart-devices, embedded systems.   We are heading into a very connected future.   I want that future to be decentralized and under our control.

Hold on to your hats!   We’ll be there soon 🙂

Porting Ethereum – Tizen cross-builds. Update by Anthony Cros, 5th November 2015


We are still working on 2 fronts in parallel, the webthree (C++) implementation (formerly known as cpp-ethereum) and the go-ethereum (Golang) one.

go-ethereum (Golang)

Block synchronization problem

Not much progress on that front beside confirming an issue that seems to occur with ARM builds regarding block synchronization (see previous post). It seems other people have reported the same issue and hopefully the devs will figure it out soon.

LES sub-protocol (light client)

We are also waiting for the LES sub-protocol to be finished, which according to the latest update (see “Light client/mobile” section) is making good progress.

web-three (C++)


A lot of work has been put into cross-compiling the C++ implementation, and after a lot of sweat I finally produced a binary to test out! Unfortunately it results in a good o’ segfault for the moment. I have informed the devs of it and am waiting for their feedback. It may be an issue with the CryptoPP library, which is actually due for removal (see Gavin’s comment on the matter).


We are making the process of producing this binary open for anyone to try out (see our Github repo).
There exists a Dockerfile that can be used as basis, although it is not finalized yet. Still, a basic Ubuntu 14.04 image to which the packages listed in the Dockerfile are added should provide the right environment to run the scripts above.


I have also spent some time on improving upon the devs’ representation of the various dependencies involved in building eth. I started from the original DOT file:
and added information I gathered from compiling from source myself as well as various comments from the devs:


which results in


It is still a work-in-progress but we will hopefully have a good overview of all these dependencies soon.

Stay tune for more progress!

Porting Ethereum – Tizen cross-builds. Update by Anthony Cros, 14th October 2015

NOTE:   You can follow along with our day-to-day progress on the Ethereum Porting Gitter channel.


Some progress! On both fronts: go-ethereum and cpp-ethereum.

Our efforts lately have been focused on cross-compiling these two projects targeting an ARM architecture.


The easier one first. As Bob mentioned in his latest post, Péter Szilágyi from the go-ethereum team has created the great xgo tool, that allows cross-compiling go-ethereum to different platforms (though it is not limited to cross-compilation for Ethereum, it is a general tool).

Using xgo and the instructions from its README file, I was able to generate a binary for geth quite easily and without any change (xgo notably leverages the power of Docker).   I was then able to run this binary on a Samsung TM1 developer phone (with Tizen O.S.), a process I will detail in an upcoming post. The binary worked well up until a point during block synchronization (~block 90K) where it failed, though nothing indicated it was an issue with the platform itself (more likely the particular version of geth I had used for compilation). I will rebuild and report on the result soon!

tony:~/tizen-sdk/tools[130] $ ./sdb push ~/.tony/program/go/go1.4.2/bin/geth-linux-arm /home/developer
pushed geth-linux-arm 100% 19MB
1 file(s) pushed. 0 file(s) skipped.
/home/tony/.tony/program/go/go1.4.2/bin/geth-linux-arm 4142 KB/s (20639213 bytes in 4.865s)
tony:~/tizen-sdk/tools[0] $ ./sdb shell
sh-4.1$ cd /home/developer/
sh-4.1$ ls
geth-linux-arm testupload.txt
sh-4.1$ ls -l
total 20160
-rwxr-xrwx 1 developer developer 20639213 Sep 29 18:49 geth-linux-arm
-rwxrwxrwx 1 developer developer 0 Jul 3 16:55 testupload.txt
sh-4.1$ ./geth-linux-arm
Disclaimer of Liabilites and Warranties


Do you accept this agreement? [y/N] y

I1004 23:21:26.410705 9630 flags.go:414] WARNING: No etherbase set and no accounts found as default
I1004 23:21:26.411956 9630 database.go:71] Alloted 16MB cache to /home/developer/.ethereum/chaindata
I1004 23:21:26.454467 9630 database.go:71] Alloted 16MB cache to /home/developer/.ethereum/dapp
I1004 23:21:26.475128 9630 backend.go:291] Protocol Versions: [62 61], Network Id: 1
I1004 23:21:26.476165 9630 backend.go:333] Blockchain DB Version: 3
I1004 23:21:26.480377 9630 chain_manager.go:248] Last block (#0) d4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3 TD=17179869184
I1004 23:21:26.546630 9630 cmd.go:125] Starting Geth/v1.2.0/linux/go1.5.1
I1004 23:21:26.547729 9630 server.go:311] Starting Server
I1004 23:21:26.568572 9630 udp.go:207] Listening, enode://95b46a352806ebd5e97ec6bdcdcb9ea425eed48c95f78963df264c9985cba1aa72c658482951025322a8db49b88ae3eeb2314a0995df8d636de0276259bdaa5b@
I1004 23:21:26.569580 9630 backend.go:559] Server started
I1004 23:21:26.570892 9630 ipc_unix.go:109] IPC service started (/home/developer/.ethereum/geth.ipc)
I1004 23:21:26.571563 9630 server.go:552] Listening on [::]:30303
I1004 23:21:26.574707 9630 nat.go:111] mapped network port udp:30303 -> 30303 (ethereum discovery) using NAT-PMP(
I1004 23:21:26.588775 9630 nat.go:111] mapped network port tcp:30303 -> 30303 (ethereum p2p) using NAT-PMP(
I1004 23:21:36.715515 9630 downloader.go:275] Block synchronisation started
sh-4.1$ pwd
sh-4.1$ find
sh-4.1$ find -type f | tr "\n" "\0" | du -cs --files0-from=-
1392 ./nodes/000001.log
4 ./nodes/LOCK
8 ./nodes/LOG
8 ./nodes/MANIFEST-000000
8 ./nodes/CURRENT
8 ./nodekey
8 ./chaindata/LOG.old
8 ./chaindata/MANIFEST-000008
4 ./chaindata/LOCK
1892 ./chaindata/000010.ldb
8 ./chaindata/LOG
8 ./chaindata/CURRENT
892 ./chaindata/000007.log
4 ./dapp/000002.log
8 ./dapp/MANIFEST-000003
8 ./dapp/LOG.old
4 ./dapp/LOCK
8 ./dapp/LOG
8 ./dapp/CURRENT
4288 total


Much more manual work here, but after much struggle I was able to successfully cross-compile the libweb3core library. I created a set of scripts that should allow anyone to reproduce this process (in fact please do and report on any issue encountered!).
For it to work, I had to use a number of hacks along the way however:

  1. code – Hardcoding Boost‘s project-config.jam file to use my gcc cross-compiler (I tried many different flags/environment variables for but none ever worked/were picked up)
  2. code – Commenting out the CXXFLAGS-march=native flags from CryptoPP‘s Makefile. Likewise I found no cleaner way to unset this flag (which you must for it to succeed).
  3. code – I was never able to get the ARCHIVE_INSTALLS_DIR flag to get picked up during configuration for JsonCpp, instead having to rely on DESTDIR during the installation phase (not necessarily a big issue, but still frustrating)
  4. I ended up having to create a ~/$HOME/cryptopp symlink to CryptoPP’s installation directory for libweb3core‘s CMake file to be able to detect CryptoPP’s headers, no other combinations ever seemed to work. This on top of making CMAKE_INCLUDE_PATH point to the source directory. Removing either results in a failure to detect said headers (note that no such issue occured for the detection of the library itself).
  5. code – Disabling of MiniUPNP, which has apparently broken backward compatibility in its latest version and for which I wasn’t able to find a working version (typically because of failure to include upnp-dev.h, which would have also required hacking their CMake file).
  6. code – Removal of erroneous -lOFF artifacts from the CMake configuration phase of libweb3core, a bug I have brought to the attention of the cpp-ethereum team.

If anyone is aware of workarounds for these or can even suggest a more straighforward/correct way of getting to the same result, please contact me on gitter.

So overall it’s quite a lot of pieces that need to work together in order to create such a binary. Next step will be building other necessary components for eth to run. After which I will hopefully be able to test the C++ client on the same Z3 phone!

Stay tuned for more progress!

Porting Ethereum – Native build on Tizen emulator (dead-end) – by Anthony Cros

So as Bob mentioned in his yesterday’s update, I tried to build natively on the Tizen emulator (available as part of their SDK). Unfortunately this proved to be an dead-end (see the full story below).

We still thought we’d describe what our process was, as that might help someone down the road and/or convince the Tizen people to make this process possible in the future. After all it’s a pity to have a Linux flavor that can’t build anything natively… Why not stick to Android then?

So first step is installing the SDK (network install or local image-based install, either are fine).

This basically creates 3 folders (assuming a *NIX-based system here):

  • ~/.installmanager_2.3.1
  • ~/.tizen-sdk-data
  • ~/.tizen-sdk

The last one is the most interesting one. The first two are essentially there for storing logs of the SDK installation and the emulator data and logs. The tizen-sdk dir (A.K.A SDK_PATH in scripts) is a pretty massive folder (~6GB), which contain files for the emulator, IDE (Eclipse spin-off) and libraries/toolchains for the various platforms and architectures.

The emulator can be found under ~/tizen-sdk/tools/emulator, and the bin/em-cli in it is what I used to get the emulator running (note that there’s also a UI in it, but it died on me consistently). So with it you can do a few interesting things:

  • ./em-cli list-image, which lists the base images available: x86-standard / mobile-2.3.1, x86-circle / wearable-2.3.1, x86-standard / wearable-2.3.1
  • ./em-cli create [...], to create such a VM (see below for details)
  • ./em-cli launch [...], to launch VMs
  • ./em-cli delete [...], to delete VMs

Note that em-cli -h gives you all the actions possible, while em-cli -h <ACTION> gives you help on a specific action (e.g. em-cli -h create)

So you can create a VM called mytizenvm like so:

./em-cli create -n mytizenvm --base-id 2

The value for --base-id corresponds to the ID field from the list-image command above, in this case corresponding to x86-standard / wearable-2.3.1 (ID 2). This should return Success: To create new Virtual Machine is completed. (sic). The data is stored under ~/tizen-sdk-data/emulator/vms/mytizenvm by default (where you’ll also find logs).

The content of ~/tizen-sdk-data/emulator/vms/mytizenvm is as follow:

$ file *
logs:                    directory 
emulimg-mytizenvm01.x86: QEMU QCOW Image (unknown version)
swap-mytizenvm01.img:    QEMU QCOW Image (unknown version)
vm_config.xml:           XML document text

So really just a QEMU image and a config file.

Next up is launching the VM:

./em-cli launch -n mytizenvm

You can see the logs under ~/tizen-sdk-data/emulator/vms/mytizenvm/logs. By now you should see something like this pop up on desktop environment:


Note that the button on the right-hand side is clickable and that right-clicking on the watch image itself gives you access to a contextual menu. Also, closing the watch cleanly has never worked for me, I always had to Force Close it (in Advanced sub-menu of the contextual menu).

From here, we want to open a shell in order to access the emulated device: use the Shell option in the contextual menu, this will pop-up your default terminal (gnome-terminal in my case). Tadah! You are now in the Tizen system.

On it:

  • you are the developer user, whose home dir is /home/developer
  • you can become root: su - root
  • you can setup a shared directory with your “host” machine (the one you started the emulator with), by default under /mnt/host on the device (right-click> Control Panel > Device Manager > Host Directory Sharing). Note that the /mnt/host is owned by the system user.
  • you can see what ports are open: netstat -tulpn
  • you have access to a few very basic binaries under the usual bin folders (see echo $PATH for complete list)

But in order to build either geth or eth, ones needs to… be able to build in general! And this is were things get rough. There is no make. So we should try and build it! But… there’s no gcc to build it either! So we need to build gcc itself… So it means having to go through these steps.

There is also an rpm binary available however, and holds many RPM files. I poked around at it but was unable to get anything useful out of that binary (it lacks both -bb and --rebuild options for one thing).

So at this point, I decided to get help on the Tizen forum, and Bob pinged one of his contact on the Tizen side. And then we were basically adviced to give up that route and to stick to cross-compilation (see Tizen native builds section of Bob’s post for the specific answer).

So now… off to cross-compilation wonderland instead (luckily the SDK setup will be useful here as well)!

Porting Ethereum to mobile Linux

02 hotel porter_std

Last week the ETHDEV team made the decision to implement Ethereum Light Client as a sub-protocol, rather than as part of the main protocol.   The decision makes sense, to manage risk, and to separate concerns, but it delays things.   Probably by about “two weeks”.

It is going to take some time for the dust to settle and for the client implementations to get back to working proof-of-concept on that still-to-be-defined sub-protocol.   So Anthony and I are going to go off on a tangent for the time being, and focus on porting the existing full-node clients (both eth and geth) to all of the mobile Linux platforms of interest.

A new Ethereum Porting Gitter channel has been created, which I have written this “state of play” article for.

We are going to work on the following platforms and devices:

Form factor Device OS Version
Developer phone Samsung RD-PQ Tizen 2.3.0
Smartphone Samsung Z1 Tizen 2.3.0
Smartwatch Samsung Gear S2 Tizen 2.3.1
Developer phone Samsung TM1 Tizen 2.4.0 Beta
Smartphone Samsung Z3 Tizen 2.4.0
Smartphone Jolla Phone Sailfish 2.0
Smartphone (future) Intex Aquafish Sailfish 2.0
Tablet (future) Jolla Tablet Sailfish 2.0
Smartphone Meizu MX4 Ubuntu Edition Ubuntu Touch ??.??

John Gerryts has been doing a very similar task for the last few months as part of a DEVGrant for EthEmbedded.   His focus so far has been on compiling on-platform.   This challenge has mainly laid in broken dependencies and in working through oddities in the specific platforms.   The SBCs are all “just” Linux distros.

Mobile operating systems are rather different beasts than the capable little general computers which John has been porting Ethereum to.   Mobile devices have usually been designed for running applications on, not building and developing applications on.   There has been a major asymmetry between the power and specifications of desktop machines and mobile devices.  There still is some asymmetry, but the gap is closing fast.

You don’t develop iOS applications on an iPhone.   You develop them on a Mac with a cross-compiler.    You don’t develop Android applications on an Android phone.   You develop them on a PC, Mac or Linux box with a cross-compiler.   Most mobile devices have never had enough memory or processing power to build anything substantial.    The setup has been very similar to that which I have used for the majority of my professional development career building PlayStation and XBOX games.   You develop on a desktop machine and build binaries to transfer to the target machine and then use a remote debugger.

That time is coming to a close.   We are seeing a convergence across all device form-factors.   All computing devices are good now.   They nearly all have multiple cores, decent amounts of memory, network connectivity, ARM or x86 SoCs and are all much-of-a-muchness in their “form”.    There isn’t much reason left why you wouldn’t use your phone for software development, or even your watch in a few years time.   I want to push the envelope on that, which is why I asked Anthony to start with looking at native builds on these devices.    That didn’t work so great for Tizen, and he will blog about that, but it looks to be a workable approach for Sailfish and Ubuntu Touch, which are very “normal” Linux distros.

Tizen native builds

Raster says:  Tell him to cross compile.  Tizen 2.x on things like emulator is for running tizen apps and nothing more.   You will not fix tizen 2. All devices locked down. No root for you.  You could cross build a toolchain for $home  But you will need magic to get headers and other things working in home when the bins are in usr.  But rpms won’t help you. You need root.  Emulator not useful as its x86.  So you get gcc on it. Fine.  Bins you make won’t work on any shipping tizen device (worth noting).   Rpi2 or other boards are a better bet imho

Sailfish native builds

Carsten Munk says: I’d for most purposes recommend a chroot on the device for compilation. you can for most intents and purposes take the ARM target of sailfishos and chroot into it on device. we have a couple of funny package dependencies that if you start developing a little too hard, device won’t boot up, so 😉

Ubuntu native builds

Niklas Wenzel says: Every program available in the Ubuntu archives for the armhf architecture can be run on your phone (though you are going to run into issues with GUI programs). I’ve been compiling my stuff on my phone for quite some time now.  However, the cross-compilation setup for Ubuntu SDK apps is really straight forward and way more comfortable than any compilation on the phone itself.  Additionally, installing additional debian packages on the phone requires a writable system image which means that your phone can break when you install OTA updates in the future. (To prevent that, you can reflash the phone to its previous state with a read-only system partition but that also means that the additional packages you installed will be removed from the phone again.) You could also set up a chroot on the phone for compiling stuff though.

Cross-compilation of geth and eth.

Péter Szilágyi who works on Ethereum is also the author of xgo and has put together Wiki pages on Cross-compiling Ethereum and Ethereum on Android, as well as adding cross-compile targets into the go-ethereum makefile for us today.   That is all cross-compilation for go.   Niklas Wenzel was also kind enough to point us at his template for Go QML cross-compilation.

Cross-compilation of C++ for the eth client will be much simpler, given that C++ cross-compilation is the default for all of these mobile Linux platforms.

So lots of work to do.  Anthony is digging in.    When we have got everything working to the degree in which that is possible (native/cross * eth/geth * Tizen/Sailfish/Ubuntu) plus a few OS version variants, we can move on to look at where we are sitting compared to John’s SBC builds.    Hopefully we can get all of this work into some cohesive whole and maybe even upstream it all into the main C++ and go client repos.   We will see 🙂

I also want to set up an automated build farm for all of this hardware, using real devices, not emulators.   And maybe we can even do some automated testing too.

When all of that is done, I hope we will be ready to go with actual Light Client code-paths within those applications we can now build for so many different platforms.    We should also look at in-process execution for the go codebase (as already exists with libethereum) for inclusion within applications and on small IoC devices.

Stay tuned!

Go for mobile Linux platforms

In parallel with Anthony’s hands-on work digging into the protocols and the go and C++ client codebases, I have started investigating options for bringing the go codebase to new platforms.

The recent Go 1.5 release added support for Android and iOS.    There is a gomobile tool which can be used to generate Java and ObjC binding for go packages for integration into existing native applications, or to build standalone APK and APP files based on a generic application framework, for pure go applications on mobile.

At first, I thought it would be necessary to extend this support to include C++ code generation to bring go to mobile Linux platforms, but I am now of the opinion that just building the existing go client for these mobile Linux platforms might actually be entirely adequate – treating them purely as other Linux distros, rather than specifically as mobile platforms.   At the time of writing, that would result in full-node clients, but would be the basis for light client when that “mode” is available.   It would not support in-process go light-clients, but that isn’t currently a supported scenario anyway.

So … I will get going to compiling the go client for the various mobile Linux platforms (Sailfish, Tizen and Ubuntu Touch) which we are targeting.  The go client has been ahead of the C++ client for light client, and ultimately I think we are going to want both implementations (and more – Python, Java, Javascript) on all platforms they can reach.

I will be leaning on the work already done by EthEmbedded, because our mobile/wearable platforms are very, very similar to those embedded platforms – even sharing the exact same SoCs in some cases!

Ethereum Light Client update, Wednesday 9th September (by Anthony Cros)

Hi everyone,

Another update, since quite a lot has changed since last time!

The go-ethereum team is now actively working on a first version of light clients.  I guess that first version will handle the simplest uses cases, i.e. not taking part in securing the network.

cpp-ethereum devs have also mentioned on the newly created Ethereum Light Client Skype channel that they expect the newer protocols to be added to the C++ codebase within a few weeks (this will be needed for them to start working on light client capabilities).

In light of these changes, we are now offering our help to the go team to help speed up the development in any capacity we can. I had a Skype session with Zsolt Felföldi who is in charge of this task, and we agreed that if there was anything he could reasonably delegate to me, I would take it over (I’m now quite familiar with that codebase).

But as the The Mythical Man-Month posits, it may actually best to watch from the sideline until we can participate more efficiently.  Either way, all this is good news for those of us excited about light client support!

Stay tuned for more news in the weeks to come…