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

[mezzomix]

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!

[d5000]

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.

[mezzomix]

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!

[d5000]

An die Lightning-Experten: Was meint Gmaxwell hiermit:

The funds in channels are required based on the number of channels.  Lightning designs today are setup to only build channels as a product of payments you're already making. Using lightning in a "hub like" way requires extra transactions that you never would have made normally.   The big advance of lightning over the prior payment channels proposals is specifically that it doesn't need hubs.

Recently BU's "chief scientist" was making exactly the opposite argument based on the same facts: He argued that lightning did not improve scalablity because there would need to be as many channels as users and so when users went up the channel count would go up.

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.

[Danton]

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)?

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.

[d5000]

LN ermöglicht Zahlungen über mehrere Zwischenstationen (Hops), auch ohne, dass sich alle Hops auf dem Weg kennen müssen [...] 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.

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

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

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

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

.

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?

Cold Storage oder Paper Wallet wären dann jedenfalls nicht mehr möglich.

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.

[mezzomix]

Cold Storage oder Paper Wallet wären dann jedenfalls nicht mehr möglich.

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.

Das ist nicht notwendig. Ich denke nicht, dass es aktzeptabel oder wünschenswert ist, dass ein LN Knoten das komplette Vermögen kontrolliert. Ich gehe davon aus, dass man bei allen Second-Layer Lösungen die dafür genutzte Summe explizit zur Verfügung stellen muss.

[Danton]

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

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.

Alles Mögliche ist denkbar... Wie es genau sein wird hängt von der Umsetzung des Protokolls in Anwendersoftware ab!

Es könnte eine separate LN-Wallet-Software geben, die man explizit herunterladen muss, explizit Bitcoins in LN-Netzwerk verschieben muss und bei jeder Transaktion explizit entscheidet, ob sie über LN laufen soll. LN könnte als anderer Extremfall aber auch nahtlos/unsichtbar in Bitcoin Core integriert werden. So das es für den Nutzer keinen sichtbaren Unterschied zwischen "normalen BTC" und "LN-BTC" gibt. Er hat dann natürlich auch keinen Einfluss darauf, was im Hintergrund passiert.

So absurd ist letztere Variante auch nicht: Eine Bitcoin-Wallet ist auch jetzt schon eine ziemlich starke Abstraktion, die die ganzen technischen Details vom Nutzer verbirgt und sich "eigenmächtig" um Inputs, Outputs,  Change-Adressen, u.s.w. kümmert. Mit LN würde sich die Wallet dann halt zusätzlich auch noch darum kümmern über welches Protokoll die Transaktionen abgewickelt werden. Ebenfalls ein technisches Detail, was man von den Nutzern verstecken könnte (sollte?).

Wenn LN als Lösung des Scalability-Problems von Bitcoin gedacht ist, läuft das tendentiell eher auf letztere Variante hinaus. Andernfall wäre es mehr eine zusäzliche Anwendung. Aufgrund der höheren Anforderungen an einen LN-Client (24/7 online) und der höheren Risiken erwarte ich aber auch, dass die Nutzung von LN zumindest einmalig eine bewusste Entscheidung des Nutzer voraussetzten wird.

[SebastianJu]

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

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.

Alles Mögliche ist denkbar... Wie es genau sein wird hängt von der Umsetzung des Protokolls in Anwendersoftware ab!

Es könnte eine separate LN-Wallet-Software geben, die man explizit herunterladen muss, explizit Bitcoins in LN-Netzwerk verschieben muss und bei jeder Transaktion explizit entscheidet, ob sie über LN laufen soll. LN könnte als anderer Extremfall aber auch nahtlos/unsichtbar in Bitcoin Core integriert werden. So das es für den Nutzer keinen sichtbaren Unterschied zwischen "normalen BTC" und "LN-BTC" gibt. Er hat dann natürlich auch keinen Einfluss darauf, was im Hintergrund passiert.

