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

Danke! Ich hab den Threadname jetzt mal geändert, damit man hier auch über andere 2nd-Layer-Techniken diskutieren kann.

Jedenfalls sehen Extension Blocks sehr interessant aus.

Bei den Extension Blocks stellt sich mir jetzt noch die selbe Frage wie bei den Sidechains: Wie funktioniert der Mechanismus, um Bitcoins "zurückzuüberweisen"? Also Main Block -> Extension Block sollte recht einfach sein über ein spezielles Script, das Problem ist aber das Tauschen der "Extension-Bitcoins" in die "Hauptchain-Bitcoins", da diese ja in der Hauptchain nicht existieren bzw. "entsperrt" werden müssten. Du hast es ja schon kurz angesprochen, dass es da mehrere Möglichkeiten gibt. Kennst du da bestimmte Vorgehensweisen, welche diskutiert werden? Kannst mir gerne auch einen Link dazu geben ...

Hatte mich auch kurz gefragt, ob das OT geht, aber selbst mit LN brauchen wir ja mehr Blockspace zum öffnen und schließen der LN Kanäle - sehe das einfach als mittelfristig notwendige Basistechnologie, damit LN seine Aufgabe erfüllen kann.

Ist sonst ziemlich unfair gegenüber den Entwicklern und der Technologie LN, weil LN als Layer 2 nicht alles alleine lösen kann und sollte.

Ja das Prinzip ist dem der Sidechains sehr ähnlich.
Die Kopplung zwischen den Mainblocks und Extension Blocks ist jedoch enger, als bei Mainchain und Sidechain.

Sagen wir mal so: Man könnte den Transfer von Coins zwischen Hauptchain und Extension Blocks einfacher und sicherer gestalten, als den zwischen Hauptchain und einer Sidechain.

Hinter den bekannten Bitcoin Adressen steckt ja implizit eine Anweisung, wie die Transaktion zu erstellen ist. Also welche ScriptSig zu verwenden ist, zum Beispiel bei P2KH Adressen (die einfachen 1er Adressen) mit einem PubkeyHash, sowie das zugehörige Main-Netzwerk und eine Prüfsumme um sicher zu stellen, dass die Adresse korrekt ist.
Es wäre also möglich ein andere Adresse oder ein anderes Adressformat für den Extension Block zu nutzen, so das dein Wallet wie bisher die notwendige Transaktion aus der Empfängeradresse erstellen kann.

Hypothetisch könnte dich dein Bitcoin Wallet fragen, ob du einen jeweilige Extension-Blockchain benutzen willst, und ob du die als Full-Archival-Node, Pruned-Node oder SPV-Node nutzen willst. Weiterhin sollte man einstellen können, ob dein Wallet automatisch die Bitcoins Up und Downgraden darf zwischen der Hauptchain (Haupt Utxo) und dem Extension Block (Extended Utxo).

Wenn man das auf automatisch stellt, würde ein einfacher Nutzer keinen Unterschied merken bei der Benutzung von Extension Blocks und Main Blocks. Bei den meisten Wallets sieht man ja auch nur, was für aktuelle Utxos man nutzt, wenn man etwas unter die Haube schaut oder Funktionen wie CoinControl nutzt.

Nachteil ist eben, dass zunächst jeder wohl auch weiterhin seine Adresse für Main Blocks und Extension Blocks angeben müsste, weil die Benutzung von den Extension Blocks ja freiwillig ist.
Aber das gleiche haben wir aktuell auch, wenn man Altcoins nutzt, weil einem die Transaktionsgebühren zu hoch sind.
Ich hoffe langfristig werden wir sowieso wegkommen den Nutzer mit den bekannten Bitcoin-Adressen zu quälen, sondern stärker auf andere Dinge setzen, so das Wallet sich die Empfängeradresse zum Beispiel über ein Payment Protocol selbst erzeugt. Das Payment Protocol würde dann erkennen, dass es auch die Extension Blocks benutzen kann und eine entsprechende Adresse wählen. Payment Protocols haben ja auch andere Vorteile, zum Beispiel eine höhere Anonymität gegenüber Dritten. Somit wäre das nur ein Problem für die Übergangsphase.


Und zu deiner zweiten Frage:
Grundsätzlich sollten auch mehrere Extension Blocks auf einen Hauptchain Block folgen können. Das ist immer alles eine Frage, wie eng man das Koppeln will und was für Vor und Nachteile sich daraus ergeben. Irgendwo verwischt auch die Grenze zwischen bestimmten Arten von Sidechains und Extension Blocks.

