Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Understand Lightning Network Part 2

Par Anis BENZIANE Publié le 08/07/2019 à 19:37:33 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Introduction

Lightning has been one of the most talked about subjects in the bitcoin community for years, its a new protocol built on the Bitcoin block chain that allows for more scalability.

Ascribing Blame

To start the penalization process you first need to figure out who to blame, in order to do so, you must figure out who broadcast an older transaction , this happens by having half signed transactions in each party’s possession, so Alice has transactions that were signed by Bob and vice versa, these transactions spend from the same outputs but have different contents, and you can easily find which of these transactions were broadcast and trace it back to Alice or Bob.

Contract Revocation

This happens by having different types of outputs on the most recent commitment and the older commitments, the most recent commitment has two path ways the first is a delivery output, spending the outputs of the counter party immediately and the second is a Revocable delivery output, this spends the rest of the outputs back to yourself, this is a time-locked output that can only be redeemed after a certain block number. When the commitment transaction becomes an old one another type of output is added and that is the Breach Remedy output, the breach remedy output is used as a penalization output as it immediately spends your outputs to your counterparty.

For example: Lets say the current agreed upon allocation is 0.5 btc to Bob and 0.5 btc to Alice, Bob has a commitment transaction that immediately spends 0.5 btc to Alice and spends 0.5 to himself only redeemable after 1000 blocks, Alice has a commitment transaction that immediately spends 0.5 to Bob and spends 0.5 to herself only redeemable after 1000 blocks, if the allocation changes to 0.2 to Bob and 0.8 to Alice, another commitment transaction is created that is identical to the previous one but with the new allocations, however, a breach remedy output is added to the previous transaction. In Bob’s transaction it immediately spends Bob’s coins to Alice and vice versa, this output works as a penalization mechanism as if one party broadcasts an old transaction, within the first 1000 blocks the counter party can redeem all the coins, not just his own.

Most of the time all these security measures will not be enforced, in case both parties are cooperative they can broadcast to the block chain the current state at any time, one party member can can contact the other party and spend from the funding transaction with an output that matches the outputs of the most current commitment transaction, this allows both party members to update the channel as they wish as long as the other party member agrees, so balances can move in both directions as long as it equals or its less than the total funds in the Funding transaction, cooperative closing of the channel reduces the number of transaction that occur on the block chain and both parties will receive their funds immediately, no need to wait a 1000 blocks for the revocable delivery output.

Hashed Timelock Contracts

All of this is great, but it still doesn’t explain how we can use this for anything other than two participants and here comes the beauty of Hashed Timelock Contracts, HTLC for short, the purpose of an HTLC is to allow for a global state across multiple nodes via hashes, it works by making an output that is dependent on a data input from a known hash, lets explain this with an example.

Say I’m Bob and I want to pay the book store, but I only have a payment channel with Alice and I don’t want to open another one, Alice has a payment channel with Martin who in turn has a payment channel with the book store, so I generate a random data R and hash it with my private key H, then I send the private key to the book store and on my payment channel with Alice I initialize a HTLC output stating that if Alice has certain data from a known hash H, i’ll send her 0.1 btc. But if 3 days have passed and she doesn’t have them, i’ll just take my money back. Alice in turn starts a HTLC output with Martin with the same conditions, only its 2 days not 1, and Martin starts one with the coffee shop with the same conditions and only with 1 day, now Alice and Martin know that their money is safe, as Bob promised Alice the money if she has the data and Alice promised Martin the money if he has data the coffee shop has the private key so it can send back the data to Martin and claim the 0.1 btc, which in turn sends it back to Alice and claim the money and so on until the money is claimed from Bob, this way Bob can cryptographically prove that the money arrived to the book store and if one node in the path to the book store is not cooperative, you can always find another node that has a path to the bookstore, the only problem is that you might have to wait for that HTLC to fail and you get your “promised” money back.

Sometimes the receiver may not be able to produce the preimage R in the first day, if that happens and the receiver could produce it in any subsequent days, the receiver should not disclose R to any of the multihop channel participants, as if they do, some nodes can claim payment without any obligation to pay the receiver, in which case the sender will have spent the money only to land in the pockets of one of the intermediary nodes, not the receivers’.

It is important not to send huge amounts of money per HTLC. In case one of the nodes in the path is uncooperative, the payment will get stuck and the sender must wait until the expiry before receiving the funds again, it is recommended to use small payments while keeping in mind the tradeoff between transaction fees on a long route and the amount of coins you can risk being locked up.

To settle the transactions on the block chain, there two different cases, one is that the sender broadcasts the commitment transaction that includes the HTLC, this assumes that this HTLC was never settled off chain, the other party can produce the preimage R and they will be able to redeem the funds from the HTLC on the block chain, if the time has passed then the sender can broadcast a Timeout transaction , this transaction is a RSMC transaction and does not need preimage R to be redeemed and it can only be redeemed after 1000 blocks, after the maturity period the sender can broadcast an HTLC Timeout Revocable Delivery transaction and claim the funds. If the receiver broadcasts the transaction he has two options, either to produce R and broadcast an HTLC Execution transaction, wait for 1000 blocks and then broadcast an HTLC Execution Revocable delivery transaction that will immediately release the funds to him. Or if the time has passed and he wasn’t able to produce the R image, the sender can broadcast an HTLC timeout delivery transaction and claim the funds immediately.

Lightning network fees are paid directly between nodes within the channel, they are not for computing power like block chain fees, rather they are for the time-value of money that a node risks in a channel, its like you are leasing them money from a node for a certain time and paying them for that time.

Lightning Risks

Lightning isn’t all good though, while being one of the most innovative techniques in Bitcoin, some of the risks it bring to the table is

Improper Timelocks

If participants choose timelocks with insufficient time it is possible that the transactions believed to be invalid become valid, enabling coin theft by the counterparty, so there is always a trade-off between longer timelocks and more fees.

Forced Expiration Spam

If one malicious node creates many channels and forces them all to expire at once, these may cause spam on the block chain itself which can cause some timelocked transactions to become valid.

Coin Theft via Cracking

One of the risks of having a channel is that your private key must always be online as its being used continuously to sign, while the risk can be reduced for the sender and the receiver, the intermediary nodes are always online and so they must have good security to be able to out-compete others in the long run and conduct greater transaction volumes.

Data Loss and Forgetting to Broadcast in Time

In case a party loses data or forgets to broadcasts in time, the counterparty can steal funds, these risks can be mitigated by delegating a third party service to hold the data or watch the block chain for you.

Conclusion

Lightning network bring different use cases that were not and could not be available on the block chain, like Instant transactions, Exchange Arbitrage, Micropayments, Smart Contracts and Cross-chain payments.

Cross-chain payments is probably the most innovative use of Lightning, it uses Lightning on different block chains to make a trustless trade between two parties in different block chains, so lets say I have 100 Litecoins and 5 Bitcoins and Bob has 2 Bitcoins and needs 40 Litecoins, through HTLC I can send the Litecoins to Bob in exchange for a data that I am sure will get me his 2 Bitcoins, this can diminish the need for centralized exchanges that has a single point of failure risk.

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels