Lightning-Netzwerk

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Lightning Netzwerk)
Zur Navigation springen Zur Suche springen
Lightning-Netzwerk

Bitcoin's Lightning Network Visualization.png
Visualisierung der Topologie des Lightning Netzwerkes im Mai 2018
Basisdaten

Maintainer Joseph Poon, Thaddeus Dryja
Entwickler Elements Project (Blockstream)
Lightning Labs
ACINQ
MIT DCI
Erscheinungsjahr 2018
Aktuelle Version 0.6.2[1]
(26. Oktober 2018)
Programmiersprache C, Go, Java
Kategorie Kryptowährung
Lizenz MIT
https://lightning.network/

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.[2] Joseph Poon hatte diese Ideen zuvor auf Bitcoin-Meetups und Konferenzen diskutiert.

Entstehungsgeschichte[Bearbeiten | Quelltext bearbeiten]

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.[3] 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 Bitcoins 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, dem Speicherplatz, den eine Transaktion benötigt, und der 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. Auf einem Bitcoin-Meetup in San Francisco entwickelten sich in den Jahren 2013 bis 2015 mehr und mehr Ideen, die letztlich zum Vorschlag des Lightning-Netzwerks führten. 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.[4] Im August 2017 wurde durch einen Mechanismus im Bitcoin-Protokoll zur Konsensfindung deutlich, dass über 90 % der Bitcoin-Miningpower im Netzwerk das Update unterstützen. Diese Mehrheit reichte aus, um einen Softfork des Bitcoin-Protokolls durchzuführen.[5]

Unabhängig von dem 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 nahe steht und mit c-lightning eine Implementierung in C entwickelt. Erste erfolgreiche Tests dieses Projektes führten Christian Decker und Rusty Russell bereits im Oktober 2016 durch.[6] 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 White Papers einen RFC-Standard für das Lightning-Netzwerk.[7] Diesem Standard sollten sämtliche Implementierungen folgen.

Funktionsweise[Bearbeiten | Quelltext bearbeiten]

Das Kernelement des Lightning-Netzwerks ist der sogenannte Zahlungskanal (Payment Channel). Mithilfe eines Kanals können sich zwei Knoten des Netzwerkes durch Benutzung eines 2-2-Multisignatur-Wallets gebührenfrei Geldbeträge zuschicken und hierdurch den Saldo des Kanals bis zu einer vorher definierten Obergrenze aktualisieren. Nach einer initialen Funding Transaction zur Öffnung des Kanals können die Knoten selbst beliebig viele weitere Transaktionen untereinander tätigen, ohne sie in der Blockchain zu speichern, wodurch diese entlastet und die Skalierbarkeit verbessert wird. Dazu halten sie nach jeder Zahlung den aktuellen Saldo in einer Commitment Transaction fest, die von beiden Knoten signiert werden muss. 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. Der Durchsatz des Zahlungskanals ist nur limitiert durch Latenz und Durchsatz des verwendeten TCP-Sockets. Laut Christian Decker sind somit aktuell circa 500 Transaktionen pro Sekunde in einem Zahlungskanal möglich.[8] 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.

Verbreitung[Bearbeiten | Quelltext bearbeiten]

Im Dezember 2017 wurde das erste Mal bekannt, dass die 3 Implementierungen alle 75 Integrationstests bestanden und damit tatsächlich kompatibel miteinander sind.[9] Im Januar 2018 veröffentlichte Blockstream mit Lightning Charge einen Node.js-Server, der eine REST-API zur Verwendung des Lightning-Netzwerks bereitstellt.[10] 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.[11] Im April folgte das „Eclair Wallet“ mit Lightning-Support für Android. Die Anzahl der Knoten im Lightning-Netzwerk ist am Wachsen und besteht aktuell aus über 3000 Knoten mit über 10.000 Zahlungskanälen und einer Gesamtkapazität von über 100 Bitcoin (Stand: 22. Juli 2018).[12] Das Netzwerk selbst befindet sich aus Sicht der Entwickler jedoch noch im Pionier- und Teststadium und kann aufgrund einer festgesetzten Obergrenze für den Saldo von Zahlungskanälen bislang noch nicht für große Finanztransaktionen verwendet werden.