So absurd ist letztere Variante auch nicht: Eine Bitcoin-Wallet ist auch jetzt schon eine ziemlich starke Abstraktion, die die ganzen technischen Details vom Nutzer verbirgt und sich "eigenmächtig" um Inputs, Outputs,  Change-Adressen, u.s.w. kümmert. Mit LN würde sich die Wallet dann halt zusätzlich auch noch darum kümmern über welches Protokoll die Transaktionen abgewickelt werden. Ebenfalls ein technisches Detail, was man von den Nutzern verstecken könnte (sollte?).

Wenn LN als Lösung des Scalability-Problems von Bitcoin gedacht ist, läuft das tendentiell eher auf letztere Variante hinaus. Andernfall wäre es mehr eine zusäzliche Anwendung. Aufgrund der höheren Anforderungen an einen LN-Client (24/7 online) und der höheren Risiken erwarte ich aber auch, dass die Nutzung von LN zumindest einmalig eine bewusste Entscheidung des Nutzer voraussetzten wird.

Ich glaube auch dass es vollkommen inakzeptiert sein wird wenn es eine extra Wallet gibt. Die Verbreitung wird vernachlässigbar sein.

Integriert in bitcoin core wird vermutlich die Lösung werden, natürlich gegen den Widerstand der halben Bitcoincommunity. Das Thema hat sicher nicht an Kontroversität verloren.

Was ich aber nicht sehe ist wie das Wallet selbst entscheiden soll welche Transaktionen über LN laufen sollen. Es müsste Bitcoins in Kanälen sperren und das würde besonders bei Usern die nicht ständig über ein Vermögen verfügen sicher ziemlich schlecht ankommen.

Ziemlich unangenehm das ganze Thema, besonders die permanent steigenden Gebühren.

[MoinCoin]

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

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.

Alles Mögliche ist denkbar... Wie es genau sein wird hängt von der Umsetzung des Protokolls in Anwendersoftware ab!

Es könnte eine separate LN-Wallet-Software geben, die man explizit herunterladen muss, explizit Bitcoins in LN-Netzwerk verschieben muss und bei jeder Transaktion explizit entscheidet, ob sie über LN laufen soll. LN könnte als anderer Extremfall aber auch nahtlos/unsichtbar in Bitcoin Core integriert werden. So das es für den Nutzer keinen sichtbaren Unterschied zwischen "normalen BTC" und "LN-BTC" gibt. Er hat dann natürlich auch keinen Einfluss darauf, was im Hintergrund passiert.

So absurd ist letztere Variante auch nicht: Eine Bitcoin-Wallet ist auch jetzt schon eine ziemlich starke Abstraktion, die die ganzen technischen Details vom Nutzer verbirgt und sich "eigenmächtig" um Inputs, Outputs,  Change-Adressen, u.s.w. kümmert. Mit LN würde sich die Wallet dann halt zusätzlich auch noch darum kümmern über welches Protokoll die Transaktionen abgewickelt werden. Ebenfalls ein technisches Detail, was man von den Nutzern verstecken könnte (sollte?).

Wenn LN als Lösung des Scalability-Problems von Bitcoin gedacht ist, läuft das tendentiell eher auf letztere Variante hinaus. Andernfall wäre es mehr eine zusäzliche Anwendung. Aufgrund der höheren Anforderungen an einen LN-Client (24/7 online) und der höheren Risiken erwarte ich aber auch, dass die Nutzung von LN zumindest einmalig eine bewusste Entscheidung des Nutzer voraussetzten wird.

Ich glaube auch dass es vollkommen inakzeptiert sein wird wenn es eine extra Wallet gibt. Die Verbreitung wird vernachlässigbar sein.

Integriert in bitcoin core wird vermutlich die Lösung werden, natürlich gegen den Widerstand der halben Bitcoincommunity. Das Thema hat sicher nicht an Kontroversität verloren.

Was ich aber nicht sehe ist wie das Wallet selbst entscheiden soll welche Transaktionen über LN laufen sollen. Es müsste Bitcoins in Kanälen sperren und das würde besonders bei Usern die nicht ständig über ein Vermögen verfügen sicher ziemlich schlecht ankommen.

