Topic: Lightning Network und andere "2nd Layer": Lösung für Problem der vollen Blöcke? - page 4. (Read 8887 times)

Danke für die Einschätzung. Ja, das habe ich so schon mehr oder weniger gewusst, bis auf das:


Aber nur vom Ausgangs-Client aus, oder? Das heißt, mein Client eröffnet für mich einen Channel, wenn ich selber etwas zahlen will, aber nicht, wenn ich eine Zwischenstation bin? Zweiteres würde ich nämlich strikt ablehnen ...

.

Diese Zweifel teile ich, zumal die Clients der Zwischenstationen ja dauerhaft online sein müssen. Es kann natürlich sein, dass LN davon profitiert, dass eh die meisten Blockchain.info oder ähnliche Web-Anbieter nutzen, die ja tatsächlich dauerhaft online sind.

Was passiert eigentlich, wenn ein Pfad gefunden wird, eine Zwischenstation jedoch während der Ausführung des LN-Transfers plötzlich offline geht?


Das glaube ich wiederum nicht ... dafür kann man ja dann eine Funktion im Client einbauen, der es untersagt, bestimmte BTC in Channels zu stecken.

Ohne Channel können über LN definitiv keine Zahlung erfolgen. Es ist auch zwingend erforderlich, dass zumindest die zahlende Partei im Channel ausreichend BTC reserviert/gelockt hat. Anders geht es auf keinen Fall!

Ich werde auch nicht 100% schlau aus der Aussage, aber ich denke Gmaxwell will darauf hinaus, dass das LN-Netzwerk nicht zwingend eine Hub-Topologie/Struktur benötigt. LN ermöglicht Zahlungen über mehrere Zwischenstationen (Hops), auch ohne, dass sich alle Hops auf dem Weg kennen müssen. Es sind daher beliebige Netzwerkstruren, insbesondere auch gleichmäßig vermaschte Netze ohne zentrale Knoten denkbar. LN sieht vor, im Moment der Zahlung, über Routingverfahren einen Pfad durch das LN-Netzwerk zum Zahlungsempfänger zu finden und die Zahlung darüber abzuwickeln. Der Pfad kann auch vorher unbekannte Zwischenstationen beinhalten. Zahlungen würden dann ggf. jedes mal einen anderen Weg gehen, je nachdem wo Kapazitäten verfügbar sind. Falls kein Pfad verfügbar ist, könnte ad hoc ein neuer Channel eröffnet werden (der dann später ggf. auch für andere Zahlungen zur Verfügung steht).

Idealerweise würde man LN so implementieren, dass der Nutzer davon überhaupt nichts mitbekommt. Also, dass der Client eigenständig Channels zu irgendwelchen anderen Nutzern aufbaut, nach Möglichkeit nutzt, neue Pfade findet und Channel auch wieder abbaut. Der Nutzer sollte sich darum nicht kümmern müssen.

Es wäre spannend zu sehen, ob ein LN-Netzwerk ganz ohne zentrale Hubs in der Realität funktionieren würde. Ich habe da gewisse Zweifel... Fraglich auch, ob die Nutzer es überhaupt akzeptieren würden, dass ihr Bitcoin-Client ihre Bitcoin eigenmächtig in irgendwelche Channels steckt und (auch) für die Abwicklung fremder Transaktionen benutzt. Cold Storage oder Paper Wallet wären dann jedenfalls nicht mehr möglich.

An die Lightning-Experten: Was meint Gmaxwell hiermit:


Heißt das, LN kann (zum Zahlen oder Weiterleiten von BTC) genutzt werden, ohne einen Channel aufzumachen (also ohne BTC in einer Transaktion zu "reservieren")? Das verstehe ich (auf Basis des Designs, das ich am Anfang gepostet habe) überhaupt nicht. Gibt es da ein völlig neues Design?

Oder geht es hier nur um die Nutzung von LN als Zahlungsempfänger, den wir vorher diskutiert haben, bei dem tatsächlich kein Locking notwendig ist, man aber das Geld erstmal nicht für Zahlungen verwenden kann (bis man tatsächlich einen Channel aufmacht)?

Stammt übrigens aus einer Diskussion über diesen Artikel.

Deshalb würde ich dezentrale Hubs bevorzugen, auch wenn dies nicht realistisch ist, da die WhatsApp Generation - wie jeder weiss - mit massiver Gewalt zur Nutzung der zentralen Services gezwungen wird.  

