Always On: Ein Zwischenfazit zum Lightning Netzwerk

Nachdem ich einen Lightning-Node aufgesetzt und es geschafft habe, damit Zahlungen zu empfangen, ziehe ich eine Zwischenbilanz. Die Kurzversion ist, dass Lightning gut ist für Internetunternehmen und User ist, die nur bezahlen wollen. Für normale User, die auch Geld empfangen wollen, ist es eine grauenhaft komplizierte, undurchsichtige, teure und unsichere Methode, um das zu tun, was Bitcoin schon lange kann. Aber eigentlich ist das egal.

Mein Node, mein Node

Nach etwa einer Woche Arbeit habe ich es geschafft, einen Lightning-Node auf einem virtuellen privaten Server (VPS) zu starten. Es fühlt sich gut an, ein wenig so, als wäre ich Golum, der endlich seinen Schatz in den Händen hält.

Die Installation lief eigentlich ganz gut. Wenn es Probleme gab, wurden sie in der Regel nicht von der Lightning-Software verursacht, sondern dadurch, dass ich so gut wie keine Erfahrung mit den involvierten IT-Technologien habe. Für einen geübten Entwickler dürfte es nicht das geringste Problem sein, einen Lightning-Node zum Laufen zu bringen und zu benutzen. Die Software LND wirkt stabil und auch relativ intuitiv bedienbar.

Es war relativ aufwändig und teilweise frustrierend. Aber ich hatte auch viele Erfolgserlebnisse, so dass die Freude überwogen hat. Ich denke, jeder, der gerne mit Software frickelt, wird auch Spaß an Lightning haben, und sich tierisch freuen, wenn er mal einen einsatzfähigen Lightning-Node hat.

Es ist mir gelungen, einzelne Zahlungen auszuführen und Spenden für das Blog automatisiert anzunehmen. Teilweise gab es, sowohl bei ein- als auch ausgehenden Zahlungen, Probleme damit, eine Route zu finden, aber in der Regel haben die Zahlungen reibungslos geklappt. Nach ziemlich langem Herumprobieren habe ich es auch irgendwie geschafft, automatisiert zu erkennen, dass eine Zahlung angekommen ist.

Für kompetente User – sagen wir, Entwickler oder jedes Unternehmen, das mit Bitcoin arbeitet – ist die Lightning-Software mehr oder weniger produktionsreif. Wenn diese kompetenten User sich noch in häufigen Frequenzen gegenseitig Geld überweisen – sagen wir, von Börse zu Börse – bietet Lightning bereits in der heutigen Form enorme Vorteile. Auch für diejenigen, die mit Bitcoin vor allem bezahlen wollen, ist Lightning eine gute Alternative zu onchain-Zahlungen, vergleichbar mit einer Debitkarte.

Für normale User, die wie ich vor allem Geld empfangen wollen, ist Lightning dagegen weniger attraktiv: Es ist eine teure, zeitaufwändige, komplizierte, undurchsichtige und unsichere Methode, um das zu erreichen, was eine schnöde Light-Wallet schon jetzt bietet. Ich möchte diesen Punkt genauer erklären und erörtern, was sich hier in absehbarer Zeit verbessern kann.

Probleme

Teuer

Um Geld mit Lightning zu empfangen muss man permanent online sein. Meine Lösung war es, einen virtuellen Server (VPS) zu mieten. Da ein Lightning-Node einen Bitcoin-Node braucht, musste das VPS ziemlich viel Festplattenspeicher haben. Es kostet mich etwa 10 Euro im Monat.

Zeitaufwändig

Um den Node auf dem VPS einsatzbereit zu haben, musste ich zunächst Bitcoin Core synchronisieren (ca. 24 Stunden), LND die Blockchain filtern lassen (weitere 24 Stunden), und dann warten, bis ich eingehende Liquidität hatte (ca. 6 Stunden). Liquidität zu erhalten war relativ einfach, kann unter Umständen aber schwierig werden.

Kompliziert

Nun … Ist es für Sie Alltag, ein VPS zu mieten, dieses per SSH / SCP anzusteuern, im Terminal zu arbeiten, Konfigurationsdateien manuell zu schreiben, das VPS irgendwie mit HTML / PHP zu verbinden und APIs abzufragen? Wenn ja, dürfte ein Lightning-Node nicht allzu kompliziert für Sie sein. Wenn nein, wird es Ihnen so gehen wir mir – es ist sehr kompliziert und herausfordernd.