Ziemlich unangenehm das ganze Thema, besonders die permanent steigenden Gebühren.

Die Kanäle sind ja nur N/N (meist 2/2) Multisig Wallets.
Bitcoin-QT ist ja sowieso nicht gerade das meist genutzte Wallet, von daher wäre das wohl eher wichtig, wenn das zunächst mal direkt bei Coinbase, Kraken, Blockchain.info, Breadwallet & Co reinkommt.

Die Benutzererfahrung ist allerdings schon etwas seltsam, da man nie weiß, ob der andere gerade online ist oder nicht und man die BTC nutzen kann.
Wird etwas schwierig das einem Neuling zu erklären und den zu überzeugen einzusteigen.
Und wird sicher genauso schwer ein Wallet zu entwickeln, was das so abstrahiert, dass der Nutzer nicht zu viel einstellen muss, aber auch nicht enttäuscht/sauer ist, weil er nicht verstanden hat, was er da eingestellt hat oder das Wallet dem Nutzer die Entscheidung abgenommen hat und er dann 30 Tage oder mehr nicht an seine bitcoins rankommt.

Wenn man jetzt seine BTC in einem Kanal gebunden hat, über den man eine dritte Person leider nicht erreicht (z.B. weil irgendwo die Kanäle auf dem weg nicht genug freie Kapazität haben), könnte man natürlich einen weiteren Kanal aufmachen, aber nicht jeder hat so viel zusätzliche freie bitcoins/Geld, dass er einfach noch einen zusätzlichen Kanal aufmachen kann.
Was die Verfügbarkeit des Kanals angeht muss man "Vertrauen" in den Partner haben, was wohl auch nicht der Dezentralisierung hilft.

So einen Hub abzusichern ist sicher auch nicht ganz ohne, denn in der einfachen Ausprägung handelt es sich da ja um ein Hot-Wallet, was auf einem Online Gerät ist. Und selbst mit zusätzlichem Multisig kann man es leicht vermasseln, wie man bei Bitgo/Bitfinex gesehen hat.

Meine Meinung: Hilfe gegen volle Blöcke ja, aber es wird eine ganze Zeit dauern, bis das notwendige Software gereift ist. Und nutzbar wird das sicherlich nicht für alle Anwendungsfälle, Lösung also nein.

Hatte überlegt an Wallet Software bzw. Security Verbesserungen für Lightning mitzuentwickeln, aber bis die malleability gefixt wird durch segwit, oder was auch immer, wird wohl noch einige Zeit verstreichen und solange wird das sowieso nichts mit LN.
Extension Blocks wäre ja toll, aber die Antwort von Matt Corallo auf der Mailingliste ist nicht gerade ermutigend:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510.html

Und es gibt ja noch andere Entwicklungen. Werde mich selbst jetzt mal stärker mit Rootstock und Lumino befassen.
Das ist momentan mein Favorit zur Skalierung, auch wenn man sich mit der Federated Sidechain als Übergangslösung für den 2-way peg zwischen BTC und SBTC erstmal anfreunden muss.
Aber es hat den riesen Vorteil, dass es keine "Erlaubnis" / Konsens braucht um implementiert zu werden, woran segwit und BU momentan ja scheitern.
Immerhin sieht es so aus, als ob da schon viele dabei (und wohl auch mehr Miner, als bei segwit oder Unlimited) sind und man so der Federation "vertrauen" kann, weil die im eigenen Interesse handeln nicht zu schummeln.
Mal abwarten bis Ende Mai, bis das Live Netzwerk online seien soll.

Und es gefällt mir 1000 mal besser, als über Altcoins oder Coinbase-Style zentrale Datenbanken / SQL offchain zu skalieren, was momentan passiert.

[d5000]

@MoinCoin: Guter Post, stimme dem meisten zu (außer dem Teil, das ich Altcoins ebenfalls für eine valide Skaliermöglichkeit halte).

Rootstock hört sich als 2-way-pegged-Sidechain mit Merged Mining schon auf den ersten Blick sehr gut an. Werde mal weiter drüber nachforschen, insbesondere wie dezentral es ist.

