The Lightning adoption is progressing.
The Lightning Network, the off-chain solution to bitcoin’s scaling problem, is on everyone’s lips. They should not only solve the traditional problem of transaction fees on a sustainable basis, but also enable quick swapping into other cryptocurrencies via Atomic Swaps.
Lightning adoption is progressing, first applications are written
A few days ago BTC-ECHO reported that the Lightning Network has now arrived on the Main Net. The number of Lightning Nodes has now reached almost 1,500, the SegWit adoption is progressing faster than the Bitcoin cash acceptance.
These positive news are currently culminating in the word re-creation LApps. LApps are Lightning apps, that is applications that would not run without the Lightning Network. For less than a week Blockstream is now releasing a new LApp every day.
These primarily focus on micro-payment solutions and want to offer bitcoin-based payment solutions, especially in the content sector. One feels reminded SatoshiPay : About FileBazaar Micro-Payments for users who offer photos, videos or documents to be possible. Lightning Publisher for WordPress is a significant name: it allows bloggers to put individual posts behind a paywall. With Nanotip you can pay small amounts of money to other litecoin users — Reddit users will quickly remember Tipbots. Finally, PayPerCall is intended to expand the concept of microtransactions to a wide variety of API calls.
Loss of money through the use of the Lightning network
So far, the experience of the Lightning Network coincides with what one perceives when looking out the window. However, the spring fever is clouded by an unpleasant news: One user said his bitcoin transaction was lost on the Lightning Network.
A user with a bad channel database (ie a database containing the available payment channels for the network) did what everyone would have done: he restored an old backup.
Now, the problem was that this backup was outdated. The Lightning Node of the unfortunate sent so wrong status of the payment channels. Other nodes recognized this mistake, interpreted it as an attack attempt and acted accordingly.
Strictly speaking, the Lightning Network worked as it should: it realized that the database had stored incorrect account balance information. Wanted, this would be synonymous with a double-spending attempt.
Such a rigorous approach is important: the Lightning Network announces the sender in the first step only that he wants to send a certain amount x to the recipient — an actual transaction takes place later. Now such announcements would not be worth much more than promises if they are not decentrally controlled and reconciled.
And it is precisely this control that has fallen victim to the poor user. By the way, the user does not have to complain about a big loss: he wanted to send only 20 Euro.
Error in the application layer, not in the Lightning Network
So the bug was not so much the Lightning Network itself as the application layer. The Lightning client should not allow transactions based on an old channel database at all, so that such errors can not happen.
You can see from the incident that the Lightning Network certainly has to do its homework. For the individual bitcoin user, this means that for the time being he should be careful about Lightning transactions and not send too much money. However, this should be quickly realized with a network that advocates microtransactions.
Author: Marko Vidrih