Undurchsichtig

Es ist relativ schwer zu verstehen, über welchen Weg man mit wieviel bezahlt wurde. Es gibt mehrere Methoden, aber bei mir funktioniert noch keine ausreichend gut. Die Übersicht in einer Lightning-Wallet zu bewahren ist wohl etwas schwieriger als bei einer normalen Bitcoin-Wallet.

Unsicher

Es gehört zum Wesen eines Lightning-Nodes, das die privaten Schlüssel entsperrt zugänglich sein müssen, wenn ich es richtig verstehe. Da ich sie zudem auf einem fremden Server, dessen Betreiber ich nicht kenne, lagere, fühle ich mich grundsätzlich ziemlich unsicher.

Ein VPS mit einem öffentlichen Bitcoin- und Lightning-Node ist wie ein Leuchtturm für Hacker. Teilweise hat mein Server mehr als 20.000 fehlgeschlagene Login-Versuche in wenigen Stunden angezeigt. Auch das fühlt sich nicht sicher an.

Mein PHP-Skript hatte zudem eine Schwachstelle. Ein Leser hat mich per E-Mail über sie informiert, aber noch bevor ich sie fixen konnte, hat ein anderer Leser durch sie meinen Server runtergefahren, um Schlimmeres zu verhindern. Es wäre glaube ich relativ einfach möglich gewesen, meine Channels zu schließen und auf eine bestimmte Adresse auszuzahlen, und ich bin sicher, ein Hacker wird auch weiterhin Schwachstellen finden, da ich kein geübter Programmierer bin.

Es fühlt sich sehr viel unsicherer an, Coins auf einem Lightning-Node zu speichern, als auf einer normalen Wallet. Mehr als 100 Euro würde ich vermutlich nicht dort lassen.

Kann man die Probleme beheben?

Teilweise lassen sich die Probleme sicherlich reduzieren oder aus der Welt schaffen.

Zum einen bin ich kein allzu kompetenter User. Man könnte anstatt eines VPS einen Raspberry Node betreiben, anstatt die Software zum Empfangen selbst dahinzupfuschen könnte man professionell gemachte Software benutzen, die es sehr wohl schon gibt. Es wäre billiger, einfacher, sicherer und transparenter möglich gewesen. Daher dürfte Lightning im jetzigen Stadium wohl vor allem für  profesionelle und kompetente User ansprechend sein.

Zum anderen darf man hoffen, dass die Technologie benutzerfreundlicher wird. Es gibt an sich keinen endgültigen Grund, weshalb man einen Full Node braucht, um Lightning zu benutzen. In Zukunft dürfte es möglich werden, einen Light-Node dafür zu benutzen, womit die Kosten für das VPS auf 2-3 Euro je Monat sinken, und die Wallet in wenigen Minuten startklar sein kann. Auch wird die Installation einfacher werden, und es wird einfach einzurichtende und zu bedienbare Interfaces und APIs geben. Auch dürfte es grundsätzlich möglich sein, Zahlungsanforderungen über das Nachrichtensystem von Lightning zu erbitten und zu versenden. Das würde den ganzen Schnullifax mit HTML / PHP beseitigen.

All das und mehr wird langfristig sehr viel an Komplexität aus dem System herausnehmen. Aber es bleiben einige Probleme, die schwer oder gar nicht lösbar sind …

Always On

Um mit Bitcoin Geld zu empfangen, muss man nicht online sein. Solange die Blockchain von den Minern fortgeschrieben wird, kann sich jeder User, egal welches System er benutzt, auf den neuesten Stand bringen. Satoshi hat diese Eigenschaft von Bitcoin explizit im Whitepaper beschrieben:

Die Ausstrahlung neuer Transaktionen muss nicht zwingend jeden Knoten erreichen. So lange sie viele Knoten erreichen, werden sie früher oder später in einem Block aufgenommen. Blockausstrahlungen sind auch tolerant gegenüber verlorenen Nachrichten. Wenn ein Knoten einen Block nicht empfängt, wird er diesen anfordern, sobald er den nächsten Block empfängt und erkennt, dass ihm einer fehlt.

Lightning bricht mit dieser Eigenschaft. Es gibt keine Datenbank mit allen Transaktionen mehr; wenn man Geld empfangen möchte, muss man online sein, damit die Transaktion eine Route zu einem findet. Das ist kein Problem für Unternehmen, die sowieso einen Server ständig laufen lassen.

