The Bitcoin Lightning Network holds promise as a cheap and fast second layer service built on top of Bitcoin that allows micro payments without incurring network fees other than those needed to open and close a channel.

The technology is already available and can be used to pay for stuff online, but is still very far from 100% reliable, let alone user-friendly. However solutions that are relatively easy to get running already exist. In this article I am going to share my experience setting up and using two such solutions: one for desktop PCs and another for Android mobile.

As is customary regarding the Lightning Network (LN), I must preface everything by warning you that this is still very early beta-quality software and that bugs that can lead to failed payments and loss of funds are a real possibility. If you want to try LN for yourself, you should set aside only an amount of bitcoins you are comfortable to lose. A LN testnet is also available for those who want to test the technology but don’t actually want to send real payments. Both solutions I discuss here can operate on testnet as well as on mainnet.

How LN Works

Before we begin, let’s explain — in very broad strokes — how the Lightning Network works. Knowing this is very important, because you will not be able to understand what you can and can’t do (and why). If you are familiar with this, just skip this section.

Payments over LN are possible after two parties open a channel between themselves. Upon creating a new channel, either or both parties pledge a certain amount of bitcoins that they can spend within this channel. In order to open a channel, you need to link your LN node with a Bitcoin wallet from where the LN node can fund the opening of new channels and remit the outstanding balance upon channel closure.

When you open a new payment channel, your LN node takes the starting amount from the Bitcoin address you have provided and broadcasts a spend transaction to the Bitcoin network. Just like with a normal spending, you need to pay network fee to include this transaction in the blockchain, but unlike regular bitcoin spends, all future payments in both directions over that channel are free or really cheap. Only after you decide to close a channel will you have to pay another network fee, as the final balance is remitted back to you.

In practice, I expect people will not have to close LN channels that often; a channel can be used until the remaining amount becomes too small to be processed over Bitcoin mainnet, but these amounts of dust can still be spent on the LN network. Future LN node implementations will probably have smart algorithms to manage balances on open channels to optimize this, the same way smart Bitcoin wallets these days manage your UTXOs. So for the time being remember that channel opening fee is needed but channel closure fee is optional.

A widely recognized limitation of LN payments is that a single channel can remit only the amount that is locked up inside. This means that for practical purposes people will have to keep multiple channels open and plan ahead as to what amounts of Bitcoin to allocate when opening them. So the second thing I want you to carry on your mind is that you will have to become comfortable with the idea of having multiple channels open, which is a bit different than the Bitcoin way of operation.

The main problem for getting started with Lightning Network is to put some Bitcoins into one or more LN channels. The very first versions of LN software required a lot of footwork like writing raw Bitcoin transactions and such, it was really terrible and very risky. However both solutions I am writing about today eliminate that on ramp difficulty. The desktop LN node interfaces with a Bitcoin wallet, and the mobile LN node acts as a Bitcoin wallet itself. Let’s start with the desktop LN node first.

Lightning Network Desktop Node

Eclair is an LN implementation by ACINQ that can run on Windows, Mac OS and Linux via GUI, CLI or JSON-RPC API. The only requirement is a synchronized, segwit-ready, zeromq-enabled, wallet-enabled, non-pruning, tx-indexing Bitcoin Core node. I happen to have such a node running on my local network, so all I needed to do was to bind it to a local IP, enable RCP and set a username and password for API access.

I installed Eclair under Windows, and my only head-scratching moment was where I should put the eclair.conf file. Installation notes said it goes in ~\.eclair which I assumed was the folder where the Eclair JRE executable was located ( C:\Users\{username}\AppData\Eclair\). However this was not the right location and the program failed to start telling me it couldn’t communicate with the Bitcoin Core node. Once I moved the config file to C:\Users\{username}\.eclair\, Eclair launched and connected to my node.

Lightning Network Mobile Node (Android only)

