Why do you prefer BSV and fire BTC and its LN

In September, a study https://arxiv.org/pdf/1909.06890.pdf about Bitcoin's Lightning Network began to emerge on the networks. Its authors - Saar Tochner, Aviv Zohar and Stefan Schmid - are convinced that Bitcoin's Lightning Network is a very fragile tool. Why? Why? Because it would be enough to connect intelligently to it to succeed in parasitizing it to the point where the majority of payments on the network could simply no longer succeed.


Theoretical foundations
So let's quickly review together the main differences between the Bitcoin network and the Lightning Network, a network built in a second layer above it.

Bitcoin and its bases
In the Bitcoin blockchain, the possession of bitcoins takes the form of so-called public and private key sets. A private key is produced by randomly selecting any number from 1 to 2256. This number is then subjected to a particular mathematical operation, called an elliptical curve multiplication (called secp256k1, corresponding to the ECDSA algorithm). This results in what is called a Bitcoin public key. This public key is then passed through the mill of another computer function - a hash function - to obtain a public address. The latter is used to receive payments and can be shared without risk. It can start with a 1, a 3, or with bc1 since some protocol evolutions. These addresses are then checked for convenience in the form of a portfolio (also called a wallet), centralizing a user's associated private keys.


Thus, and to summarize, you control private keys that only you know with a wallet, they allow you to prove that you own funds denominated in Bitcoins (with a lowercase b) on the Bitcoin network (with a capital B). You can then receive bitcoins, and choose to send them to others using the address system described above.

The Lightning Network: Bitcoin, but instantly
But when you try Bitcoin, you will find that for a bitcoin transaction to be accepted by the Bitcoin network, a certain confirmation time must pass: usually, it will take between ten to thirty minutes, varying (with possible extremes) depending on the relative congestion of the network at the time of your transaction and the fees you agree to pay to the network.


This is why a solution is currently under development to enable almost instant Bitcoin transactions: the Lightning Network. Built on top of the Bitcoin protocol, it allows bitcoins to be sequestered on the Bitcoin network while respecting the requirements related to validation times (so-called on-chain bitcoins), then to be spent instantly and without delay on the Lightning Network's software overlayer (so-called off-chain bitcoins).

To use the Lightning Network (also abbreviated as LN), it is therefore necessary to have on-chain bitcoins and to "download" them on this parallel network. The latter is based on specific computer nodes, deployed in parallel and above the Bitcoin network. They validate that the bitcoins received on the LN are real bitcoins existing on the Bitcoin blockchain.

Some necessary details about the LN
The sequestration
To be able to transfer bitcoins on-chain to this off-chain network, there are two solutions: use portfolios compatible with Lightning Network and manage a network node for you, or deploy your own. Once your wallet (or node) is ready, you will need to set up payment channels to other LN nodes.

https://ibb.co/K2SZk62

Illustration of a mutlisig transaction on the Bitcoin blockchain.
Let's imagine that Alice and Bob decide to create a channel that they both feed. They will have to constitute a payment channel at the level of the LN network, i.e. they will sequester bitcoin balances at the level of the Bitcoin blockchain using transactions co-signed with their respective private keys (so-called multisig transactions).

A special feature: on the Lightning Network, at the moment, the opening of a payment channel does not imply that the two participants contribute financially to feed this channel. While each channel is in principle bidirectional (funds can go in either direction), they are not automatically supplied by each of the parties, but mainly by the person who initiates the opening.

But the Lightning network does not only seek to allow instant payments between users who open channels between them. By extension, the goal is to allow you to pay another user to whom you are not connected, as long as other nodes with whom you share a channel share a connection with them. The idea is therefore to build a spider web network allowing instant payments from everyone to everyone, even if everyone is only connected to a few.

To achieve this, the LN relies on HTLC, for Hash Time-locked Contracts. In such a system, payments are made via conditional promises, which are only validated upon arrival.

https://ibb.co/Qm6r42M

Illustration of an HTLC.
So, if Alice wants to pay Dave via the LN, she will basically answer a payment request from Dave. This payment request will include a secret (R) formatted in hash (H) status, which only Alice will hold, and which she will then demonstrate to hold to issue her payment. In short, it is the hash (H) of the secret (R) that passes through the payment channels, and explains the need for their use.

Without going into further detail, an HTLC-based network of interconnected nodes theoretically allows - and under conditions - all players to pay each other at some point, instantly and even if they are not directly connected. However, it should be noted that these HTLCs depend on a time condition, i.e. they correspond to payment requests with time limits (usually a payment request on LN expires in 24 hours).

The overlay network, its liquidity and use
However, there are still a number of nuances to be made, which we will do now. The LN is still an embryonic network, and many errors can occur when trying to use it, even if its software implementations are constantly evolving. To summarize very briefly, it is still often the case that transactions submitted to the network fail due to multiple factors. The one that will interest us for the rest of the article is the following: the liquidity of the network.

As mentioned above, at present, payment channels are bi-directional, but not necessarily equally supplied in both directions of traffic between the different users.