Aber normale User haben in der Regel kein Gerät, das “always on” ist. Weder der Laptop, noch ein Programm auf dem Smartphone (das vermutlich recht viele Ressourcen ziehen würde). Man könnte daran denken, einen Lightning-Mini-Node auf die Router zu bringen. Aber ich vermute, das wird niemals wirklich einfach werden, schon allein deswegen, weil es so viele verschiedene Router gibt, die alle auf ihre eigene Weise Ports öffnen, Firewalls hochziehen und mit anderen Geräten kommunizieren.

Dies ist überhaupt kein Problem, wenn man ein professioneller User ist, der sowieso einen Server hat, oder wenn man mit Lightning nur bezahlen möchte. Es dürfte aber ein großer Hemmschuh dafür werden, normale User dazu zu bringen, Lightning so wie Bitcoin zu verwenden – nämlich als simple Adresse, an die man bezahlen kann. Das “Always-on”-Problem macht es haarsträubend aufwändig, um die einfache Spendenadresse, die ich mir 2013 ohne jedes Hintergrundwissen fürs Blog eingerichtet habe, mit Lightning zu rekonstruieren.

Wie ließe sich das lösen? Es wäre es vorstellbar, dass Lightning-Nodes Zahlungsanforderungen aufheben, die einen Sender suchen, und sie in regelmäßigen- oder unregelmäßigen Abständen nochmal weiterleiten, so ähnlich wie Bitcoin-Nodes unbestätigte Transaktionen im MemPool halten. Aber ich denke, das dürfte schwierig so zu implementieren sein, dass man nicht mit einem DoS-Angriff die Nodes scharenweise überlasten kann.

Einfacher und realistischer wird es sein, wenn jemand einen “Forwarding-Service” anbietet: Einen Node, der Zahlungen mit einem bestimmten Empfänger für diesen aufhebt und weitergibt, sobald der andere Node wieder online ist. Ein solcher Forwarding-Node könnte auch gleichzeitig “Watchtower” sein und damit verhindern, dass es zu Verlusten aufgrund von unregulär geschlossenen Channels kommt (das ist ein anderes Thema, das ich hier nur anreisse).

Eine noch einfachere Alternative wäre es, eine Lightning-Wallet als Online-Wallet zu benutzen, bei der der Betreiber der Online-Wallet bzw. der Bank die privaten Schlüssel besitzt. Aber das finde zumindest ich gar nicht attraktiv.

Liquidität

Eine der fundamentalen Eigenschaften von Lightning ist, dass man nur so viel Geld empfangen kann, wie eingehende Liquidität in Channels an einen liegen.

Um es genauer zu erklären: Wenn ich einen Channel mit 0,1 Bitcoin zu Node B bilde, liegen zunächst 0,1 Bitcoins bei mir. Ich kann dann Geld an Node B zahlen und weiterleiten, aber ich kann noch nichts empfangen. Wo nichts ist, kann auch nichts rüberschwappen. Damit das möglich wird, muss ich entweder Geld ausgeben oder Node B muss einen Channel an mich öffnen.

Wer Geld empfangen will, muss also zunächst genauso viel Geld ausgeben, wie er empfangen will, oder jemanden finden, der so viel Geld in einen Channel zu einem steckt. Ich hatte nach ein wenig Herumfragen auf Twitter und hier im Blog recht rasch rund 1.000 Euro eingehende Liquidität, womit ich schon mal recht weit komme (auch wenn Gehaltseinzahlungen noch nicht gehen).

Allerdings verfügt nicht jeder über die Kanäle, die ich habe, und die Lightning-Szene wird auch nicht immer so enthusiastisch sein, um bereitwillig Channels zu neuen Nodes aufzumachen. Am Ende wird es darauf ankommen, ob es sich lohnt, einen liquiden Channel zu einem Node zu eröffnen. Und da denke ich, dass normale User nicht so viel zu bieten haben.

Ein Channel mit hoher eingehender Liquidität lohnt sich nur, wenn der Ertrag die Opportunitätskosten übersteigt. Beispielsweise wenn der Zielnode eine hohe ausgehende Liquidität zu anderen Nodes hat und wichtige Routen abdeckt, so dass man durch den Channel an Gebühren verdienen kann. Mein Node etwa bietet das nicht. Zumindest gab es auch nach mehr als einer Woche keine einzelne Zahlung, die meinen Node passiert hat.

