Lightning Network - Bitcoin

[Christoph Bergmann]

Am 9.2.2019 um 20:19 schrieb Xaladilnik:

Bereits 660 BTC und 6000 Nodes

https://1ml.com/statistics

Duetschland an 2. Stelle mit 270 Nodes und unter den Städten ist Frankfurt am Main ebenfalls an 2. Stelle mit 36 Nodes 

Frankfurt mit dem Superinternet-Knotenpunkt ist einer der globalen Top-Standorte für günstige Cloud-Server mit einer guten Bandbreite. Das heißt nicht zwingend, dass die Nodes einem Deutschen gehören.

Aber abgesehen davon ist es gut vorstellbar. Die Begeisterung hierzulande für Lightning ist schon umwerfend. Ich denke, das hat damit zu tun, dass Deutschland komplizierte, aber nachhaltige Lösungen mag.

[fox42]

vor 21 Stunden schrieb Christoph Bergmann:

[...] Ich denke, das hat damit zu tun, dass Deutschland komplizierte, aber nachhaltige Lösungen mag.

Für das Betreiben von Knoten ok. Für die Adaption als Zahlungsmittel braucht man einfach zu nutzende Apps.. Meinetwegen eine Bitcoin Wallet App, die dann einen mehr oder weniger dauerhaften Channel zu einem Bankknoten des Vertrauens aufbaut. So wie ich das verstanden habe, will man ja nicht häufig Channel auf und zu machen, gleichzeitig wird aber Guthaben von beiden Seiten geblockt.

[Xaladilnik]

Seven Fun and Interesting Use Cases for Bitcoin's Lightning Network:

https://www.cryptoglobe.com/latest/2019/02/seven-fun-and-interesting-use-cases-for-bitcoin-s-lightning-network/

[ratzfatz]

https://ethereumworldnews.com/multi-billion-dollar-store-dominos-pizza-now-accepts-bitcoin/

[leblitzdick]

vor 1 Stunde schrieb ratzfatz:

https://ethereumworldnews.com/multi-billion-dollar-store-dominos-pizza-now-accepts-bitcoin/

leider noch nicht bei uns...😕

[SkaliertDoch]

https://blockchain-hero.com/grosser-us-einzelhaendler-zieht-bitcoins-btc-lightning-network-visa-vor/

[Amsi]

Am 18.11.2018 um 14:32 schrieb Amsi:

Wow, habt ihr gesehen wie viel Channels die letzten Tage dazugekommen sind?
Mittlerweile gibt es über 15.000 Channels mit in Summe knapp 340 Bitcoin, was immerhin 1,9 Mio. Dollar sind!

Nur ca. 4 Monate später sind es bereits über 36.000 Channels und knapp 760 Bitcoin! 🚀🚀🚀

[SkaliertDoch]

vor 31 Minuten schrieb Amsi:

Nur ca. 4 Monate später sind es bereits über 36.000 Channels und knapp 760 Bitcoin! 🚀🚀🚀

Weniger als 4 Monate später! Das ist der Hammer! 

[Ulli]

https://www.btc-echo.de/bitcoin-wie-fiat-nur-guenstiger-lightning-mit-bitfury-weiter-auf-ueberholspur/

[ratzfatz]

Am 5.3.2019 um 14:17 schrieb SkaliertDoch:

https://blockchain-hero.com/grosser-us-einzelhaendler-zieht-bitcoins-btc-lightning-network-visa-vor/

Die Überschrift ist ja leicht übertrieben. Es finden im Moment Gespräche statt ob LN geeignet sein könnte . 

Bearbeitet 15. März 2019 von ratzfatz

[Thiasos]

Na, wer weiß es?

 

https://i.redd.it/lah4bhjawbm21.png

 

Bearbeitet 16. März 2019 von Thiasos

[Jokin]

1 Coin

[leblitzdick]

vor 4 Stunden schrieb Thiasos:

Na, wer weiß es?

 

https://i.redd.it/lah4bhjawbm21.png

 

Der eine Daumen war auch meine Antwort 🙂

[Jokin]

Das Beispiel zeigt ganz gut die Unzulänglichkeiten des Systems auf.

Ich bin mir aber nicht sicher ob das auch zukünftig so bleiben wird. Es gibt ja diverse Lösungsansätze:

Einer davon könnte so aussehen, dass bereits die Suche nach einer Route mit der Anforderung "Alice will 4 Coins an Frank senden" und es nicht nur eine Antwort von Bob kommt "ich kann nur "1 Coin" sondern "Ich kann 1 Coin für Gebühr von 1 Satoshi, ich kann auch 4 Coins für Gebühr von 200 Satoshis".

