The New York Bitcoin Residency

18 November 2020James Isaac

At the end of 2018, I was fortunate enough to be invited to participate in a Bitcoin Residency, taking place over the course of a week in Manhattan, New York.

New York City

Many thanks to Chaincode Labs for making this possible; organising everything from an excellent venue and line-up of speakers/mentors, to flights and accomodation.

Having had a persisting interest in Bitcoin for several years prior (including building a mining rig back in 2013), being able to dive into the heart of it – developing directly on top of it, and meeting some of Bitcoin's core developers – was a fascinating and unforgettable experience.


To get more into the specifics, the residency was focused around app development on top of Bitcoin's rapidly evolving Lightning Network.

You may have heard the oft-repeated (yet ill-informed) criticism of Bitcoin that it can't ever scale, as the blockchain is limited to 7 transactions per second, with core developers having no interest in raising the block size. Anyone who follows Bitcoin development, knows this viewpoint is several years out of date, as this is where Layer 2 solutions (with Lightning Network being the most popular) come in.

The premise behind Layer 2 solutions is a belief that it's actually beneficial to keep the main chain (Layer 1) as small as possible. Not every single purhcase of coffee needs to be immutably stored on a globally distributed ledger, replicated for eternity. This strict stance on keeping the chain small (in the past years, not letting it grow much beyond the initial 1MB per 10-minute block) has meant it's still entirely feasible for anyone around the world to participate in the Bitcoin network on standard home hardware, able to mirror the entire blockchain (around 300GB as of today) and independently verify the entire history of transactions back to the genesis block.

Following this idea that space on Bitcoin's base layer is scarce, and limited to the most important transactions via a fee market (tying in to Bitcoin's growing narrative as a store of value, or digital gold), a solution is still needed for small transactions, or even microtransactions, which shouldn't pollute limited blockchain space.

The ingenuity behind Bitcoin's Lightning Network, is it manages to achieve the best of both worlds, in a way that seems almost too good to be true. Lightning transactions happen off-chain, in a way that's practically instant, feeless, and untraceable, yet still maintain trustless, decentralised security, backed by participants' Bitcoin private keys.

To give an (overly simplified) idea of how this is possible: an incredibly smart application of game theory allows two participants in the Lightning Network mutually hold signed transactions ready to commit to the main chain, if and only if their partner reneges on the agreed rules of the Lightning protocol. This exchange of contracts is designed in such a way that both parties come out best by simply following the rules, meaning none of this ever has to go on the main chain. Seeing as this is all done programmatically, highly automated use-cases for money which were never before possible – even the real-time "streaming" of money (many transfers of updated contracts per second) are unlocked.

Now that you've heard some of the technical details which had me excited about Lightning's development, and quick to jump at the opportunity for this residency, I'll take a short detour to talk more about the trip itself.

This was my first visit to the US's East Coast, and only a year after my first visit to the US altogether – San Francisco and LA a year earlier. So naturally I excited just to visit New York (and other parts of the US too, as my wife and I were able to extend our stay by a few more weeks).

I was fairly blown away by the city itself. A fan of architecture around London, particularly its skyscrapers, New York felt like what I was used to seeing on a much bigger scale. The raw vastness and density of the city was incredible.

A personal favourite of mine was the recently topped-out 432 Park Avenue. Seeing it in person really drove home how supernatural its proportions are.


Returning to the residency. I was one of a dozen developers selected to participate – the organisers brought together an impressively diverse range of technical skills and backgrounds. Quite importantly, experience developing on Bitcoin was not a requirement, as that's what the residency was aiming to bring us up to speed on.

The structure was a week of learning and building -- each day divided into a morning of talks from those involved in the Lightning Network ecosystem, and an afternoon of independent building.

Christian Decker giving a talk on Lightning Network

Each of us had pitched our idea for an app that makes use of Lightning Network's peer-to-peer payments, and had the goal for the week of developing it to a point where we can present it on Friday afternoon.