Wenn ein Node nicht attraktiv ist, wird es wenig Gründe geben, einen liquiden Channel zu ihm zu unterhalten. Dafür sind die Opportunitätskosten zu groß: Wer Liquidität bindet, verzichtet darauf, die Coins sicher im Cold Wallet zu verwahren oder die Liquidität lukrativer einzusetzen, sei es an anderer Stelle im Lightning Netzwerk oder im Margin Lending oder der Arbitrage.

Wie wird man dann eingehende Liquidität bekommen? Die Antwort liegt vermutlich in “Liquiditäts-Providern”, also Nodes, die anderen Usern eingehende Liquidität geben und dafür eine kleine Gebühr nehmen. Wenn diese Nodes bereits Transaktionen weiterleiten, Watchtower sind oder gar eine Online-Wallet bereitstellen, bekommen die User alles aus einer Hand.

Die neuen Banken?

Für profesionelle User und Leute, die nur bezahlen wollen, ist Lightning weitgehend unproblematisch. Lightning gibt eine gute Debit-Karte ab, und alle hierfür verbleibenden Probleme von Usability und Routing sollten in absehbarer Zeit zu lösen sein. Auch für Bitcoin-Unternehmen, Plattformen und Payment-Provider dürfte Lightning gut funktionieren, sofern es ihnen gelingt, genügend eingehende Liquidität zu halten und mit den Einschränkungen der Sicherheit umzugehen.

User, die allerdings das haben wollen, was sie mit Bitcoin derzeit haben – ein einfaches, pseudonymes, sicheres, mittelsmannloses System um Geld zu empfangen und zu versenden – werden mit Lightning wohl auf absehbare Zeit die Hilfe von Mittelsmännern benötigen. Es könnte sein, dass die Technik hier noch einige große Sprünge macht, aber mir fehlt derzeit die Phantasie, um mir das auszumalen.

Um Geld zu empfangen, benötigt ein User in mehreren Beziehungen Hilfe: Um nicht ständig online sein zu müssen, um die Zahlungsaufforderung weiter zu reichen, um sich vor Verlusten durch betrügerische Schließungen von Channels zu schützen, und um genügend eingehende Liquidität zu erreichen. Es bietet sich an, dass ein Dienstleister diese Aufgaben für den User übernimmt.

Man könnte solche Dienstleister die neuen Banken nennen. Sofern es keine Online-Wallet ist, unterscheiden sich die neuen jedoch deutlich von den alten Banken: Sie können keine Guthaben beschlagnahmen, nur sehr eingeschränkt Zahlungen blockieren (falls überhaupt), und sie können auch nur sehr eingeschränkt Daten über das Zahlungsverhalten ihrer Kunden sammeln. Natürlich ist für alle diese Vorteile wichtig, wie Lightning beim User implementiert wird und wie diese Dienstleister ihren Service aufbauen.

Egal, oder?

Man könnte jetzt eine Litanei anstimmen, dass Lightning die Mittelsmänner, die Bitcoin überflüssig gemacht hat, zurückbringt. Aber das ist nicht einmal die halbe Wahrheit, sondern eher grundfalsch.

Denn diejenigen, die wie gewohnt mit Bitcoin Geld empfangen wollen, verlieren nichts, wenn andere User Lightning wie eine Debit-Karte verwenden oder Bitcoin-Unternehmen ihre Zahlungsströme untereinander mit Lightning abwickeln. Ganz im Gegenteil: Indem Lightning auf diese Weise den Druck von der Blockchain nimmt, schafft es Platz dafür, dass diejenigen, die Bitcoin nativ verwenden, dies günstig und effizient machen können.

Damit ist Lightning selbst dann ein Gewinn, wenn es für normale User schwierig bis unmöglich ist, sich ohne Mittelsmann bezahlen zu lassen.

About Christoph Bergmann (1328 Articles)
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder, es es seit Mitte 2013 führt. Christoph hat vor kurzem ein Buch geschrieben: Bitcoin: Die verrückte Geschichte vom Aufstieg eines neuen Geldes. Das Buch stellt Bitcoin in seiner ganzen Pracht dar. Ihr könnt es direkt auf der Webseite Bitcoin-Buch.org bestellen - natürlich auch mit Bitcoin - oder auch per Amazon. Natürlich freuen wir uns auch über Spenden in Bitcoin oder Bitcoin Cash an die folgende Adresse: 1BvayiASVCmGmg4WUJmyRHoNevWWo5snqC. Weitere Adressen (bech32, SegWit, Litecoin, Ethereum) finden Sie HIER. Tipps für Stories sind an christoph.bergmann@mailbox.org immer erwünscht. Wer dies privat machen möchte, sollte meinen PGP-Schlüssel verwenden.