Jammern muss aber keiner. Eigenes Geld - eigene Verantwortung. Anders ausgedrückt: Jeder ist in diesem Fall seines eigenen Unglückes Schmied!

Bei der On-Chain-Nutzung hat man aber als Normalsterblicher zumindest die Chance, selbst ein halbwegs sicheres System aufzusetzen - man braucht also nicht zwangsläufig auf Blockchain.info und Co. zurückzugreifen. Große Geldmengen in Paperwallets, eine eigene Partition mit einer Wallet für kleine Zahlungen - und es bleibt alles dezentral, selbst wenn man keinen Full Node betreiben möchte sondern z.B. Electrum nutzt, hat man kaum Abhängigkeiten von einem zentralen Provider (da der Blockchain-Server ja dir allerhöchstens fehlerhafte Daten liefern kann aber nie Zugriff auf dein Geld hat).

Bei einem LN nach dem "Hub and Spoke"-Modell entstehen dagegen neue Abhängigkeiten, und die will ich nur für kleine Beträge dulden, wenn ich schon ein dezentrales System wie Bitcoin nutze.

Es ist genauso zentralisiert wie die heutigen Full-Nodes bei denen ebenfalls komplexe Abläufe automatisiert durchgeführt werden.

Im Prinzip ist das ganze, wie überall, ein soziales Problem. Nur hinsitzen, sich über Zentralisierung beklagen und dann den grossen zentralisierten Anbieter nutzen, weil man ja sonst seinen Arsch um den Bruchteil eines
Millimeters bewegen müsste, wird mit absoluter Sicherheit kein Problem lösen.

Man kann es nicht oft genug Schreiben: Eigenes Geld - eigene Verantwortung!

Beides würde meines Erachtens dann doch auf das eher zentralisierte Hub-Modell herauslaufen, nicht auf das dezentrale "Six degrees of separation" - Modell. Jeder Hub müsste sozusagen "hauptberuflich" oder zumindest "professionell" arbeiten, da er die Strafmechanismen automatisch durchführen müsste und damit ein extrem sicheres System bräuchte.

Wie gesagt, das wäre für mich für Micropayments kein Drama, aber doch, wenn es die Haupt-Transaktionsmethode bei Bitcoin werden soll.

Da eine Transaktion üblicherweise in Sekunden über die gesammte Kette geht und der Hub-Betreiber garantiert nicht in dieser Sekunde in den Urlaub geht, sehe ich dabei kein grosses Problem. Daneben habe ich die Protokolle so verstanden, dass die Strafmechanismen automatisch ablaufen müssen, da diese der ökonomischen Absicherung dienen. Es wäre wenig sinnvoll, wenn man darauf verzichten würde.

Sicherlich wird man aber bei keinem neuen System mit grossen Geldbeträge starten. Neben möglichen Lücken im Protokoll muss man auch mit Implementierungsfehlern rechnen. Es wäre dämlich einem komplett neuen System sofort sein Vermögen anzuvertrauen (OK, für die Altcoiner nicht - die machen sowas regelmässig. Hat jemand DAO gesagt?). Micropayments sind daher logischerweise die erste Wahl für ein solches System.

Beim LN würde sich das Problem etwa so darstellen:

Es gibt ja die Möglichkeit, wenn zwei Parteien einen Payment-Channel offen haben, dass einer von beiden versucht, den Channel auf einen alten "Status" zurückzusetzen und dadurch einen Vorteil zu erlangen. Beispiel: Kunde hat dem Händler fünfmal etwas für je 1 BTC gekauft und versucht jetzt den Channel ganz zurückzusetzen - er hätte dann 5 BTC gespart und trotzdem die Leistungen erhalten.

Um das zu verhindern, muss die Gegenpartei (also hier: der Händler) in einer bestimmten Zeit (die nicht allzu lange ist, z.B. 72 Stunden) den in das System eingebauten "Straf-Mechanismus" nutzen: er kann im Fall eines Zurücksetzens der BTC durch die Gegenpartei alle BTC aus dem Channel für sich selbst reklamieren.

Was ist aber jetzt, wenn der Händler z.B. im Urlaub ist und den Payment-Channel vergisst? Klar, man kann eine Art Alarmsystem einrichten, aber trotzdem ist es für den Händler mühsamer, dieses tatsächlich ständig im Blick zu behalten (schließlich hat er im Normalfall ja eine Vielzahl offener Channels). Theoretisch kann die Wallet selbstständig den "Strafmechanismus" auslösen, aber das wäre wieder sicherheitstechnisch riskanter.

