Lightning Network: Micropayments To Scale The Bitcoin Blockchain

The Lightning Network has emerged as a transformative layer built on Bitcoin, promising to make transactions faster, cheaper, and more scalable. It creates channels between users, enabling them to transact through shared connections, akin to friends-of-friends relationships. While the technical intricacies can be challenging to articulate, the essence lies in creating and managing these channels. In this Trakx’s research, we’ll explore how the Lightning Network could lead to a more decentralized and efficient network.

The Great Bitcoin Schism of 2017

In the summer of 2017, Bitcoin (BTC) soared to the then astronomical figure of $3,000. However, the Bitcoin community found itself at a crossroads, torn apart by a long-standing issue – the limitation of the blockchain block size. Satoshi Nakamoto had set the block size at 1MB, a decision that became a bottleneck as transactions surged during Bitcoin’s euphoric rise. The community, faced with the need for scalability, splintered into two paths, each proposing a different solution.

The first path advocated increasing the block size, initially to 8MB and later to 32 MB. The second path, a more intricate solution, proposed a protocol modification called Segregated Witnesses (SegWit). This modification slightly increased the block size limit but introduced a revolutionary technology known as the Lightning Network.

Both solutions were valid, but the debate centered on potentially excluding individuals from running a full node due to the increased block size.

The schism led to a fork in Bitcoin, a divergence in its trajectory. On one side, there were larger blocks, and on the other, the adoption of SegWit technology. The question arose: which chain should rightfully be called Bitcoin? Exchanges stepped in to resolve the dilemma, naming the chain with larger blocks Bitcoin Cash and continuing to use Bitcoin for the SegWit-adopting chain.

Enter the Lightning Network

The Lightning Network (LN) emerged as a groundbreaking solution to the challenges posed by the Bitcoin block size limit. It operates through channels, essentially a multi-signature address on the Bitcoin blockchain where a party deposits BTC. Moving BTC within the channel requires two signatures. This address manages accounting through technical mechanisms, determining the BTC balance for each party involved. This accounting is maintained through the exchange of signed transactions.

Crucially, these signed transactions, though not immediately written to the blockchain, determine the amount of BTC owed to each user when the channel is eventually closed. The signed transaction can be envisioned as a piece of paper stating, “From this channel containing 10 BTC, Joe is entitled to 6 BTC, and Anna is entitled to 4 BTC,” bearing the signatures of both parties. In reality, the channel is rarely closed, and values circulate through exchanging these symbolic pieces of paper. The Lightning Network keeps track of everyone’s debts and credits, settling them when the channel is closed by writing the transaction to the blockchain.

Six Degrees of Separation in Bitcoin

The Lightning Network introduces a novel concept similar to the theory of six degrees of separation in semiotics and sociology. This theory posits that every person can be connected to any other person or thing through a chain of acquaintances and relationships, with no more than five intermediaries. Leveraging this theory, the entire world could be easily connected and simplified through large connectivity hubs, echoing the internet’s history.

In practical terms, the Lightning Network operates on the premise of indirect connections. Users need not establish direct channels with everyone; instead, they can utilize channels of common contacts. The theory aligns with the idea of third-party channels, where a user, like Anna, can transact with another user, Julia, through a common friend, Joe, who acts as an intermediary.

Consider a scenario where Anna needs to pay 1 BTC to Julia. They lack a direct channel, but both have a common friend, Joe, who has channels for Anna and Julia. Anna routes her payment through Joe, enabling the transaction without needing an on-chain Bitcoin transaction.

This flexible and efficient routing mechanism showcases the power of the Lightning Network in navigating indirect transactions, creating a decentralized and interconnected web of value exchange. As the Lightning Network continues to evolve, it stands as a testament to the resilience and adaptability of the Bitcoin ecosystem.

Diving into the Technical: Safeguarding Lightning Network Channels

Let’s delve into the technical aspects and understand how a Lightning Network channel is opened. Paradoxically, to open a channel smoothly, what is prepared is a closing transaction for the channel. Therefore, even before opening the channel, the network knows how to close it. It precludes potential fraudulent actions or inconveniences arising from double signatures (threats of non-signing or disappearance of a signatory), which would make the secure closure of the channel impossible.

If the signatories decide to deposit 5 BTC each, they will exchange a closing transaction that will distribute the 10 BTC in the channel, with 5 going to each party. When the two signatories create and exchange this closing transaction, they proceed with opening the channel. It involves both signatories signing the transaction with the respective deposited BTC, and the channel can be closed at any time, thanks to the pre-created closing transaction.

A new closing transaction is created to transfer value, in which one of the parties modifies the initial values. For example, if the channel consists of 5 BTC for Anna and 5 BTC for Joe, and Anna needs to pay Joe 1 BTC, she constructs a closing transaction that returns 6 BTC to Joe and 4 BTC to Anna, signed by both parties.

The challenge now is that Joe must ensure Anna discards the initial closing transaction, the one closing the channel and distributing 5 BTC each. If Anna were to close the channel with that transaction, Joe would lose the BTC that Anna had paid him. How can one compel a person to delete old signed transactions? In reality, there is no direct way, as a transaction is a simple file that users can back up infinitely, hide, etc. So, let’s explore how the network maintains security.

