Lightning Network

Beim Lightning Network handelt es sich um einen Timelocked Off-Chain Payment Channel. Es ermöglicht schnelle Bitcoin-Zahlungen.

Was ist das Lightning Network?

Das Lightning Network ist eine Offchain-Lösung für Bitcoin-Zahlungen. Das heißt, Nutzer können BTC abseits der Bitcoin Blockchain, fixieren und an andere Nutzer senden. Das Versenden von Werten erfolgt nahezu instantan und bedarf, ähnlich wie bei On-Chain-Transaktionen, keiner vertrauenswürdigen Drittinstanz. Das Lightning Network gilt als vielversprechende Skalierungslösung für Bitcoin.

Die Sache mit der Skala 

Bitcoin soll ein elektronisches Geldsystem sein, bei dem sich die Teilnehmer direkt Geld zusenden können. Ein Geldsystem, das nicht von einer Zentrale kontrolliert wird, sondern auf einem Computerprotokoll basiert. Theoretisch sollte dieses Geldsystem allen Menschen auf der Welt zugänglich sein. Damit wäre ein universeller Währungsstandard gegeben; eine gemeinsame „Sprache“ für die ganze Menschheit.

Doch die Theorie lässt sich nicht so einfach in die Realität umsetzen. Auch wenn Bitcoin bereits ein elektronisches Geldsystem ohne kontrollierende Mittelsmänner ist, kann es nicht von allen Menschen genutzt werden. Der Grund dafür ist die Skala, die dafür erforderlich ist.

Das Problem verdeutlicht sich, wenn man sich vorstellt, wie viele Transaktionen täglich in der Weltwirtschaft stattfinden. Während die Bitcoin Technologie problemlos gigantische Summen transferieren kann, stößt sie an ihre Grenzen, wenn es um eine hohe Frequenz an Transaktionen geht. Der Grund dafür ist technischer Natur: Die Blockchain, auf der alle Transaktionen festgehalten werden, bietet nur limitierten Platz für Transaktionen.  

Das kann man sich ein bisschen wie ein Bus vorstellen. Dieser Bus hat eine begrenzte Anzahl an Sitzen. Wenn alle Sitze voll sind, können nicht mehr Leute mitfahren. Ganz ähnlich verhält es sich mit den Blöcken in der Bitcoin-Blockchain. Auch diese haben nur eine bestimmte Anzahl an „Sitzplätzen“ für Transaktionen. Wenn alle Plätze belegt sind, können nicht mehr Transaktionen „mitfahren“ (also bestätigt werden).  

Ein Mechanismus in Bitcoin ist, dass die Transaktionen durch ihre Transaktionsgebühr sich einen Sitzplatz im Bus sichern können. Das heißt, wenn Alice eine super wichtige Transaktion an Bob schicken möchte, die auf jeden Fall im nächsten Bus Platz finden soll, kann sie eine überdurchschnittlich hohe Gebühr bezahlen. Der „Busfahrer“ (der Miner) muss die Transaktion nicht mitfahren lassen, allerdings kann er sich einen schönen Pfennig dazu verdienen, wenn er es tut. Er hat also einen ökonomischen Anreiz der Transaktion Platz in seinem Bus zu machen.  

Alles schön und gut, oder? Noch nicht, denn was passiert, wenn das jeder macht? Der Platz auf der Blockchain, der Platz im nächsten Block, im nächsten Bus, ist fest limitiert. Wenn mehr und mehr Menschen das Bitcoin-Geldsystem nutzen wollen, immer mehr Transaktionen sich in den Bus drängeln wollen, dann steigen die Transaktionsgebühren. Denn die Transaktionen stehen durch ihre Gebühren miteinander im Wettbewerb für einen Platz auf der Blockchain. Im Dezember 2017 konnte man ein Beispiel von diesem Hochbieten der Transaktionsgebühren sehen.  

Wie viele Transaktionen kann Bitcoin pro Sekunde verarbeiten? 

Eine oft rezitierte Metrik, wenn es um die Funktionalität von Bitcoin geht, sind die Transaktionen pro Sekunde. Ein Block in Bitcoin darf maximal 1 Megabyte groß sein. Eine durchschnittliche Transaktion hat eine Größe von 400 Byte. Das heißt, im Schnitt passen 2.500 Transaktionen in einen Block. Ungefähr alle 10 Minuten wird ein neuer Block gefunden. Folglich kann das Bitcoin-System ungefähr 4 Transaktionen pro Sekunde verarbeiten.  

