Lightning Network är förmodligen den mest efterlängtade tekniska innovationen som läggs ut ovanpå Bitcoin. Betalningsskiktet, som först föreslogs av Joseph Poon och Tadge Dryja för ungefär ett år sedan, lovar att stödja ett praktiskt taget obegränsat antal off-chain-transaktioner bland användare, nästan utan kostnad – samtidigt som den säkerhet som erbjuds av Bitcoin utnyttjas.

Minst tre företag – Poon och Dryja’s Blixt, Blockstream och Blockchain – arbetar för närvarande med implementeringar av tekniken. Men få utanför denna lilla tekniska frontlinje förstår fullständigt hur “framtiden för mikrobetalningar” sätts för att öka Bitcoins kapacitet.

I denna tredelade serie, Bitcoin Magazine beskriver grundläggande byggstenar i Lightning Network och visar hur de passar ihop för att förverkliga detta kommande protokolllager.

Den första delen av denna serie täckte grundläggande byggstenar och förklarade hur dessa används för att skapa dubbelriktade betalningskanaler. Denna andra del förklarar hur dubbelriktade betalningskanaler förvandlas till ett nätverk.

Nätverket

I den tidigare artikeln etablerade Alice och Bob en dubbelriktad betalningskanal. Nu vill Alice betala en bitcoin till en tredje person, Carol.

För att göra det kunde Alice och Carol öppna en betalningskanal mellan dem. Men det behöver de faktiskt inte. Som det visar sig har Bob och Carol redan en gemensam kanal, så Alice kan helt enkelt betala Carol genom Bob.

Specifikt kan Alice betala Bob en bitcoin och Bob kan betala Carol en bitcoin.

Alice litar dock inte riktigt på Bob – eller Carol för den delen. Hon är rädd att om hon betalar Bob, kommer Bob aldrig att betala Carol. Eller kanske Bob kommer betala Carol, men Carol kommer att hävda att hon aldrig fått pengarna, och Alice skulle inte veta vem hon skulle skylla på.

Alice vill därför se till att hon bara betalar Bob en bitcoin, om han betalar också Carol en bitcoin. Detta åstadkommes (delvis) med ett enkelt kryptografiskt trick.

När Alice vill skicka en bitcoin till Carol ber hon Carol att skapa ett värde (en slumpmässig nummersträng) och skicka hashen till henne. Alice ber också Carol att byta ut det ursprungliga värdet med Bob mot en bitcoin.

Alice tar emellertid haschen från Carol, vänder sig till Bob och säger till Bob att hon kommer att ge honom en bitcoin om han ger henne motsvarande värde (som bara Carol har).

Så Bob vänder sig till Carol och ger Carol en bitcoin i gengäld för värdet.

Sedan vänder Bob tillbaka till Alice med värdet. Alice vet att Bob måste ha fått värdet från Carol i utbyte mot en bitcoin, och avslutar därför att Carol fick sin bitcoin. Så Alice kan med säkerhet ge Bob en bitcoin.

Alla är glada.

Väl… nästan alla är glada.

I det här “naiva” scenariot måste mellanhänder Bob fortfarande lita på Alice och Carol. Bob måste lita på Carol för att verkligen ge honom värdet efter att han skickat henne en bitcoin, och Bob måste lita på Alice att verkligen ge honom en bitcoin när han presenterar värdet för henne.

Bitcoin-för-värdet-affärer måste därför garanteras absolut längs nätverket. Mer specifikt: om Bob ger en bitcoin till Carol, han måste garanteras få tillbaka bitcoin från Alice.

Det är där Hash Time-Locked Contracts (HTLCs) kommer in.

Hash tidslåsta kontrakt

Så Alice och Bob vill byta ut en bitcoin för värdet genom en HTLC. (Och Bob och Carol vill också byta bitcoin för samma värde – men tänk på det för tillfället.)

För att göra det, snarare än att skicka Bob en bitcoin rakt upp, skickar Alice en bitcoin till en ny (och återigen: funky) multisig-adress. Bitcoins som är låsta på den här adressen kan låsas upp på två olika sätt.

Det första alternativet är att Bob ska inkludera sin signatur och värdet.

Det andra alternativet är att Alice ska inkludera sin egen signatur. Det här alternativet har dock en CLTV-tidslås: Alice kan underteckna och sända transaktionen först efter – säg – två veckor har gått.

Detta innebär att Bob har två veckor på sig att skapa en efterföljande transaktion där han inkluderar sin signatur och värdet och sänder det för att skicka bitcoin från den funky multisig-adressen till sig själv. Som sådan är denna handel garanterad. Bob kan endast hävda Alice’s bitcoin om han ger värdet: att sända det över Bitcoin-nätverket gör det offentligt synligt för Alice att se.

Och om Bob inte ger värdet i tid, finns det ett “time-out-alternativ” för Alice att få tillbaka sin bitcoin. Enkel.

Tillbaka till nätverket, eftersom det verkligen är varför denna HTLC-installation behövs.

Som nämnts etablerade inte bara Alice och Bob utan även Bob och Carol en HTLC. Så, om Carol hävdar sin bitcoin från Bob, Bob kommer få tillbaka värdet; det kommer att synas på blockchain.

Därför, om det händer, Bob kommer garanterat också att få en bitcoin från Alice. Bob kan ta det värde som Carol gjorde offentligt synligt på blockchain, inkludera det i sin HTLC med Alice och hävda en bitcoin för sig själv också. De två kanalerna är effektivt kopplade.

Som en sista detalj, det är viktigt att Bob får värdet från Carol innan Alice kan återta sin bitcoin från Bob. Om Bob bara får värdet från Carol efter Alice återvände redan sin rygg, Bob är trots allt fast i mitten. Tidsgränsen i Bob och Carol’s HTLC måste därför löpa ut innan time-out i Alice och Bobs HTLC löper ut. (Till exempel efter exakt tio dagar, istället för två veckor. Det är också därför HTLC: er behöver CheckLockTimeVerify (CLTV) –och inte CheckSequenceVerify (CSV).)

Slutligen finns det ytterligare ett problem att lösa: för att blixtnätverket ska vara användbart måste allt detta utföras utanför kedjan. Hur detta görs beskrivs i den tredje och sista artikeln i denna serie.