RouteMaster: Recovering Blockchain Wallets via Physical Location

Last weekend, Yin Yee and I went to the Blockchain Hackathon at Huckletree.  The theme (in case you couldn’t guess) was blockchain, and there were 2 challenges each with 3 tracts:

  1. Global Citizenship
    1. Encrypted Key Re-connection
    2. Bio Identity ‘Access Recognition’
    3. Data Sovereignty
  2. Consuming Digital Objects
    1. Digital Ownership Tracking
    2. Consumption – Access Control
    3. Monitoring Digital States

I was interested in working on the first challenge, as how to define identity is an interesting question.  It also felt to me that, for the second challenge, any Digital Rights Management (DRM) system would have to be centralized, and this would weaken a key value of blockchain: decentralization.  Indeed, most of the projects for the second challenge focused on trying to make consumers more honest by improving transparency rather than by securing media.

My only prior experience with blockchain was at a Fintech hackathon in November 2015, where we built Credit Passport, a service to allow you to securely share your financial history with credit providers to help preserve your credit rating when moving between countries.  We used Colu (which at the time was aiming to be a blockchain-secured data store, much like IBM’s Hyperledger) as a store, and so we didn’t need to get too involved in the details of blockchain technology itself.

…which all meant this hackathon was a great opportunity to learn!

(Yin Yee had much more experience with blockchain, having designed and built a cryptocurrency for her masters’ thesis and worked for a blockchain startup.)

Routemaster buses, after which our team was named

On Saturday morning, Peter Jones pitched an idea around checking in at a series of real-world locations to take back control of a wallet for which you’d lost the key – the clever thing here was that we were bootstrapping blockchain security from existing real-world physical security – for example, it would be relatively hard for a hacker to both get into my home and into my office at work.  Hanson Aboagye joined Yin Yee, Peter and me to form the “RouteMaster” team.  We spent quite a while brainstorming and ramping up on Ethereum (a blockchain for smart contracts).  Eventually, at about 15:30, we settled on building

  • an Ethereum smart contract that could
    • store your Ether cryptocurrency and make transactions if requested to by its current “owner”
    • store a list of locations that its owner regularly visited
    • change owner if a new user logged into the same list of locations and the previous owner stopped logging in
  • an Android client that
    • stores Ethereum account details
    • allows the user to make payments
    • allows the user to check in at locations, detected via Bluetooth Low Energy (BLE) beacons
  • a Raspberry Pi 3-based beacon that
    • broadcast its identity, IP address and an ever-changing random token over BLE
    • accepted HTTP requests from the Android client to check in on the user’s behalf (checking the random token to ensure that they were local).

That was the idea.  We ran into a few problems along the way.

  • The Android Bluetooth Low Energy stack seems to be a little unreliable – even using well-rated apps from the Google Play store, some phones would sometimes stop detecting BLE beacons while others could. We tried power-cycling and clearing the cache but to no avail. In the end, this was the thing that stopped us demonstrating the full flow.
  • Ethereum nodes need to download quite a lot of data to synchronize the blockchain. This is understandable, but with everyone at the venue trying to use one blockchain or another and (presumably) using a lot of network bandwidth, the initial synchronization was quite slow.
  • This was our first time developing in Solidity – the language in which Ethereum smart contracts are written – and so we wrote a few bugs (and wrote contracts that used a lot of gas, i.e. Ethereum compute cycles). Thanks to Nick from Ethereum (on the Colour Card team) for answering our beginner questions!
  • We found a documentation bug that it took us a while to debug, which stopped us from unlocking multiple accounts for RPC API access. Once we raised it, though, it was fixed very quickly – thanks to bas-vk for the fast turn-around!

The presentations were 15 minutes long, which was much longer than I’m used to – 2-3 minutes is more common, and TechCrunch Disrupt London Hackathon in December last year was just 1 minute per team! However, many of the presentations included some pretty detailed explanations of the protocols and algorithms used, so there was plenty to cover.

We were the penultimate team to present.  Peter talked about the business case and then we dived into the demo.  Unfortunately, our demo script was pretty complicated, and we made a mistake so couldn’t show everything – at least our code didn’t let us down this time!

We were very surprised to win second prize given how strong the other teams were! Congratulations to all the other winners, thanks to the sponsors and organizers for making it happen and all the other teams for their energy, enthusiasm and knowledge – it was a great experience and I learned far more at this hackathon than many I’ve been to!

The source for both the Android client and the Raspberry Pi-based server are up at

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s