[MoinCoin]

@MoinCoin: Guter Post, stimme dem meisten zu (außer dem Teil, das ich Altcoins ebenfalls für eine valide Skaliermöglichkeit halte).

Rootstock hört sich als 2-way-pegged-Sidechain mit Merged Mining schon auf den ersten Blick sehr gut an. Werde mal weiter drüber nachforschen, insbesondere wie dezentral es ist.

Danke für die Blumen.

Natürlich sind Altcoins auch eine valide Skalierungsmöglichkeit, aber die müssen dann eben ihren eigenen Netzwerk-Effekt aufbauen.
Mit vielen Altcoins kann man aktuell nicht besonders viel machen.
Mich persönlich macht das auch etwas unglücklich, weil das meiner Meinung nach den Netzwerk-Effekt von Bitcoin untergräbt.
Ein paar Altcoins hab ich mittlerweile auch wieder, da mir die Transaktionsgebühren bei bitcoin für kleinere Beträge zu hoch sind. Halte etwa 99% bitcoin und 1% Altcoins, somit bleibt mein persönliches Risiko durch Altcoins für mich überschaubar.
Ist schon traurig, so können die sich z.B. bei ETH und Dash schon ganz schön viel Mist erlauben und sind trotzdem aktuell wieder im Aufwind.


Und um den Bogen zurück zu schlagen, was hat das mit dem Lightning-Network zu tun?
Das schöne an einem Lightning-Network wäre ja, dass es auf dem Netzwerk-Effekt aufbauen könnte, den bitcoin als Währung schon hat.

[d5000]

Hier ein Post eines Lightning-Devs auf Medium, der ganz interessant ist, weil er zeigt, dass die Implementation tatsächlich (zumindest vorläufig) auf Micropayments beschränkt werden soll:

https://medium.com/@rusty_lightning/miners-and-bitcoin-lightning-a133cd550310#.kv57bat2n

Einige interessante Dinge:

- Lightning-Payments werden erstmal auf 0.042 BTC begrenzt
- Der Dev glaubt nicht, dass LN für große Zahlungen nützlich ist, da bei größeren Transaktionen BTC-Onchain billiger bleibt (weil Routing schwieriger wird und man wohl dann den "Durchgangshubs" eine Fee zahlen muss)
- Wenn jeder Mensch auf der Welt einen LN-Channel betreiben würde, würde es 63 Jahre dauern - zumindest bei der derzeitigen Begrenzung auf 1 MB

Sein Fazit ist, dass die Miner-Furcht vor LN unbegründet ist.

[Danton]

Einige interessante Dinge:

- Lightning-Payments werden erstmal auf 0.042 BTC begrenzt
- Der Dev glaubt nicht, dass LN für große Zahlungen nützlich ist, da bei größeren Transaktionen BTC-Onchain billiger bleibt (weil Routing schwieriger wird und man wohl dann den "Durchgangshubs" eine Fee zahlen muss)
- Wenn jeder Mensch auf der Welt einen LN-Channel betreiben würde, würde es 63 Jahre dauern - zumindest bei der derzeitigen Begrenzung auf 1 MB

Sein Fazit ist, dass die Miner-Furcht vor LN unbegründet ist.

Damit scheint aber auch die Hoffnung, dass LN eine Lösung für das Scaling-Problem darstellt irgendwie unbegründet... 

Mikrotransaktionen spielen beim Bitcoin derzeit keine Rolle. Das Scaling-Problem besteht bei normalen Transaktionen. Und wenn LN dafür 1) nicht geeignet ist und 2) für den Auf- und Abbau von Channels selbst Blockchain-Kapazität verbraucht, wird die Scaling-Problematik durch LN eher noch verschärft als gelöst!

[mezzomix]

