As discussed last week, Bitcoin’s Lightning network is an off-chain payments channel between peers. Users commit a certain amount of BTC to open a channel with a certain node.
From that point onwards and until the channel is closed, Bitcoin can be traded back and forth between users without the hassle of paying high fees or waiting for long confirmation times.
Both the Casa Lightning Node, a startup that created a small hardware device so that users can easily setup a LN node (much like you set up your internet via a modem), and the Open Node team, who received a hefty investment from the community’s favourite Bitcoin advocate Tim Draper, are promoting better use-cases and implementations for this decentralised P2P payment channels technology, built alongside the Bitcoin layer.
Beyond Initial Integration
Many clever people like Andreas Antonopolous, Jimmy Song and Ivan Livqvist, who seriously believe this technology will solve a great deal of the current issues Bitcoin is facing, especially around scalability and the ability for people to micro-transact.
As the Lightning Network grows, additional integration options will become available that could provide exchanges and users with security and ease-of-use benefits beyond the two basic integration strategies described last week: exchange-to-exchange and exchange-to-user integration.
With Lightning, it can become possible to allow exchange users to make trades from within dedicated local apps, making deposits and withdrawals transparent to users. These apps can run on desktops, smartphones, or on more secure hardware devices such as the Ledger Blue.
With exchange functionality integrated with a Lightning wallet, funds can be moved into an exchange’s control for the minimum time required for a trade to execute. Immediately after an order is filled or expires, the funds would be returned to the control of the user’s wallet/exchange app via Lightning. This could potentially create a simpler experience for users as well as reducing risk for exchanges in case of security breaches, as the amount of funds stored in hot wallets could be much lower.
An amazing example is the new Blue wallet, as demoed by our dear Ivan here, that allows users to store Bitcoin, while at the same time, using the LN for micro-payments.
With the two integration strategies previously discussed, it’s assumed that users will be opening channels directly with exchanges. This will be economical for larger-scale traders who move money in and out of exchanges often.
However, as the Lightning network develops, it will be possible for users to have open channels into the public Lightning network and for those users to be able to route deposits and withdrawals via intermediary nodes.
It will likely take some time before there is enough connectivity within the Lightning Network for this to work, but when this becomes possible, it will allow a user’s channels to be used for a variety of different kinds of payments as well as multiple exchanges. With channel set-up costs spread across multiple applications and counter-parties, Lightning transactions will become cheaper and more convenient.
There are many ways to improve scalability and off-chains are a great way to accomplish that.
Why should increasing the block-size be a better solution, if it will put more stress onto small transaction due to increasing fees?
Lightning Network’s core issues
There are two major perceived issues with general off-chain P2P micro-payments solutions:
- How to make sure channels don’t get too centralised within one or two nodes?
- How to improve routing through channels?
LN’s centralisation problem
The most discussed bottleneck is the problem of centralisation.
I don’t think the LN will suffer massive centralisation issues, at least not more than Bitcoin mining, which people tend to say is centralised because there are around three pools with more than 50% of the hashing power.
No, the LN will most likely be quite decentralised in terms of routing as more nodes join the network.
Of course, there will be corporate nodes running which will most likely be used as hubs – users prefer to connect to nodes with many channels open, as they route payments onto different people with greater ease.
This means there will always be a certain degree of centralisation, although because nodes cannot choose which transactions to route, nor they can reject channels from being opened, I see the LN as an open and permission-less way of using a Bitcoin side-chain, without the hassle of forking the network, in order to gain more transactions per second.
We can’t forget each hard-fork represents a decrease in the overall Bitcoin security, as the more miners who switch to the new PoW, won’t be contributing to the Bitcoin network hashing power (blockchain weight).
LN’s routing problem
Another issue with the LN can be associated with routing. It has been stated that routing is one of the unsolved issues of networks, as the way onion routing (used by the browser TOR), works is by adding layers between nodes, allowing each node to only know the previous sender and the forwarding node.
The idea is that if you want to send Bitcoin to a peer to whom you do not have an open channel with, you are depending on other nodes to create “safe” passage. The problem of onion routing is simple: if the channel breaks, the transaction fails because the node which holds the transaction does not know the transaction originator.
Apart from that, this issue means some delays in information reaching out its destination, as I don’t think there’s a chance for any type of real attack – because the LN is not the main BTC network.
Put your mind at ease
My advice? Play around with the Lightning network and judge for yourself. There are apps already running on the LN, like Poketoshi to help you try it out.
Don’t forget: the more you learn, the better decisions you’ll make!