Man könnte die Extension Blocks auch mit Bitcoin-NG verknüpfen und den letzten Extension Block in dem aktuellen Main Block, sowie eintragen - derjenige Miner, der den Main Block gemined hat ist dann sozusagen auch der Gewinner, der die nächsten Extension Blöcke minen dürfte, bis der nächste Miner einen Main Block mined, der auch diese Extension Blocks minen will.

Es gibt extrem viele Freiheiten, aber ich denke es wäre sinnvoll am Anfang das ganze erstmal möglichst einfach zu machen, damit das ganze einfach zu verstehen, kurzfristig zu implementieren und zu testen ist und am wichtigsten: sicher funktioniert.

Wenn man dann einen besonders fortschrittliche Idee hat, lässt sich das sowieso deutlich leichter einbinden, als in Main Blocks.
Innerhalb des Extension Blocks kann man immer Hardforken (also den Aufbau und die Fähigkeiten des Extension Blocks komplett ändern), ohne das Risiko zu haben zusätzliche BTCs zu erzeugen oder die Chain zu splitten.
Die Frage ist da eher immer, ob man die Rückwärtskompatibilität trotzdem haben will. Ich denke, wenn man das so macht, wie viele Altcoins, und frühzeitig ankündigt, dass es Hardforks geben wird (z.B. Monero), dann ist das akzeptabel.

Alternativ hat man sowieso immer die Möglichkeit einen zusätzlichen Extension Block einzuführen.

Danke MoinCoin! Also im Prinzip sind dann Extension Blocks ähnlich wie Sidechains, nur dass jeder Block direkt von einem Hauptchain-Block referenziert wird (also sozusagen eine "in die Hauptchain integrierte Sidechain"). Wird dadurch der Prozess des Transfers von Coins zwischen Hauptchain und Extension Blocks einfacher? Können mehrere "Extension Blocks" auf einen Hauptchain-Block folgen? Erstmal nur die beiden Fragen, um hier nicht zu weit OT zu gehen

Hab die PM erhalten, danke. Von mir aus können wir einen Extension-Block-Thread aufmachen, interessiert sicherlich auch andere. Wobei, da ich den Thread hier ja gestartet hatte, ist es kein Problem das auch hier zu diskutieren. Vielleicht nenne ich den Thread dann einfach in "2nd layer-Technologien" um ...

Genau - der Vorteil ist aber, dass man es aber eben trotzdem funktioniert und man nicht warten muss, bis der Softfork in Core implementiert und dann im Netzwerk aktiviert wird. Bis segwit implementiert und getestet war hat es ja auch ewig gedauert und jetzt ist nicht mal klar ob/wann segwit aktiviert werden kann.
So geht es immerhin trotzdem vorwärts. Und niemand kann etwas dagegen machen ohne Bitcoin zu zerstören.
Es ist bei weitem nicht perfekt, aber ich werde es lieber nutzen als Altcoins.

Ehrlich gesagt bin ich wirklich erstaunt, wie wenig Entwicklung es im Bereich Extension Blocks gibt und das der so selten erwähnt wird, die Idee ist ja nicht gerade neu.
Leider gibt ja nicht mal ein BIP oder eine wirklich fertige Spezifikation.

Ich versuch mich mal an einem ELI5: Extension Blocks sind die Softfork Variante von größeren Blocks, die viele ja wollen und man sonst über Hardforks erreicht.
Extension Blocks sind eine Layer 2 Technologie und lassen so also Layer 1 in Ruhe, während Projekte wie BU versuchen das direkt alles in Layer 1 zu ändern, ohne jedoch Konsens zu erreichen, weil es eben sehr unterschiedliche Interessen auf Layer 1 gibt.

Die Cornell Universität hatte vor 2 Jahren eine Studie herausgegeben in der Stand, dass wir mit 4 MB Blöcken ca. 10% aller Full Nodes verlieren würden. Da die Basis Blöcke bei Nutzung von Extension Blocks unabhängig von der Größe der Extension BLocks weiterhin maximal nur 1 MB hätten wäre es wohl möglich mit Extension Blocks sogar deutlich weit über die 4 MB zu gehen ohne direkt Nodes zu verlieren, die nur auf Layer 1 arbeiten.