Die Grenze ist tatsächlich etwas niedrige, kann aber einfach angehoben werden. Es ist aber trotzdem sinnvoll klein anzufangen, da Probleme bei einem neuen System nicht auszuschliessen sind. Es ist nicht sinnvoll einem neuen Protokoll sofort grössere Beträge anzuvertrauen - ich würde es zumindest nicht machen. Erst mal muss sich sowas im realen Einsatz stabilisieren.

Daneben sollte LN nicht die einzige Applikation bleiben. Side-Chains/Sub-Chains stellen ebenfalls eine Skalierungsmöglichkeit bereit und sollten daher nicht ignoriert werden.

[MoinCoin]

LN ist aktuell noch Alpha. Soweit ich weiß ist der Standard (BOLT) noch nicht mal fertig.
Da ist es schon okay den Betrag als Sicherheitsmaßnahme erstmal niedrig anzusetzen..

An sich sind die 0.042 BTC kein Problem, da man ja praktisch beliebig viele 0.042 BTC Transaktionen auf einmal senden kann.
Eine Wallet-Software kann das ja vor dem Benutzer verstecken.
Dauert dann eben 10 Sekunden, statt 1 Sekunde, weil mehr Daten auszutauschen sind.

Wenn LN erstmal Beta ist, wird das sicherlich angehoben.

Es gibt da noch ganz andere Baustellen.
Bei der letzten Demo von Eclair diese Woche, ist mir aufgefallen, dass die Node id und dann IP+Port als URI angeben. Das hat mich etwas verwirrt, weil es so unpraktisch erscheint (NAT, Firewall, DSLite), zeigt aber auch nur, dass alles noch in einem sehr frühen Stadium ist.

Aktuell läuft das Discovery wohl sogar noch per IRC
https://github.com/lightningnetwork/lightning-rfc/blob/c5ca57b853a77256cbdc96dd676c01fda5aec126/06-irc-announcements.md

Da müssen die sich auch noch einigen - mit DHT, TURN (Traversal Using Relays around NAT) etc. gibt es dafür aber immerhin potentielle Lösungen . Und ohne direkte Protokollunterstützung geht es ja auch mit einem Proxy, der den offenen Port vorhält.

Node ID sollte aber hoffentlich reichen als Ziel, alles andere da sollen sich bitte die Programme drum kümmern.

Achja... dauert alles noch eine ganze Weile

[d5000]

Damit scheint aber auch die Hoffnung, dass LN eine Lösung für das Scaling-Problem darstellt irgendwie unbegründet... 

Mikrotransaktionen spielen beim Bitcoin derzeit keine Rolle. Das Scaling-Problem besteht bei normalen Transaktionen. Und wenn LN dafür 1) nicht geeignet ist und 2) für den Auf- und Abbau von Channels selbst Blockchain-Kapazität verbraucht, wird die Scaling-Problematik durch LN eher noch verschärft als gelöst!

Naja, ~40 Dollar ist schon OK als Grenze. Die Autoren argumentieren ja auch, dass durch LN neue Use Cases möglich werden, wie eben der vielzitierte Kaffee. Langfristig könnten die 0.042 auch eher 100 Dollar entsprechen, wenn der jetzige Dip überwunden ist

Es stimmt allerdings, dass die durchschnittliche Transaktion deutlich größer ist. Wenn ich diese beiden Charts kombiniere:

- https://blockchain.info/charts/n-transactions (~300.000 Transaktionen pro Tag)
- https://blockchain.info/charts/estimated-transaction-volume (~300-350.000 BTC pro Tag)

erhalte ich etwa 1-1,2 BTC pro Transaktion. Interessant wäre eine Aufteilung z.B. in Quartile oder auch der Median, da sehr große Transaktionen (z.B. von Exchanges) diesen Mittelwert verzerren könnten. Weiß nicht, ob es so einen Chart irgendwo gibt oder man den selber ausrechnen müsste.

[MoinCoin]

- Wenn jeder Mensch auf der Welt einen LN-Channel betreiben würde, würde es 63 Jahre dauern - zumindest bei der derzeitigen Begrenzung auf 1 MB

Um nochmal darauf zurück zu kommen.

