• ino ino Ads by Toktok9ja
  • Balvinciglobal Balvinciglobal
  • Murya-Magazine-Banner Murya-Magazine-Banner



What is the Light­ning Net­work? A Beginner’s Guide

Image result for What is the Lightning Network? A Beginner’s Guide

If you’ve ever dealt in Bit­coin, you may have suf­fered through hour-long (or at worst, day-long) trans­ac­tion times. It’s becom­ing com­mon­place for Bit­coin to have back­logs of 150k+ uncon­firmed trans­ac­tions at times of high trans­ac­tion vol­ume, and when we cou­ple this with its exor­bi­tant fees, it’s a won­der how you’re ever gonna use it to pay for that 5 piece meal at KFC.

The light­ning net­work is here to help with that. This con­cept is the brain­child of Thad­deus Dry­ja and Joseph Poon, and the duo pre­sent­ed it with a whitepa­per back in 2015. If you’re not too keen on read­ing the lengthy paper chalk full of tech jar­gon, we’re gonna lay it out for you in layman’s terms here.

What is the Light­ning Net­work?

On its most basic lev­el, the light­ning net­work is a method for Bit­coin users to exchange cur­ren­cy val­ue off the Bit­coin blockchain. This is accom­plished using a few com­plex algo­rithms that inter­act with Bitcoin’s base script, and it allows for, that’s right, light­ning quick pay­ments at a frac­tion of the trans­ac­tion fees. As such, it’s been pre­sent­ed as a nec­es­sary scal­a­bil­i­ty tool, one that Bit­coin will need if it wants to be a viable pay­ment option in the future. This prac­tice can extend to cross-chain atom­ic swaps. These swaps are the same in prac­tice, except that they take place between two dif­fer­ent currencies/blockchains. We go over atom­ic swaps in more detail here.

Now that we’ve cov­ered the much-too-sim­ple expla­na­tion, it’s time for a length­i­er one.

Light­ning Net­work: How it Works

Open­ing a Bilat­er­al Pay­ment Chan­nel

To get start­ed using the light­ning net­work, you’d want to set up a pay­ment chan­nel. Pay­ment chan­nels are the trans­ac­tion avenue through which the light­ning net­work trans­fers val­ue. To estab­lish one, you have to open a trans­ac­tion for this chan­nel direct­ly on the blockchain.

“But I thought you said all of this takes place off-chain?” Don’t worry–it still does, but you first have to let the Bit­coin net­work know that you’re open­ing a trans­ac­tion. Once you’ve done this, you and the oth­er par­ty you’re trans­act­ing with will keep your own bal­ance sheet of the exchanges you make on the chan­nel. Trans­ac­tions and updat­ed account bal­ances will be record­ed on this ledger every time funds are moved, and after you’ve con­duct­ed your busi­ness on the chan­nel, you’ll broad­cast the final result to the blockchain to close the account.

Mul­ti-sig­na­ture Wal­lets

So if pay­ment chan­nels take place off-chain, where/how are the funds man­aged until they’re record­ed onto the blockchain?” What a good look­ing ques­tion. In order to use a pay­ment chan­nel, both par­ties need to send their funds to a mul­ti-sig­na­ture wal­let address.

Let’s say Mol­ly and Steve have placed bets on the out­come of the Super Bowl. They each wager 1 BTC and want to make sure that the oth­er holds his/her end of the bar­gain, so they deposit both of their funds into a mul­ti-sig­na­ture wal­let. This wal­let func­tions like a safe for deposits, while a set of pri­vate keys for the trans­ac­tions func­tion like com­bi­na­tions that allow either par­ty to access the funds. The funds will remain locked in the wal­let until: 

  • both Mol­ly and Steve sign a final­iz­ing trans­ac­tion with these pri­vate keys, 
  • one par­ty decides to final­ize the trans­ac­tion them­selves, or 
  • a time lim­it is reached and the trans­ac­tion is auto­mat­i­cal­ly sub­mit­ted. Once this hap­pens, the funds will be moved back to either party’s indi­vid­ual wal­lets. 

In order to suc­cess­ful­ly set up the mul­ti-sig­na­ture wal­let, both Mol­ly and Steve cre­ate a val­ue (essen­tial­ly, a secret key to unlock trans­ac­tions) which they then use to cre­ate a hash and send to each oth­er. Hold onto this information–it’s vital to under­stand­ing how com­mit­ment trans­ac­tions work lat­er.

