A quick overview of what the Lightning network is

A payment layer that makes use of the script language in Bitcoin

A way to send and spend Bitcoin across nodes instantly and irreversibly

A layer that builds on the security of the underlying protocol, Bitcoin

Read more about it here or here

Setup of network for routing of payments

In my demo, I have setup a number of lightning network nodes, and set it up to work with the Bitcoin regression test network.

Since routing is working, I might as well setup several nodes to understand how channel balances behave between nodes that are not directly connected.

For my setup I have used the readily available Eclair 0.2-alpha1 that anyone can download for both Windows and Linux, and do exactly the same tests as I have.

First setup

At first I open Bitcoin-QT in regression test mode and mine “some” blocks I setup 4 Eclair nodes I open up a channel from nodeA to nodeB I open up a channel from nodeB to nodeC I open up a channel from nodeC to nodeD

As I open channels, I must fund those channels, which is a function the GUI application allows me to do. Its easy and takes a few seconds to setup. Each node has an URI, and opening a channel requires the URI of the node you connect and establish a channel with.

In order for channels to establish and fully connect to each other, it requires 6 confirmation. This is easy to do as I can mine all the blocks via simple commands Bitcoin Core regression test.

Network ready! Payments can begin

In this instance, since nodeD is connected to nodeA via two different nodes in between, it requires routing by the nodes in the network. I cant send a payment directly to nodeA from nodeD, as we do not have an established channel. My payment will simply get routed through nodeB and nodeC.

All the blocks required for the channels to be established are now “mined” and all my channels are open.

I am generating a payment request from nodeD to nodeA so that nodeD can receive 5 milli Bitcoin.

Payment is done! Fee’s on channels is updated and balances on all channels in between nodeA and nodeD is also updated.

All the eclair nodes are connected to the same Bitcoin Core client, and in my case, as I run it all on the local network, each communicates via its own port.

In this scenario I am also sending a payment from nodeB to nodeC which have a direct channel established between them.

Payment done again!

All channels are now closed between all nodes, and each channel has been closed as one payment to the Bitcoin network (in this case the local Bitcoin core node that runs in test mode).

All the nodes are still connectede to the Bitcoin client, and can at any given point open new channels between themselves again.

Nodes as servers

In my tests for this post, I used the GUI to give an impression of how it all behaves. Eclair however comes with its own daemon, and with its own API commands that can be triggered from the command line, much like the API commands within Bitcoin Core.

A web wallet interface could already interface with the eclair damon server, and allow web wallet users to send Bitcoin to other Lightning network users, via an even more simplified interface as entry point.

Conclusion

There would be no limit to how many times the nodes in my example could keep sending payments to each other in the topology of 4 nodes on the network.

There is no limit to how much each channel could be funded with between each of the nodes. And there is no limit to how these nodes can interact between each other.

There is also no limit from how many nodes could join the network of 4 nodes and keep growing this network.

While this is an early version of the first working Lightning network node, it is already doing the most important thing, sending payments via the network, and routing payments through nodes that serve as link between endpoints.

In my next post I will be testing the Lightning network on the Bitcoin testnet network and later I will try to configure the Eclair Lightning Network node to work with whichever blockchain has integrated SegWit.