Wie viel Transaktionen pro Sekunde kann die Bitcoin-Konkurrenz? 

Um etwas Perspektive auf die Kapazität von Bitcoin zu bekommen, vergleichen wir die Transaktionen pro Sekunde mit zwei attraktiven Alternativen; Visa und Paypal. Während die Bitcoin Blockchain bei mehr als vier Transaktionen pro Sekunde an ihre Grenze stößt, kann PayPal bis zu 115 Transaktionen pro Sekunde verarbeiten. Marktführer Visa macht ohne Probleme sogar 2.000 Transaktionen pro Sekunde, zu Stichzeiten auch 4.000 Transaktionen. Nach eigenen Angaben kann Visa aber weit mehr: Bis zu 56.000 Transaktionen in der Sekunde sollen möglich sein. Wie kann Bitcoin da mithalten und zu einem globalen Zahlungssystem werden? 

Zwei Nuancen müssen bei dieser Diskussion allerdings auch Erwähnung finden: Die Transaktionsgröße und die Finalität einer Transaktion.  

In Bitcoin ist es für die Gebühren und das Netzwerk egal, ob ein Betrag von 0,001 BTC oder 10.000 BTC versendet wird. Was zählt ist die Anzahl der Inputs und Outputs der Transaktion. Bei alternativen Zahlungssystemen wie Visa und PayPal zahlt man stattdessen meist eine prozentuale Gebühr am Transaktionsbetrag. Große Beträge zu versenden ist dementsprechend teuer. 

Die Finalität der Transaktion beschreibt die Möglichkeit, dass die Transkation zurückgenommen werden kann. Bei Bitcoin ist das sehr schwierig: Sobald eine Transaktion abgeschickt ist und in einen Block geschrieben wurde, kann sie kaum wieder rückgängig gemacht werden. Das ist ein Vorteil, denn Verkäufer können sich so sicher sein, dass der vermeintlich freundliche Kunde sie nicht nachträglich betrügt. Anders ist dies bei PayPal und Visa: hier gibt es einen Zeitraum (meistens 30 bis 120 Tage) in denen die Zahlung widerrufen werden kann. Möglich ist das, da PayPal oder Visa die zentrale Autorität im Geldsystem sind. Sie bestimmen die Geschichte der Transaktionen und können diese auch nachträglich verändern.  

Während Bitcoin in der Transaktionsfrequenz also das Nachsehen hat, kann die Technologie bereits jetzt massiv in Sachen Transaktionsgröße und finanzieller Finalität punkten.  

Lösungsansätze für die Skalierung: On-Chain vs. Off-Chain 

Die Frage nach der Transaktionskapazität wird auch oft die Skalierungsfrage genannt. Im Kern hat sie mittlerweile den selben Charakter wie die Gretchenfrage in Goethes Faust angenommen: 

 Nun sag, wie hast du’s mit der Skalierung?”

Grundsätzlich lassen sich die Antworten in zwei Lager aufteilen: On-Chain-Skalierung und Off-Chain-Skalierung.  

Der Ansatz On-Chain-Vertreter, um auf das Bus Beispiel zurückzugreifen ist, den Bus zu vergrößern. Das heißt die Blöcke auf 1 Megabyte zu limitieren, wird eine neue Obergrenze für den Block festgelegt. So passen mehr Transaktionen in der Bus, der nach wie vor alle 10 Minuten abfährt. Angenommen die Blockgröße erhöht sich auf 10 Megabyte, dann erhöht sich auch die Anzahl der Transaktionen pro Sekunden um das 10-fache. Das heißt es wäre dann möglich circa 40 Transaktionen pro Sekunde zu verarbeiten. Der Weg über die Erhöhung der Blockgröße die Kapazität der Blockchain zu verbessern findet seinen Ausdruck in der Bitcoin Hard Fork Bitcoin Cash (BCH).  