Ich freunde mich mehr und mehr mit der Idee an, dass 1 MB auf Layer 1 trotzdem langfristig reichen könnte.
Ich halte es zwar nicht für die technisch beste Lösung, aber wahrscheinlich die beste technische Lösung die erreichbar ist.

LN als Layer 2 direkt auf Layer 1 bleibt damit allerdings nur eine Übergangslösung.

Wie auch schon bei RSK Lumino erst Layer 4 ist, wäre es wohl sinnvoll für das LN noch mal ebenso eine Zwischenschicht einzuführen, wenn man keinen Konsens für größere Blöcke auf Layer 1 findet.

LN als Layer 3 und ein Layer 2 für LN Settlements könnte ich mir als Lösung vorstellen.
Layer 2 könnten zum Beispiel Extension Blocks (über Softfork möglich) oder Sidechains (mit Softfork oder ohne Fork als Federated Sidechain) sein.
Extension blocks könnte man so designen, das aus der Benutzererfahrung Layer 1 und 2 praktisch verschmelzen, wenn der Nutzer einen bestimmten Extension Block unterstützen möchte.

Unterschiedliche Extension Blocks könnten unterschiedliche Eigenschaften aufweisen.
Man könnte einen Extension Block mit Segwit haben, auf dem dann Layer3-LN aufsetzt und gleichzeitig einen anderen Extension Block mit
Big Blocks (EC / BIP 100 / BU), ohne das Risiko eines currency splits zu haben. Wäre das ein tragfähiger Kompromiss?
Geht natürlich auch direkt als Extension Block mit Segwit und BigBlocks.

Node-Dezentralisierung auf Layer 1 könnte somit erhalten bleiben.
Hardforks auf Layer 2 haben dann auch kein Risiko mehr die Basis-Währung BTC zu splitten.
Bei BU und bei UASF mit counter hardfork sehe ich das Momentan als ziemlich sicher, dass nicht nur das Netzwerk, sondern auch die Währung gesplittet wird.

LN auf Layer 2 als Übergangslösung könnte wie gesagt grundsätzlich aber erstmal funktionieren. Es muss also gar nicht unendlich skalieren.

Es könnte hart werden für Bitcoin, aber langfristig sollte das trotzdem noch lösbar sein.
Als nächstes kommt am 22.05. RSK Ginger

Edit:
LN geht natürlich auch gleichzeitig auf Layer 1 und Layer 2 Blocks

[mezzomix]

Layer 2 kann weit mehr als nur ein einziges LN sein! Dort könnten durchaus verschiedene Off-Chain/Side-Chain/Sub-Chain Lösungen koexistieren und nach Bedarf (auch gleichzeitig) genutzt werden.

[MoinCoin]

Layer 2 kann weit mehr als nur ein einziges LN sein! Dort könnten durchaus verschiedene Off-Chain/Side-Chain/Sub-Chain Lösungen koexistieren und nach Bedarf (auch gleichzeitig) genutzt werden.

Was meinst du mit mehr als ein einziges LN?
Folgendes Beispiel würde ich eher als ein gemeinsames großes LN sehen:
Alice ---(Layer-1-BTC Channel)---> Bob ---(Layer-2-BTC Channel)---> Charlie ---(Layer-1-BTC Channel)---> Dave

Notiz am Rande:
Ich glaub ich habe zuletzt zu viel /r/bitcoin gelesen.
Wenn man das zu viel liest, sollte man meinen, dass es keine Alternativen zu segwit + LN als Layer 2 gibt und auch nichts anderes benötigt wird.
/r/bitcoin ist für mich die schlimmste Anti-Werbung für Bitcoin und der Grund, warum ich lange Zeit Bitcoin Unlimited für "die bessere Lösung" gehalten habe.

Insbesondere wenn ich sowas lese, was ein bestimmter Core-Dev schreibt, denke ich manchmal das ist praktisch wie Propaganda für Bitcoin Unlimited
https://www.reddit.com/r/Bitcoin/comments/61wdqc/the_most_compelling_reason_why_segwit_lightning/

Segwit ist nur der allererste Schritt.