Lightning Network und andere "2nd Layer": Lösung für Problem der vollen Blöcke?

[d5000]

Kann man beim Lightning Network auch einen Zahlungskanal (in der Regel zu einem Hub) aufmachen, bei dem man selbst als Endnutzer gar keine Bitcoins "reserviert"? Das wäre ja für den Fall interessant, dass man auch sein Gehalt über LN erhält (oder eben BTC über eine Börse kauft, die auch per LN auszahlt).

Klar, das ist der einfache Fall. Man kann dann (erst mal) keine Zahlung senden, aber das war ja auch nicht gefragt. Für den Sender gibt es auch kein zusätzliches Risiko, da er das Geld sowieso verschickt hätte. Für den Sender ist es egal, ob er Dir erst mal eine Unterschriebene Transaktion (Off-Chain) schickt oder ob er diese Transaktion gleich ins Netz stellt. Du kannst ihn auch nicht betrügen, denn mehr als die einzelnen Zahlungen wird er sinnvollerweise niemals signieren.

Das er Off-Chain-BTC über diesen Weg "empfangen" kann, ist erstmal klar.

Aber kann der Empfänger diese "Off-Chain-BTC" dann auch weiterleiten, ohne echte BTC zu reservieren? Ich denke eher nicht, oder? Sonst könnte man ja selbst als Hub fungieren, ohne einen einzigen echten BTC zu riskieren.

(Ich glaube, ich muss mir das Prinzip noch mal genau anschauen, habe irgendwie einen Knoten im Kopf )

[1715557922]

1715557922

[1715557922]

1715557922

[1715557922]

1715557922

[1715557922]

1715557922

[1715557922]

1715557922

[mezzomix]

Aber kann der Empfänger diese "Off-Chain-BTC" dann auch weiterleiten, ohne echte BTC zu reservieren? Ich denke eher nicht, oder? Sonst könnte man ja selbst als Hub fungieren, ohne einen einzigen echten BTC zu riskieren.

Da der Empfänger mit der Signatur des Senders unwiderruflich die Zahlung erhalten hat, könnte das schon funktionieren. Ich müsste aber auch erst mal nachschauen, ob das Script das tatsächlich hergibt.

[d5000]

Danke für die Einschätzung.

Einen ähnlichen Effekt (also dass man keine BTC "kaltzustellen" und damit zu riskieren braucht, um einen Kanal aufzumachen - z.B. wenn man einen Crash fürchtet) kann man aber wohl so erzielen:

- Kanal zu Hub aufmachen und eine Anzahl "X" Bitcoins dafür reservieren
- Alle "X" BTC sofort auf einer Börse verkaufen, die Lightning als Zahlung akzeptiert

Dann könnte man Zahlungen (z.B. Gehalt) per Lightning erhalten und jeweils die Menge "X" weiterleiten, um z.B. Dinge dafür einzukaufen.  Mit dieser Möglichkeit könnten auch ängstlichere Bitcoinuser Lightning nutzen. (Habe ich hoffentlich richtig verstanden.)

[SebastianJu]

Genau das ist die Weiterentwicklung von den gerade entwickelten Off-Chain Verfahren (LN ist nur eins von mehreren). Bisher sind sichere Verbindungen über mehrer Punkte relativ schwierig zu realisieren. Ohne das Transaction Melleability Problem geht es deutlich einfacher. Solange es sich bei den Off-Chain Transaktionen nur um eine Applikation im Bitcoin System handelt, kann die Nutzung langsam wachsen.

Bei der Nutzung von Zwischenstationen (Hubs) sind die Limits dieser Hubs mit den Geschäftspartnern ausschlaggebend. Im Rahmen der Limits der Gesammtstrecke kann sich die Transaktion dann bewegen. Auf den ersten Blick besitzt so ein Hub Ähnlichkeit mit einer Bank. Tatsächlich muss der Hub-betreiber das Geld allerdings tatsächlich haben und kann nicht einfach Geldschöpfung betreiben. Für die Abwicklung der Transaktionen nutzt man also (im Idealfall nur für einen Sekundenbruchteil) die Bonität der beteiligten Hubs.

Kannst du genauer sein wie das funktioniert? Hat man dann nicht direkte Zahlungskanäle sondern jeweils Zahlungskanäle zum Hub und die rechnen dann, ähnlich wie bei ripple, die Schulden verschiedener User gegen?

Mal angenommen, jemand bekommt einen Bitcoin für eine Signaturkampagne. Den will er jetzt auf einem Exchange verkaufen. Kann LN da eine Rolle spielen?

Bezüglich Hub, klingt nach Zentralisation da je größer der Hub desto effektiver? Oder teilen die sich irgendwie die Verknüpfungen mit allen andereren Hubs? (Ich stell lieber dumme Fragen anstatt es aus falschem Stolz zu unterlassen. )

[mezzomix]