Die Alternative dazu ist das Off Chain Scaling. Hier möchte man nicht die Transaktionskapazität der Blockchain selbst verbessern, sondern eine zweite Ebene für Transaktionen schaffen, die an die erste Ebene, an die Blockchain, andockt. Diese zweite Ebene (auf Englisch: Second Layer) würde die Sicherheitsaspekte von Bitcoin erben, und zudem eine Magnitude mehr Transaktionen erlauben. Also anstatt linear zu skalieren, wie beim On-Chain-Ansatz, könnte mit der zweiten Ebene Millionen von Transaktionen abgewickelt werden. Und das sofort, zu sehr geringen Beträgen und mit ähnlicher Sicherheit wie beim Bitcoin-System selbst. Diese Methode Bitcoin außerhalb der Blockchain zu skalieren hört auch auf den Namen Lightning Network. 

Das Lightning Network 

Das Lightning Network (kurz: LN) ist für viele Bitcoin-Vertreter die logische nächste Entwicklung des Bitcoin Zahlungssystems. Vorstellen kann man sich die Architektur wie eine Torte mit mehreren Schichten. Die Bitcoin Blockchain ist der Boden, oder die sogenannte Base Layer. Darauf aufbauen würde das Lightning Network. Gewisse Charakteristika der Base Layer könnten geerbt werden, wie beispielsweise Sicherheit, während andere Limitierungen nicht mehr gelten, eben die limitierte Anzahl an Transaktionen.  

Erreicht wird die Verknüpfung von Base Layer und Lightning Network durch eine Reihe von kryptografischen Mechanismen.  

Zahlungskanäle – Die Basis des Lightning Network 

Kern des Lightning Network sind Zahlungskanäle (Payment Channels). Ein Zahlungskanal kann man sich wie einen Tunnel zwischen zwei Parteien, Alice und Bob, vorstellen. Er verbindet Alice und Bob also direkt miteinander. Der Unterschied zwischen einem Zahlungskanal und einer Transaktion auf der Blockchain ist, dass Zahlungen innerhalb des Tunnels nicht auf der Blockchain festgehalten werden. Stattdessen können Alice und Bob den Stand des Zahlungskanal immer weiter aktualisieren und erst wenn sie „fertig“ sind den letzten Zustand auf die Blockchain schreiben. Die Aktualisierung des Zahlungskanals passiert außerhalb der Blockchain und ist nicht an deren Limitierungen gebunden. Alice und Bob könnten mehrmals pro Sekunde den Stand ihres Kanals erneuern. Mit anderen Worten, Micro-Transaktionen werden so nicht nur möglich, sondern auch plausibel.  

Wer also das Lightning Network verstehen will, sollte im ersten Schritt Zahlungskanäle verstehen. 

Unidirektionale Zahlungskanäle 

Der klassische Kanal oder Payment Channel besteht zwischen zwei Teilnehmern (Peers), Alice und Bob. Für den Kanal wird die Multisignature-Technologie Bitcoins und eine sogenannte Locktime genutzt. Mithilfe von Multisignature-Transaktionen können Transaktionen generiert werden, die mehr als einen Private Key zum Signieren einer Transaktion benötigen. Im Fall von Zahlungskanälen generiert man sogenannte 2-2-Multisig-Transaktionen. Das heißt, dass die mit dieser Transaktion zusammenhängenden Bitcoin die Zustimmung beider Parteien für ein Senden benötigen. Die Locktime sorgt dafür, dass für eine bestimmte Dauer die Coins innerhalb der Multisig nicht transferierbar sind. 

Stellen wir uns das Ganze an einem Beispiel aus der echten Welt vor: Bob betreibt einen Kaffeeladen bei dem Alice jeden Morgen einen Kaffee kauft. Damit Alice nicht jedes Mal eine Transaktion in die Blockchain schreiben muss, die relativ lange dauert und viel kostet. Eröffnet sie daher einen Zahlungskanal mit Bob. Sie schickt dafür einen bestimmten Betrag, in unserem Beispiel 10.000 Satoshi an eine 2-2 Multi-Sig-Adresse. Dabei kontrolliert Alice einen private Key und Bob den anderen. Damit eine gültige Transaktion in die Blockchain geschrieben werden kann, müssen sowohl Alice wie auch Bob die Transaktion signieren.  

Zudem bringt Alice eine zweite Transaktion ein, die nach einem Monat die 10.000 Satoshi automatisch an ihre Adresse zurückschickt. Das ist ihre Absicherung. Sollte es also zu Problemen mit Bob kommen, erhält Alice nach einem Monat ihr Geld zurück. Bob könnte die 10.000 Satoshi also maximal für einen Monat als „Geisel halten“ – nicht für immer. 

