Lightning-Netzwerk

Beteilige dich an der Diskussion!

Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! (+) Begründung: Aus der allgemeinen QS; dort gegebene Begründung nachfolgend. --217.239.13.50 12:33, 23. Okt. 2020 (CEST) Die Technologie hat sich weiterentwickelt. Die Lesbarkeit, Verständlichkeit und Struktur lassen zu wünschen übrig Es haben sich tendenziöse Quellen eingeschlichen. Diese sind zum Teil veraltet und lassen sich sicherlich durch einige der über 1000 existierenden Forschungsartikel zu dem Thema ersetzen. Mehr Infos auf der Diskussionsseite --Renepick (Diskussion) 23:59, 20. Okt. 2020 (CEST)

Das Lightning-Netzwerk ist ein Protokoll zur Skalierung von Blockchain-Technologien. Es wurde im Juli 2015 durch ein White Paper von Joseph Poon und Thaddeus Dryja vorgeschlagen. In den Folgejahren wurden eine Detailspezifikation und hierauf basierend mehrere unabhängige Implementierungen entwickelt, auf deren Grundlage auf der Bitcoin-Blockchain ein Netzwerk entstand, das im April 2021 mehr als 42000 Zahlungskanäle und eine Kapazität von ca. 1200 Bitcoin hatte.

Entstehungsgeschichte

Das Netzwerk im Entstehen, Screenshot Recksplorer, 5. Februar 2018

Die grundlegende Idee der Zahlungskanäle geht schon auf Satoshi Nakamoto zurück. Seine Implementierungsidee war jedoch nicht sicher. Es gab in den folgenden Jahren einige ähnliche Ideen, und Meni Rosenfeld beschrieb 2012 schon eine Konstruktion, die dem heutigen Lightning Network in vieler Hinsicht ähnelt. Technische Komplikationen (etwa transaction malleability, die erst durch Segregated Witness behoben wurde) und fehlende Motivation – weil Bitcoin selbst noch wenig genutzt wurde – verhinderten jedoch lange entscheidende Fortschritte.

Als der Preis eines Bitcoin gegen Ende 2013 erstmals 1000 US-Dollar überschritt, wurde deutlich, dass die Blockchain, welche dem Bitcoin-Netzwerk zu Grunde liegt, und die nicht beliebig viele Transaktionen pro Sekunde zulässt, ein Problem mit der Skalierbarkeit bekommen würde. Die Anzahl der Transaktionen war beschränkt durch die Blockgröße von 1 Megabyte, den Speicherplatz, den eine Transaktion benötigt, und die Blockzeit von statistisch etwa zehn Minuten. Daraus ergibt sich, dass auf der Bitcoin-Blockchain weltweit nur ca. 7 Finanztransaktionen pro Sekunde durchgeführt werden konnten. Kreditkartenanbieter verarbeiten mit rund 40.000 Zahlungsvorgängen pro Sekunde deutlich mehr Transaktionen. Die Entwickler des Bitcoin-Protokolls waren sich einig, dass das Problem der Skalierbarkeit gelöst werden musste, damit Bitcoin tatsächlich die Geldfunktion eines Tauschmittels erfüllt und eine realistische Chance besteht, dass Bitcoin als Währung von Menschen akzeptiert wird.

Innerhalb der Bitcoin-Entwicklercommunity entstanden Diskussionen darüber, wie man das Skalierbarkeitsproblem des Bitcoin-Netzwerks lösen könnte. Als Lösungsvorschläge kursierten vor allem die Anhebung der Blockgröße wie auch die Einführung von Layer-2-Lösungen wie das Lightning Network. Die Mehrheit der Bitcoin-Entwickler bevorzugte das Lightning Network, während die Minderheitenfraktion sich zu Bitcoin Cash abspaltete und dort mit 32-Megabyte-Blöcken die Transaktionskapazität deutlich anhob. Um die Entwicklung und Implementierung des Lightning-Netzwerks zu ermöglichen, benötigte man jedoch das Segregated-Witness-Update des Bitcoin-Protokolls. Dies war aufgrund der Dezentralität des Bitcoin-Netzwerks nur schwer zu erreichen, da sich die Community auf die Durchführung des Updates einigen musste. Im August 2017 wurde durch einen Mechanismus im Bitcoin-Protokoll zur Konsensfindung deutlich, dass über 90 % der Bitcoin-Miningpower im Netzwerk das Update unterstützten. Diese Mehrheit reichte aus, um einen Softfork des Bitcoin-Protokolls durchzuführen.