Das nur mal als Beispiel in die Runde geworfen, was die Nachteile gegenüber On-Chain-Transaktionen sind und weshalb ich persönlich LN nur für kleinere Micropayments benutzen würde - egal ob als "Händler" oder als "Kunde". Man muss also noch mehr als bei On-Chain-Transaktionen ständig wachsam sein und sein System unbedingt virenfrei halten.

zumindest braucht jeder Fahrzeugführer eine Fahrerlaubnis, ...

+ Elektrotechnik + Informatik + Physik + ... 

Sehr kompliziert so ein aktuelles KFZ.

No shit, aber wie d5000 schon schrieb das gilt schon Bitcoin selbst. Niemand muss wissen wie Bitcoin im Detail funktioniert um es zu nutzen. Gilt auch für Autos, scheinen trotzdem irgendwie benutzt zu werden, obwohl viele schon mit Reifenwechseln überfordert sind.

---

Kommt wohl auf deine Definition von "normal" an.


Ja.


Venus, manchmal Mars, je nach Wetterlage auch mal Erde.


DAS ist mal ne Referenz, das muss man sich mal auf der Zunge zergehen lassen: 'Ich bin kriminell, ich hab Ahnung'


Du kannst also z.B. CoinJoin und die unterschiede die in DASH daran vorgenommen erklären? Wieso verstehst du dann LN nicht?


Wer soll bloß diese 'Automobile' fahren wenn man dafür ein Maschinenbaustudium absolvieren muss?


Aah, natürlich. "Die anderen sind alle böse, nur bei uns gibts Sonnenschein".

Da muss ich commander11 recht geben, das muss "idiotensicher" sein, sonst bleibts Spielzeug für Nerds. Was interessiert es mich, was z.B. meine Bank bei einer Überweisung alles anstellt?

Naja, wenn jeder Neuling wissen müsste, was ein "Script" und ein "Output" ist, um eine Überweisung zu tätigen, hätten wir auch bei Bitcoin höchstens 0,1 % der aktuellen Nutzer.

Auch bei LN werden die Details natürlich vor dem User versteckt werden. Wobei du in einem recht hast: Bei LN müssen die Nutzer - soweit ich es bisher verstanden habe - schon einiges wissen, wenn sie das Risiko auf sich nehmen wollen, LN auch für große Zahlungen zu nutzen. Daher bleibe ich dabei: Das ganze ist als Alternative zur Prepaid/Giftcard interessant und wird da auch wohl seine Nische finden, aber nicht für die wichtigen Dinge wie Gehalt oder größere Einkäufe.

So nach 10 Minuten lesen merkt ihr hier was


