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