Unabhängig vom Ausgang der Abstimmung entstanden bereits im Jahr 2016 mehrere Projekte, die sich mit der Entwicklung des Lightning-Netzwerks als Open-Source-Software beschäftigten. Zum einen das Elements-Projekt, das Bitcoin Core und dem Unternehmen Blockstream nahesteht und mit Core Lightning eine Implementierung in C entwickelt. Erste erfolgreiche Tests dieses Projektes führten Christian Decker und Rusty Russell bereits im Oktober 2016 durch. Zum anderen die aktuell am weitesten fortgeschrittene Implementierung lnd der Firma Lightning Labs, die in der Sprache Go implementiert ist. Außerdem entwickelt das französische Unternehmen ACINQ eine Implementierung in Scala namens eclair, die unter anderem als Mobile-Wallet für Android-Geräte verfügbar ist.

Eine zentrale Rolle in der Entwicklung des Protokolls nimmt der australische Entwickler Rusty Russell von der Firma Blockstream ein. Russell, der zuvor von Linus Torvalds als einer der stärksten Linux-Entwickler ausgezeichnet wurde, entwickelte auf Grundlage des Whitepapers einen RFC-Standard für das Lightning-Netzwerk. Diesem Standard sollten sämtliche Implementierungen folgen.

Funktionsweise

Im Kern besteht das Lightning-Netzwerk aus sogenannten Zahlungskanälen (Payment Channels) zwischen zwei Knoten des Netzwerks. Ein Kanal wird einmalig über eine Transaktion auf der Blockchain eröffnet. Durch diese Transaktion wird ein gewisser Betrag auf der Haupt-Blockchain für Lightning verfügbar gemacht. Dabei wird der Betrag der Transaktion dem Knoten, der die Transaktion durchführt, zugeschrieben. Der Kanal hat als maximale Obergrenze („Kapazität“) den Betrag dieser Eröffnungstransaktion.

Die Kapazität eines Kanals beschreibt die Gesamtmenge an Satoshi, die sich in dem Kanal befinden. Dieser Betrag ist immer vorhanden, kann jedoch zu unterschiedlichen Teilen beiden Teilen des Knotens gehören. Das Übertragen von Beträgen zwischen den Knoten innerhalb eines Kanals ist dabei gebührenfrei. Dazu halten sie nach jeder Zahlung den aktuellen Saldo in einer Commitment Transaction fest, die von beiden Knoten signiert werden muss. Diese Zahlung wird jedoch nicht auf die Blockchain übertragen, sondern nur von den Knoten untereinander gespeichert, sodass durch die Übertragung keine Gebühr anfällt.

Die Idee entspricht damit dem Kontokorrent im klassischen Handelsrecht, wobei die Saldierung der Forderungen allerdings erst erfolgt, wenn einer der Teilnehmer den Kanal schließt, indem er eine Settlement Transaction veröffentlicht. Erst diese speichert den finalen Saldo beider Parteien in der letzten Commitment-Transaction wieder in die Blockchain. Anders als beim Kontokorrent müssen die beiden Parteien, die den Kanal bilden, aber einander nicht vertrauen. Dennoch finden die Transaktionen in dem Zahlungskanal nur mit dem Wissen der beiden Akteure statt.

Um zu verhindern, dass eine ältere Commitment-Transaction von einem Partner veröffentlicht wird, enthält jede Transaktion ein sogenanntes Revocation Secret, das die vorherige Commitment-Transaction ungültig macht. Versucht ein Knoten, fälschlicherweise eine ältere Transaktion zu veröffentlichen, kann die Gegenseite mit dem Revocation Secret die komplette Kapazität des Channels an sich selbst übertragen.

Der Durchsatz eines Zahlungskanals ist nur limitiert durch die Latenz des verwendeten TCP-Sockets. Laut Christian Decker sind somit circa 500 Transaktionen pro Sekunde in einem Zahlungskanal möglich. Das Protokoll zur Verwaltung eines Kanals ist mithilfe von Hashed Time Locked Contracts so konstruiert, dass betrügerisches Verhalten (z. B. Veröffentlichung einer älteren Commitment Transaction) innerhalb eines Zahlungskanals von der Gegenseite gemeldet werden kann. Das Bitcoin-Netzwerk prüft den Betrugsversuch und sanktioniert betrügerisches Verhalten, indem der gesamte Geldbetrag des Kanals an die Opferseite ausgezahlt wird.