Denn Bob kann seine Payment-Channels mit Carol und David schließen und mit anderen Coin-Werten neu aufbauen, sodass er 4 Coins bereit hält, die er an David senden kann.

Nun liegt die Entscheidung bei Alice ob sie nur 1 Coin an Frank für super geringe Gebühren sendet oder ob sie für deutlich höhere Gebühren die vollen 4 Coins an Frank sendet.

Die höheren Gebühren kompensieren dann die Kosten für das Ab- und Aufbauen neuer Channels zwischen Bob und Alice, Bob und David sowie zwischen David und Frank.

 

Ein anderes Szenario sieht vor, dass die 4 Coins nicht in einer Transaktion gesendet werden sondern mit mehreren Transaktionen. Und auch das geht in der Konstellation ganz einfach:

1. Transaktion: Frank schickt sich selber 3 Coins ... Frank -> Ella -> Carol -> David -> Frank
2. Transaktion: Alice schickt sich selber 1 Coin ... Alice -> Bob -> Carol -> Alice
3. Transaktion: Alice schickt 4 Coins an Frank ... Alice -> Carol -> Ella -> Frank

 

Und ein drittes Szenario sieht vor, dass Alice ihre Paymentchannel mit Bob und Carol abbaut und einen direkten Channel zu Frank aufbaut und die 4 Coins direkt dorthin schickt.

 

Von daher ist das eigentliche Problem nur solange ein Problem wie man die Payment-Channels unangetastet lassen möchte und nur eine einzige Transaktion durchführen möchte.

[Thiasos]

24 minutes ago, Jokin said:

 

1. Transaktion: Frank schickt sich selber 3 Coins ... Frank -> Ella -> Carol -> David -> Frank

 

Mir ist nicht klar, wie in diesem Szenario Carol etwas an David senden kann.

[Jokin]

vor 24 Minuten schrieb Thiasos:

Mir ist nicht klar, wie in diesem Szenario Carol etwas an David senden kann.

Oops ... mein Fehler - zu flüchtig geschaut ... Frank kann über ... Carol->Bob->David ... nur einen Coin an sich selber senden ...

Wobei das Senden an sich selber wohl auch nicht so einfach in einer einzigen Transaktion geht?

[Tschaul]

Das Bild ist irreführend, das Netzwerk ist sehr viel stärker vernetzt, dadurch gibt es viel mehr Pfade von A nach B. Das gillt bloß eben nicht für die Endpunkte an denen die normalen User hängen. Die einfach Handy-Wallets haben meißt nur ein Channel zu einem großen Hub. 

Das Problem ist doch einfach, dass diese Channels alle einseitig von ihnen aus gefundet sind. Dadurch müssen sie erst Coins wegschicken bevor sie welche bekommen können. Was es bräuchte wäre beidseitig gefundete Channels. Das könnte aber nur eine kommerzielle Wallet leisten, die daran Geld verdient. So etwas gibt es leider noch nicht.

[Thiasos]

13 hours ago, Tschaul said:

Das Bild ist irreführend, das Netzwerk ist sehr viel stärker vernetzt, dadurch gibt es viel mehr Pfade von A nach B. Das gillt bloß eben nicht für die Endpunkte an denen die normalen User hängen. Die einfach Handy-Wallets haben meißt nur ein Channel zu einem großen Hub. 

Das Problem ist doch einfach, dass diese Channels alle einseitig von ihnen aus gefundet sind. Dadurch müssen sie erst Coins wegschicken bevor sie welche bekommen können. Was es bräuchte wäre beidseitig gefundete Channels. Das könnte aber nur eine kommerzielle Wallet leisten, die daran Geld verdient. So etwas gibt es leider noch nicht.

Hier mal mein Verständnis:

Die Bottlenecks sind die Start- und Endpunkte. Wenn diese nicht über ausreichend Kapazität verfügen, wird keine Route gefunden. Und selbst wenn der Endpunkt mit einem großen Hub verbunden ist, ergeben sich m. E. eine Menge Probleme:

• Dieser Hub müsste alle seine Channels mit ausreichend Kapazität ausstatten
• Angenommen, dieser Hub verfügt über tausende Channels, so würden hier eine große Menge an Kapazitäten benötigt
• Da die Lightning Bitcoins in einer Hot Wallet stecken, ist der Betreiber des Hubs des Risikos eines Verlustes ausgesetzt
• Damit sich das Betreiben eines Hubs trotzdem lohnt, müsste dieser entsprechend hohe Gebühren verlangen
• Zudem führt die Notwendigkeit von Hubs zu einer Zentralisierung des Netzwerks, was dem eigentlichen Ziel von Bitcoin m. E. widerspricht
  • LN führt mit den Hubs Intermediäre ein
  • welche Transaktionsgebühren erheben
  • welcher den Channel zu dir jederzeit schließen kann (Zensur)
  • falls ein großer Hub ausfällt, würden große Teile der Nodes vom System ausgeschlossen werden und somit viele Endpunkte nicht mehr erreichbar sein