Once Mol­ly and Steve deposit their respec­tive funds into the mul­ti-sig­na­ture wal­let, they can then cre­ate what’s called an open trans­ac­tion and broad­cast it to the blockchain. Once this is broad­cast­ed, a series of com­mit­ment trans­ac­tions are then used to man­age funds.

Trans­fer­ring Val­ue with Com­mit­ment Trans­ac­tions

Turns out, Mol­ly won the bet, but she’s nice, so she says Steve only owes her 0.5 BTC instead of 1. To ini­ti­ate a trans­fer of this wealth, both Mol­ly and Steve would update their respec­tive bal­ances in the pay­ment chan­nel by sign­ing a com­mit­ment trans­ac­tion. Com­mit­ment trans­ac­tions divide funds between both par­tic­i­pants per their mutu­al agreement–in essence, these trans­ac­tions act like IOUs that will be paid out once the pay­ment chan­nel is closed.

For exam­ple, in order to exchange val­ues, Mol­ly signs a trans­ac­tion that sends 1.5 BTC to her­self and .5 to a new mul­ti-sig­na­ture wal­let address. Then, she signs this trans­ac­tion and sends its hash to Steve. In turn, Steve signs a com­mit­ment trans­ac­tion to mir­ror Molly’s, where­in he sends .5 BTC to him­self and 1.5 to anoth­er mul­ti-sig­na­ture wal­let. He then signs this and sends this transaction’s hash over to Mol­ly.

So, we’ve got a) the orig­i­nal 2 BTC sit­ting in the pay­ment channel’s mul­ti-sig­na­ture wal­let, b) .5 BTC sit­ting in a mul­ti-sig­na­ture wal­let that’s payable to Steve, and c) 1.5 BTC sit­ting in a mul­ti-sig­na­ture wal­let that’s payable to Mol­ly. Effec­tive­ly, once either par­ty sends their respec­tive trans­ac­tion hash­es, the bal­ance sheet in the pay­ment channel’s mul­ti-sig­na­ture would update as both par­ties have agreed to the trans­fer. Vio­la, the cur­ren­cies have been exchanged with­out using Bitcoin’s blockchain.

The val­ues from these wal­lets can be unlocked only under three con­di­tions: 

  1. a cer­tain amount of time expires,
  2.  either par­ty unlocks the funds from the mul­ti-sig­na­ture wal­lets they set up with the wallet’s val­ue (key), or 
  3. both par­ties decide to sign off on the trans­ac­tion togeth­er. 

It’s impor­tant to note that, if one par­ty decides to close the chan­nel and sign off on a trans­ac­tion alone, s/he will have to wait a pre-deter­mined amount of time (dic­tat­ed by the con­tract) from the time that the trans­ac­tion is signed to receive his/her funds. This may seem exces­sive, but it’s imper­a­tive to pre­vent cheat­ing through pay­ment channels–more on this in a bit.

Recur­ring Payments/Updating the Chan­nel

What if Mol­ly and Steve want to keep updat­ing the chan­nel or make more than one exchange?

To illus­trate this fur­ther, say Steve was pay­ing Mol­ly for a recur­ring ser­vice, like a hair­cut. Steve deposits 0.2 BTC into their mul­ti-sig­na­ture wal­let, and every time he gets his locks trimmed, he signs a com­mit­ment trans­ac­tion to Mol­ly for 0.001 BTC and sends it to the new mul­ti-sig­na­ture address. To do this, he’d have to repeat the steps we just went over, sans open­ing a trans­ac­tion on the net­work as that’s accom­plished by the time the first com­mit­ment trans­ac­tion is signed.

So, to process recur­ring pay­ments, account bal­ances in the mul­ti-sig need to be updat­ed each time. To do this, every time Steve gets his hair­cut, he’d com­mit a new sum of mon­ey to the mul­ti-sig­na­ture wal­let that he set up to pay Mol­ly. But in doing so, he cre­ates a new val­ue and a new hash for this new trans­ac­tion. Mol­ly does the same, and when both par­ties exchange the new hash­es, they also include the old val­ues (keys) for the pre­vi­ous trans­ac­tion.

In effect, this ensures that nei­ther par­ty can cheat the oth­er. If upon clos­ing the pay­ment chan­nel Steve tries to cheat Mol­ly out of her pay­ments by broad­cast­ing an old trans­ac­tion amount, he’s in trou­ble.