We need to understand that Bitcoin transactions can include temporal and practical conditions. In the closing transaction, a condition is always inserted. It is a somewhat complex aspect to grasp, and let’s add another layer: the closing transactions maintaining the two users are not identical; they differ in conditions.

In the first closing transaction maintained by Anna, where 5 BTC each will be distributed, two conditions are inserted: 5 BTC are instantly given to Joe, and the other 5 have two conditions: they will go to Anna within 24 hours, OR they will go to Joe if he reveals a keyword known to both. In this way, after a series of transactions, Anna is entitled to 3 BTC and Joe to 7 BTC. Suppose Anna decides to write the old transaction on the blockchain. In that case, Joe has 24 hours to protect himself, reveal the keyword, activate the condition, and take the remaining 5 BTC without anything going to Anna.

Similarly, Joe possesses an identical transaction but with inverted conditions: Anna instantly receives 5 BTC, and Joe receives the 5 BTC after 24 hours, provided Anna does not reveal the keyword. If Joe is entitled to more than 5 BTC, he will not be incentivized to write this transaction. There is no need for concern; Joe and Anna do not have to monitor each other’s actions to intervene within 24 hours. Fortunately, the protocol handles everything automatically.

In essence, anyone attempting to defraud the counterpart loses all the BTC in the channel, even those to which they are entitled. This clever trick doesn’t erase old signed transactions but disincentivizes their use.

Addressing Criticalities: Challenges in Lightning Network Security

However, there are some critical points to consider:

• Online Presence for Security: One notable concern is that users must be online to protect themselves from malicious actions by their counterparts. In the example mentioned, the 24-hour window is an illustration, but parties can agree on different timeframes. It necessitates vigilance, as the participants must be alert within the agreed-upon period to safeguard their interests.
•  Custodianship of Closing Transactions: Another critical aspect involves the custody of the closing transaction. If one of the parties were to lose it, their recourse would be limited to hoping that the counterpart would generate a new transaction. This scenario diverges from the fundamental principle underlying the creation of blockchain: establishing an environment where trust in others is minimized.

While introducing innovative solutions to blockchain scalability and transaction speed, the Lightning Network exposes users to unique challenges. The requirement for online presence and the potential vulnerability arising from the loss of closing transactions underline the importance of continuous technological advancements and user education to ensure a secure and user-friendly experience.

As the Lightning Network matures, it will be interesting to observe how these challenges are addressed, potentially through the development of more robust mechanisms or user-friendly solutions that mitigate the need for constant online presence and enhance the overall reliability of the network. The evolving landscape of blockchain and cryptocurrency technologies often sees iterative improvements, and the Lightning Network is no exception in this dynamic ecosystem.

Third-Party Channel Transactions in the Lightning Network

Now, let’s delve into the technicalities of transactions involving third-party channels. The plot thickens. Consider a scenario where Anna needs to send 1 BTC to Julia, but lacking a direct channel, they utilize a mutual “friend” – an already opened channel owned by Joe.

How can we ensure the intermediary (Joe) sends the owed amount to the recipient? Let’s explore this together.

Transactions facilitating the exchange continue to have these two conditions. However, the special condition now includes a cryptographically hashed “password.” This password is formulated by the recipient, encrypted through a hash function, and shared with the sender and the intermediary. It’s sufficient to know that it’s impossible to derive the encrypted password (P) from the hash function, but it’s easy to derive the hash from the encrypted password. Let’s denote the hash as H and the password as P. Julia shares H with the involved parties, and the transactions are composed as follows:

1. Anna’s transaction with Joe:

•    1 BTC returns to Anna within 2 hours.
•    1 BTC goes to Joe if he can reveal P from H.

2. Joe’s transaction with Julia:

•    1 BTC returns to Joe within 1 hour.
•    1 BTC goes to Julia if she reveals P from H.

Julia, who formulated the password, can reveal it and fulfill the condition. Once P is revealed to Joe, he too becomes aware of it and can satisfy the condition of Anna’s transaction, recovering the BTC he gave Julia.

As observed, the temporal conditions are different to safeguard the intermediary. Assuming both temporal conditions are 2 hours; if Julia were to write her closing transaction on the blockchain after 1 hour, 59 minutes, and 59 seconds, she could withdraw Joe’s BTC. However, Joe could not write and publish the transaction in time to reveal P to Anna and retrieve the BTC.

Furthermore, once P is revealed, anyone can write the transaction on-chain. However, this would close the channel, which is inconvenient for all parties. Therefore, the participants agreed to exchange simple channel closure transactions with modified amounts, forgetting about H and P.

This entire process occurs entirely automatically. Participants can communicate without communicating over the phone or sending emails. The Lightning Network’s sophisticated protocol manages these complexities seamlessly, underscoring the efficiency and automation inherent in its design.

Decoding the Lightning Network: Insights and Considerations

In this Trakx blog post, we have delved into the technical workings of the Lightning Network. Understandably, it could be more intuitive and user-friendly. However, this issue is addressed through custodial wallets, which are riskier but more user-friendly. The advice is to load only the amount intended for short-term use onto custodial wallets. For the more experienced, it is worth delving into and testing this fascinating technology. It offers a solution to the block size issue without compromising the aspirations of small operators who wish to maintain a full node to decentralize our beloved Bitcoin.