Eine weitere Kernidee des Lightning-Netzwerks ist das Routing von Zahlungen durch das Netzwerk. Sobald durch Öffnen von Zahlungskanälen zu mehreren Knoten ein vermaschtes Netz zwischen den Teilnehmern entsteht, lassen sich Zahlungen zwischen zwei beliebigen Knoten vornehmen, selbst wenn diese nicht direkt durch einen Zahlungskanal miteinander verbunden sind. Knoten, die den Betrag nur weiterleiten sollen, können diesen nicht stehlen, da dieser erneut durch einen Hashed Time Locked Contract und ein Geheimnis – das sogenannte Zahlungsurbild (Payment Preimage) – gesichert ist, welches nur der empfangende Knoten kennt. Das Routing ermöglicht somit Teilnehmern, nach dem Erstellen eines bilateralen Zahlungskanals Transaktionen mit beliebigen anderen Teilnehmern des Netzwerks durchzuführen. Durch Onion-Routing, wie es z. B. im Tor-Netzwerk verwendet wird, soll zudem die Privatsphäre der Teilnehmer geschützt werden. Insbesondere beim Finden von Routen und dem Verwalten von Routingtabellen besteht zurzeit noch der meiste Entwicklungsbedarf.

Eigenschaften

Das Lightning-Netzwerk hat per Design mehrere wünschenswerte Eigenschaften, um das Problem der Skalierbarkeit von Bitcoin zu lösen. Zu diesen zählen geringe Gebühren, welche insbesondere Micropayments ermöglichen. Außerdem ist die Privatsphäre der Teilnehmenden im Netzwerk höher als im Bitcoin-Netzwerk.

Marginale Transaktionsgebühren

Das Lightning-Netzwerk ermöglicht es, innerhalb eines Zahlungskanals gebührenfrei Geld hin und her zu überweisen. Für das Routing können Knoten Gebühren verlangen. Diese sollen voraussichtlich nicht höher als ein Satoshi pro Hop sein. Daher lassen sich mit dem Lightning Netzwerk erstmals weltweit Geldbeträge praktisch gebührenfrei in Echtzeit übertragen.

Micropayments

Da die Transaktionsgebühren im Lightning-Netzwerk bei wachsender Nutzeranzahl nicht steigen, sondern sich sogar potentiell verringern, bietet sich das Lightning-Netzwerk insbesondere – aber nicht ausschließlich – für Micropayments an.

Privatsphäre

Das Lightning-Netzwerk-Protokoll funktioniert ohne die Veröffentlichung einzelner Transaktionen in einem Zahlungskanal. Somit ist die Privatsphäre deutlich höher als beim Bitcoin-Netzwerk, bei dem sämtliche Transaktionen in der öffentlichen Datenbank gespeichert sind. Die Blockchain speichert nur Kontostände bei Öffnung und Schließung der Zahlungskanäle. Aus welchen Einzeltransaktionen sich die entstandene Differenz zusammensetzt, wissen nur die Knoten selbst.

Second-Layer-Protokoll

Das Lightning-Netzwerk-Protokoll kann als eine Abstraktionsschicht oberhalb einer Blockchain verstanden werden. Es wäre also möglich, Transaktionen zwischen zwei verschiedenen Blockchains zu tätigen (sogenannte Atomic Swaps), falls beide alle nötigen Voraussetzungen für das Lightning-Netzwerk erfüllen.

Technik

Das Lightning-Netzwerk hat konzeptuell zwei aufeinander aufbauende Schichten. Die Grundlage bilden bidirektionale Zahlungskanäle, die es ermöglichen, beliebig oft Geldbeträge bis zu einer zuvor definierten Obergrenze zwischen zwei Teilnehmern hin- und herzusenden. Wichtig ist, dass die beiden Parteien weder einander noch einer dritten Instanz vertrauen müssen. Die Blockchain (z. B. Bitcoin) stellt als dezentrales System das Vertrauen bereit. Aus diesen Zahlungskanälen wird als zweite Ebene ein Netzwerk aufgebaut, wodurch Zahlungen zwischen zwei Teilnehmern durch die Zahlungskanäle von anderen Teilnehmern verschickt werden können. Auch bei der Konstruktion des Netzwerks gilt die besondere Eigenschaft, dass man zu keinem Zeitpunkt den Teilnehmern der Zahlungskanäle vertrauen muss, da auch hier die Blockchain als vertrauensgebende Instanz wirkt.

Bidirektionale Zahlungskanäle durch Revocable Sequence Maturity Contracts