For instance, if when he clos­es the chan­nel Steve owes Mol­ly 1 BTC out of the orig­i­nal 2 BTC he deposit­ed but he signs the orig­i­nal trans­ac­tion to give him­self the orig­i­nal amount, Mol­ly can call him on it because she has the val­ues from all pri­or trans­ac­tions. What’s more, Steve has to wait before his trans­ac­tion clears accord­ing to the time­frame both par­ties agreed on before con­duct­ing busi­ness, while Molly’s is instant. Thus, if she sees that she’s been paid 0 BTC for her ser­vices, she can sign off on the 2 BTC in the mul­ti-sig­na­ture wal­let because she has the key for this trans­ac­tion, and thus, the abil­i­ty to unlock its funds.

Thus, if one par­ty attempts to defraud anoth­er, the coun­ter­par­ty is award­ed all of the mali­cious party’s funds. This penal­ty is in place to deter bad actors from abus­ing the pay­ment channel’s shared fund allo­ca­tion.

Addi­tion­al­ly, node oper­a­tors and min­ers who spot this foul play can act on Molly’s behalf if she’s not online to notice the cheat­ing. In com­pen­sa­tion, these guardian angels are award­ed a boun­ty (fee) in the trans­act­ed cur­ren­cy for their ser­vices.

Clos­ing a Pay­ment Chan­nel

When Mol­ly and Steve are ready to close out their accounts, they sim­ply sign a trans­ac­tion with their pri­vate keys to broad­cast their final account bal­ances to the blockchain. At this point, min­ers will ver­i­fy it per usu­al and store it on the pub­lic ledger. As with an open­ing trans­ac­tion, this clos­ing trans­ac­tion is the only inter­ac­tion that either par­ty will have with Bitcoin’s blockchain.

Alter­na­tive­ly, two par­ties could also set an expi­ra­tion date for the length of the con­tract. For exam­ple, using the nLock­Time algo­rithm, they could open a pay­ment chan­nel for 30 days, after which time, the chan­nel will close and the final bal­ances will be broad­cast­ed to the blockchain. Every time the par­ties want to update their bal­ances, how­ev­er, the expi­ra­tion date is decreased. So, if Mol­ly and Steve were plac­ing bets on mul­ti­ple foot­ball games through­out a sea­son, every time a wager was paid, the nLock­Time con­tract would have a new, short­ened expi­ra­tion date (e.g., if the first com­mit­ment trans­ac­tion would be final­ized in 30 days, the sec­ond trans­ac­tion would pay out in 29, then the third would pay out in 28, and so on).

The pur­pose of nLock­Time con­tracts is sim­ple: it keeps account bal­ances up to date and pre­vents one par­ty from fal­si­fy­ing an account state­ment. Like we went over ear­li­er, every time a com­mit­ment trans­ac­tion is agreed upon, the old account bal­ance is replaced with a fresh one, and each involved par­ty has records of this new bal­ance as well as an old trans­ac­tions val­ue (key). If any par­ty attempts to defraud the oth­er, the fraud­u­lent par­ty will be penal­ized.

Mul­ti­chan­nel Pay­ments and Hash Time Locked Con­tracts

What if Mol­ly and Steve want to send Bit­coin to each oth­er but they don’t have a pay­ment chan­nel open?” Well, they can go through an inter­me­di­ary. We’ll call this guy Chuck–tell Chuck hel­lo.

Turns out, Mol­ly and Steve both have pay­ment chan­nels open with Chuck, so instead of open­ing up a new chan­nel, they decide to us their respec­tive bidi­rec­tion­al pay­ment chan­nels to trade through Chuck.

Now, this is the­o­ret­i­cal­ly a trust­ed trade, so the trick is facil­i­tat­ing the exchange in a secure way. To do this, the Light­ning Net­work imple­ments Hash Time Locked Con­tracts (HTLCs).

Say Mol­ly wants to give 0.5 BTC to Steve because she’s just real­ly nice like that–seriously, what a peach. In order to do so, Steve must cre­ate a string of cryp­to­graph­ic num­bers called a val­ue (essen­tial­ly a con­fir­ma­tion code or key). He then cre­ates a hash of this val­ue to send to Mol­ly. To sim­pli­fy this writ­ten illus­tra­tion, we’ll rep­re­sent val­ue with V and hash with H.

When Mol­ly receives H, she shares it with Chuck. At this point, Mol­ly will only send Chuck the 0.5 BTC if he reveals V. To get V, Chuck sends 0.5 of his own BTC to Steve in exchange for V. Once he has this num­ber, he sends V to Mol­ly who then sends 0.5 BTC to Chuck. And there you have it–Molly effec­tive­ly trans­ferred 0.5 BTC to Steve.

In case you got lost, here’s how it went down:

