Lightning Network – deel III

We zijn alweer aangekomen bij het derde deel van de serie over het Lightning Network! Nadat we je mee hebben genomen van de vraag waarom het netwerk nodig is tot de basis van het protocol, gaan we vandaag voorzichtig meer de diepte in. We hebben gezien hoe je met behulp van jouw kanaal met Starbucks ook betalingen kan doen naar anderen die een kanaal met Starbucks hebben. Alice kon Bob kon betalen door haar saldo in haar kanaal met de Starbucks node te verlagen en dat van Bob met dezelfde hoeveelheid te verhogen. Dit zag er als volgt uit:

voor de transactie
KANAAL ALICE – STARBUCKS: verdeling 5 BTC ALICE; 0 BTC STARBUCKS
KANAAL BOB – STARBUCKS: verdeling 3 BTC BOB; 2 BTC STARBUCKS

na de transactie
KANAAL ALICE – STARBUCKS: verdeling 4 BTC ALICE; 1 BTC STARBUCKS
KANAAL BOB – STARBUCKS: verdeling 4 BTC BOB; 1 BTC STARBUCKS

We hebben in het vorige deel de simpele cryptografische truc besproken waardoor Alice en Bob zekerheid hebben over de doorgang van de transactie. Het enige probleem waar we nu nog mee zitten is dat Starbucks er helemaal niet zeker van is dat Bob en Alice zich aan de afspraken houden. Als Starbucks de 1 BTC bij het saldo van Bob optelt, willen ze er zeker van zijn dat hij de inputwaarde aan hen geeft waarmee ze Alice kunnen bewijzen dat Bob zijn 1 BTC heeft gekregen. Daarbij willen ze de zekerheid dat Alice de 1 BTC terugbetaalt als ze de inputwaarde laten zien.

Om het Lightning Network te laten werken hebben we zekerheid nodig en moeten we niet afhankelijk zijn van vertrouwen. Als Starbucks een bitcoin aan Bob geeft, dan moeten ze zeker weten dat ze er eentje terugkrijgen van Alice.

Om dat te bewerkstelligen hebben we hash time-locked contracts nodig. In plaats van dat Alice de bitcoin direct naar Starbucks stuurt maken we gebruik van een speciaal soort bitcoin-adres. Alice stuurt de bitcoin naar een multi-signature adres. De bitcoins die naar dit adres worden toegestuurd kunnen vervolgens op twee manieren worden losgelaten.

De eerste manier waarop dat kan is met de handtekening van de Starbucks én de inputwaarde die ze van Bob hebben gekregen in ruil voor de bitcoin (de cryptografische truc die we eerder hebben besproken).

De tweede manier is simpelweg met de handtekening van Alice. Dit betekent dat ze de bitcoin die naar het adres is gestuurd blijkbaar ook terug kan claimen. Hoe weet Starbucks dan zeker dat ze dat niet doet voordat zij de inputwaarde van Bob hebben gekregen? Of stel dat de Starbucks Bob één bitcoin heeft gegeven voor de inputwaarde en Alice ze vervolgens te snel af is met haar eigen handtekening?

Dit is het punt waarop hash time-locked contracts om de hoek komen kijken! Bij de tweede manier om de bitcoin vanuit de wallet te verzenden – de handtekening van Alice – is opgenomen dat zij dit pas kan doen nadat een bepaalde tijdsperiode is verlopen – bijvoorbeeld 14 dagen. Ze kan de transactie wel publiceren, maar moet vervolgens twee weken wachten voordat hij wordt doorgevoerd.

De Starbucks heeft dus 14 dagen de tijd om een transactie te ondertekenen met de inputwaarde die ze van Bob hebben gekregen. Speelt Alice vals en probeert ze de transactie naar zichzelf te sturen, dan heeft de Starbucks nog twee weken om de transactie te publiceren en alsnog de bitcoin te claimen voordat Alice dat kan doen.

Als de Starbucks na twee weken de inputwaarde van Bob niet heeft gepubliceerd, dan krijgt Alice haar vastgezette bitcoins terug.

Om de transactie helemaal dicht te timmeren moet Starbucks ook zeker weten dat ze van Bob de inputwaarde krijgen op het moment dat ze een bitcoin naar hem sturen. Hier gebruiken we hetzelfde principe voor. Een belangrijk detail is dat het kanaal tussen de Starbucks en Bob eerder moet verlopen – bijvoorbeeld binnen 10 dagen – zodat Starbucks de inputwaarde krijgt vóór het moment dat Alice haar bitcoin terug kan claimen.

Begrijp je deze drie artikelen dan heb je een aardig begrip van hoe het Lightning Network in de basis werkt! In het volgende artikel over het Lightning Network gaan we het hebben over de argumenten tegen het protocol en bespreken we alternatieven om de schaalbaarheid van het Bitcoin protocol te realiseren, bijvoorbeeld het verhogen van de blokgrootte (Bitcoin Cash). Wederom bedankt voor het lezen en tot snel!

Geef een reactie