Running a LN node on a mobile device is more difficult, because the Bitcoin node with your wallet might not always be accessible (while possible to do, it is not advisable to expose your wallet via RPC outside the local network. In order to bypass this chicken and egg problem, Eclair have done something else: they have created a combined Bitcoin and LN wallet app (Eclair Wallet Testnet, Eclair Wallet Mainnet, no iOS versions because… Apple).

The Bitcoin wallet is really simple — when creating a new wallet, you only get a single (SegWit compatible) address that you can fund from another wallet app. The balance on that address is used to fund your LN channel(s); leftover LN balances are returned to it; and of course you can spend Bitcoins from that address directly. It is not a good Bitcoin wallet by any stretch of the imagination — it uses an Electrum Server maintained by the developer (ACINQ) and fee estimation might suck; there are some illogical interface solutions (explained below), but this really doesn’t matter, because once you get past them, it works as expected.

Important note: at time of writing the mobile Eclair Wallet (I am reviewing version 0.3.1) supports only outbound LN channels. You cannot receive/forward payments over LN.

After you start the app and enter your PIN code, you are greeted by the ‘Your Bitcoin Address’ page, which is used to fund the wallet. The total available balance is shown on top, with separate readings for Bitcoin and LN balances. If you tap anywhere within the blue area, the BTC numbers will change to USD or EUR counter value depending on how you have set up the app.

The ‘Transaction History’ page holds a log of all payment events on both networks (Bitcoin Mainnet and LN), newest ones on top.

Let me translate all transactions from you, starting from the bottom (the beginning):

• Apr 23, 2018 21:50:07 This is the initial 0.003 BTC funding transaction from another wallet of mine into Eclair.
• Apr 23, 2018 21:50:52 This is the transaction with which I opened a LN channel with ACINQ (the developer of Eclair). As you see, I put 0.002 BTC into this channel, and chose a ‘fast’ transaction. The Eclair app chose a network fee of 902 sat (6 sat/b), which was sub-optimal — 1 sat/b transactions were possible at that time — but it doesn’t really matter, does it 🙂
• Apr 23, 2018 21:52:39 While I waited for the 6 confirmations required by ACINQ to open my LN channel with them, I sent another 0.005 BTC from a different wallet of mine into Eclair, just for the fun of it.
• Apr 23, 2018 22:18:09 There! This is my very first LN transaction. As 5000+ folks before me, I used it to buy some dumb Lightning stickers from the Blockstream store.
• Apr 24, 2018 21:02:37 This is how a purposefully failed transaction due to insufficient channel capacity looks like, and this is the main issue people will be having with LN. While I have enough balance in my wallet to send a 0.0025 BTC, my payment channel with ACINQ does not have sufficient capacity (remember, I put 0.002 BTC on that channel, and I spent most of that paying for the dumb Lightning stickers)
• Apr 26, 2018 21:43:30 This is the transaction with which I closed my channel to ACINQ. The network fee on that transaction (871 sat, 7.6 sat/b) was technically paid by ACINQ who initiated the transfer, but in practice the amount was subtracted from my remaining balance in this channel. At this point I don’t know what the protocol for paying the closure fee is; perhaps the person who closes the channel is responsible for this? I have to research this, I have no clue.

Remember how I told you about interface inconsistencies? Well, the Transaction History tab is the perfect example, because from here you also initiate both Bitcoin Mainnet and LN payments (either by scanning or copy/pasting a payment request). Perhaps if the tab was only called ‘Transactions’ it would be more intuitive. But anyway here is how it looks like:

And finally, the ‘Lightning Channels’ tab is the place where you create and monitor your channels. The possible operations are copy/paste or scan a node URI, add a random node (this feature is not yet available as of version 0.3.1 of Eclair Wallet) or connect to an ACINQ node (which makes most sense anyway, it will probably be well interconnected).

 

Paying Myself

The next step I did was to try and establish a channel between my desktop and mobile LN nodes. Because the desktop version of Eclair does not generate QR codes for node addresses, I emailed myself its connection data (pubkey@ip:port) and copy/pasted that from my mobile Eclair.

The first attempt at establishing a channel failed because I had forgotten to open port 9735 on my router. The second attempt at establishing a channel failed because I had forgotten to disable Windows Firewall for the LAN connection on the PC where my desktop Eclair node was running. The third attempt went through immediately:

This time I chose ‘slow’ funding transaction speed (1099 sat, 3 sat/b) and the transaction was picked in the next block. Because of wallet fragmentation the transaction was quite big (3 inputs; 1 output; 277 bytes). If you open and close LN channels regularly, be prepared for this. But also think about what I said, that closing LN channels may not be necessary — you can probably consolidate small remainders into newer channels that you open with yourself (e.g. between a desktop and a mobile node, like me).

The only thing that I still had to test was open another LN channel from my desktop node to another node. This would test the ability of my Eclair desktop node to command my local Bitcoin node. I used the Lightning Network Visualizer to select a well-connected node nearby and gave it a go. Because it was about 2:00am when I did this, I was about to set both the channel capacity *and* push the same amount to the other node, but I caught myself at the last moment and set Push Amount back to zero. Here goes nothing.

As soon as I pressed that blue Connect button, a wonderful thing happened: the second channel was immediately created, and the number of All Nodes and All Channels started rising quickly and stabilized at around 650 nodes and 1800 channels after 10 minutes.

The more observant among you may have noticed that the first channel (the one with 0.0025 BTC capacity) is offline. But that was only because my phone was asleep. As soon as I re-opened the Eclair Android app, channel state returned back to ‘NORMAL’.

Then, seconds later, the new channel disappeared. I checked my Bitcoin Core wallet, there was no outgoing transaction. But the channel re-appeared again a minute later, and disappeared once more. Definitely something weird going on, but I couldn’t see the problem. As it was really late, I decided I’d investigate this further the next day and went to bed.

Caveats

I haven’t been able to break things just yet, and so far the only caution I can give concerns the mobile Eclair wallet. If you delete the app for whatever reason, you can restore it from the 24-word (BIP-39 compatible) seed and your bitcoins will be fine, but you will lose all open LN channels. Obviously, the desktop app as well needs to be backed up somehow. I will write more about this.

Update #01: I was able to experience a bitcoin-losing event, although I don’t know why exactly. Using the channel between my mobile and desktop node (total capacity 0.0025 BTC less 0.0005 BTC for a payment I already made), two days later I decided to make a second payment for 0.0015 BTC. That payment did come through immediately as expected, but shortly afterwards the desktop node initiated a forced uncooperative channel close, for whatever reason.

For my mobile wallet that was fine; I immediately saw a return BTC transaction for the remaining balance. However remember that my desktop node seems unable to communicate with my local Bitcoin Core node. So the settlement transaction for the desktop end of the channel isn’t being communicated to the Bitcoin network… and my 0.002 BTC seem to be gone forever (or at least until I figure out how to make Eclair talk with Bitcoin Core and re-broadcast that closing transaction.

Update #02: No loss of funds after all. After I restarted my PC and span up Bitcoin Core, I launched Eclair desktop node and it immediately broadcast the closure transaction with which the payment arrived in my local Bitcoin Core wallet. Eclair set a modest network fee of 123 sat (< 1 sat/b) — nice! Another thing I noticed is that the transaction was broadcast as opt-in RBF enabled which would allow me to increase the network fee from Bitcoin Core in case the transaction got stuck due to low fee. Job well done ACINQ!

Some More Thoughts on LN payments

At the beginning of the article I said that spending bitcoins on LN requires a little bit of pre-planning because users need to predict how much coins to commit and how many channels to open. But there is also another difference that will become important as soon as LN gets widely adopted: the issue with accounting units.

With Bitcoin, things are relatively simple — most users recognize that the main unit (1 BTC) is broken down into 100,000,000 satoshi, and amounts expressed as fractions of BTC, mBTC, bits or satoshi make sense. And for practical reasons, because of network fees, we are used to spend amounts in the mBTC range (0.001 BTC and more). There are those who predict that with time the use of BTC as a unit of measure will decline and disappear, because Bitcoin will appreciate so much and get adopted so widely that ‘normal’ transactions using satoshi will become the norm.

But the native unit of the Lightning Network is 1 millisatoshi — 1/1000th part of 1 satoshi — and from a cursory look at the LN source code it seems to me this limit can be adjusted downwards even further if needed (settlement balances will still need to be rounded to the nearest satoshi when channels are closed.) But anyway the point is that LN is offering ridiculously small micro payments right now, and we need to readjust our thinking very quickly to get used to these really small measurements.