In den aktuellen Implementierungen basieren die bidirektionalen Zahlungskanäle auf sogenannten RSMCs (englisch Revocable Sequence Maturity Contracts). Es sind noch zwei weitere Konstruktionen für bidirektionale Zahlungskanäle bekannt. Zum einen wurde ein Ansatz vorgestellt, nach dem ein Zahlungskanal mit Hilfe von Invalidierungsbäumen betrieben werden kann. Zum anderen lassen sich mit eltoo Zahlungskanäle mit deutlich weniger Aufwand implementieren, allerdings ist ein Softfork des Bitcoin-Protokolls nötig, welcher als BIP118 vorgeschlagen wurde. Die Kernidee aller bekannten Konstruktionen von Zahlungskanälen basiert darauf, einen Betrag (die Kapazität) auf ein 2-2-Multisignatur-Wallet zu überweisen und anschließend gemeinsam Transaktionen von diesem Wallet zurück an die Parteien zu verhandeln, welche die Bilanz des Zahlungskanals zwischen den Parteien kodiert. Diese Transaktionen werden jedoch im regulären Fall nicht an das Bitcoin-Netzwerk publiziert, sondern erneuert, um eine Zahlung vorzunehmen. Das wesentliche Problem besteht nun in der Invalidierung alter Transaktionen, so dass keine alten Bilanzstände an das Bitcoin-Netzwerk veröffentlicht werden können. Im Folgenden wird die Konstruktion der Zahlungskanäle und Invalidierung alter Bilanzen basierend auf RSMCs beschrieben.

Zahlungskanäle öffnen

Um einen Zahlungskanal zwischen den Parteien A und B zu öffnen, einigen sich zwei Knoten gemeinsam einen Betrag auf ein 2-2-Multisignatur-Wallet zu übertragen. Das geschieht in den sogenannten „Funding Transactions“. Bevor diese Transaktionen jedoch an das Bitcoin-Netzwerk gebroadcastet werden, werden zwei Commitment-Transaktionen (eine für jede Partei) erstellt, welche die Funding-Transaktion ausgeben und den bereitgestellten Betrag jeder Partei wieder an die Partei zurücküberweisen. Erst wenn beide Seiten die von der anderen Seite signierte Commitment-Transaktion besitzen, werden die Funding-Transaktionen gebroadcastet und der Zahlungskanal ist erstellt. Die Commitment-Transaktionen sind wichtig, damit jede Seite den Kanal – auch ohne das zusätzliche Einverständnis der anderen Partei – schließen kann. Die Commitment-Transaktionen werden – obwohl sie signiert sind – zunächst nicht an das Netzwerk gebroadcastet. Ihr Zweck ist es, die Bilanz des Kanals zu kodieren und sicherzustellen, dass beide Parteien die Möglichkeit haben, ohne Zustimmung der jeweils anderen Seite den Kanal wieder zu schließen. Die Commitment-Transaktionen besitzen zwei Outputs. Einen für jede Partei. In der Commitment-Transaktion von Partei A ist der Output an Partei A jedoch durch einen RSMC gebunden. Das bedeutet, dass A den Output erst nach einer gewissen Anzahl an Blöcken, nachdem die Commitment-Transaktion gemint wurde, ausgeben kann. Vorher kann der Betrag nur ausgegeben werden, wenn für diese Commitment-Transaktion die sogenannten Revocation Keys beider Parteien bekannt sind. Dieses Script in der Bitcoin-Transaktion wird durch OP_CHECKSEQUENCEVERIFY ermöglicht, was durch die Aktivierung von BIP112 Teil des Bitcoin-Protokolls wurde. Das Script, mit dem der Output, der regulär der Partei A zusteht, ausgegeben werden kann, sieht (vereinfacht) wie folgt aus:

OP_IF
   144 OP_CECKSEQUENCEVERIFY
   OP_HASH160 <A's key>  OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
   2 <Revocation Key von A><Revocation Key von B> 2 OP_CHECKMULTISIGVERIFY
OP_ENDIF

Zahlungen vornehmen