Nichtmal Die BTC Experten die Jahrelange in der Materie sind  CHECKEN wie dieses LN Dingsbums Funktionieren soll ?`


was schreibt Ihr hier für Abhandlungen ?


Für Normale user ist Normal BTC Zahlung schon viel zu viel ??


Meint ihr Ehrlich Ein normaler Mensch macht was Ihr hier diskutiert ??


Iwelche Channel Ersteller und iwas beachten das die nicht geblockt und geclost usw werden


Auf Welchen Planeten Lebt Hier


Das ist ist die Reinste Verarsche was die Blockstream Core Devs euch hier Als Massen Scaling verkaufen sollen und ihr

Wasted Eure Zeit mit so einen Schwachsinn ^^


Keiner wird sowas nutzen.

Wenn nichtmal ein Sebastiuon mit 1600 Posting das Checkt wer soll sowas  Nutzen ??


Da nutzt selbst ich lieber dann eine Vcc oder Paypal oder eher Dash etc



zeigt mal eure Diskussion hier eine " normale " Person !


Wer Soll sowas dann nutzen erstmal CryptoCurrency Fach studieren muss  ?


Blocksteam und Core Devs sind gefunded von Axa Ventures deren Ceo bei BIlderberger rumläuft haben die leute hier das immernoch nicht begriffen .

Das sind genau die gleichen leute die Merkel und Co befehlen Europa zu zerstören und USA Chaos mit den aufgebauten Trump schauspieler zu machen.  


Die Lösung ist BU oder Bitcoin ist bald Nr 2.

@shorena, danke für die Klarstellung. Es wäre natürlich zu prüfen ob dieser DOS-Angriff überhaupt eine reale Gefahr darstellt, da der Angreifer ja keinen direkten monetären Vorteil draus ziehen kann, ich könnte mir es aber schon vorstellen - z.B. um bestimmten Hubs oder Bitcoin allgemein zu schaden.

@Danton, danke, das deckt sich mit meinen Einschätzungen. Das Problem des mangelnden Anreizes einen Hub zu betreiben, wenn man kein "Profi" mit entsprechenden Ressourcen ist, sehe ich auch. Deshalb denke ich, dass eine relativ starke Zentralisierung leider wahrscheinlich ist.

Für echte Micropayments (alles unter 10-20 USD) wäre das für mich aber trotzdem eine akzeptable Lösung - eine Art Paypal, bei dem der Hub nicht betrügen kann. Ich denke weiterhin, man sollte nicht alles auf eine Karte setzen, sondern mehrere Lösungen nebeneinander für das Skalierungsproblem anbieten. Insgesamt bin ich optimistisch.

Klingt erstmal gut, wird in der Praxis aber kaum so kommen!

Für jeden eröffneten Channel müssen eine bestimmte Menge Bitcoins geblockt werden. Die Anzahl an Coins bestimmt die maximale Kapazität des Channels. Für den einfachen Endnutzer wäre es also am Besten genau einen Channel zu einem gut-vernetzten Hub zu haben. Weitere Channels bringen keine Vorteile, blockieren aber zusätzliche Bitcoins.

Gleichzeitig besteht für Normalnutzer wenig Anreiz einen Hub zu eröffnen. Für einen funktionierenden Hub muss man noch deutlich mehr Bitcoins blocken, als für einen Channel. Und das Betreiben eines Hubs ist gefährlich, man muss z.B. die Schlüssel 'online' vorhalten um Transaktionen automatisch signieren zu können. Das Lightning-Paper enthält eine lange Liste von Möglichkeiten, wie man die Coins in einem Channel verlieren kann. Und als Hub mach man sich direkt zur Zielscheibe. Das Betreiben eines Hubs wäre was für Profis, die ihre Systeme entsprechend absichern können.

Im Endeffekt dürfte es auf eine Struktur hinauslaufen, die unserem jetzigen Bankensystem nicht unähnlich ist: Wenige sehr große, untereinander vernetzte, Hubs und sehr viele einfache User mit oft nur einem Channel!

Ne, das kann so nicht funktionieren! Die echten BTC sind fix für einen Channel reserviert und können demnach nicht gleichzeitig auch noch zur Deckung eines anderen Channels verwendet werden. Sowas geht nur beim Fractional-Reserve-Banking 

Wenn man die Bitcoins aus einem Channel über einen anderen Channel weiterleiten will muss man das über die Blockchain machen. Also Channel schließen und neuen Channel aufmachen.

Relevant ist einzig und allein die Gesamtmenge der für den Channel reservierten Bitcoins. Wer diese Bitcoins einbringt ist erstmal egal. Einen Anreiz zu betrügen gibt es in keinem Fall, da im Betrugsfall alle Bitcoins im Channel an die andere Partei ausgezahlt werden (egal wer ursprünglich mal wieviel eingezahlt hat).

Wer nichts einzahlt, kann erstmal nur empfangen und selbst keine Zahlungen senden. Damit ein Channel in beide Richtungen funktioniert müssen also beide Parteien etwas eingezahlt haben. Netto(!) kann man in einem Channel maximal soviel versenden, wie man ursprünglich mal eingezahlt hat. Wer über den Channel regelmäßig Zahlungen erhält kann immer wieder Etwas versenden. Wenn die Zahlungen aber immer nur in eine Richtung laufen, wird der Channel irgendwann "leerlaufen", weil alle Coins (gedanklich) auf der anderen Seite sind. Dann sind keine weiteren Zahlungen möglich.

Franky ist - vermute ich - nicht unbedingt gegen SegWit (+LN) sondern gegen die Art und Weise wie es umgesetzt wird.

Zum Angriff. Die höheren Gebühren fall nur beim öffnen eines Channels an, micro payments sind davon also nur indirekt betroffen. Es erzeugt aber einen (weiteren) Anreiz einen Channel möglichst lange offen zu halten. Ob das überhaupt eine brauchbare Lösung ist scheint weiterhin noch gar nicht klar zu sein.[1] Die Verteilung der Extra-Fee Bedarf zusätzlicher Informationen die wohl so erstmal gar nicht anfallen würden.

[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-November/000650.html