https://ibb.co/0CKfnsv

For example, here is the status of the open (and currently open) channels of one of my personal LN nodes.

As you can see, my LN node is connected to three other LN nodes. These are the nodes of LNBIG.com (one of the main multi-connected liquidity providers in the network), the Kryptosphere student association and Namson Lê (UX Researcher at Zap, an LN compatible wallet).

He is also waiting for a connection with the node of Jonathan Fraga, contributor to the Journal du Coin.

As you can see, the channels that have not yet been used retain uni-powered balances, in the sense that only the one who opened the payment channel supplied this bi-directional channel. This is the case of the channels I opened with Kryptosphere and Namson, but it is also the case in the other direction for the channel Jonathan opened with me.

In the end, schematically and at best, if I want to receive a payment, I could only receive the total of the distant balances coming towards me, while I could only send the total of the local balances supplied by my side. In the previous example, since the Jonathan channel is not yet validated, I could only send 264,640 satoshis instantly - and subject to other factors beyond my control. I could only receive 68,634 satoshis at the moment, but 364,563 satoshis once all channels are open. So I could pass my satoshis to a node not connected to mine, as long as it is itself connected to other nodes from one close to the other until it is linked to a node in my neighbourhood.

https://ibb.co/ZHCn3Ks

Visualization of a personal LN node (blue, surrounded by a red circle) and its connections, using graph.lndxplorer.com.
It is therefore important to be connected to the network of other nodes, and well enough to be able to take full advantage of the LN. However, and as we will see below, the network is still experimental, and it is advisable not to remain measured in the balances of bitcoins that you are sequestering on LN: keep in mind that it is possible to see the attacked network, to suffer unexpected bugs or to lose your funds because of bad handling. You don't go after digital gold without taking any risks. So prefer to put pocket money in it that you would accept to lose, without this loss preventing you from sleeping if it were to happen. Your servant speaks from experience...

Traffic jams on the highway of the value
Why and how to attack the Lightning network?
Finally, let us return to the study under discussion: Saar Tochner, Aviv Zohar and Stefan Schmid are its authors, and they wanted to test the solidity of the current LN network. How would he react to an attacker who wanted to disrupt the proper functioning of the network? Let's say LN becomes mainstream one day, could we attack him to paralyze him? This study therefore aims to provide some answers, but cannot be totally categorical. As we will see, the LN is constantly evolving with the updates of its software clients (named after lnd, c-lightning).

Avarice is a naughty sin
Their idea is that a malicious user could deploy a node that would interface effectively in the network, so that it would end up occupying a relatively central place in the network. Once in place, he would see transactions in transit and then decide not to transmit them anymore. In doing so, it would be able to disrupt some of the transactions in question, which could not be completed. To really threaten the network, the authors consider an attacker who would actually deploy several aggressive nodes. By doing so, the attacker would control both the most connected and most used payment channels, but also the main secondary channels that would be used by software customers as a backup solution when the first payment attempt fails.


https://ibb.co/bNmFYYB

To place themselves in this enviable position, the authors explain that it would be sufficient to exploit the channel opening mechanisms of each of the LN implementations: thus, assuming that payments will preferentially transit through channels requiring very low transaction costs, the authors consider a model where an attacker would place nodes offering almost free transactions in order to attract a maximum number of users.

Each implementation uses various consensus models called gossip models, allowing a decentralized organization of these connections at the price of certain concessions.

The conclusions of the study
The study thus considers that such an attacker, taking advantage of an established centralizing position (similar to the LNBIG node mentioned above), could take advantage of the delay mechanisms linked to the temporal component of the HTLC and its position to block all payments submitted to it, and thus paralyse the network. The figures mentioned are chilling, as you will see.


https://ibb.co/2g03f0q

Number of channels per node, and their capacities.
So I contacted the authors of the study for clarification. To enlighten me, Mr. Aviv Zohar explained to me that it would only take "opening 20 payment channels" in an intelligent way to paralyze nearly "80% of the transactions on the LN network". Thus, to block almost all transactions under or equal to $100 (a value already significant today on the LN), it would be enough to open "20 channels with each $100 affected per channel, so that it would be enough to mobilize $2000" to paralyze the LN network. These figures were reported in-extenso earlier this week by CoinDesk.

However, even if the Lightning Network is still in its infancy, such a conclusion may be pensive. On a personal level, and even if I fully accept the idea that the LN is currently a curious experiment that is only just beginning, it seemed strange to me that it is enough to create an LN node, connect to 20 other peers and propose very low fees to block the network almost entirely, with a simple starting capital of 2000 dollars.

Conclusions to be mitigated
I therefore continued my exchanges with the authors, which are still ongoing at the moment. I would like to take this opportunity to thank them for their openness and their wise answers to questions that are not always the sharpest. They may also justify an update of this article and its arguments and counter-arguments.