Damit Zahlungen innerhalb eines Kanals vorgenommen werden können, wird für jede Seite im Kanal eine neue Commitment-Transaktion vereinbart. Diese gibt die Funding-Transaktion – also die Kapazität auf dem Multisignatur-Wallet – anders aus als bislang und führt damit zu neuen Eigentumsverhältnissen des Multisignatur-Wallets. Bevor die neue Commitment-Transaktion signiert werden kann, werden Signatur und Revocation Keys der vorherigen Commitment-Transaktion mit einer Art Diffie-Hellman-Schlüsselaustausch ausgetauscht. Der Revocation Key ermöglicht es der gegenüberliegenden Partei wegen OP_CHECKSEQUENCEVERIFY für ein Zeitfenster sämtliche Outputs der alten Commitment-Transaktion auf das eigene Bitcoin-Wallet zu übertragen. Diese Bestrafung erzeugt eine Bedrohung, die eigenen alten Commitment-Transaktionen zu veröffentlichen. Somit wird effektiv die Möglichkeit geschaffen alte Commitment-Transaktionen ungültig zu machen und dafür zu sorgen, dass immer nur das aktuelle Paar von Commitment-Transaktionen als autorative Quelle für die Bilanz des Kanals gilt. Wichtig ist es, für jedes Update des Zahlungskanals neue Revocation Keys in der Commitment-Transaktion zu verwenden. Außerdem müssen alle alten Revocation Keys aufbewahrt werden, da man sonst nichts gegen potentiell betrügerisches Verhalten der anderen Partei unternehmen kann. Es bietet sich auch an, die eigenen alten Commitment-Transaktionen zu löschen, damit diese nicht aus Versehen, z. B. durch einen Software-Bug, veröffentlicht werden.

Zahlungskanal schließen

Kanäle können einseitig durch die Veröffentlichung der aktuellen Commitment-Transaktion auf der Blockchain geschlossen werden. Allerdings kann der eigene Teil der Bilanz erst nach dem Timelock ausgegeben werden. Aus diesem Grund ist es auch wichtig, den eigenen aktuellen Revocation Key geheim zuhalten. Wenn die beiden Parteien jedoch zusammenarbeiten, können sie den Output der Funding-Transaktion durch eine Settlement-Transaktion ausgeben, welche die aktuelle Balance des Kanals widerspiegelt. In der Settlement-Transaktion können die Outputs für jede Partei ohne OP_CHECKSEQUENCEVERIFY vereinbart werden, so dass diese, sobald die Transaktion vom Bitcoin-Netzwerk akzeptiert wurde, ohne Timelock wieder ausgegeben werden können. Sobald man eine solche Settlement-Transaktion vereinbart hat, ist diese auch wirklich dem Bitcoin-Netzwerk mitzuteilen und der Kanal zu schließen, da man den Zahlungskanal nicht mehr ohne Vertrauen nutzen kann.

Netzwerk aus Zahlungskanälen durch Hashed Time Locked Contracts

Die wesentliche Technologie, die das Routing der Transaktionen ohne Vertrauen der teilnehmenden Zahlungskanäle ermöglicht, sind die Hashed Time Locked Contracts, kurz HTLC. Die Idee ist es, einen weiteren Output (den HTLC) in den Commitment-Transaktionen zu vereinbaren. Dieser kann von der empfangenden Partei nur dann innerhalb eines Zeitfensters ausgegeben werden, wenn diese noch ein Geheimnis bereitstellen kann. Der Hash des Geheimnisses steckt in dem Script, welches nötig ist, um diesen weiteren Output auszugeben. Wird das Geheimnis, nachdem die Commitment-Transaktion vom Bitcoin-Netzwerk bestätigt wurde, nicht innerhalb von einer durch OP_CHECKSEQUENCEVERIFY festgelegten Anzahl von Blöcken von der empfangenden Partei bereitgestellt, kann nur die sendende Partei den Output ausgeben. Das Routing einer Zahlung findet dadurch statt, dass auf einem Weg von der sendenden Partei zu der empfangenden Partei eine Kette von bedingten Transaktionen durchgeführt wird. Alle diese Transaktionen beinhalten denselben Hash. Sobald die empfangende Partei ihre Zahlung einfordert, muss sie das Geheimnis in ihrem Zahlungskanal bereitstellen. Das Geheimnis wird jetzt rückwärts entlang des Weges zur sendenden Partei durchgereicht. Keine Partei kann auf diesem Weg Geldbeträge stehlen oder einbehalten. Im Gegenteil. Durch unkonformes Verhalten läuft man Gefahr, die eigene Zahlung nicht zurückerstattet zu bekommen. Insbesondere müssen die Commitment-Transaktionen nicht veröffentlicht werden, sobald das Geheimnis bekannt wird. Es reicht, ein neues Update des Kanals durchzuführen, bei dem der HTLC-Output entfernt und der Betrag der empfangenden Partei zugeschrieben wird.