Ich würde sagen, das System wird erst mit möglichst vielen Vernetzten Hubs richtig wertvoll. Mit einem einzigen grossen Hub ist der Nutzwert begrenzt, da nicht jeder mit diesem einen Anbieter zu dessen Konditionen arbeiten möchte. Ich würde es daher bevorzugen, wenn möglichst viele Nutzer Hubs anbieten und sich mit anderen Nutzern bzw. deren Hubs vernetzen. Wie auch bei Bitcoin selbst, steigt der Wert des Systems mit der Nutzung. Nebenbei kann so eine hohe Transaktionslast, verteilt auf viele Schultern, abgedeckt werden. Ausserdem vermeidet man damit einen Single-Point of Failure. Als Nebeneffekt werden die einzelnen Zahlungen einer zentralen Überwachung entzogen und Zensuransätze werden praktisch unmöglich gemacht.

[d5000]

Ich habe gerade folgendes aus dem englischen Forum gefischt:

https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-November/000648.html

Es geht um Angriffs-Szenarien, in denen der Angreifer mit Transaktionen über viele Nodes hinweg einen DOS auf das Netzwerk auslösen kann. Als Lösung wird die Zahlung einer recht hohen Gebühr durch den Sender einer Lightning-Transaktion vorgeschlagen. Das wäre natürlich wieder ein Nachteil bei Micropayments.

Den Link habe ich allerdings von einem bekannten Gegner von Segwit/Lightning, und hundertprozentig verstehe ich das technische Prinzip dahinter nicht. Wenn jemand sich auskennt: Ist das nur Propaganda bzw. das Problem schon gelöst oder tatsächlich ein möglicher Nachteil?

[shorena]

Ich habe gerade folgendes aus dem englischen Forum gefischt:

https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-November/000648.html

Es geht um Angriffs-Szenarien, in denen der Angreifer mit Transaktionen über viele Nodes hinweg einen DOS auf das Netzwerk auslösen kann. Als Lösung wird die Zahlung einer recht hohen Gebühr durch den Sender einer Lightning-Transaktion vorgeschlagen. Das wäre natürlich wieder ein Nachteil bei Micropayments.

Den Link habe ich allerdings von einem bekannten Gegner von Segwit/Lightning, und hundertprozentig verstehe ich das technische Prinzip dahinter nicht. Wenn jemand sich auskennt: Ist das nur Propaganda bzw. das Problem schon gelöst oder tatsächlich ein möglicher Nachteil?

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

[Danton]

PS: Ich habe noch mal drüber nachgedacht und glaube inzwischen, dass dieses Szenario tatsächlich Bullshit ist und dass die Menge an BTC, die man für einen Kanal reserviert, die Maximalmenge ist, die man für eine Zahlung (bzw. einen Geldempfang) verwenden kann. Wäre schön wenn mir das jemand bestätigt.

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.

[Danton]

Aber kann der Empfänger diese "Off-Chain-BTC" dann auch weiterleiten, ohne echte BTC zu reservieren? Ich denke eher nicht, oder?

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.

[Danton]

Ich würde sagen, das System wird erst mit möglichst vielen Vernetzten Hubs richtig wertvoll. Mit einem einzigen grossen Hub ist der Nutzwert begrenzt, da nicht jeder mit diesem einen Anbieter zu dessen Konditionen arbeiten möchte. Ich würde es daher bevorzugen, wenn möglichst viele Nutzer Hubs anbieten und sich mit anderen Nutzern bzw. deren Hubs vernetzen. Wie auch bei Bitcoin selbst, steigt der Wert des Systems mit der Nutzung. Nebenbei kann so eine hohe Transaktionslast, verteilt auf viele Schultern, abgedeckt werden. Ausserdem vermeidet man damit einen Single-Point of Failure. Als Nebeneffekt werden die einzelnen Zahlungen einer zentralen Überwachung entzogen und Zensuransätze werden praktisch unmöglich gemacht.

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!

[d5000]

@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.

[commander11]

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.

[d5000]

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.

[blizzen1]

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?

[shorena]

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?

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.

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

Kommt wohl auf deine Definition von "normal" an.

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

Ja.

Auf Welchen Planeten Lebt Hier

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

Keiner wird sowas nutzen. UNd ich bin der cybercrime Scene wo Technische überdurchschnittliche Leute unterwegs sind.

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

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

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

Wer Soll sowas dann nutzen erstmal CryptoCurrency Fach studieren muss  ?

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

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

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

[mezzomix]

Wer Soll sowas dann nutzen erstmal CryptoCurrency Fach studieren muss  ?

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

+ Elektrotechnik + Informatik + Physik + ... 

Sehr kompliziert so ein aktuelles KFZ.

[blizzen1]

Wer Soll sowas dann nutzen erstmal CryptoCurrency Fach studieren muss  ?

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

+ Elektrotechnik + Informatik + Physik + ... 

Sehr kompliziert so ein aktuelles KFZ.

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

[d5000]

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.

[mezzomix]

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.

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.

[d5000]

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.

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.