Ich wüsste nicht, warum es einen Counter Hardfork in diesem Szenario geben sollte der Erfolg haben könnte, deswegen besteht auch kein Risko, dass die Währung BTC gesplittet wird.

Um die erweiterte Kapazität nutzen zu können braucht man wie auch bei segwit oder einem Hardfork einen neuen Client, der die extension blocks unterstützt. Aber der neue Client kann den Benutzer fragen, ob er die zusätzlichen ressourcen aufwenden will um auch den extension block zu unterstützen. Man könnte gleichzeitig Layer 1 als Archival Full Node nutzen und Layer 2 Extension Blocks als Pruned Full Node oder sogar als SPV Node.

Die tatsächliche Spezifikation von Extension Blocks könnte sehr unterschiedlich ausfallen
Auf jeden Fall erstellen Alle Miner weiter die normalen Blöcke und wenn er will, eben zusätzlich einen extension Block.
Praktisch ist es so, dass von einem Miner im Main Block auch eine Referenz auf den Extension Block abgelegt werden muss, könnte man genauso machen, wie das bei segwit gemacht wird. Theymos hatte segwit letztens als speziellen extension block beschrieben in einem Artikel auf /r/bitcoin, ich halte das jedoch für eher unglücklich, da segwit eine Layer 1 Technologie ist und ich extension blocks als Layer 2 Technologie sehe.

Alte Clients sehen zwar die Referenz, aber für die ist das nur Text und hat keine Bedeutung.
Der Basis Block ist deswegen unter den alten Regeln weiterhin voll gültig und alle Transaktionen im Block können vollständig von alten Clients verifiziert werden.

Es wäre also Rückwärtskompatibel und der Client könnte jederzeit noch überprüfen, ob alle Regeln in den Basis Blockhain (z. B. 21M Limit von Basis Bitcoins) eingehalten werden. Ist sogar besser als bei segwit, denn da haben alte Clients das Problem, dass sie in der Basis Blockchain nicht überprüfen können, ob jetzt eine Segwit Transaktion wirklich mit einer gültigen Signatur ausgestattet war oder nicht.
Und wenn es zu einem UASF bei segwit besteht die Gefahr, dass alte Clients und SPV Clients ggf. auf dem counter hardfork landen (dazu braucht ja nur ein miner sich selbst eine segwit transaktion schicken und diese dann ohne gültige signatur wieder ausgeben, also ohne BTCs zu klauen).

Alte Clients haben also nur einen indirekten Nutzen durch die höhere Übertragungskapazität im Extension Block, wenn andere statt des Basis Blocks den Extension Block nutzen, aber es ist freiwillig.

Wenn man jetzt ein Ultra-HODLer ist, der an Bitcoin nur als Digitales Gold interessiert ist kann man die Extension Blocks ohne Sicherheitsverlust ignorieren, das ist der große Unterschied zu einem Hardfork mit größeren Blöcken, wo man nun den gesamten großen Block untersuchen müsste um sicher zu sein, dass alles mit den eigenen bitcoins in Ordnung ist.

Wenn man Bitcoin für regelmäßige Zahlungen nutzen will, oder öfter LN Channel öffnen möchte, und genug Rechenleistung und Bandbreite hat, ist es wahrscheinlich sinnvoll primär in den Extension Blocks Transaktionen durchzuführen, denn die Transaktionskosten sind wahrscheinlich geringer.

Für Miner wäre das auch interessant, da sich neue Möglichkeiten ergeben Transaktionsgebühren zu bekommen - und ggf. wäre das auch ein Kompromiss um aus dem segwit vs. Big Blocks Dilemma rauszukommen.

Wie der Mechanismus aussieht um die BTCs vom Main Block in den Extension Block zu bekommen und zurück müsste festgelegt werden, da gibt es mehrere Möglichkeiten.

Ob der Mechanismus ohne Wartezeit oder mit Wartezeit funktioniert ist wieder eine Sache, die man abwägen müsste.
Selbst wenn die Coins im Transfer gesperrt werden, wäre das aber immer noch viel besser als bei einem Chain-Split, denn da kann man die alleine überhaupt nicht zwischen den Blockchains bewegen, falls wir also tatsächlich einen Hardfork hätten, wäre das so, als ob man seine Bitcoins mit unendlich Wartezeit zum Transfer in die die andere Blockchain sperrt