Zum einen hat Alice nun einen Zahlungskanal zu Bob eröffnet, zum anderen hat sie eine Absicherung, dass sie spätestens in einem Monat an ihr Geld wiederkommt. Wie funktioniert dieser Zahlungskanal jetzt? 

Wenn Alice nun am Morgen bei Bob in den Kaffeeladen kommt, hat sie in dem Zahlungskanal 10.000 Satoshi und Bob hat Null Satoshi. Alice bezahlt ihren Kaffee indem sie den Stand des Kanal updated. Dafür kreiert sie innerhalb der Multi-Sig-Wallet eine Transaktion, die ihr nur noch 9.000 Satoshi schicken würde und Bob 1.000 Satoshi. Diese Transaktion signiert sie und schick diese an Bob. Bob hat jetzt eine signierte Transaktion von Alice für die 2-2 Multi-Sig-Wallet. Das heißt er könnte sich entscheiden ebenfalls seine Signatur hinzuzufügen und dann diese Transaktion (9.000 Satoshi an Alice, 1.000 an Bob) in die Blockchain zu schreiben. Das tut er allerdings nicht, da er weiß, dass Alice morgen wiederkommt. Ihm reicht die Gewissheit, dass er jetzt bereits einen signierten Scheck von Alice hat. Diesen kann er jederzeit vor Ende der Locktime selbst unterschreiben und dann wie eine normale Transaktion in die Bitcoin Blockchain schreiben.  

Am nächsten Morgen kommt Alice wieder in den Laden um Kaffee zu kaufen. Wieder zahlt sie über den Zahlungskanal. Also, sie kreiert eine neue Transaktion in der Multi-Sig-Wallet, die ihr jetzt nur noch 8.000 Satoshi schickt und dafür 2.000 Satoshi an Bob. Diese Transaktion signiert sie und händigt den metaphorischen Scheck Bob aus. Diese inkrementale Aktualisierung kann so lange fortgesetzt werden, bis die Locktime abgelaufen ist. Oder bis Alice kein Geld mehr in dem Kanal übrig hat, das sie ausgeben kann. 

In diesem Kontext erklärt sich auch der Begriff „Off Chain“ gemeint ist. Alice bezahlt Bob mit Bitcoin, allerdings berühren diese Zahlungen nicht direkt die Blockchain. Sie passieren außerhalb der Blockchain (Off Chain).  

Der Vorteil ist also, dass Alice jeden Morgen ihren Kaffee kaufen kann. Das tut sie nicht mit einer Transaktion auf der Blockchain, sondern mit einem Scheck für Bob, den dieser jederzeit einlösen kann. Vorher muss Alice eine Art Pre-Paid-Konto aufladen, von dem sie dann die einzelnen Transaktionen abziehen kann. Wenn Bob den Scheck einlöst, oder wenn die Locktime ausläuft, wird der Zahlungskanal geschlossen. Eine Transaktion wird in die Blockchain geschrieben und verteilt das übrige Geld entsprechend an Alice und Bob. 

In der Blockchain stehen nur zwei Transaktionen. Einmal die Transaktion, die die Multi-Sig-Wallet finanzierte und einmal eine Transaktion, die den Zahlungskanal schließt. Aber zwischen diesen 2 Transaktionen auf der Blockchain hätten eine Million oder mehr kleine Transaktionen zwischen Alice und Bob stattfinden können.  

Bisher haben wir allerdings nur einen unidirektionalen Zahlungskanal betrachtet. Also wenn Alice ausschließlich Geld an Bob schickt (wie eben beim Kaffeekauf). Doch wenn das Ganze auch in die andere Richtung funktionieren soll, wird die Sache etwas komplizierter. 

Commitments – Wenn Kanäle in beide Richtungen gehen sollen 

Damit die Grundlage für das Lightning Network gelegt ist, bedarf es bidirektionaler Zahlungskanäle. 

Nur müssen diese Zahlungskanäle auch „vertrauenlos“ etabliert werden. Das heißt, beide Parteien können nichts durch Betrug gewinnen und es bedarf keiner schlichtenden dritten Partei.  