My project idea was Nanomeet, a tool allowing event organisers to collect payments at events without the overhead of dealing with credit cards or cash. The use-cases were fairly diverse, ranging from something as simple as returning the money for cinema tickets when seeing a film with friends, to something that could be used at a larger event like a conference with a wide inventory of products/experiences/services able to be paid for via the website.

The vision was compelling:

  • No infrastructure needed for organisers or attendees, beyond a Bitcoin wallet app on their phone.
  • No involvement of banks (unlike using credit cards) or other large centralised payment processors (unlike using apps like PayPal).
  • Transactions which are practically instant, and with negligible fees (fractions of a penny), thanks to Lightning Network's innovations.
  • Easy for the organiser to keep track of purchases, as they can see the history of transactions (unlike cash).

Putting together a prototype for this in five afternoons was certainly a challenge, but the energy brought into the workspace, and having those who gave talks on hand to help with problems, created a highly enjoyable and productive space.

Getting started on the implementation, one of the big challenges that became clear was that, due to how new the technology we were working with was, we were building at a very low level. Managing Lightning Network nodes and the channels between them manually was quite an involved and delicate process. The struggles most attendees had with this even prompted one of the speakers, Bitcoin core developer Christian Decker, to spend the week building a tool that automated much of the setup of a test Lightning Network.

Without having dug deep into LN, I'd have found it hard to imagine why it's taking multiple years to become a user-friendly and widely adopted system. But having seen the complexity by working closely with it and the related Bitcoin protocols, it becomes clear how much surface area needs to be covered to have truly thriving ecosystem, and how many layers of software are really necessary. The analogy has been done to death, but I do think there's merit in seeing Bitcoin/LN as it is today, like the Internet was in the early days. So much of what we take for granted on the web today, and can trivially build on top of, would have seemed like a pipe dream in the late 90s.

Despite having so much ground to cover in getting myself up to speed with developing against LN, I was able to put together a presentable app by the end of the week. You can watch my presentation below:

So, did I launch Nanomeet as an app you can use today? Unfortunately not.

As touched on towards the end of the talk, my premise for the app was a little flawed (due to a lack of understanding of the specifics of LN). In my head I imagined Nanomeet able to sit in the middle of the attendees and hosts, acting more or less as a router of payments, logging those transactions on the webapp as they go through.

But, this turned out not to be feasible – Nanomeet could not send a payment it received from an attendee on to the organiser without that organiser having issued an invoice. So Nanomeet needed to store an account balance for organisers, which they can withdraw against at their convenience. Sending payments without invoices was a planned feature for LN (it may well be a feature at the time of writing), but it was sitting behind many other pieces of infrastructure LN teams had on their roadmaps.

Making the move from being a real-time router of payments, to a service which holds live funds for several users, wasn't a jump I was particularly keen about. Especially on a technology so early and rapidly changing, the ongoing risk and maintenance burden would be extremely high, which is tricky with something which is more akin to a side project than a real commercial endeavour. Naturally any service built on top of Bitcoin (an untraceable programmable cash) is an obvious target for hackers, so there's really no getting round needing bullet-proof ops and security.

Despite not launching a product, I still had an awesome time. Meeting great people, experiencing the Bitcoin community and ecosystem, learning in-depth about LN and Bitcoin, hacking together a product, and exploring a new city, were all hugely enjoyable experiences. One of my highlights outside of the residency was visiting a Bitcoin "Socratic Seminar" meetup in New York – that was probably the highest signal-to-noise ratio I've ever experienced in a technical meetup; really inspiring to see the passion and depth on something that it is truly open and decentralised, when so much of society seems to be going in the other direction.

Many thanks again to Chaincode labs, and particularly Bitcoin developers John Newbery and James O'Beirne who put huge effort into organising the residency. I hope there's more still to come on my story with Bitcoin.

Stay up to date

Follow M10c on social media

Want to work with us?

Have something in mind for your next project? We'd love to hear more, and discuss if we can collaborate to create something great together.

Get a proposal