Onion-Routing

Die Kernidee des Onion-Routings ist es, dass im Gegensatz zum IP-Routing nicht ein Paket mit Sender- und Empfängeradressen erstellt wird, welches dann durch das Netzwerk geroutet wird. Viel mehr muss ein Sender zuerst einen Pfad durch das Netzwerk finden. Nun können für jeden Hop Transaktionen ineinander verschachtelt werden. Dadurch wird die Privatsphäre erhöht, weil die einzelnen Konten auf dem Weg nur wissen, von wem sie Geld empfangen und an wen sie das Geld weiterleiten müssen. Knoten dürfen für die Dienstleistung, Zahlungen weiterzuleiten, einen Teil der Zahlung als Gebühr einbehalten. Diese Gebühr wird von den Knoten über das Gossip-Protokoll dem Netzwerk mitgeteilt und kann beim Berechnen der Pfade berücksichtigt werden.

Verbreitung

Im Dezember 2017 wurde das erste Mal bekannt, dass die 3 Implementierungen alle 75 Integrationstests bestanden und damit tatsächlich kompatibel miteinander sind. Im Januar 2018 veröffentlichte Blockstream mit Lightning Charge einen Node.js-Server, der eine REST-API zur Verwendung des Lightning-Netzwerks bereitstellt. Es entstanden LApps (lightning apps), welche Dienste vor allem aus dem Bereich Micropayments anbieten. Im März 2018 wurde erstmals eine Implementierung für das Bitcoin-Netzwerk als Beta freigegeben. Auch wurden von Blockstream mehrere Lightning-Apps vorgestellt, die sich für Zahlungsdienste im Web einsetzen lassen. Im April folgte das „Eclair Wallet“ mit Lightning-Support für Android. Die Anzahl der Knoten im Lightning-Netzwerk wächst und bestand im März 2020 aus ca. 18.000 Knoten mit über 39.000 Zahlungskanälen und einer Gesamtkapazität von über 1100 Bitcoin. Das Netzwerk selbst befindet sich aus Sicht der Entwickler jedoch noch im Pionier- und Teststadium. Daher konnte es bis Version 0.11 aufgrund einer festgesetzten Obergrenze für den Saldo von Zahlungskanälen noch nicht für große Finanztransaktionen verwendet werden, Version 0.11 ermöglichte Wumbo Channels ohne dieses Limit.

Kontroversen und Risiken

Wenn Knoten ein altes Backup einspielen, könnten sie eine alte Commitment-Transaktion veröffentlichen. Dies könnte von der Gegenseite als Versuch von betrügerischem Verhalten gesehen werden und entsprechend zum Verlust der Bitcoins führen.

Im Februar 2018 wurde auf der Entwicklermailingliste bekannt, dass das Lightning-Netzwerk eine neue Form von 51-%-Attacken auf das Bitcoin-Netzwerk ermöglicht. In dieser ist es nicht nur möglich, die eigenen Bitcoins doppelt auszugeben, sondern man kann sich die Summe aller Bitcoins in den eigenen Zahlungskanälen erstehlen. Da eine 51-%-Attacke mit dem Wachstum des Netzwerkes jedoch immer unwahrscheinlicher wird und auch eine Gefahr für das Bitcoin-Netzwerk darstellt, kann dieses Risiko aus Sicht der Entwickler vernachlässigt werden. Der Bitcoin-Entwickler Peter Todd warnte davor, dass das Lightning-Netzwerk für DoS-Attacken anfällig sei.

Das Whitepaper empfiehlt, das Netzwerk so anzuordnen, dass es dem Bankennetzwerk oder Tier-1-Netzwerk entspricht. Durch diesen Aufbau als Hub and Spoke müsse ein Teilnehmer im Netzwerk außerdem nicht die ganze Routingtabelle haben.

Länderübergreifende Tests des auf Bitcoin-Basis entwickelten Zahlungsnetzes Lightning ergaben, dass bei Überweisungen nicht nur Sender und Empfänger genügend Liquidität benötigen, um Zahlungen annehmen zu können, sondern auch alle Knoten zwischen ihnen. Überweisende konnten mitunter nur durch die Aufteilung des Überweisungsbetrages in Teilbeträge Überweisungen tätigen.

Weblinks

Einführungsvortrag auf Wikimedia Commons

• Projektwebseite
• White Paper (PDF; 2,9 MB)
• Spezifikation
• Mailingliste
• C-Implementierung
• Go-Implementierung
• Scala-Implementierung