Lightning Netzwerk - Eclair: Aufsetzen eines LN-Knoten im Testnetz

[butch3r]

Danke für die Links. Ich finde das auch ziemlich spannend.

Manche hier im Forum sind ja eher pessimistisch was die Annahme von Lightning angeht. Besonders, weil ja auch die Verbreitung von Segwit ziemlich schleppend voran geht. Meiner Meinung nach ist aber ein entscheidender Unterschied, dass ich als Nutzer bei der Nutzung von Segwit erstmal keinen Unterschied merke. Ich tue zwar etwas gutes fürs Netzwerk, aber gefühlt hat das kaum einen Einfluss.

Bei Lighting bin ich ab der ersten Transaktion so gut wie Kostenlos und um ein vielfaches schneller. Z.B. für Exchanges, die ein hohes Transaktionsvolumen haben, könnte das schon ein ausreichender Anreiz sein.

[curiosity81]

Was mir aufgefallen ist ist, dass auf https://explorer.acinq.co auch Knoten angezeigt werden, welche aktuell nicht online sind. D.h. dies kann auch ein Grund dafür sein dass ihr euch nicht mit einem Knoten verbinden könnt.

Die IP muss händisch in der eclair.conf ausgetauscht werden falls sich die IP über Nacht ändert und Eclair muss neu gestartet werden, damit sie auf oberer Seite korrket angezeigt wird. Das dauert dann ein Weilchen bis das upgedatet ist. Funktioniert aber.