Steve cre­ates V and H→ Steve sends H to Mol­ly→ Mol­ly sends H to Chuck→ Chuck sends BTC to Steve→ Steve sends V to Chuck→ Chuck sends V to Mol­ly→ Mol­ly sends BTC to Chuck

Thus, the val­ue (V) serves as a con­fir­ma­tion code/key for the hash (H), which rep­re­sents a receipt/lock for the trans­ac­tion.

That’s all fine and dandy, but how does Mol­ly know that the val­ue Chuck sends her is legit, and what’s keep­ing Steve from run­ning away with the BTC Chuck pays him?”

Again, good ques­tions. Just as nLock­Time keeps every­one hon­est in a bidi­rec­tion­al pay­ment chan­nel, Hash Time Locked Con­tracts keep par­ties account­able in this mod­el.

With HTLCs, the Bit­coin funds being trans­act­ed are locked up yet again in a mul­ti-sig­na­ture wal­let and can only be unlocked a) after the val­ue (V) and hash (H) are pre­sent­ed or b) the con­tract expires after a time­out peri­od.

In effect, this means that, when Mol­ly and Chuck go into an agree­ment for Mol­ly to pay Steve, she locks the Bit­coin she owes Chuck in a mul­ti-sig­na­ture wal­let using the HTLC. Once Chuck pays Steve and receives V, he can then enter V and H into the HTLC to be reim­bursed with the Bit­coin Mol­ly com­mit­ted to the con­tract. Alter­na­tive­ly, if Chuck fails to hold up his end of the bar­gain and the con­tract expires after, say, a week, then Molly’s Bit­coin is freed up and goes back into her per­son­al wal­let.

The same inter­ac­tion takes place on Chuck and Steve’s own pay­ment chan­nel. Chuck can not relin­quish his Bit­coin to Steve until Steve reveals V. Once Steve reveals V into the mul­ti-sig con­tract, Chuck now has V and Steve receives his BTC.

This process could, the­o­ret­i­cal­ly, be run through mul­ti­ple pay­ment chan­nels and mul­ti­ple indi­vid­u­als.

Wrap­ping Up: Why the Light­ning Net­work Mat­ters

It’s a com­pli­cat­ed top­ic. Syn­the­siz­ing this infor­ma­tion into digestible chunks was hard enough, so cheers to you for stick­ing with it this long.

For a TL;DR recap: The Light­ning Net­work is an off-chain sys­tem that allows indi­vid­u­als to swap cur­ren­cies mul­ti­ple times with­out hav­ing to put all of these trans­ac­tions on-chain. Instead, only two trans­ac­tions (and open­ing and clos­ing) are record­ed on the blockchain, while all oth­er trans­ac­tions, as many as there may be, are processed through a sec­ondary lay­er of off-chain nodes.

There are a cou­ple of key ben­e­fits to this mod­el:

Effec­tive micro­trans­ac­tions: The Light­ning Net­work is geared towards micro­trans­ac­tions. Instead of hav­ing to pay exor­bi­tant fees that may out­weigh the val­ue being trans­ferred, the Light­ing Net­work allows users to send small sums of cur­ren­cy to each oth­er with­out hav­ing to go through the Bit­coin net­work direct­ly. They still have to pay a fee to node oper­ates, but it is minis­cule com­pared to Bitcoin’s usu­al net­work fee.

Scal­a­bil­i­ty and laten­cy solu­tions: Going along with the pri­or point, the Light­ning Net­work would cut back on net­work bloat. Reduc­ing the num­ber of on-chain trans­ac­tions means less work for min­ers which, in turn, means faster trans­ac­tion times and low­er fees. If every trans­ac­tion doesn’t have to be put on the blockchain’s pub­lic ledger, the net­work would run much more smooth­ly. Fur­ther, Light­ning Net­work trans­ac­tions would be much quick­er than those on-chain.

You’re prob­a­bly won­der­ing how any aver­age user would be able to nav­i­gate the mul­ti-step process we just out­lined prop­er­ly. Well, Dry­ja, Poon, and oth­ers are work­ing on applications/interfaces that work out all of the com­pli­cat­ed steps for you–all you have to do is press a few but­tons.

Cur­rent­ly, Light­ning Net­works are being devel­oped for Bit­coin, Lite­coin, and Vert­coin. The Light­ning Net­work is still in test­net, and no main net launch date has been con­firmed yet at the time of this pub­li­ca­tion.

Orig­i­nal Arti­cle was first Pub­lished at Coin­Cen­tral

Leave a Reply

Your email address will not be published. Required fields are marked *