Besser kann man es nicht sagen. Dasselbe gilt auch für alle die sich über die Gebühren beschweren, aber noch immer nicht auf SegWit Adressen umgestiegen sind. Momentan gibt es ja auch viele wie den User Anti-Cen in den Unterforen Development & Technical Discussion, die dauernd nur davon reden wie zentralisiert das Lightning Network sei und dass die Hubs bloß neue Banken seien, hier nirgends das versprochene Mama und Papa banking wäre usw. Dabei sieht es aber so aus, dass man bei einem Blick auf die momentane Vernetzung auf
https://lnmainnet.gaben.win/ ,bis auf SLEEPYARK unten, ein sehr gut vernetztes System sieht, in dem grob mit dem Auge geschätzt 250+ Nodes mehr als 2+ Channels haben und nicht dieses propagierte Bankensystem, bei dem 1 Hub 100 Channels hat und verhältnismäßig 90 Nutzer zu diesem einen Hub einen Channel haben und zu sonst keinem. Außerdem gilt wie du sagst, wer ein Problem damit hat muss sich ja nur selber beteiligen und selber Alternativen bieten (mehrere Channels öffnen). Die äußersten Nodes in der Grafik sind wahrscheinlich auch meistens neue User und ist verständlich, dass die äußerste Schicht nicht mit 3 Channels anfängt, bei einem unfertigen System und eventuell Geld weghauen. Also ich bin momentan sehr zufrieden mit dem Verlauf den das Lightning Network nimmt. Muss sagen, dass ich auch nichts gegen einzelne zentrale Megahubs habe, warum sollte es nicht riesige Hubs geben, schließlich würde man ja theoretisch auch bei einer großen Firma nicht drum herumkommen, wenn sie ihre Mitarbeiter in BTC bezahlt, dass sie mehrere 1000 Channels hat.
Was mich mehr interessiert, ist schon bekannt wie das "Rebalancing" funktionieren soll? Habe nur diesen Namen dazu einmal gehört. Falls jemandem nicht klar ist was ich meine. Angenommen es gäbe 2 Channels, die so aussehen:
A (1BTC) ==== (1BTC) B (1BTC) ===== (1BTC) C
A legt 1 BTC in einen Channel zu B, B legt 2 BTC in die Channels, 1 pro Channel und C legt 1 BTC in den Channel zu B
Wenn jetzt C an A 1 BTC über B überweisen will, dann läuft es meines Verständnisses nach so, dass da ja HTL Contracts zwischen A/B und B/C abgeschlossen werden. Wenn A der Empfänger ist entwickelt er das Paar zu dem HTL Contract H (Output) & R (Input) und gibt jedem auf dem Weg H weiter, also an B & C. Jetzt sagt C an B, du kriegst 1 BTC, wenn du mir den Input bzw. die Lösung zu H in 10 Tagen geben kannst und B zu A, du kriegst 1 BTC, wenn du mir den Input zu H in 9 Tagen sagen kannst. A gibt R an B und kriegt 1 BTC und B hat dann mindestens X s/min/h/d länger Zeit um sich seinen Bitcoin zu holen.
Was mich jetzt interessieren würde, der aktuelle Status der Channels wäre ja der, dass nun B keine BTC mehr an A schicken kann, weil ihr Channel so aussieht A (2BTC) ==== (0BTC) B . Aber B selber hat ja nun noch keine "eigene" Zahlung an A getätigt. Es ist jetzt nicht so, dass B um Geld betrogen werden würde, aber es dennoch etwas umständlich wäre jetzt die Channel zu A & C zu broadcasten und neu zu öffnen und die 2 BTC die man zu C hatte auf beide Channel wieder aufzusplitten. Das soll angeblich durchs rebalancing gelöst werden, wenn man einer der Mittelmänner auf dem Weg der Transaktion war.