Deze ronde is gesloten

In onze vorige blogpost hebben we het schaalprobleem van blockchain besproken, hoe het Lightning Network een oplossing kan bieden en wat een payment channel precies is. Verder hebben we gezien hoe Alice een betalingskanaal met de Starbucks heeft geopend. Maar hoe werkt het nu als Alice een persoon of bedrijf wil betalen waar ze geen betalingskanaal mee heeft? Dat gaan we behandelen in deze blog!

Het zou onhandig zijn als voor iedere relatie een nieuw betalingskanaal geopend moet worden. Gelukkig is er voor dit probleem een ingenieuze oplossing bedacht! Om bijvoorbeeld haar vriend Bob te betalen hoeft Alice alleen maar op zoek te gaan naar een gemeenschappelijk betalingskanaal. Het toeval wil dat Bob ook een betalingskanaal met de Starbucks heeft! Zonder dat ze een nieuw betalingskanaal hoeft te openen met Bob, kan ze hem betalen via de Starbucks. Dit heet payment routing. Het Lightning Network protocol gaat op zoek naar de goedkoopste route van Alice naar Bob. Voor iedere tussenstop betaal je een kleine fee in satoshi

Voorbeeld: Alice stuurt via kanaal Starbucks 1 BTC naar Bob
Stel dat Alice een saldo van 5 BTC heeft in haar kanaal met de Starbucks en 1 BTC naar Bob wil overmaken, dan kan dit simpelweg verrekend worden. Haar saldo wordt 4 BTC en dat van de Starbucks stijgt met 1 BTC. Het saldo van Bob in zijn betalingskanaal stijgt met 1 BTC en dat van de Starbucks daalt met 1 BTC.

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

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

Het probleem met deze oplossing is dat Alice er op moet vertrouwen dat de Starbucks het geld naar Bob overmaakt. Wat ook kan gebeuren is dat Starbucks het geld overmaakt naar Bob, maar hij claimt het nooit te hebben gehad. Alice weet in dat geval niet wie er liegt. Dit probleem kan worden opgelost met een simpele cryptografische truc.

!WARNING! Het verhaal gaat nu iets technischer worden !WARNING!

Alice wil de zekerheid dat haar 1 BTC alleen aan de Starbucks wordt toegekend als Starbucks deze vervolgens doorstuurt naar Bob. Dit probleem lossen we op door gebruik te maken van hashing. Een hash kun je zien als de digitale vingerafdruk van een stuk data. Dezelfde input levert in een hashfunctie altijd dezelfde output op – vandaar de vergelijking met een vingerafdruk.

Voor het voorbeeld gebruiken we een SHA-256 hash calculator: https://www.xorbin.com/tools/sha256-hash-calculator

De hash van ‘Alice houdt van koffie’ = 1acaada0e599bd2b95a69481a6fbb4bd0e523fdd9a217be59ec860b09f734317

Verander je de input, dan verandert de output ‘alice houdt van koffie’ =
62eb427eea5a30ae7ed2e31e0c4bde55c02fca85195326d06d135b9f309e0428

Voor de transactie vraagt Alice aan Bob of hij een random input kan verzinnen en alleen de hash daarvan naar haar kan sturen. Alice krijgt de hash: 6f83d4b224ba0fb026adf224a813adf3d44f9903ecf9588cfc0d17ea169096a6. Ook zegt ze tegen Bob dat hij enkel de input aan Starbucks moet geven in ruil voor de 1 BTC.

Vervolgens zegt Alice tegen de Starbucks dat ze hen 1 BTC stuurt als ze haar de input geven die de hash oplevert die ze van Bob heeft gekregen. Die input wil Bob alleen geven in ruil voor de 1 BTC. Dus geeft de Starbucks 1 BTC aan Bob en krijgt de input ‘Bob wil zijn bitcoin’.

De Starbucks gaat vervolgens naar Alice en geeft haar de input ‘Bob wil zijn bitcoin’. Alice weet dat de Starbucks de input alleen van Bob kon krijgen in ruil voor de 1 BTC en weet dus dat ze hem hebben betaald. Ze kan heel simpel controleren of het klopt door de input in de hashfunctie te stoppen en te controleren of de uitkomst overeenkomt met de hash die ze eerder van Bob heeft gekregen.

Dat klopt! ‘Bob wil zijn bitcoin’ levert de hash: 6f83d4b224ba0fb026adf224a813adf3d44f9903ecf9588cfc0d17ea169096a6 op en komt exact overeen met de hash die ze eerder van Bob heeft gekregen! Alice weet zeker dat de Starbucks Bob heeft betaald en maakt de 1 BTC over naar de Starbucks! Alles is helemaal goed gegaan!

!WARNING! Dit was het technische gedeelte voor deze post !WARNING!

Het lijkt alsof we er nu helemaal zijn, maar we zitten nog met één klein probleem in dit verhaal! Hoe weet de Starbucks namelijk zeker dat Bob de input geeft als zij 1 BTC naar hem overmaken? En als ze de input al van Bob hadden gekregen, hoe weet de Starbucks dan zeker dat ze de 1 BTC van Alice krijgen als ze de input laten zien? Moet de Starbucks er maar op vertrouwen dat Alice en Bob eerlijk zullen handelen? Dan zou het Lightning Network natuurlijk niet werken.

De Starbucks mag dan wel een rijke organisatie zijn, maar ze zijn natuurlijk niet van plan om gratis geld weg te geven! Om het Lightning Network écht succesvol te maken moeten we niet afhankelijk zijn van vertrouwen. De overgang van de bitcoins moet volledig door het protocol worden gegarandeerd. Iedereen moet zekerheid hebben.

Hoe we dit probleem voor de Starbucks gaan oplossen lees je volgende week! Als we Hash Time-Locked Contracts (HTLCs), de technische oplossing voor dit probleem, gaan bespreken. De komende weken laten we ook onze lightning schijnen op de veelgehoorde kritieken op het Lightning Network, bijvoorbeeld het argument dat het protocol uiteindelijk voor een gecentraliseerd netwerk zal zorgen. Bedankt voor het lezen en tot volgende week!