But I also needed other informed opinions: to do so, I contacted various contributors of the three main LN implementations. I have not yet been able to get an answer from Acinq and its flash software client, but two other good souls have agreed to give me their opinion on this study. I would also like to thank Mr. Namson Lê and Mr. Antoine Poinsot for their availability and their respective insights, respectively contributors to the lnd and c-lightning clients.

Collateral damage
It should be noted that it is not a question of rejecting the conclusions of the said study en bloc (you have it?). Fabrice Drouin, co-founder of Acinq, a company working on flash implementation, has already expressed himself to CoinDesk, considering it a "very interesting" study and considering that it was healthy to see "independent researchers[taking an interest in the Lightning Network]".

However, it should be pointed out that it may seem a little strange to consider that it is enough to connect your node directly by proposing low rates to bring down the network, all for a very modest cost.

Indeed, it is interesting to take into account in particular the maintenance costs required by the deployment of a central node on the network. It is not a question of opening 20 channels, it is still necessary to ensure their maintenance, to pay the variable on-chain costs of opening and closing the channels (in particular when closing channels that have become inactive because the attached nodes are no longer reactive). It should be noted that even if the final invoice were a little higher, these costs would not make it explode given the very small size of the LN at the moment. As a reminder, the LNBIG operator - seeing 40% of the network's capacity go up - was estimating his channel management fees at $1,000 a month for opening and closing channels, which is not really enough to break three pasta to a hacker duck either.

But where things may get complicated is when you have to consider that the dynamic system by which nodes send payments between channels takes into account the recent behaviour of their peers.

Maintain your reputation
The knots are not blind. If one of their peers spends his or her time refusing to transmit payments sent to him or her by a node, the sending node will attempt to bypass it by passing through to its final destination. You can better understand why the authors of the study were considering an attacker who would have invested on several nodes, in order to try to block the passages by the main possible paths.

In the case of c-lightning, Antoine Poinsot explained that a fairly simple Djikstra algorithm was currently used to serve this purpose. On the Indian side, Namson Le refers to a recent update in June that serves roughly the same purposes, and introduces a probabilistic payment routing mechanism where the component of efficiency and honesty of peer nodes comes into play in the selection of routes used to send payments. In addition, a feature that allows you to blacklist nodes considered to be faulty and avoid using roads where the wrong actors are operating. The investment could therefore seem somewhat unreasonable: in a few attacks, the nodes in question would find themselves blacklisted, and little borrowed.

As such, it would therefore be possible that recent (and future) developments of these software clients may already be sufficient to mitigate any attack that would resemble the one described in the study in question. What interest would an attacker have in inserting himself as the main trust node of the network, in maintaining this place for a certain time, only to see his frequentation finally fall and finally be excluded from routing schemes and no longer be used? Well... Simply because this reputation system is far from perfect.

Relative anonymization
As described above, peer-to-peer payments are based on the HTLCs described above. The particularity of the LN is that it offers anonymization of nodes: if my neighborhood of nodes sharing direct channels with me knows that I send satoshis and pass them on, it ignores the final destination of my shipment. Similarly, the node that will receive my payment, if it does not have a direct channel with me, will not know exactly where the payment comes from and the path it has taken.

This is an advantage in terms of privacy, but clearly a problem in terms of reputation system: as Aviv Zohar explains, since the nodes are anonymized, it will be very difficult for them to know precisely which node is malicious on the roads used. Moreover, since the attacker deployed several other malicious nodes to position himself as backup routes during the first payment failure, he could then more or less continuously continue to refuse payments.

In summary: if its close vicinity could be aware of its behaviour and exclude it from their transmission paths, this would not necessarily be the case for other more distant nodes. Similarly, there is a time component in the reputation mechanism: it would be sufficient to deploy an honest node for two weeks to position itself effectively, as reputations in place do not keep an older memory of events, and most are based mainly on each node's latest payment attempts. It is only after this incubation period that the attacker would take action.

Liquidity is not lacking
Finally, and to conclude, we must consider the question of liquidity: if in your neighbourhood near interconnected nodes, you have to consider your local liquidity, the situation is different in the global LN context. To allow instantaneous exchanges of the LN, the system mainly considers the overall liquidity present in the channels. Thus, according to Mr. Zohar, an attacker who came to open channels himself and maintained his knot honestly for two weeks would have every chance of attracting channel openings to him. It would then propose low charges to pass most payments through it, while deploying additional opposing nodes to cover emergency lanes. Ultimately, this would ensure that it could paralyze payments commensurate with the liquidity it provided.

The final word
If you've held out so far, congratulations.

In summary, and to conclude, we have just explored together the bases of both Bitcoin and its Lightning Network. As we have repeated over and over again in articles on the LN, this network is fundamentally experimental: experimentation means risk. These risks do not mean that the very viability of the network is in question: as Mr. Zohar explains, the objective of the study conducted by himself and his colleagues is to ask questions to lead to changes in the protocol that can solve the problems identified. According to him, in this particular case, it will eventually be possible to respond to threats of this type, using changes in payment routing protocols (and better reputation systems) but also likely spontaneous changes in the LN typology over time (more honest nodes occupying default backup paths, if more people deploy nodes).