28 Comments on Always On: Ein Zwischenfazit zum Lightning Netzwerk

  1. Super Artikel!
    Ich finde es toll das Du obwohl Du ein Big Blocker bist, offen mit neuen Technologien umgehst, und diese ziemlich unabhängig bewertest. Klasse. Danke!

  2. Alle Achtung, daß Du Dir die Mühe gemacht hast einen Lightning Node zu installieren und zu testen und versucht hast die Praxistauglichkeit zu überprüfen. Ich denke die Technik wird sich weiter entwickeln und irgendwann wird es einfacher sein Bitcoins zu benutzen in allen Facetten die man haben will. Rom wurde auch nicht in einem Tag erbaut.

  3. Sehr guter Artikel! Aber die Kritik an der Sicherheit basiert doch eher auf einem mangelhaften PHP Script – Die alte Geschichte von der Kette und dem schwächsten Glied.

    • Hi, jein. Klar ist die Lücke am Ende mein Skript. Aber Bitcoin selbst macht es dem User halt konzeptionell viel einfacher. Ich kann Geld mit einer Adresse empfangen, während ich den Private Key auf einer Cold Wallet habe. Mit Lightning müssen die Private Keys auf einer Hot Wallet sein, soweit ich weiß sogar entriegelt, und in meinem Fall muss diese Hot Wallet auch noch auf einem VPS liegen, dessen IP-Adresse ich öffentlich bekanntgebe. Kann man bestimmt auch sicher machen, aber ist um Welten schwieriger als bei einer guten alten Bitcoin-Adresse.

    • Das Grundproblem ist “always on”, welches Christoph mittels VPS “gelöst” hat und damit verliert er die Hoheit über seine privaten Schlüssel, da mindestens der Admin des Wirtsystems darauf Zugriff hat. Das offensichtlich unsichere PHP Script verdeutlicht eher, dass Leute, die keine Ahnung von Server-Administration haben auch keinen betreiben sollten.
      Die Raspi Methode ist da im Vorteil, solange man nicht gerade im Urlaub ist, wenn z.B. der Router oder der Raspi selber abschmiert und der Node offline geht und damit betrügerische Channel-Schließungen ermöglicht.

      Sofern es keine Online-Wallet ist, unterscheiden sich die neuen jedoch deutlich von den alten Banken: Sie können keine Guthaben beschlagnahmen, nur sehr eingeschränkt Zahlungen blockieren (falls überhaupt), und sie können auch nur sehr eingeschränkt Daten über das Zahlungsverhalten ihrer Kunden sammeln.

      In diesem Absatz scheint so ziemlich alles falsch zu sein. Sobald der Dienstleister Liquiditätsprovider ist, was ja das Hauptproblem zu sein scheint, kann er klammheimlich einen betrügerischen alten State eines Channels auf der Blockchain veröffentlichen und man bräuchte noch (mindestens) einen externen Watchtower, um dies zu erkennen. Bitcoin ist trustless und dezentral, Lightning nicht. Ich werde es zwar wahrscheinlich trotzdem nutzen, aber mit Sicherheit nie Channels mit relevanten Beträgen offen halten.

      • Mh, kann sein, dass Liquiditäts-Dienstleister mehr Einfluss haben, als ich auf den ersten Blick gedacht habe. Wenn sie die exklusive Liquidität geben, können sie vermutlich auch ganz gut Zahlungen zensieren (da sie ja die Straße kontrollieren).

      • In Christoph’s Absatz ist so ziemlich alles richtig. Natürlich ist LN trustless und dezentral.

        Jeder kann Liquiditätsprovider sein, und jeder kann um vermeintlich zentrale LN nodes vorbeirouten. Also dezentral.

        Um die Veröffentlichung alter Channelstates erfolgreich zu bekämpfen, reicht es (neben der Möglichkeit eines Watchtowers) auch, einmal am Tag kurz online zu gehen und die Channelstates zu checken. Sowas geht sogar mit einer mobile Wallet. Außerdem weiß auch ein Angreifer nicht, ob du in den nächsten 24 Std wieder online gehst, dann würde er nämlich den kompletten Teil aus seiner Seite des Channels verlieren (“Justice will be served!”). Also trustless.

      • @CSW

        Jeder kann Liquiditätsprovider sein, und jeder kann um vermeintlich zentrale LN nodes vorbeirouten. Also dezentral.

        Das Blöde ist nur, dass der durchschnittliche User ungern relevante Beträge zur Liquidität des Netzwerks beisteuern wird, das sind in der Regel große Unternehmen, die sich einen besseren (günstigeren) Zugang zum Netzwerk versprechen und man wird für alles, was über die Portokasse hinausgeht nicht ohne diese routen können. Außerdem ist das “Vorbeirouten” alles andere als trivial.

        Um die Veröffentlichung alter Channelstates erfolgreich zu bekämpfen, reicht es (neben der Möglichkeit eines Watchtowers) auch, einmal am Tag kurz online zu gehen und die Channelstates zu checken. Sowas geht sogar mit einer mobile Wallet.

        Das ist für mich nicht trustless, da ich meine Channels regelmäßig überwachen muss um nicht abgezockt zu werden. Das eröffnet neue Angriffsvektoren, und sei es nur ein D(d)oS auf Christophs VPS oder ein Ausfall der Internetverbindung Deines Providers, wenn Du Deine Channel einmal pro Tag checken willst. Erst kürzlich hatte O2 massive Probleme und anhand der IP Adresse kann der potenzielle Angreifer erkennen, bei welchem Provider Du bist… Von Zuständen wie z.B. auf Kuba will ich gar nicht sprechen, wo es Dir fast überall unmöglich ist, alle 24 Stunden auch nur kurz online zu gehen.

        Mein Fazit: Lightning ist allemal ein Ersatz für Flattr und ähnliche Micropayments, aber nicht wirklich eine Entlastung der (Bitcoin) Blockchain auf der sich derlei ohnehin nicht (mehr) abspielt.

  4. Wer jetzt nicht gerade 100% online sein muss, kann die eigene Node über dynamische DNS-Dienste auch zu Hause laufen lassen. Nach den Einrichtungskosten kommen dann nur noch minimale laufende Kosten dazu.

    Das wird alles noch viel nutzerfreundlicher werden. Hauptsache es wird jetzt nicht wieder die ganze Debatte ideologi- und emotionalisiert. Je mehr man mit der Bitcoin-Blockchain machen kann, desto stärker wird das Ding.

    Die große Cash-Kampagne ist vorbei, Bitmain hat es aufgegeben.

    “Wir können die ermüdenden politischen Debatten hinter uns lassen und zu neuen Grenzen aufbrechen, bauen, basteln, schweißen, löten.” (!!!)

  5. Es kommen ja sicherlich noch Tools, womit das ganze nutzerfreundlich auch für Reguläre Empfänger wird. Ohne Woocommerce Plugins etc. wäre Bitcoin ebenfalls eine grauenhafte Methode um Geld zu empfangen.

  6. Worüber ich mal nachgedacht habe: Welches Problem löst Lightning eigentlich? Jetzt ernsthaft.
    Die Blöcke sind kleiner, ja. Aber die Blockgröße an sich ist eigentlich das geringste Problem beim Skalieren. Das größte Problem ist die Größe des UTXO Set – und das wächst, egal ob Lightning oder Big Blocks, denn auch jeder Lightning Channel braucht mindestens ein UTXO (ich nehme mal an zwei UTXO pro Channel).
    Zudem kommen noch weitere Probleme hinzu: Usability, Fractional Reserve System und Sicherheit. Vorteil sind schnelle und sehr sichere Transaktionen, für welchen Preis?

    • Nachdem du mit einer Transaktion (=ein UTXO) einen LN Channel geöffnet hast, kannst du anschließend quasi unendlich viele LN Transaktionen machen, ohne mit dem Mempool zu interagieren. Genau das ist ja der Vorteil von offchain: Keine Transaktionen im Mempool und den Blöcken. DAS ist “massive scale”!!

      Und fractional reserve gibt es nicht.

      • Anonymous // 31. August 2018 at 21:15 //

        Unendlich viele Transaktionen kann ich auch mit einem Standard Payment Channel machen, da brauche ich kein Lightning für. UTXO Set Größe ist auch gleich.
        Lightning ist ein Fractional Reserve System, nicht zu verwechseln mit Fractional Reserve Banking. Die Konsequenzen sind aber die gleichen, z.B. ein Bank Run auf dem Lightning Network ist genauso gut möglich, wie bei Fractional Reserve Banking.

    • “Worüber ich mal nachgedacht habe: Welches Problem löst Lightning eigentlich? Jetzt ernsthaft.”

      Stimmt, habe jetzt auch mal ernsthaft darüber nachgedacht. Lightning löst überhaupt kein Problem, sondern schafft nur ganz viele neue künstliche Probleme. Keine Ahnung, wieso die ganzen Top Wissenschaftler daran arbeiten. Ich schätze, einfach mal, dass die im Gegensatz zu mir alle total bekloppt sind.

  7. Hi, die letzen beiden Artikel, einfach nur wieder top!
    Du hast ein umfangreiches Bild über das Lightning Netzwerk gezeichnet und auch ein wenig Euphorie gekillt 😉 , aber cool aufgeklärt, vielen Dank dafür.

  8. Ein wichtiger Punkt ist, dass alle Mittelsmänner ersetzbar sind. Wenn also irgendwer versagt oder zensiert, kann man ihn austauschen durch z.B. einen Mittelsmann in einem unregulierten Land.

    Ein häufig genanntes Argument gegen Lightning ist, dass es zur Zentralisierung durch Hubs führt. Das ist sicher auch so, aber diese Hubs sollten leicht ersetzbar sein. So können Regierungen nach wie vor nichts gegen unerwünschte Zahlungen machen.

    • Du kannst auch jederzeit deine Bank wechseln. Wie einfach und teuer das ist, ist entscheidend.

      • Kranich // 31. August 2018 at 12:22 //

        Wie die Finanzmarktkrise vor Augen führte, lassen sich Banken aktuell aber nicht so einfach schließen bzw. abwickeln. Wechseln alle Kunden auf einmal die Bank (Bank-Run), kommt das Finanzsystem an seine Grenzen. Das sollte bei “Lightning-Banken” (Mittelsmännern) nicht der Fall sein.

  9. Zum Thema eingehende Liquidität sollte die Gebühr hier in der Größenordnung normaler Zinssätze sein, da der Provider ja die Mittel festlegt und a) nicht anderweitig investieren kann und b) diese auch erst mal selber haben muss. Man wird also Zinssätze von 2-10% p.a. für die eingehende Liquidität rechnen müssen. Solche Sätze wird natürlich niemand für größere Summen wie z.B. das Gehalt zahlen wollen. Eine Lösung für dieses Problem ist mir nicht bekannt und scheint nahezu unmöglich. Also scheint es, dass Lightning von normalen Usern nur für Zahlungen verwendet werden kann.

    Da in einem Channel immer einer netto eingehend ist und einer netto ausgehend fallen diese Liquiditätskosten immer für mindestens eine Partei an, oder nicht? Das würde LIghtning sehr teuer machen. Das fällt jetzt bei den üblichen Kleinstbeträgen nur noch nicht auf. Aber wenn ein Händler dann effektiv einen Dauerkredit braucht für seine Liquidität könnte das die Kostenersparnis durch Kryptowährungen zunichte machen oder übertreffen.

    • Wäre es denn möglich, dass ein evtl. sowieso notwendiger Mittelsmann ausreichend Liquidität für alle seine Channels zentral bereitstellt, und bei festgestelltem Bedarf nur die Channels kurzfristig mit Liquidität “füllt”, bei denen größere anstehende Zahlungseingänge festgestellt werden (z.B. Gehaltseingänge)? Ließe sich denn ein solcher Bedarf schon während des Routings feststellen und darauf hin kurzfristig reagieren?

      Damit würde sich doch die insgesamt gebundene Liquidität reduzieren lassen. Im Laufe des Monats wandern die meisten Zahlungseingänge als Zahlungsausgänge dann sowieso wieder zurück zum “Mittelsmann”, oder?

      • Den Channel füllen erfordert eine On-Chain Transaktion, was den Zweck von Lightning zunichte macht. Man muss leider im Voraus Kapazität festlegen, indem man On-Chain Coins einfriert. Ohne dieses Einfrieren könnte leicht betrogen werden.

      • @tobi
        Ok, dann macht Lightning wirklich wenig Sinn.
        Ich teile dann deine Bedenken. Wenn sich dafür keine Lösung findet, dann wird sich in der Zukunft Lightning “nur” als Bezahlsystem für kleine Micro-Payments durchsetzen können. Vielleicht können Banken als Mittelsmänner über eine Art “Saldo” die Kapitalkosten minimieren. Vermeiden, lassen sie sich wohl kaum. So schön und elegant die technische Realisierung dann auch sein mag, das könnte aus meiner Sicht tatsächlich noch ein großes Problem von Lightning werden.

  10. Ich bin mal gespannt wie weit man das alles vereinfach und reduzieren kann. 1 bis 2 jahre können da schon viel ausmachen

  11. Danke für den ausgewogenen Artikel.

    Das always-on-Problem, das Du so entscheidend findest, erscheint mir allerdings kaum problematisch: entweder will ich im Moment bezahlt werden, dann ist mein Handy/computer an, oder ich habe eine Webseite, dann habe ich auch einen Webserver, der ist auch immer an. Das scheinen mir die bei weitem häufigsten use cases für Zahlungen zu sein.

    • Schön, dass du hier kommentierst.

      Kann sein, dass Always-On nicht für alle Fälle problematisch ist, z. B. wenn man Geld im Einzelhandel oder live von Freunden empfängt oder von einer Börse abbucht. Ich kann nur von meinen Anwendungen reden, und da ist es in fast allen Fällen relevant. Affiliate-Auszahlungen kommen irgendwann, Spenden auch, ich schreibe eine Rechnung, die irgendwann bezahlt wird, oder eine Mail, die sagt: Überweis’ mir doch mal X BTC an Adresse Y …

  12. Kartoffelkopf // 31. August 2018 at 12:31 // Reply

    Zur Sicherheit der Node: Lieber Herr Bergmann, falls die IP, welche im anderen Artikel angegeben ist, wirklich die echte für den Service war, dann müssen Sie sich auch nicht wundern, wenn Hinz und Kunz versucht sich dort einzuloggen. Anonsten stimmt es natürlich trotzdem, dass, wer am Lightning-Netzwerk teil hat, auch die IPs der Knoten kennt. Und jeder Knoten wird dadurch zu einem potentiellen Angriffsziel.

    Zur Hardware: Ich kann mir gut vorstellen, dass ein aktueller Raspi ausreichend ist für einen Fullnode wenn er an eine externe Festplatte angeschlossen ist.

  13. Ein paar unsortierte Anmerkungen zum guten Artikel:

    1) Das eclair wallet kennst du ja, das ist auch für Anfänger geeignet und nach der Channeleröffnung auch sofort einsatzbereit ohne full node aufsetzen etc. Nachteil ist, man kann (bis jetzt) nur senden. Es gibt aber eine aufgemotzte eclair Version von einem anderen Entwickler, die Android Lightning Wallet (http://lightning-wallet.com/). Diese kann auch unter Zuhilfenahme eines zusätzlichen Servers Zahlungen empfangen. Der Server dient gleichzeitig als Watchtower und Routen-Finder. Immer noch alles trustless, allerdings geht jegliche privacy flöten, da dem Server alle deine Zahlungsrouten bekannt sind.

    2) Ist bis jetzt noch nicht offiziell von den LN Implementierungen unterstützt, aber man kann jetzt schon einen LN node mit einem pruned bitcoin node betreiben. Ich habe 2 Nodes: Einen auf einem Raspi OHNE externe Festplatte, nur 32GB SD-Karte. Und außerdem einen VPS Provider mit 20GB SSD, der mich im Paket keine 2 Euro im Monat kostet.

    3) Das imho derzeit größte Problem wird weder im Artikel noch sonstwo groß angesprochen: Wenn ich bei einem bestehenden LN node mit diversen Channels einen irreparablen Crash habe (z.B. Hardwaredefekt), kann ich mittels seed, das bei der Installation angelegt wird, NUR das onchain wallet wiederherstellen. Alles was in channels steckte, ist erstmal weg (bei den größeren Nodes sind das gerne mal ein paar 10k Euro). Vielleicht gibt es ein frisches Backup (bei LND ist das z.B. die Datei channel.db), aber wenn ich das wieder einspiele, laufe ich Gefahr einen veralteten Channelstate einzuspielen (kann ja sein ich hab nach dem letzten Backup ein paar Zahlungen geroutet oder empfangen), und dann werden mich die entsprechenden Peers automatisch “punishen”, und ich verliere meinem kompletten Einsatz auf meiner Seite des Channels! Die einzigen (afaik), die dieses Problem momentan angehen, sind Aqinc/Eclair: https://medium.com/@ACINQ/enabling-automated-backup-on-eclair-wallet-9f58dc3d8407

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s