Ein Szenario wäre zum Beispiel, dass Bob einen alten Zustand des Zahlungskanals auf die Blockchain schreibt. Falls Alice die Zahlung im Zahlungskanal schon akzeptiert hätte und Bob eine Ware ausgehändigt oder eine Dienstleistung erbracht hätte, wäre sie so um ihr Geld betrogen. Dies darf natürlich nicht passieren. Deswegen bedürfen bidirektionalen Zahlungskanälen einen extra Schritt. Es muss eine kryptographische Absicherung für beide Parteien eingerichtet werden, damit die Teilnehmer nicht ungestraft auf alte Zahlungskanalzustände zurückgreifen können.  

[Recap – Zusatzinformation] Warum ist dieses Szenario bei unidirektionalen Zahlungskanälen kein Problem? Beim unidirektionalen Zahlungskanal zahlt nur Alice an Bob Geld. Dafür händigt sie Bob immer wieder einen von ihr signierten Scheck mit dem aktualisieren Stand des Kanals. Zu keinem Zeitpunkt bekommt Alice von Bob einen signierten Scheck. Das bedeutet, dass sie keine Transaktion von der Multi-Sig-Wallet tätigen kann, denn für diese braucht sie zwei Signaturen. Bob auf der anderen Seite gewinnt mit neuen Transaktionen immer nur mehr Geld. Er würde aus ökonomischem Eigeninteresse keinen alten Zustand in die Blockchain schreiben, da dies bedeuten würde, er bekäme weniger Bitcoin als Alice ihm eigentlich überschrieben hat. In unidirektionalen Zahlungskanälen ist es für Bob also immer am besten den neusten Stand zu veröffentlichen. 

Bidirektionale Zahlungskanäle sind wie folgt aufgebaut und abgesichert:  

Alice und Bob wollen einen bidirektionalen Zahlungskanal etablieren. Dafür müssen sich die beiden Parteien zuerst auf eine Eröffnungstransaktion (Funding-Transaktion) mit den jeweiligen Beträgen einigen. Also, wie viel jeder in den Kanal einbezahlt. In unserem Beispiel zahlt Alice einen 10.000 Satoshi ein und Bob bezahlt nichts ein. Alice schickt die 10.000 Satoshi an eine 2-2-Multi-Sig-Wallet. Für diese Wallet hat Alice einen Key und Bob hat den anderen. Beide müssen also für eine gültige Transaktion auf der Blockchain diese signieren. Sollte Bob verschwinden kann Alice nach einer bestimmten Zeit das Geld zurückholen. 

Jetzt möchte Alice den Zahlungskanal benutzen und Bob 1.000 Satoshi schicken. Dafür kommt eine zweite Multi-Sig-Wallet ins Spiel. Nachdem die Funding-Transaktion stattgefunden hat, kreiert Alice eine neue Transaktion, bei der sie 9.000 Satoshi an eine von ihr kontrollierte Adresse gehen und 1.000 Satoshi an die neue Multi-Sig-Wallet. Für diese neue Multi-Sig-Wallet werden wieder zwei Signaturen benötigt. Die eine gehört Alice, die andere ist eine temporäre, neue Adresse von Bob. Zudem hat diese Transaktion ein Zeitschloss, also sie kann erst nach einer verstrichenen Zeitperiode ausgegeben werden. Soweit so gut. Bob könnte sich jetzt entschließen mit seiner temporären Signatur zu unterschreiben und den Zahlungskanal damit zu schließen. Oder er wartet auf die nächste Aktualisierung des Zahlungskanals.  

Bob möchte jetzt über den gleichen Kanal 500 Satoshi an Alice schicken. Dafür muss er seine vorherige Signatur preisgeben, indem er den zugehörigen Private Key mit Alice teilt. Dann erstellt er eine neue Transaktion bei der Alice 500 Satoshi bekommt und 500 Satoshi nach wie vor an Bob gehen. Für diese Transaktion ist eine temporäre, neue Signatur von Alice notwendig und eine Signatur von Bob. Diese Transaktion ist wieder mit einem Zeitschloss verstehen, sodass Bob seine vollen 1.000 Satoshi bekommt, sofern Alice nicht reagiert.  

Doch, da es sich um einen bidirektionalen Zahlungskanal handelt, muss ein Schritt vor der Commitment-Transaktion vorgenommen werden. Sie müssen sich das Geheimnis, das Pre Image, ausdenken und austauschen.  