• Je größer das Netz wird, desto schwieriger könnte das Finden eines passenden Pfades werden, denn ein Channel mit ausreichender Kapazität könnte im nächsten Moment nicht mehr über ausreichende Kapazität verfügen, weil bereits eine andere Transaktion diesen Channel genutzt hat
• Durch Lightning wird ein einfaches System durch ein sehr komplexes System ersetzt
• Das Verlustrisiko ist hoch

Angenommen, der Supermarkt selbst ist an einem großen Hub angebunden. Und weiterhin angenommen, es würden über diesen Channel täglich hunderte Transaktionen vom Hub zum Supermarkt abgewickelt. Schon nach relativ kurzer Zeit wäre die Kapazität des Channels zum Supermarkt leer. Und dann?

Second Layer Anwendungen wie Lightning können nur in einer Nische funktionieren. So ist Lightning nur für Micropayments gedacht, aber nicht für den Einkauf im Supermarkt. Man stelle sich vor, du stehst an der Kasse und es wird keine passende Route gefunden. Lightning wird bereits seit 2013, also seit 6 Jahren, entwickelt und benötigt laut Aussagen der Entwickler noch weitere Jahre. Es ist unsicher, ab wann (und ob überhaupt jemals)  ein funktionierendes System existieren wird.

Ich finde es riskant, sich auf Lightning als Skalierungslösung zu verlassen. BTC benötigt eher kurzfristig eine Lösung, um als Cash zu funktioneren.

 

Vielleicht habe ich Denkfehler, Fehler in der Argumentation und ganz sicher fehlenden Sachverstand. Lass es mich wissen, wo ich falsch liege.

[Thiasos]

18 hours ago, Jokin said:

Das Beispiel zeigt ganz gut die Unzulänglichkeiten des Systems auf.

Ich bin mir aber nicht sicher ob das auch zukünftig so bleiben wird. Es gibt ja diverse Lösungsansätze:

Ein Lösungsansatz könnte irgendwann mal AMP (Atomic Multipath Payments) sein.

Quote

Einer davon könnte so aussehen, dass bereits die Suche nach einer Route mit der Anforderung "Alice will 4 Coins an Frank senden" und es nicht nur eine Antwort von Bob kommt "ich kann nur "1 Coin" sondern "Ich kann 1 Coin für Gebühr von 1 Satoshi, ich kann auch 4 Coins für Gebühr von 200 Satoshis".

Denn Bob kann seine Payment-Channels mit Carol und David schließen und mit anderen Coin-Werten neu aufbauen, sodass er 4 Coins bereit hält, die er an David senden kann.

Nun liegt die Entscheidung bei Alice ob sie nur 1 Coin an Frank für super geringe Gebühren sendet oder ob sie für deutlich höhere Gebühren die vollen 4 Coins an Frank sendet.

Die höheren Gebühren kompensieren dann die Kosten für das Ab- und Aufbauen neuer Channels zwischen Bob und Alice, Bob und David sowie zwischen David und Frank.

 

Ein anderes Szenario sieht vor, dass die 4 Coins nicht in einer Transaktion gesendet werden sondern mit mehreren Transaktionen. Und auch das geht in der Konstellation ganz einfach:

1. Transaktion: Frank schickt sich selber 3 Coins ... Frank -> Ella -> Carol -> David -> Frank
2. Transaktion: Alice schickt sich selber 1 Coin ... Alice -> Bob -> Carol -> Alice
3. Transaktion: Alice schickt 4 Coins an Frank ... Alice -> Carol -> Ella -> Frank

 

Und ein drittes Szenario sieht vor, dass Alice ihre Paymentchannel mit Bob und Carol abbaut und einen direkten Channel zu Frank aufbaut und die 4 Coins direkt dorthin schickt.

 

Von daher ist das eigentliche Problem nur solange ein Problem wie man die Payment-Channels unangetastet lassen möchte und nur eine einzige Transaktion durchführen möchte.

Dies zeigt, wie komplex Lightning ist.  KISS (keep it simple stupid) hat sich in der Softwareentwicklung ziemlich gut bewährt.

[Jokin]

vor 3 Stunden schrieb Thiasos:

Man stelle sich vor, du stehst an der Kasse und es wird keine passende Route gefunden.

Ähm.

Aber ich stehe doch genau vor der Kasse.

Warum kann ich keinen direkten Payment-Channel mit der Supermarktkasse aufbauen? Da packe ich dann ausreichend Funds rein und zack, ist meine Ware bezahlt. Im einfachsten und teuersten Fall baue ich den Channel dann wieder ab - da hätte ich die Transaktion auch gleich als BTC-Transaktion in die Blockchain schreiben können.

Nun muss man aber auch noch ein bisschen weiter denken. 

Was ist denn, wenn ich Mitarbeiter des Supermarkts bin?

Ich bekomme dann monatlich meinen Lohn und habe dann genug in meinem Channel um meine Einkäufe in diesem Supermarkt zu bezahlen. Damit funktioniert das Grundkonzept ohne dass ich Channels öffnen und schließen muss.

Dadurch wird aber auch deutlich, dass das Netzwerk am besten funktioniert, wenn der Zahlungsverkehr auch immer in beide Richtungen funktioniert - ich bezahle etwas, aber ich sollte auch etwas bekommen, was ich dann wieder ausgeben kann. Und das im Idealfall über denselben Channel - nicht dass ich nur einen Channel habe über den ich was erhalte und über den anderen bezahle ich ... 

Oder ist das Netz dann doch so ausgereift, dass Channels sich automatisch ausbalancieren - also von einem Channel Coins in einen anderen transferieren? - eigentlich dürfte das nicht ohne ein Schließen von Channels gehen, oder?

[Tschaul]

Das Problem ist gelöst:

Lightning Loop Lets Users Empty Lightning Channels Without Closing Them
https://bitcoinmagazine.com/articles/lightning-loop-lets-users-empty-lightning-channels-without-closing-them/

Damit kann man seine eigenen Channels balancen mit einer on-chain-Transaktion.

[Jokin]

Sehr gut!

Es war ja nur eine Frage der Zeit bis man seine Funds von einem Channel zum anderen verschieben kann.

Damit ergibt sich eine theoretische Kapazität über jede Route hinweg bis zu der Betragshöhe was ich senden will.

Wenn einer der Nodes auf dem Weg zum Empfänger on-chain balancen muss um meinen Betrag durchzurouten, erhöht dieser die Fee entsprechend. Damit kann der Sender selber entscheiden ob er senden will oder nicht.

Später wird es noch "Splitsending" geben. Sobald einer der Nodes zwischen Sender und Empfänger feststellt, dass er nur einen Teilbetrag weiterrouten kann, den Rest jedoch über eine andere Route, dann wird auch das möglich sein - ist aber kompliziert umzusetzen.

[Jokin]

Am 9.2.2019 um 20:19 schrieb Xaladilnik:

Bereits 660 BTC und 6000 Nodes

https://1ml.com/statistics

Duetschland an 2. Stelle mit 270 Nodes und unter den Städten ist Frankfurt am Main ebenfalls an 2. Stelle mit 36 Nodes 

1056 BTC und 7500 Nodes.

Davon 1100 Nodes in den USA (Platz 1) und 339 in Deutschland (Platz 2)

Meiner ist die Nummer 339 in der Liste 🙂

Derzeit experimentiere ich ein wenig damit herum - für's iPhone hab ich "Bluewallet", gibt es bessere Empfehlungen?

[Thiasos]

Quote

While still in the testing phase, Lighting Labs’ blog post emphasized that “Loop Out transactions are limited to a maximum of 0.01 BTC” and will require no additional fees beyond on-chain transaction fees.

Mit anderen Worten: zusätzlich zu den Onchain-Fees werden nach Ende der Testphase weitere Gebühren anfallen.

Ich frage mich, ob das Geschäftsmodell vorsieht, bewusst ein Problem zu schaffen, um dann für die Lösung dieses Problems Gebühren zu verlangen.

[triumvirat]

vor 4 Stunden schrieb Jokin:

Derzeit experimentiere ich ein wenig damit herum - für's iPhone hab ich "Bluewallet", gibt es bessere Empfehlungen?

 

Was stimmt nicht mit der Bluewallet? Hab sie auch installiert(LinageOS) + Lnd + LndHub, läuft problemlos.

Die Einrichtung der Wallet ist etwas gewöhnungsbedürftig, funktionieren aber tadellos.

 

PS: Vielleicht ist die Zap Wallet was für dich. Kann sie leider nicht testen da nur für iOS, die Desktop-Wallet ist gut.

Bearbeitet 22. März 2019 von triumvirat
Ergänzung