Davon hängt dann ab, wie die Nutzererfahrung ist, wenn man eine Transaktion von BTCs aus dem Main Block zu einer Adresse machen will, die im Extension Block gespeichert wird. Das könnte etwas länger dauern. Je mehr Miner einen speziellen extension Block unterstützen, desto mehr Freiheiten hat man, da die Miner auch den Extension Block absichern. Wenn alle Miner auch den extension Block minen, könnte man die coins natürlich ohne Wartezeit hin und her transferieren.

Eine Transaktion innerhalb des Extensionblocks würde ungefähr so funktionieren, wie wir das aktuell gewohnt sind mit den normalen Blöcken. Schlechter wird es wohl kaum, man könnte es auch so designen, dass es schneller als auf Layer 1 geht.

Der Extension Block kann praktisch ein beliebiges Format haben - aber zur Einfachheit kann man den am Anfang natürlich genauso aufbauen, wie einen "normalen" Bitcoin Block. Dann wäre die Arbeit das mit SPV Wallets auf dem Smartphone zu unterstützen sehr gering.

Extension Blocks haben ähnliche Nachteile für Nutzer, die diese nutzen, wie größere Standardblöcke, also erhöhter Speicherbedarf, CPU-Verbrauch und das alle alles speichern müssen. Aber keiner zwingt einen die extension blocks zu nutzen, man kann also auch weiterhin mit seinem Raspi Bitcoin nutzen und hat den alten geringeren Ressourcenbedarf.
Extension blocks können wohl kaum eine höhere Sicherheit haben, als die Hauptblöcke, dafür bezahlt man ja aber auch weniger Transaktionsgebühren als Nutzer.

The Blue Matt (Core-Dev) hat sich in der Mailing List darüber beschwert, dass Miner ja aus ökonomischen Gründen gezwungen wären dabei mitzumachen, aber ich sehe das anders. Es ist wie bei LN - es finden zusätzliche Transaktionen statt, die vorher niemals hätten stattfinden können. Dem Miner der nicht mitmacht, entgehen also überwiegend Transaktionsgebühren, die sonst bei Paypal oder bei einer Altcoin gelandet wären.

Eins frage ich mich allerdings doch, welche Effekte aufgrund dieses ökonomischen Aspekts auf Miner Zentralisierung zu erwarten sind. Andererseits funktionieren FIBRE,das Cornell Falcon Network und Thinblock Technologien schon jetzt ziemlich gut und erlauben es auch wieder kleineren Pools mitzumachen, ohne das ein größeres Orphan Risiko besteht.

Andererseits könnte es genau das sein, was die Miner wollen - mehr Blockspace zu verkaufen. Ich kann nämlich verstehen, dass viele Miner nicht unbedingt LN Hub Operatoren werden wollen, weil das komplett andere Fähigkeiten verlangt und einige Miner aktuell nicht ganz zu unrecht sauer sind. Und so hätten wir wieder eine Chance das Bitcoin-Ökoystem zusammenzuführen.


Ich denke das löst sich ganz einfach. Wer nicht kompatibel zum BOLT Standard ist wird Schwierigkeiten haben, weil keiner die Software benutzen werden will wegen dem fehlenden Netzwerkeffekt und glaube eher, dass es deswegen ein gemeinsames LN geben wird.
Ggf. wird es zwischendrin irgendwelche Clients geben, die zwischen den inkompatiblen Standards eine Bridge bauen werden und das Netzwerk so wieder vereinen.
Problem bleibt weiterhin die Routenfindung

Edit: Satzbau
Edit 2: Im Gegensatz zu Segwit bleibt die Teilnahme an Extension Blocks, wie bei allen Layer 2 Technologien, auch für neue Clients freiwillig

Es gibt jetzt schon mehr als eine LN Implementierung. Die meisten haben kompatible Schnittstellen, was aber nicht zwingend so sein muss.

RSK hat ja (noch) den Nachteil, dass noch ein Opcode für die "Rückumwandlung" der Sidechain-BTC in normale BTC fehlt und somit die vorläufige Lösung des Pegs erstmal recht zentralisiert ist. Ich glaube, damit holt man keinen echten Bitcoin-Fan auf den 2. Layer.

Danke übrigens für den Hinweis auf Extension Blocks. Gibt es da irgendwo eine Beschreibung für technische Laien? Ich finde da nur sehr technische Beiträge (Dev-Mailingliste ...) die für mich als Nichtinformatiker doch recht schwierig zu verdauen sind

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.

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.

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

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.

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

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.

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!

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.

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.

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

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.

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.

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.

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.