The Lightning adoption is progressing. For several days now, Blockstream has been releasing a new application every day that uses the Lightning Network. But the second-layer network still suffers from teething troubles.
The Lightning Network, the off-chain solution to Bitcoin’s scaling problem, is on everyone’s lips. It should not only solve the classic problem of transaction fees in the long term, but also enable a quick exchange into other crypto currencies via Atomic Swaps.
Lightning adoption progresses, first applications are being created
A few days ago, it has been reported that the Lightning Network has now arrived on the Main Net. The number of Lightning Nodes has now reached almost 1,500 and SegWit adoption is progressing faster than bitcoin cash acceptance.
These positive news are currently culminating in LApp’s word creation. LApps are Lightning Apps, i.e. applications that would not run without the Lightning Network. For less than a week now Blockstream publishes a new LApp daily.
These primarily focus on micro-payment solutions and want to offer bitcoin-based payment solutions, particularly in the content sector. One feels reminded of SatoshiPay: Via FileBazaar micro-payments should be possible for users who offer photos, videos or documents. Lightning Publisher for WordPress is a significant name: Bloggers can use it to place individual posts behind a paywall. With Nanotip you can pay other Litecoin users small amounts as recognition – Reddit users quickly feel reminded of tipbots. Finally, PayPerCall will extend the concept of microtransactions to various API calls.
Loss of money by using the lighting network
So far, the experience of the lighting network coincides with what you perceive when looking out of the window. However, the feelings of spring are clouded by an unpleasant message: one user stated that his bitcoin transaction was lost via the Lightning Network.
A user with a faulty channel database (i.e. a database containing the available payment channels for the network) did what anyone would have done: restore an old backup.
Now, however, the problem was that this backup was obsolete. The Lightning Node of the unfortunate sent wrong statuses of the payment channels. Other nodes recognized this error, interpreted it as an attack attempt and acted accordingly.
Strictly speaking, the Lightning Network worked as it should: it recognized that the database had stored incorrect information regarding account balances. This would be equivalent to a double-spending attempt.
Such a strict procedure is important: In the first step via the Lightning Network, the sender only announces that it wants to send a certain amount x to the recipient – an actual transaction takes place later. Such announcements would not be worth much more than promises if they were not controlled and reconciled decentrally.
And it is precisely this control that the poor user has fallen victim to. Incidentally, the user has nothing to complain about: he only wanted to send the equivalent of 20 euros.
Error in the application layer, not in the Lightning Network
The error was therefore less one of the lighting network itself than of the application level. The Lightning Client should not even allow transactions based on an old channel database, so such errors cannot occur.
You can see from the incident that the Lightning Network certainly still has to do its homework. For the individual Bitcoin user this means that he should be careful with Lightning transactions for the time being and not send excessive amounts. However, this should be possible quickly with a network that advocates microtransactions.