Eigenschaften[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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 hat Christian Decker in seiner Dissertation an der ETH Zürich einen Ansatz vorgestellt, mit der man einen Zahlungskanal mit Hilfe von Invalidierungsbäumen betreiben kann.[13] Außerdem haben Christian Decker, Rusty Russell und Olaoluwa Osuntokun im Mai 2018 „eltoo“ vorgestellt.[14] Mit eltoo lassen sich Zahlungskanäle mit deutlich weniger Aufwand implementieren, allerdings ist ein Softfork des Bitcoin-Protokolls nötig, welcher als BIP118 vorgeschlagen wurde[15]. 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[Bearbeiten | Quelltext bearbeiten]

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.[16] 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[Bearbeiten | Quelltext bearbeiten]

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 aktuellste 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[Bearbeiten | Quelltext bearbeiten]

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 zusammen arbeiten, 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[Bearbeiten | Quelltext bearbeiten]

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 Geheimnis 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[Bearbeiten | Quelltext bearbeiten]

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.

Kontroversen und Risiken[Bearbeiten | Quelltext bearbeiten]

Es ist gefährlich, ein Backup eines Zahlungskanals zu erstellen. Wenn Knoten ein altes Backup einspielen, könnten sie aus Versehen 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.[17]

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.[18] Der Bitcoin-Entwickler Peter Todd warnte davor, dass das Lightning-Netzwerk für DoS-Attacken anfällig sei.[19]

Momentan lassen sich im Lightning-Netzwerk Zahlungen nicht immer erfolgreich routen. Eine Analyse von Diar.co hat ergeben, dass eine Wahrscheinlichkeit von 100 % für eine erfolgreiche Zahlung zurzeit nur für Beträge unter 3 Cent gegeben ist. Ab etwa 5 Euro falle die Wahrscheinlichkeit, dass man eine Route findet, auf unter 50 %; bei 50 Euro betrage diese nur etwa 10 %.[20] Begründet ist dies durch fehlende Liquidität im Netzwerk. Das White Paper 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.[21]

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einführungsvortrag auf Wikimedia Commons

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. Release 0.6.2. 26. Oktober 2018 (abgerufen am 26. Oktober 2018).
  2. Joseph Poon, Thaddeus Dryja: The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. 14. Januar 2016, abgerufen am 30. Juni 2018 (PDF; 3 MB, englisch).
  3. Aaron van Wirdum: The History of Lightning: From Brainstorm to Beta. Abgerufen am 6. August 2018 (englisch).
  4. heise online: Segregated Witness: Protokolländerung soll den Bitcoin leistungsfähiger machen. Abgerufen am 16. April 2018.
  5. SegWit wurde erfolgreich auf der Bitcoin Blockchain aktiviert | BTC-ECHO. In: BTC-ECHO. 24. August 2017 (btc-echo.de [abgerufen am 16. April 2018]).
  6. Der erste Einschlag: Christian Decker und Rusty Russel von Blockstream testen Lightning-Prototyp. In: BitcoinBlog.de - das Blog für Bitcoin und andere virtuelle Währungen. 6. Oktober 2016 (bitcoinblog.de [abgerufen am 16. April 2018]).
  7. lightningnetwork/lightning-rfc. Abgerufen am 16. April 2018 (englisch).
  8. Scaling, Layer 2 And Cryptographic Innovations Discussed At Consensus 2018 - Coinjournal. Abgerufen am 18. Mai 2018 (amerikanisches Englisch).
  9. Lightning Developers: Lightning Protocol 1.0: Compatibility Achieved ✅. In: Lightning Developers. 6. Dezember 2017, abgerufen am 16. April 2018.
  10. Lightning Charge Powers Developers & Blockstream Store. Abgerufen am 16. April 2018.
  11. Bitcoin Lightning App: Paypercall zeigt die volle Lightning Power. Abgerufen am 16. April 2018.
  12. #recksplorer. Abgerufen am 22. Juli 2018 (englisch).
  13. Decker, Christian: On the Scalability and Security of Bitcoin. 2016, doi:10.3929/ethz-a-010619000 (hdl.handle.net [abgerufen am 16. April 2018]).
  14. Christian Decker, Rusty Russell, Olaoluwa Osuntokun: eltoo: A Simple Layer2 Protocol for Bitcoin. Abgerufen am 21. Juli 2018 (PDF).
  15. Christian Decker: BIP118. Abgerufen am 22. Juli 2018 (englisch).
  16. BtcDrak, Mark Friedenbach, Eric Lombrozo: BIP112. Abgerufen am 22. Juli 2018 (englisch).
  17. Bitcoin Lightning Netzwerk: Fehler führte zum Verlust von Bitcoins. Abgerufen am 16. April 2018.
  18. [Lightning-dev] New form of 51% attack via lightning's revocation system possible? Abgerufen am 16. April 2018.
  19. root: Bitcoin Entwickler warnt Lightning Network ist anfällig für DoS – Angriffe | Münze News Telegraph. Abgerufen am 16. April 2018.
  20. Lightning-Netzwerk: Erfolgreiches Routing nimmt mit steigendem Betrag rapide ab. In: BitcoinBlog.de - das Blog für Bitcoin und andere virtuelle Währungen. 27. Juni 2018 (bitcoinblog.de [abgerufen am 12. Juli 2018]).
  21. Joseph Poon, Thaddeus Dryja: The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. Abgerufen am 12. Juli 2018 (PDF, englisch).