In der Praxis übernimmt das die Wallet und der Nutzer bekommt von dem Prozess nicht viel mit. Generell kann man sich das allerdings so vorstellen. Die Wallet-Applikation genereriert eine zufällige, große Zahl. Das ist das Pre Image. Dann hasht die Wallet-Applikation das Pre Image. Das ist der Hash. Bevor es mit dem Zahlungskanal richtig losgehen kann, erstellen beide Teilnehmer daher ein solches Pre Image und den dazugehörigen Hash. Diesen Hash tauschen sie untereinander aus. Jetzt ist alles bereit für den bidirektionalen Zahlungskanal. 

Alice schickt Bob jetzt 10.000 Satoshi, indem sie wieder einen Scheck für die Multi-Sig-Wallet unterschreibt. Dieser Scheck zahlt ihr 49.990.000 Satoshi aus und Bob 50.010.000 Satoshi. Es handelt es sich also um eine Commitment-Transaktion. Doch diese Transaktion ist besonders, denn sie ist mit einem Hashed Timelock Contract versehen. Das heißt Alice benutzt zum einen den Hash den Bob ihr gegeben hat und sagt „wer beweisen kann, dass er das Pre Image zu diesem Hash kennt, kann den HTLC auflösen.“ Die andere Möglichkeit eine Transaktion zu tätigen ist, dass eine bestimmte Zeitspanne vergeht. Bei einem HTLC wird diese Zeit in Blockanzahl angegeben (ein Block dauert ungefähr 10 Minuten).  

Bob kann so jederzeit an sein Geld kommen. Dafür löst er den Zahlungskanal in einer Settlement-Transaktion auf, indem er sein Pre Image in der Transaktion präsentiert. Alice kann das nicht, denn sie kennt das Pre Image nicht. Sollte Bob nicht mit Alice kooperieren und versuchen das Geld „Geisel zu halten“, kann er das nur bis das Zeitschloss abgelaufen ist. Wenn er bis dahin nicht den Kanal geschlossen und sein Geld für sich beansprucht hat, kann Alice wieder an ihr gesamtes Geld kommen.  

Lightning Network – Aus den Kanälen wird ein Netzwerk 

Jetzt haben wir die technischen Grundlagen für das Lightning Network verstanden. Doch wie kommt es nun von einem bidirektionale Zahlungskanal zwischen Alice und Bob zum Netzwerk zwischen allen Teilnehmern? 

Der HTLC besteht aus zwei Komponenten, auf der einen Seite dem Geheimnis (Secret) und auf der anderen Seite einem Zeitschloss. Das Geheimnis ist eine zufällige Zahl, die mit einer Hash-Funktion gehasht wird. Die ursprüngliche Zahl, die für die Erzeugung des Hashes benutzt wird, heißt auch Pre Image.  

Bisher müssten die Teilnehmer für jede neue Zahlungsaktivität einen neuen Channel errichten. Sollte also Alice mit Carol Geschäfte machen wollen, müssten beide Geschäftspartner einen Zahlungskanal errichten. Das Lightning Network setzt hier an – Zahlungen könnten über die einzelnen Teilnehmer geroutet werden. Anstatt dass Alice einen neuen Kanal zu Carol aufbaut nutzt sie stattdessen existente Kanäle zwischen ihr und Bob und Bob und Carol. Bob agiert in diesem Fall als Zwischenschritt, als Hop, zwischen Alice und Carol. 

Der kritische Leser wird hier stutzig: „Momentan mal, das Geld geht von Alice über Bob an Carol – ist das nicht genau das Treuhänder-Model, das Bitcoin ersetzen will?“ 

Das Lightning Network ist kein vertrauensbasiertes Treuhänder-Model. Denn auch wenn die Zahlung über Bob ihren Weg zu Carol findet, hat Bob zu keinem Zeitpunkt Kontrolle über das Geld von Alice. Das wird durch fortgeschrittene Kryptographie möglich gemacht. Eben dem Mechanismus von bidirektionalen, vertrauen losen Zahlungskanälen, die Hashed Timelock Contracts (HTLC).  