Gestern waren es 97 Knoten im Mainnet.
Heute sind es 134 Knoten im Mainnet bei 312 Channels.
(https://lnmainnet.gaben.win/)

Und das Netzwerk bindet etwa 2.3 BTC.
https://p2sh.info/dashboard/db/lightning-network?orgId=1

Aktuell liegt die Wachstumsrate zwischen 10%-40% pro Tag. Unter der Annahme, dass das Netzwerk im Schnitt um 10% pro Tag wächst so hätten wir in 30 Tagen ca. 2300 Knoten.

[curiosity81]

Heute: 162 Knoten im Mainnet mit 397 Channels und ca. 3 gebundenen BTC.

[butch3r]

Danke, dass du das hier fest hältst. Es wäre noch spannend eine Statistik über die Anzahl der Transaktionen und Nutzer im Netzwerk zu sehen.

[curiosity81]

Danke, dass du das hier fest hältst. Es wäre noch spannend eine Statistik über die Anzahl der Transaktionen und Nutzer im Netzwerk zu sehen.

Naja, eigentlich versuch ich nur den Thread oben zu halten, damit der nicht so schnell verschwindet  . Heute kann ich aber keine Statistik machen, da der eine Link nicht funktioniert.

Das habe ich noch gefunden:

https://bitcoinblog.de/2018/01/24/die-lightning-faq-fuer-fortgeschrittene/

Was mir gerade am LN nicht so gefällt, ist die Sache mit dem Onlinebleibenmüssen, d.h. einen Channel am Laufen lassen bzw. ständiges Überprüfen, dass die Partei am anderen Ende eines Channels keinen Schindluder treibt (siehe auch der bitcoinblog.de-Artikel). Selbst wenn man Schindludertreiben bestraft, so kann man sicherlich Angriffe fahren, sodass man nicht rechtzeitig wieder online ist um das Schindluder zu entdecken. Warum hat man das nicht anders gelöst?

Z.B. könnte man beim Öffnen eines Channels mit einem Gegenknoten immer auch noch eine Anzahl von Kontrollknoten aus dem Netzwerk definieren, welche die Korrektheit der Channelbenutzung überwachen. Dann wäre es Wurst ob man online ist oder nicht. Diese Kontrollknoten müssten natürlich Einsicht in den Channel haben. Finde ich aber nicht so problematisch. Auch ein Angriff wäre kaum zu fahren, da man möglicherweise die Identität der Kontrollknoten geheimhalten kann. Ich denke aber, dass diese oder eine ähnliche Methode sehr leicht auf das LN-Protokoll draufgesetzt werden kann.

[butch3r]

Was mir gerade am LN nicht so gefällt, ist die Sache mit dem Onlinebleibenmüssen, d.h. einen Channel am Laufen lassen bzw. ständiges Überprüfen, dass die Partei am anderen Ende eines Channels keinen Schindluder treibt (siehe auch der bitcoinblog.de-Artikel). Warum hat man das nicht anders gelöst?

Naja aber im Artikel ist ja auch beschrieben, dass die Zeit beliebig verlängert werden kann. Das heißt wenn man es z.B. auf eine Woche festlegt sollte es für die meisten Leute locker möglich sein den Channel ausreichend zu prüfen. Einziger Nachteil wäre, dass die Funds im Channel eher unflexibel sind.


Außerden könnte ich mir vorstellen, dass es dafür in zukunft Services geben könnte, die deinen Channel für dich prüfen. Das wäre nur ein möglicher Lösungsansatz, aber ich glaube nicht, dass es durch den Online Zwang langfristig zu problemen kommen wird.

Z.B. könnte man beim Öffnen eines Channels mit einem Gegenknoten immer auch noch eine Anzahl von Kontrollknoten aus dem Netzwerk definieren, welche die Korrektheit der Channelbenutzung überwachen. Dann wäre es Wurst ob man online ist oder nicht. Diese Kontrollknoten müssten natürlich Einsicht in den Channel haben.

Ich denke da haben sich die Entwickler aktuell gegen entschieden, damit alles möglichst anonym abläuft. Im moment sind die LN-Transationen ja verschlüsselt und sind nur von den beiden Teilnehmern einzusehen. Deinen Ansatz mit den Kontrollknoten finde ich aber auch nicht schlecht. Vielleicht ja irgendwann

[hv_]

Noch ein paar News:

https://bitcoinblog.de/2018/01/18/die-ersten-lightning-transaktionen-auf-dem-echten-bitcoin-netz/

Wieso versucht man die Bitcoin Krücke am leben zu erhalten? Ihr versucht doch auch nicht einen 2 Takter so umzukonstruieren, dass er effizienter wird, stattdessen bedient man sich besserer
Konstruktionen und ignoriert die alten Motoren. Lasst den Bitcoin Bitcoin sein, versucht doch nicht durch krücken das System skalierbar zu machen sondern bedient euch
hier besserer Techniken. Vor allem ist das Konzept des Bitcoin ökologisch meiner Ansicht nach in heutiger Zeit, wo es um Schadstoff Ausstoß oder Stromressourcen Schonung geht nicht mehr akzeptabel.
Hier gibt es weitaus bessere Verfahren die Ökologisch effizient sind.

Bitcoin kann ja gern so bleiben wie es ist und als Grundwährung wie zb unser physisches Gold bleiben, als vergleichbare Fiatwährung sollte man sich jedoch anderer Techniken bedienen.

Aber spätestens mit dem Rollout der neuen intelligenten Zähler und der dmit in Zukunft drastischen Strompreissteigerungen hierzulande werden zumindest in Deutschland die letzten Miner abgestellt.

Bitcoin ist nur als PoW mit enormen externen Langzeit (Hardware) / Kurzzeitinvestments (Strom) im freien Internet wirklich sicher. Es braucht ein ökonomisches Gleichgewicht / hohe Barriere für Angreifer das ganze SICHER am laufen zu lassen, ganz ähnlich, wie geschlossene System (Banken) mit hohen Kosten ihre Firewall / Cybersecurity bettreiben müssen - dieses Wissen ist leider nicht oft vorhanden.


Weiter bin ich als bekannter Big-Blocker ebenso an LN fundamental / sicherheitstechnisch / kundenschutzseitg interessiert, ich denke es gibt vernünftige Anwendungen, z.B. Netting von TRX bei immer denselben Gegenparteien wir z.B: HF Trading, Mirco-Payments für online content (Musik , Filme usw). Leider glaube ich nicht, dass es annähernd ausreicht, um die Skalierung zu lösen und es genügend Zeit gib (Horizont 2-3 Jahre, damit alles für Finanzsysteme sauber genug ist) , irgendetwas damit 'schnell' zu retten

Hier noch mein konstruktiven Input an alle Versuchskaninchen: Denkt an die Regularien als Payment Processor - dies ist BAFIN Gebiet und könnte manche recht schnell wieder auf den Boden bringen.

In der Schweiz sollte die FINMA relative gute Einstiegs-Regularien haben, das ist evtl hilfreicher als in D....

[mezzomix]

Ich finde Kontrollknoten eher schlecht. Besser wäre in meinen Augen ein Konzept mit langen Laufzeiten, bei denen eine/mehrere Third Party Signatur(en) zum früheren Schliessen benötigt werden.

Jetzt halte ich es für sinnvoll, erst mal mit LN Erfahrung zu sammeln. Ausserdem sagt ja keiner, dass es in Zukunft nicht für verschiedene Anwendungsfälle unterschiedliche Second Layer Lösungen geben darf.

Zur Bafin: Zum Teufel damit, ausserdem ist meine unentgeltliche Weiterleitung für die Community noch lange keine Finanzdienstleistung.

[hv_]

Zur Bafin: Zum Teufel damit, ausserdem ist meine unentgeltliche Weiterleitung für die Community noch lange keine Finanzdienstleistung.

Dein Kalliber kann sich evtl ein gute rechtliche Absicherung leisten - ich informiere hier die 'Kleinern'.


Unwissenheit schütz nicht vor Strafe.

[mezzomix]

Zur Bafin: Zum Teufel damit, ausserdem ist meine unentgeltliche Weiterleitung für die Community noch lange keine Finanzdienstleistung.

Dein Kalliber kann sich evtl ein gute rechtliche Absicherung leisten - ...

Es gibt keine rechtliche Absicherung gegen Willkür und rechtswidrige Auffassungen. Aber erst mal muss die Bafin etwas Substanzielles in der Hand haben. Solange ich meinen Hub nicht auf einer deutschen Webseite als Finanzdienstleistung bewerbe, werden die wohl damit ihre Probleme haben.

Die Frage stellt sich, was eigene Interpretationen ohne rechtlich Grundlage in vorauseilendem Gehorsam (im Englischen nennt man es FUD) bringen. cui bono?

Unwissenheit schütz nicht vor Strafe.

Und Wissen schützt nicht vor Willkür. Ist halt so, das Leben ist extrem gefährlich. Es endet immer tödlich.

[hv_]

^  mache sich besser jeder selber Schlau (ist besser mit vielem)  - es gibt bereits genügend Material hierzu.

 

[d5000]

Was mir gerade am LN nicht so gefällt, ist die Sache mit dem Onlinebleibenmüssen, d.h. einen Channel am Laufen lassen bzw. ständiges Überprüfen, dass die Partei am anderen Ende eines Channels keinen Schindluder treibt (siehe auch der bitcoinblog.de-Artikel). Selbst wenn man Schindludertreiben bestraft, so kann man sicherlich Angriffe fahren, sodass man nicht rechtzeitig wieder online ist um das Schindluder zu entdecken. Warum hat man das nicht anders gelöst?

Das ist eben der große "Tradeoff" von Lightning. Ich vermute aufgrund des Off-Chain-Designs, das ist anders gar nicht möglich, bin aber leider kein Informatiker.

Statt einem Kontrollknoten mit Einsicht in den Channel müsste es aber eigentlich ausreichen, einen Dienst zu beauftragen, die Multisig-Addresse zu überwachen, auf der die "Channel-Coins" liegen, oder? Über Block Explorer oder einen befreundeten Bitcoin-Nutzer (am besten mit Full-Node) müsste das machbar sein, ohne dass der "Überwacher" der Gegenpartei bekannt wird. Klar, irgendwie "online" muss man auch da sein, da man ja nur mit den eigenen Keys die Coins vor der Gegenpartei ausgeben und damit "retten" kann, aber da tut's ja eine Smartphone-Benachrichtigung.

Mehr Kopfschmerzen bereitet mir dieses Szenario, das ein User aus dem Bitcoinblog noch ganz harmlos findet:

Wird eine der Banken zugemacht oder will mit dem Guthaben der Kunden verschwinden, so machen einfach alle Kunden ihre Channels zu und es geht kein Geld verloren.

(der Nutzer bezeichnet große LN-Nodes als Banken).

Worauf ich hinaus will? Ganz klar: so "einfach" wird das bei einer Blockchain mit begrenztem Platz nicht gehen. Erreicht ein Hub also eine bestimmte Größe (ab ca. Hunderttausenden Nutzern), wird er "too big to fail", da die Channels nicht mehr in einer angemessenen Zeit geschlossen werden können.

Deshalb, wie gesagt, ist LN für mich eine super Prepaidkarte für Micropayments, aber mehr nicht. Für größere Mengen würde ich Sidechains oder sogar Child-Chains (Sidechains mit vorübergehender Validierung durch Full-Nodes) bevorzugen.

[curiosity81]

Was mir gerade am LN nicht so gefällt, ist die Sache mit dem Onlinebleibenmüssen, d.h. einen Channel am Laufen lassen bzw. ständiges Überprüfen, dass die Partei am anderen Ende eines Channels keinen Schindluder treibt (siehe auch der bitcoinblog.de-Artikel). Selbst wenn man Schindludertreiben bestraft, so kann man sicherlich Angriffe fahren, sodass man nicht rechtzeitig wieder online ist um das Schindluder zu entdecken. Warum hat man das nicht anders gelöst?

Das ist eben der große "Tradeoff" von Lightning. Ich vermute aufgrund des Off-Chain-Designs, das ist anders gar nicht möglich, bin aber leider kein Informatiker.

Statt einem Kontrollknoten mit Einsicht in den Channel müsste es aber eigentlich ausreichen, einen Dienst zu beauftragen, die Multisig-Addresse zu überwachen, auf der die "Channel-Coins" liegen, oder? Über Block Explorer oder einen befreundeten Bitcoin-Nutzer (am besten mit Full-Node) müsste das machbar sein, ohne dass der "Überwacher" der Gegenpartei bekannt wird. Klar, irgendwie "online" muss man auch da sein, da man ja nur mit den eigenen Keys die Coins vor der Gegenpartei ausgeben und damit "retten" kann, aber da tut's ja eine Smartphone-Benachrichtigung.

Mehr Kopfschmerzen bereitet mir dieses Szenario, das ein User aus dem Bitcoinblog noch ganz harmlos findet:

Wird eine der Banken zugemacht oder will mit dem Guthaben der Kunden verschwinden, so machen einfach alle Kunden ihre Channels zu und es geht kein Geld verloren.

(der Nutzer bezeichnet große LN-Nodes als Banken).

Worauf ich hinaus will? Ganz klar: so "einfach" wird das bei einer Blockchain mit begrenztem Platz nicht gehen. Erreicht ein Hub also eine bestimmte Größe (ab ca. Hunderttausenden Nutzern), wird er "too big to fail", da die Channels nicht mehr in einer angemessenen Zeit geschlossen werden können.

Deshalb, wie gesagt, ist LN für mich eine super Prepaidkarte für Micropayments, aber mehr nicht. Für größere Mengen würde ich Sidechains oder sogar Child-Chains (Sidechains mit vorübergehender Validierung durch Full-Nodes) bevorzugen.

Nunja, das ist wieder das Problem der Zentralisierung. Das LN sollte möglichst dezentral sein, d.h. auch kleine Parteien sollten irgendwie motiviert werden einen Knoten aufzusetzen.

Was Du und dieser Nutzer aber übersehen ist, dass nicht jeder Kunde einen Channel offen haben muss, um mit solch einer "Bank" Werte auszutauschen. Man kann sich z.B. eine Topologie vorstellen, wo der grosse Knoten zwei Channels zu zwei weiteren unterschiedlichen Knoten offen hat. Diese Knoten haben wieder jeweils zwei Nachbarknoten usw. usf., also baumartig. Wobei das LN nicht gleich dem Baum ist! Es muss nur möglich sein, dass man einen (z.B. binären) Spannbaum (https://de.wikipedia.org/wiki/Spannbaum) in das Netz aka Graph hineinprojizieren kann, mit der "Bank" als Wurzel. Dann kannst Du im Beispiel des binären Baums über N Schritte 2^N Leute abdecken und bei Betrugsversuchen der "Bank" müssen sich nur die zwei Nachbarknoten kümmern. Beim Schliessen der Channels bei einem Betrugsversuch würden also nur zwei Blockchaintransaktionen notwendig! Und Ähnliches gilt dann für alle Teilnehmer bei einem stark dezentralen Netzwerk. Alles immer unter der Vorraussetzung, dass die Kapazitäten der einzelnen Channels gross genug sind. Aber warum sollte eine Exchange 1000 kleine Channels mit geringer Kapazität öffnen wenn es wirtschaflicher ist sich ein paar Nachbarn zu suchen, welche die entsprechende Transaktionkapazität stellen können. D.h. die Summe der Channelkapazitäten ist vielleicht in jeder Ebene/Level in einem solchen Baum ähnlich, aber verteilt sich entsprechend auf mehr Knoten. Idealisiert sähe das dann so aus: die Exchange hat Kaufkraft aka Kapazität K, die zwei Nachbarn haben haben jeweils Kapazität K/2, die Nachbarn davon jeweils K/4 usw. usf..

Natürlich verbindet sich in frühen Phasen wohl jeder direkt mit einem Channel mit einer Exchange. Aber notwendig ist das nicht. Und wird sich imho auch irgendwann geben.

[curiosity81]

So jetzt kann ich wieder eine Statistik machen:

Anzahl Knoten im Mainnet: 209
Anzahl Channels im Mainnet: 575

[d5000]

Interessantes Szenario, curiosity81. Muss ich mir noch mal durch den Kopf gehen lassen, obwohl ich auf den ersten Blick nicht glaube, dass Exchanges ihren Node baumartig anlegen werden (weniger Kundenbindung, eventuell mehr Transaktionsgebühren ...), aber vielleicht öffnet mir der zweite Blick die Augen.

Klar, LN steht und fällt mit der De/Zentralisierung. Es kommt eben drauf an, wie viele User den bequemen Weg gehen und einfach alles über den Node ihrer Lieblings-Exchange regeln. Wenn das genug sind, dann könnte die Spieltheorie sogar den Betrügern in die Hände spielen, wenn sie wissen, dass die Mehrzahl ihrer Kunden ihre Channels innerhalb einer Woche nicht mehr schließen kann.

Natürlich könnten Hubs mit Betrugabsichten sich auch als mehrere Nodes tarnen, die eine Struktur wie von dir geschildert vortäuschen, sich aber im Ernstfall alle gleichzeitig verabschieden. Sowas zu entdecken dürfte schwierig sein ...

[curiosity81]

Interessantes Szenario, curiosity81. Muss ich mir noch mal durch den Kopf gehen lassen, obwohl ich auf den ersten Blick nicht glaube, dass Exchanges ihren Node baumartig anlegen werden (weniger Kundenbindung, eventuell mehr Transaktionsgebühren ...), aber vielleicht öffnet mir der zweite Blick die Augen.

Eine wirtschaftliche Topologie, wie ich sie oben beschrieben habe, schliesst doch keine Kunden aus. Kunden bekommen einen Zahlungsaufruf per (QR-)Code direkt über das Internet. Den Rest erledigt das Lightning Netzwerk. Es ist schlicht unwirtschaftlich für eine Exchange sich mit jedem Kunden einzeln zu verbinden. Jeder Kunde impliziert mindestens eine Transaktion und somit Gebühren. Und selbiges gilt für die Kunden.

Dass man sich NICHT direkt mit dem Ziel verbinden muss, DAS ist doch gerade die Eleganz und Schönheit des Lightning Netzwerk!

Um mal ein übertriebenes Beispiel zu geben: Im Extremfall reicht es schon einen Paymentchannel zum Smartphone eines guten Kumpel zu öffnen, und man kommt, rein theoretisch, mit seinen Zahlungen überall hin. Vorausgesetzt, der Kumpel hat mindestens einen zusätzlichen Channel offen um Zahlungen weiterzuleiten und beide Channels stellen genug Kapazität zur Verfügung.

Klar, LN steht und fällt mit der De/Zentralisierung. Es kommt eben drauf an, wie viele User den bequemen Weg gehen und einfach alles über den Node ihrer Lieblings-Exchange regeln. Wenn das genug sind, dann könnte die Spieltheorie sogar den Betrügern in die Hände spielen, wenn sie wissen, dass die Mehrzahl ihrer Kunden ihre Channels innerhalb einer Woche nicht mehr schließen kann.

Ich verstehen Dein Beispiel. Im Extremfall ist eine Exchange in der Mitte, man selbst ist mit ihr verbunden und der Kumpel auch. Zahlungen an den Kumpel laufen dann über die Exchange. Ich bin aber trotzdem der Meinung, dass die Exchange lieber wenige Channels mit viel Kapazität öffnen wird als viele Channels mit wenig Kapazität. Ich könnte mir nämlich vorstellen, dass im Mittel Channels mit geringer Kapazität früher schliessen. D.h. viele schwache Channels bedeuten viele Transaktionen und damit Gebühren. Ausserdem würden sie früher schliessen und man müsste sie in höherer Frequenz neu erzeugen. Der Gebührennachteil verstärkt sich so nochmals. Konsequenterweise wird es dann eine Auslese geben, starke Channels bleiben erhalten, schwache verschwinden und/oder das pendelt sich bei bestimmten Verhältnissen ein. Deshalb denke ich, dass es nicht sinnvoll ist, für jeden Kunden einen eigenen Paymentchannel aufzumachen.

Natürlich könnten Hubs mit Betrugabsichten sich auch als mehrere Nodes tarnen, die eine Struktur wie von dir geschildert vortäuschen, sich aber im Ernstfall alle gleichzeitig verabschieden. Sowas zu entdecken dürfte schwierig sein ...

Das wäre aber imho ein kostspielige Sache, wenn eine Exchange so etwas simulieren wollte. Diese künstlichen Knoten müssten auch Channels öffnen. Und über diese Channels müssten auch Transaktionen laufen. Ich weiss jetzt nicht ob es möglich sein wird, beim Routing herauszufinden über welche Knoten eine Transaktion läuft, aber prinzipiell ist das möglich. Und dann könnte man einfach eine Statistik über die Transaktionsfrequenz pro Knoten machen. Nur die Knoten, welche direkt verbunden mit der Exchange sind und über die der Grossteil der Transaktionen laufen, erfüllen meine obere Definition von diesen "mächtigen" Nachbarknoten. Alle anderen kann man wohl getrost ignorieren. Und um solche Knoten zu simulieren müsste wohl einiges an Kapital gebunden werden um eine grosse Exchange derart neu zu verkabeln ohne Verdacht zu erwecken, d.h. ohne den normalen Ein- und Auszahlverkehr zu behindern. Ich halte es nicht für unmöglich aber aktuell denke ich, dass es nicht (gut) funktionieren wird.

Das sind aber alles (System)Fragen, die kann man gar nicht so pauschal beantworten. Man müsste das im Computer simulieren und in der Realität beobachten um sie zu beantworten.

[d5000]

Eine wirtschaftliche Topologie, wie ich sie oben beschrieben habe, schliesst doch keine Kunden aus.

Mit der Kundenbindung meinte ich, dass es sich für Exchanges eventuell lohnen würde, jedem Kunden einen kostenlosen LN-Kanal anzubieten. Exchanges wollen ja einen großen Marktanteil haben, und wer dann als erster Dein offizieller Hub ist, der bekommt sicher auch die meisten Handelsaufträge von Dir. Und ein Kunde mit LN-Kanal macht auch nicht mehr TX-Gebühren aus als einer ohne (die Multisig-Transaktion ist vielleicht größer als eine reguläre, aber dafür gibt es weniger TX insgesamt).

Dass man sich NICHT direkt mit dem Ziel verbinden muss, DAS ist doch gerade die Eleganz und Schönheit des Lightning Netzwerk!

Das ist vollkommen klar - die Frage ist aber, wie groß die größeren Hubs sein werden. Denn Hubs (deutlich besser verbundene Knoten) wird es geben.

Selbst in deinem Beispiel mit einem Kumpel: Mindestens einer aus dem Freundeskreis muss sich schließlich mit der "weiten Lightning-Welt" verbinden, solange ihr nicht nur gegenseitig Zahlungen tätigen wollt. Könnte natürlich z.B. einer sein, der einen geographisch entfernteren Kumpel hat, oder der gerne Pizza bei einem bekannten LN-akzeptierenden Shop isst, oder so ähnlich. Oder halt "der Computernerd" . Der wird aber dann sicher zu einem kleinen Hub. Wenn die ganzen Kumpels aber dann den "gut verbundenen" Kumpel dazu drängen, eine höhere Kapazität aufzubauen, dann könnte der auf die Idee kommen, eine Beteiligung am Risiko zu fordern.

Ich will gar nicht übetrieben pessimistisch sein - vielleicht funktioniert das dezentrale Kumpel-Modell. Aber man sieht ja bei MtGox usw. dass die meisten User faul sind und keinen eigenen Node aufsetzen, diese werden dann wahrscheinlich auch höchstens einen eigenen Kanal offen haben oder ansonsten eine angebundene Online-Wallet oder Exchange (Hubs!) nutzen.

Selbst wenn nur einer der Hubs auf die kritische Kapazität von 100.000+ Channels käme, gäbe es eine Art "systemisches Risiko", da ein einziger erfolgreicher Hub-Exit-Scam einer zu viel sein könnte, dass das System angenommen wird.  Das sollte auf jeden Fall aktiv verhindert werden - ähnlich wie bei den Miningpools, bei denen ja einer mit nahe 50% bereits ein Risiko darstellt.

Ich bin aber trotzdem der Meinung, dass die Exchange lieber wenige Channels mit viel Kapazität öffnen wird als viele Channels mit wenig Kapazität. Ich könnte mir nämlich vorstellen, dass im Mittel Channels mit geringer Kapazität früher schliessen. D.h. viele schwache Channels bedeuten viele Transaktionen und damit Gebühren. Ausserdem würden sie früher schliessen und man müsste sie in höherer Frequenz neu erzeugen. Der Gebührennachteil verstärkt sich so nochmals. Konsequenterweise wird es dann eine Auslese geben, starke Channels bleiben erhalten, schwache verschwinden und/oder das pendelt sich bei bestimmten Verhältnissen ein. Deshalb denke ich, dass es nicht sinnvoll ist, für jeden Kunden einen eigenen Paymentchannel aufzumachen.

Verstehe ich schon, und es wäre gut, wenn Du hier recht hättest. Das wird imho sehr davon abhängen, wie sich die Gebühren entwickeln - und ob der oben geschilderte Vorteil der Kundenbindung den Nachteil von mehr TX-Gebühren ausgleicht.

Das wäre aber imho ein kostspielige Sache, wenn eine Exchange so etwas simulieren wollte. Diese künstlichen Knoten müssten auch Channels öffnen. Und über diese Channels müssten auch Transaktionen laufen.

Wenn von Beginn an eine Scam-Absicht besteht (z.B. wie bei Pirateat40 oder neuer eventuell Cryptsy oder Bitconnect ...), wird das sicher machbar sein, schließlich kosten LN-Transaktionen kaum Gebühren.

Ich weiss jetzt nicht ob es möglich sein wird, beim Routing herauszufinden über welche Knoten eine Transaktion läuft, aber prinzipiell ist das möglich.

Hoffen wir's. Ich bin aber etwas pessimistisch, ob man wirklich eine verdächtige Topologie finden kann.

Das sind aber alles (System)Fragen, die kann man gar nicht so pauschal beantworten. Man müsste das im Computer simulieren und in der Realität beobachten um sie zu beantworten.

Volle Zustimmung.

[butch3r]

Ich finde eure Diskussion interessant, aber so wie ich den letzten Artikel auf dem Bitcoinblog verstanden habe ist ein großer Exit-Scam nur möglich wenn die "Kunden" des Hubs alle offline sind.

Glücklicherweise ist Lightning nun so konstruiert, dass derjenige, der den anderen beim Betrügen erwischt, die Möglichkeit hat, den gesamten Channel zu seinen Gunsten aufzulösen. Sprich: Wer beim Cheaten ertappt wird, verliert alles.

Die Reaktion ist automatisch in allen Clients, und man muss nur den Client am laufen lassen, also nicht selber eingreifen.” Christian Decker meint, dass das Risiko eher gering ist: “Der Timer startet erst ab dem Zeitpunkt, an dem er den alten Zustand ins Netzwerk schickt, und wenn man vor dem Timeout wieder online ist, verliert der Angreifer sein gesamtes Guthaben im Channel.”

Das heißt wenn jemand soetwas versuchen würde, wäre das mit einem Großen Risiko verbunden eine Menge Geld zu verlieren.

[curiosity81]

Ich finde eure Diskussion interessant, aber so wie ich den letzten Artikel auf dem Bitcoinblog verstanden habe ist ein großer Exit-Scam nur möglich wenn die "Kunden" des Hubs alle offline sind.

Glücklicherweise ist Lightning nun so konstruiert, dass derjenige, der den anderen beim Betrügen erwischt, die Möglichkeit hat, den gesamten Channel zu seinen Gunsten aufzulösen. Sprich: Wer beim Cheaten ertappt wird, verliert alles.

Die Reaktion ist automatisch in allen Clients, und man muss nur den Client am laufen lassen, also nicht selber eingreifen.” Christian Decker meint, dass das Risiko eher gering ist: “Der Timer startet erst ab dem Zeitpunkt, an dem er den alten Zustand ins Netzwerk schickt, und wenn man vor dem Timeout wieder online ist, verliert der Angreifer sein gesamtes Guthaben im Channel.”

Das heißt wenn jemand soetwas versuchen würde, wäre das mit einem Großen Risiko verbunden eine Menge Geld zu verlieren.

Das stimmt, je mehr offene Channels man hat, desto schwieriger wird es ungestraft davon zu kommen. Und wollte man eine Angriff auf den Mempool fahren, dann gäbe es einfachere Methoden als einen LN-Hub aufzusetzen.

Trotzdem muss noch eine Methode her, dass man nicht ständig online sein muss. Wenn man die z.B. Wallet auf dem Smartphone hat und in Urlaub fährt und vergessen hat den Channel zu schliessen, wie verhindert man dann Schindluder?

Eine Idee wäre noch sowas wie ein Mempool für Channels, dafür müsste aber einsehbar sein, was für Transaktionen in einem Channel ablaufen. Sollte sich ein Knoten daneben benehmen so müsste das vom Netzwerk bestraft werden.

Die aktuelle Lösung finde ich unbefriedigend. Aber mal abwarten wie sich das entwickelt. Es gibt cleverere Leute als mich, die sich mit der Materie befassen.

[butch3r]

Ich sehe das ehrlich gesagt alles halb so wild.

Erstens weiß mein Gegenüber nicht ob ich gerade Online bin oder nicht. Das heißt derjenige müsste schon darauf spekulieren, dass ich gerade in einer Situation bin, in der ich z.B. 24 Stunden nicht online sein kann.
Solche Situationen werden aber in Zukunft immer weniger werden. Wir können mittlerweile kostenfrei in Europa roamen.
Wenn der Angreifer es trotzdem versucht, riskiert er allerdings Geld zu verlieren. Das wird sich auf dauer nicht lohnen.

Ich stelle mir das zum Beispiel so vor: Meine Handy Wallet schickt mir eine Push Nachricht, weil ich seit 18 Stunden nicht mehr online war. Dann habe ich noch 6 Stunden Zeit mir irgendwo ein Cafe/Hotel/Restaurant zu suchen um kurz online zu gehen. Falls ich regelmäßig in der Wüste oder im Urwald bin, sollte der Zeitraum natürlich entsprechend länger gewählt werden oder man schließt seine Channels vor jeder Reise.

Zusätzlich wäre es natürlich möglich online Services anzubieten, die die Channels überwachen. Aber ich glaube ich, würde bei einem Zeitraum von drei Tagen immer zurecht kommen. Ich kann mich nicht erinnern wann ich in den letzen Jahren mal länger als drei Tage offline war.