Dieser Vorgang garantiert, dass niemand in der Kette von Zahlungskanälen betrügen kann, bzw. dass Betrug sich nicht lohnt. Das funktioniert so: Dabei denkt sich Carol ein Geheimnis aus, wieder eine zufällige Zahl. Den Hash davon gibt Carol an Alice weiter. Dieser Hash wird nun zum Unterpfand: Bob erhält eine Zahlung, wenn er das Geheimnis kennt. Dieses kann Alice mithilfe des Hashes überprüfen. Bob gibt den Hash weiter – wieder mit dem Versprechen, zu zahlen, falls der Empfänger das Geheimnis lüftet. Prinzipiell kann der Weg zwischen Alice und Carol weitere Teilnehmer enthalten, die allesamt den Hash als Unterpfand nutzen, in der Abbildung hat man lediglich ein einfaches Netzwerk aus drei Parteien gebildet. 

Mithilfe der HTLCs können Payment Channels zwischen verschiedenen Parteien miteinander verbunden werden. Man sieht: Teilnehmer am Netzwerk, die als Nodes eine Brücke zwischen Alice und Carol bilden, sind das Rückgrat des Lightning Networks. Ihre Wichtigkeit kann man mit der der Miner auf der regulären Blockchain vergleichen. 

– unabhängig davon, ob Carol und Bob schon Bitcoins miteinander ausgetauscht haben oder nicht. Peer-to-Peer wäre in ein Extrem verzerrt und damit absolut nicht effizient. Ein Ansatz wäre, dass Teilnehmer an verschiedenen Zahlungskanälen Transaktionen weitergeben. Alice würde Geld an Carol über Bob schicken können. Die Frage ist, ob man Bob vertrauen kann. Zum einen könnte er das Geld für sich beanspruchen und einfach nicht weitergeben, zum anderen könnte die Lightning Node von Bob ausfallen. 

Herausforderungen mit dem Lightning Network 

Die praktische Implementierung des Lightning Networks ist noch lange nicht soweit, dass diese Technologie von einer breiten Masse an Leuten genutzt werden kann. Aktuell befindet sich das Netzwerk in einer experimentellen Phase. Für die Nutzung ist es essentiell, ein gesundes Verständnis von Technik zu haben. Doch selbst dann kann es zum Verlust der eignen Bitcoin kommen. Kurz: Auch wenn der Ansatz und die Idee bereits klar sind, gibt es immer noch viele Baustellen.  

Eine der wohl größten Baustellen – und einer der meist genannten Kritikpunkte gegen das Lightning Network – ist das Routing. Wenn ein Netzwerk aus Zahlungskanälen besteht, muss die Zahlung ihren Weg durch das Netzwerk finden. Allerdings ist die Methode des Routing nicht im Lightning Network Whitepaper spezifiziert. Die Kritiker des Lightning Networks meinen, dass es sich hier um ein unlösbares Problem handelt. Schließlich würden ständig neue Knoten online kommen und andere würden offline gehen. Allein die Bedingung, dass man zum Empfang einer Transaktion online sein muss, schreckt viele vom Lightning Network ab. So sei es doch ein Schritt nach hinten, anstatt nach vorne, denn bei Bitcoin muss der Empfänger nicht online sein, um Zahlungen zu erhalten. 

Der technologische Status des Lightning Networks ist also noch unreif. Für eine breite Adaption muss die Technologie einfach und sicher zu benutzen sein. Bestenfalls merkt der Nutzer überhaupt nicht, dass er mit dem Lightning Network und Zahlungskanälen interagiert. Allerdings wird es voraussichtlich noch einige Jahre dauern, bis es soweit ist. Nicht zuletzt könnte das Experiment auch scheitern.  

Lightning Network in der eigenen Wallet erfahren 

Das Lightning Network ist noch nicht fertig. Zwar existieren inzwischen über 2.000 Lightning Nodes. Trotzdem ist nicht garantiert, dass zwei Nutzer tatsächlich ein Zahlungskanal aufbauen können. Es ist also noch viel zu tun. Getreu dem Motto „Be your own Bank“ kann hierbei jeder mithelfen: Besonders ambitionierte können eine eigene Lightning Node aufsetzen. 

Doch auch ohne das Herunterladen der gesamten Blockchain kann man in den Genuss des Lightning Network kommen. Wer schnell experimentieren will, kann als Web-Wallet HTLC.me verwenden. Mit Zap und der Lightning App existieren zwei Desktop Wallets. Schließlich gibt es mit Eclair sogar schon eine Mobile Wallet für Android-Nutzer. Wie an anderer Stelle beschrieben, existiert mit Coingate ein Service, mit welchem man schnell Transaktionen über das Lightning Network im eigenen Webstore zulassen kann. 

Häufige Fragen (FAQ)