Topic: Lightning Netzwerk - Eclair: Aufsetzen eines LN-Knoten im Testnetz (Read 1399 times)

bauanleitung für ne node:

https://github.com/rootzoll/raspiblitz

Ich bumpe mal, vielleicht wird @Thiagosantos Frage beantwortet (ich kann es leider nicht).

Hab mir jetzt mit Hilfe aus dem englischen Forum Neutrino installiert. Das ist ein Lightclient, der keine vollständige Blockchain benötigt, aber bisher nur mit dem Testnet funktioniert. Dennoch, um etwas damit rumzuspielen sicher ganz cool, und sicher "die Zukunft" was Mass Adoption angeht.

Neutrino ist im Lightning-Client LND (Installationsanleitung) integriert. Also theoretisch einfach LND, wie im Link genannt, installieren und dann im Neutrino-Modus starten:


Mit lncli (--help um Optionen zu sehen) kann der Client gesteuert werden. Ich bin noch ganz am Anfang, finde leider keine Peers (vielleicht ist der Faucet offline und ich brauch was anderes). Werde aber in den nächsten Tagen/Wochen hoffentlich ein paar Erfolgserlebnisse hier berichten können.

Frage: kann ich über die mobile App Lightning-Zahlungen durchführen, um einen Onlineanbieter zu bezahlen?

Ich hatte die App installiert, aber es wurde verlangt, dass ich mich mit einem Node verbinde!? Per "random"-Funktion ging es nicht, da noch nicht unterstützt und als ich manuell ein Node anfügen wollte, habe ich gemerkt, dass man einen bestimmten Betrag an btc investieren muss? Allerdings war dieser Betrag unverhältnismäßig hoch im Vergleich zu meiner angestrebten Zahlung.

ein real life erfahrungbericht - er betrieb den "grössten" LN hub (ca. 40 BTC) bisher:

https://medium.com/andreas-tries-blockchain/bitcoin-lightning-network-1-can-i-compile-and-run-a-node-cd3138c68c15

https://medium.com/andreas-tries-blockchain/bitcoin-lightning-network-2-we-must-first-become-the-lightning-network-49c46953c1d7

https://medium.com/andreas-tries-blockchain/bitcoin-lightning-network-3-paying-for-goods-and-services-5d9c492b0eb2

https://medium.com/andreas-tries-blockchain/bitcoin-lightning-network-4-what-happens-when-you-close-half-of-the-lightning-network-b25b330dfad2

Genauso ist es. Warum das so ist, habe ich hier nochmal erklärt:

https://bitcointalksearch.org/topic/m.34138195

Und mit Kreditkarten macht man auch nichts anderes als zu bezahlen. Im Extremfall ist dies das Ende der Kreditkartenunternehmen.

Interessant finde ich den Ansatz mit nur ausgehenden Transaktionen, womit sich ein ausrauben nicht lohnt.

Eclair Wallet für Android.

https://play.google.com/store/apps/details?id=fr.acinq.eclair.wallet

Weitere News zum Thema:

https://coincierge.de/2018/bitcoin-lightning-beta-was-aendert-sich/

Lightning Network beta fürs Mainnet veröffentlicht:

https://blog.lightning.engineering/announcement/2018/03/15/lnd-beta.html
https://cryptoslate.com/bitcoin-lightning-network-beta-now-live/


Aktuelle Entwicklung des LN-Mainnet:

https://p2sh.info/dashboard/db/lightning-network

Danke für den Interessanten Beitrag. Leider hab ich aktuell keine Hardware frei aber werde es in Naher Zukunft auch versuchen zum laufen zu bringen.

Joa, so wirklich sind die Leute von Eclair auch nicht auf das Problem eingegangen. Wollte damit nur sagen, dass Du nicht der einzige bist, der dieses Problem sieht. Oder wir machen irgendwas falsch.


Naja, der Begriff "gehackt" verkennt ein bisschen die Realität. Es war schlicht meine eigene Blödheit.

Mehr oder weniger verifiziert habe ich mich hier:

https://bitcointalksearch.org/topic/mein-account-wurde-gehackt-ich-brauche-eure-hilfe-2908813

Das muss leider als Beweis reichen.

Ging komischerweise ganz einfach - Pakete mit apt-get installieren und fertig. Ich benutze Debian Stretch, und die dortigen OpenJDK- und OpenJFX-Pakete scheinen "genau die richtigen zu sein", jedenfalls sehe ich nur, dass die Kommandozeile etwas meckert, aber sonst öffnet sich die GUI prima. Meine Versionen:



Aha, danke! Hab sowas auch vermutet, aber dass es so viele "Leichen" sind hat mich doch erstaunt ...

Prima, werde das später noch mal durchlesen, hab den Zusammenhang auf den ersten Blick nicht ganz kapiert und gerade nicht so viel Zeit.

BTW: Hab jetzt gerade die eigenartige Zitatesammlung oben gesehen. Bist du curiosity81 und wurdest gehackt? Hab das garnicht mitbekommen. Bringt es was wenn ich dich auch noch zitiere?

Sehr schön. Kannst Du das näher erläutern wie Du OpenJDK mit OpenJFX zum laufen bekommen hast. Ich habe nach etwas rumprobieren die Lust verloren und dann die proprietäre Lösung gewählt.


Ich denke, dass sind Knoten die gerade nicht laufen. Meiner ist auch abgeschaltet wird aber immer noch angezeigt. Wahrscheinlich besteht das Testnetz zum grossen Teil auch aus Knotenleichen.


Siehe oben. Und ja möglich auch, dass der entsprechende Port geschlossen ist. Dieser Knoten selbst kann aber wohl nach draussen "telefonieren".

Das Problem mit der Erkennung der "freundlichen" und "unfreundlichen" Knoten habe ich schon mal bei Eclair angesprochen:

https://github.com/ACINQ/eclair/issues/426

Ich bin jetzt endlich mal dazu gekommen Eclair auszuprobieren.

Die gute Nachricht: Eclair scheint auch mit OpenJDK zu funktionieren, solange man auch OpenJFX installiert. Zumindest geht die GUI auf (auf der Kommandozeile scheinen aber einige Fehlermeldungen aufzupoppen) und nach einer erfolgreichen Connection füllen sich die Tabellen mit Nodes.

Wo ich noch hänge ist beim Aufbauen eines Payment-Channels. Ich erhalte bei fast allen Knoten Fehlermeldungen ("Connection failed"). Bei einem (der viele Verbindungen zu anderen Nodes hatte, also einem kleinen Hub) hatte es geklappt, und ein Channel wurde kurz aufgebaut. Danach wurde er allerdings schnell wieder geschlossen.

Kann es sein, dass man sich zu Knoten verbinden müsste, die freundlich gegenüber neuen Usern eingestellt sind, d.h. Payment-Channels mit jedem erlauben? Kann man die irgendwie von den "unfreundlichen" Nodes unterscheiden bzw. gibt es da eine Liste? Oder liegt das eventuell an Portforwarding-Problemen dieser Nodes, wie sie im letzten Abschnitt des Tutorials beschrieben wurden?

Ich führ das mal weiter:

Anzahl Knoten im Mainnet: 702
Anzahl Channels im Mainnet: 1847

Halb so wild. Bevor es eine erste richtige Anwendung gibt, ist das ja alles nur Spielerei.

Sobald z.B. die ersten Miner ihre GPUs per Lightnig kaufen können, wird die Verbreitung auch ganz andere Formen annehmen.


Edit:

Ich sehe gerade, dass laut dieser Seite schon ca. 1300 Channels offen sind.
https://p2sh.info/dashboard/db/lightning-network?orgId=1

Das heißt je nachdem wo man nachschaut gibt es unterschiedliche werte

Stand heute:

Anzahl Knoten im Mainnet: 429
Anzahl Channels im Mainnet: 964

Hmm ... die Anzahl der Channels nimmt wieder ab 

Stand heute:

Anzahl Knoten im Mainnet: 429
Anzahl Channels im Mainnet: 1013

Falls auch jemand mit dem Gedanken spielt, sich an einem Mainnet-Node auf dem RaspberryPi zu versuchen. Hier ist ein Artikel im Aufbau, der dies schön durchexerziert:

https://medium.com/@stadicus/getting-ready-for-%EF%B8%8Flightning-%EF%B8%8F-on-bitcoin-mainnet-64e3ff7f4efe

Stand heute:

Anzahl Knoten im Mainnet: 429
Anzahl Channels im Mainnet: 1032

Stand heute:

Anzahl Knoten im Mainnet: 420
Anzahl Channels im Mainnet: 1055

Stand heute:

Anzahl Knoten im Mainnet: 403
Anzahl Channels im Mainnet: 1004

Stand heute:

Anzahl Knoten im Mainnet: 385
Anzahl Channels im Mainnet: 980

Beispiel für einen "proof of concept" im Lightnig Network

https://www.coindesk.com/little-bitcoin-lightning-project-has-two-big-implications/

"The Lightning Network is the only solution for real-time transactions."

Stand heute:

Anzahl Knoten im Mainnet: 359
Anzahl Channels im Mainnet: 959

Stand heute:

Anzahl Knoten im Mainnet: 346
Anzahl Channels im Mainnet: 868

Stand heute:

Anzahl Knoten im Mainnet: 300
Anzahl Channels im Mainnet: 817

Die Leute von Eclair haben ein Tool namens Strike veröffentlicht, mit dem man einen Webshop per Lightning Network betreiben kann. Ist aber nicht ganz dezentral, so wie ich das verstehe geht das mehr in die Richtung von BitPay:

https://medium.com/@ACINQ/introducing-strike-a-stripe-like-api-for-lightning-c84762f4f634

Und von Zap wurde nun eine beta-Version veröffentlicht, ausprobiert habe ich diese aber noch nicht:

https://medium.com/@JimmyMow/announcing-zap-beta-release-346b5100376e

Alles scheinbar noch Testnet, jedoch denke ich, dass man die Konfigurationsdateien leicht derart abändern kann, dass es auch im Mainnet läuft (siehe Zap).

Edit: da mache ich doch gleich mal eine Zap-Anleitung:

https://bitcointalksearch.org/topic/lightning-netzwerk-zap-nutzung-einer-ln-wallet-im-testnetz-2837939

So, habe den Krimskrams jetzt auch mal übersetzt:

https://bitcointalksearch.org/topic/lightning-network-eclair-installation-of-a-testnet-ln-node-2833635

Stand heute:

Anzahl Knoten im Mainnet: 275
Anzahl Channels im Mainnet: 758

BTW, es gibt eine neue Version von Eclair, und zwar die alpha9:

https://github.com/ACINQ/eclair/releases

Das wäre dann wieder eine Nische für z.B. Xapo. Da deren Server eh immer an sind, so können die dann auch die Channels überwachen. Die Wallet würde dann per Mulitsig funktionieren, wobei eine Hälfte der Schlüssel auf dem Smartphone liegt, die andere bei Xapo. Und eine Debitcard die über MasterCard oder Visa läuft bräuchte man dann auch nicht mehr.

Anzahl Knoten im Mainnet: 252
Anzahl Channels im Mainnet: 736

Ich sehe das ehrlich gesagt alles halb so wild.

Erstens weiß mein Gegenüber nicht ob ich gerade Online bin oder nicht. Das heißt derjenige müsste schon darauf spekulieren, dass ich gerade in einer Situation bin, in der ich z.B. 24 Stunden nicht online sein kann.
Solche Situationen werden aber in Zukunft immer weniger werden. Wir können mittlerweile kostenfrei in Europa roamen.
Wenn der Angreifer es trotzdem versucht, riskiert er allerdings Geld zu verlieren. Das wird sich auf dauer nicht lohnen.

Ich stelle mir das zum Beispiel so vor: Meine Handy Wallet schickt mir eine Push Nachricht, weil ich seit 18 Stunden nicht mehr online war. Dann habe ich noch 6 Stunden Zeit mir irgendwo ein Cafe/Hotel/Restaurant zu suchen um kurz online zu gehen. Falls ich regelmäßig in der Wüste oder im Urwald bin, sollte der Zeitraum natürlich entsprechend länger gewählt werden oder man schließt seine Channels vor jeder Reise.

Zusätzlich wäre es natürlich möglich online Services anzubieten, die die Channels überwachen. Aber ich glaube ich, würde bei einem Zeitraum von drei Tagen immer zurecht kommen. Ich kann mich nicht erinnern wann ich in den letzen Jahren mal länger als drei Tage offline war.

Das stimmt, je mehr offene Channels man hat, desto schwieriger wird es ungestraft davon zu kommen. Und wollte man eine Angriff auf den Mempool fahren, dann gäbe es einfachere Methoden als einen LN-Hub aufzusetzen.

Trotzdem muss noch eine Methode her, dass man nicht ständig online sein muss. Wenn man die z.B. Wallet auf dem Smartphone hat und in Urlaub fährt und vergessen hat den Channel zu schliessen, wie verhindert man dann Schindluder?

Eine Idee wäre noch sowas wie ein Mempool für Channels, dafür müsste aber einsehbar sein, was für Transaktionen in einem Channel ablaufen. Sollte sich ein Knoten daneben benehmen so müsste das vom Netzwerk bestraft werden.

Die aktuelle Lösung finde ich unbefriedigend. Aber mal abwarten wie sich das entwickelt. Es gibt cleverere Leute als mich, die sich mit der Materie befassen.

Ich finde eure Diskussion interessant, aber so wie ich den letzten Artikel auf dem Bitcoinblog verstanden habe ist ein großer Exit-Scam nur möglich wenn die "Kunden" des Hubs alle offline sind.


Das heißt wenn jemand soetwas versuchen würde, wäre das mit einem Großen Risiko verbunden eine Menge Geld zu verlieren.

Mit der Kundenbindung meinte ich, dass es sich für Exchanges eventuell lohnen würde, jedem Kunden einen kostenlosen LN-Kanal anzubieten. Exchanges wollen ja einen großen Marktanteil haben, und wer dann als erster Dein offizieller Hub ist, der bekommt sicher auch die meisten Handelsaufträge von Dir. Und ein Kunde mit LN-Kanal macht auch nicht mehr TX-Gebühren aus als einer ohne (die Multisig-Transaktion ist vielleicht größer als eine reguläre, aber dafür gibt es weniger TX insgesamt).


Das ist vollkommen klar - die Frage ist aber, wie groß die größeren Hubs sein werden. Denn Hubs (deutlich besser verbundene Knoten) wird es geben.

Selbst in deinem Beispiel mit einem Kumpel: Mindestens einer aus dem Freundeskreis muss sich schließlich mit der "weiten Lightning-Welt" verbinden, solange ihr nicht nur gegenseitig Zahlungen tätigen wollt. Könnte natürlich z.B. einer sein, der einen geographisch entfernteren Kumpel hat, oder der gerne Pizza bei einem bekannten LN-akzeptierenden Shop isst, oder so ähnlich. Oder halt "der Computernerd" . Der wird aber dann sicher zu einem kleinen Hub. Wenn die ganzen Kumpels aber dann den "gut verbundenen" Kumpel dazu drängen, eine höhere Kapazität aufzubauen, dann könnte der auf die Idee kommen, eine Beteiligung am Risiko zu fordern.

Ich will gar nicht übetrieben pessimistisch sein - vielleicht funktioniert das dezentrale Kumpel-Modell. Aber man sieht ja bei MtGox usw. dass die meisten User faul sind und keinen eigenen Node aufsetzen, diese werden dann wahrscheinlich auch höchstens einen eigenen Kanal offen haben oder ansonsten eine angebundene Online-Wallet oder Exchange (Hubs!) nutzen.

Selbst wenn nur einer der Hubs auf die kritische Kapazität von 100.000+ Channels käme, gäbe es eine Art "systemisches Risiko", da ein einziger erfolgreicher Hub-Exit-Scam einer zu viel sein könnte, dass das System angenommen wird.  Das sollte auf jeden Fall aktiv verhindert werden - ähnlich wie bei den Miningpools, bei denen ja einer mit nahe 50% bereits ein Risiko darstellt.

Verstehe ich schon, und es wäre gut, wenn Du hier recht hättest. Das wird imho sehr davon abhängen, wie sich die Gebühren entwickeln - und ob der oben geschilderte Vorteil der Kundenbindung den Nachteil von mehr TX-Gebühren ausgleicht.


Wenn von Beginn an eine Scam-Absicht besteht (z.B. wie bei Pirateat40 oder neuer eventuell Cryptsy oder Bitconnect ...), wird das sicher machbar sein, schließlich kosten LN-Transaktionen kaum Gebühren.

Hoffen wir's. Ich bin aber etwas pessimistisch, ob man wirklich eine verdächtige Topologie finden kann.

Volle Zustimmung.

Eine wirtschaftliche Topologie, wie ich sie oben beschrieben habe, schliesst doch keine Kunden aus. Kunden bekommen einen Zahlungsaufruf per (QR-)Code direkt über das Internet. Den Rest erledigt das Lightning Netzwerk. Es ist schlicht unwirtschaftlich für eine Exchange sich mit jedem Kunden einzeln zu verbinden. Jeder Kunde impliziert mindestens eine Transaktion und somit Gebühren. Und selbiges gilt für die Kunden.

Dass man sich NICHT direkt mit dem Ziel verbinden muss, DAS ist doch gerade die Eleganz und Schönheit des Lightning Netzwerk!

Um mal ein übertriebenes Beispiel zu geben: Im Extremfall reicht es schon einen Paymentchannel zum Smartphone eines guten Kumpel zu öffnen, und man kommt, rein theoretisch, mit seinen Zahlungen überall hin. Vorausgesetzt, der Kumpel hat mindestens einen zusätzlichen Channel offen um Zahlungen weiterzuleiten und beide Channels stellen genug Kapazität zur Verfügung.


Ich verstehen Dein Beispiel. Im Extremfall ist eine Exchange in der Mitte, man selbst ist mit ihr verbunden und der Kumpel auch. Zahlungen an den Kumpel laufen dann über die Exchange. Ich bin aber trotzdem der Meinung, dass die Exchange lieber wenige Channels mit viel Kapazität öffnen wird als viele Channels mit wenig Kapazität. Ich könnte mir nämlich vorstellen, dass im Mittel Channels mit geringer Kapazität früher schliessen. D.h. viele schwache Channels bedeuten viele Transaktionen und damit Gebühren. Ausserdem würden sie früher schliessen und man müsste sie in höherer Frequenz neu erzeugen. Der Gebührennachteil verstärkt sich so nochmals. Konsequenterweise wird es dann eine Auslese geben, starke Channels bleiben erhalten, schwache verschwinden und/oder das pendelt sich bei bestimmten Verhältnissen ein. Deshalb denke ich, dass es nicht sinnvoll ist, für jeden Kunden einen eigenen Paymentchannel aufzumachen.


Das wäre aber imho ein kostspielige Sache, wenn eine Exchange so etwas simulieren wollte. Diese künstlichen Knoten müssten auch Channels öffnen. Und über diese Channels müssten auch Transaktionen laufen. Ich weiss jetzt nicht ob es möglich sein wird, beim Routing herauszufinden über welche Knoten eine Transaktion läuft, aber prinzipiell ist das möglich. Und dann könnte man einfach eine Statistik über die Transaktionsfrequenz pro Knoten machen. Nur die Knoten, welche direkt verbunden mit der Exchange sind und über die der Grossteil der Transaktionen laufen, erfüllen meine obere Definition von diesen "mächtigen" Nachbarknoten. Alle anderen kann man wohl getrost ignorieren. Und um solche Knoten zu simulieren müsste wohl einiges an Kapital gebunden werden um eine grosse Exchange derart neu zu verkabeln ohne Verdacht zu erwecken, d.h. ohne den normalen Ein- und Auszahlverkehr zu behindern. Ich halte es nicht für unmöglich aber aktuell denke ich, dass es nicht (gut) funktionieren wird.

Das sind aber alles (System)Fragen, die kann man gar nicht so pauschal beantworten. Man müsste das im Computer simulieren und in der Realität beobachten um sie zu beantworten.

Interessantes Szenario, curiosity81. Muss ich mir noch mal durch den Kopf gehen lassen, obwohl ich auf den ersten Blick nicht glaube, dass Exchanges ihren Node baumartig anlegen werden (weniger Kundenbindung, eventuell mehr Transaktionsgebühren ...), aber vielleicht öffnet mir der zweite Blick die Augen.

Klar, LN steht und fällt mit der De/Zentralisierung. Es kommt eben drauf an, wie viele User den bequemen Weg gehen und einfach alles über den Node ihrer Lieblings-Exchange regeln. Wenn das genug sind, dann könnte die Spieltheorie sogar den Betrügern in die Hände spielen, wenn sie wissen, dass die Mehrzahl ihrer Kunden ihre Channels innerhalb einer Woche nicht mehr schließen kann.

Natürlich könnten Hubs mit Betrugabsichten sich auch als mehrere Nodes tarnen, die eine Struktur wie von dir geschildert vortäuschen, sich aber im Ernstfall alle gleichzeitig verabschieden. Sowas zu entdecken dürfte schwierig sein ...

So jetzt kann ich wieder eine Statistik machen:

Anzahl Knoten im Mainnet: 209
Anzahl Channels im Mainnet: 575

Nunja, das ist wieder das Problem der Zentralisierung. Das LN sollte möglichst dezentral sein, d.h. auch kleine Parteien sollten irgendwie motiviert werden einen Knoten aufzusetzen.

Was Du und dieser Nutzer aber übersehen ist, dass nicht jeder Kunde einen Channel offen haben muss, um mit solch einer "Bank" Werte auszutauschen. Man kann sich z.B. eine Topologie vorstellen, wo der grosse Knoten zwei Channels zu zwei weiteren unterschiedlichen Knoten offen hat. Diese Knoten haben wieder jeweils zwei Nachbarknoten usw. usf., also baumartig. Wobei das LN nicht gleich dem Baum ist! Es muss nur möglich sein, dass man einen (z.B. binären) Spannbaum (https://de.wikipedia.org/wiki/Spannbaum) in das Netz aka Graph hineinprojizieren kann, mit der "Bank" als Wurzel. Dann kannst Du im Beispiel des binären Baums über N Schritte 2^N Leute abdecken und bei Betrugsversuchen der "Bank" müssen sich nur die zwei Nachbarknoten kümmern. Beim Schliessen der Channels bei einem Betrugsversuch würden also nur zwei Blockchaintransaktionen notwendig! Und Ähnliches gilt dann für alle Teilnehmer bei einem stark dezentralen Netzwerk. Alles immer unter der Vorraussetzung, dass die Kapazitäten der einzelnen Channels gross genug sind. Aber warum sollte eine Exchange 1000 kleine Channels mit geringer Kapazität öffnen wenn es wirtschaflicher ist sich ein paar Nachbarn zu suchen, welche die entsprechende Transaktionkapazität stellen können. D.h. die Summe der Channelkapazitäten ist vielleicht in jeder Ebene/Level in einem solchen Baum ähnlich, aber verteilt sich entsprechend auf mehr Knoten. Idealisiert sähe das dann so aus: die Exchange hat Kaufkraft aka Kapazität K, die zwei Nachbarn haben haben jeweils Kapazität K/2, die Nachbarn davon jeweils K/4 usw. usf..

Natürlich verbindet sich in frühen Phasen wohl jeder direkt mit einem Channel mit einer Exchange. Aber notwendig ist das nicht. Und wird sich imho auch irgendwann geben.

Das ist eben der große "Tradeoff" von Lightning. Ich vermute aufgrund des Off-Chain-Designs, das ist anders gar nicht möglich, bin aber leider kein Informatiker.

Statt einem Kontrollknoten mit Einsicht in den Channel müsste es aber eigentlich ausreichen, einen Dienst zu beauftragen, die Multisig-Addresse zu überwachen, auf der die "Channel-Coins" liegen, oder? Über Block Explorer oder einen befreundeten Bitcoin-Nutzer (am besten mit Full-Node) müsste das machbar sein, ohne dass der "Überwacher" der Gegenpartei bekannt wird. Klar, irgendwie "online" muss man auch da sein, da man ja nur mit den eigenen Keys die Coins vor der Gegenpartei ausgeben und damit "retten" kann, aber da tut's ja eine Smartphone-Benachrichtigung.

Mehr Kopfschmerzen bereitet mir dieses Szenario, das ein User aus dem Bitcoinblog noch ganz harmlos findet:



(der Nutzer bezeichnet große LN-Nodes als Banken).

Worauf ich hinaus will? Ganz klar: so "einfach" wird das bei einer Blockchain mit begrenztem Platz nicht gehen. Erreicht ein Hub also eine bestimmte Größe (ab ca. Hunderttausenden Nutzern), wird er "too big to fail", da die Channels nicht mehr in einer angemessenen Zeit geschlossen werden können.

Deshalb, wie gesagt, ist LN für mich eine super Prepaidkarte für Micropayments, aber mehr nicht. Für größere Mengen würde ich Sidechains oder sogar Child-Chains (Sidechains mit vorübergehender Validierung durch Full-Nodes) bevorzugen.

^  mache sich besser jeder selber Schlau (ist besser mit vielem)  - es gibt bereits genügend Material hierzu.

 

Es gibt keine rechtliche Absicherung gegen Willkür und rechtswidrige Auffassungen. Aber erst mal muss die Bafin etwas Substanzielles in der Hand haben. Solange ich meinen Hub nicht auf einer deutschen Webseite als Finanzdienstleistung bewerbe, werden die wohl damit ihre Probleme haben.

Die Frage stellt sich, was eigene Interpretationen ohne rechtlich Grundlage in vorauseilendem Gehorsam (im Englischen nennt man es FUD) bringen. cui bono?


Und Wissen schützt nicht vor Willkür. Ist halt so, das Leben ist extrem gefährlich. Es endet immer tödlich.

Dein Kalliber kann sich evtl ein gute rechtliche Absicherung leisten - ich informiere hier die 'Kleinern'.


Unwissenheit schütz nicht vor Strafe.

Ich finde Kontrollknoten eher schlecht. Besser wäre in meinen Augen ein Konzept mit langen Laufzeiten, bei denen eine/mehrere Third Party Signatur(en) zum früheren Schliessen benötigt werden.

Jetzt halte ich es für sinnvoll, erst mal mit LN Erfahrung zu sammeln. Ausserdem sagt ja keiner, dass es in Zukunft nicht für verschiedene Anwendungsfälle unterschiedliche Second Layer Lösungen geben darf.

Zur Bafin: Zum Teufel damit, ausserdem ist meine unentgeltliche Weiterleitung für die Community noch lange keine Finanzdienstleistung.

Bitcoin ist nur als PoW mit enormen externen Langzeit (Hardware) / Kurzzeitinvestments (Strom) im freien Internet wirklich sicher. Es braucht ein ökonomisches Gleichgewicht / hohe Barriere für Angreifer das ganze SICHER am laufen zu lassen, ganz ähnlich, wie geschlossene System (Banken) mit hohen Kosten ihre Firewall / Cybersecurity bettreiben müssen - dieses Wissen ist leider nicht oft vorhanden.


Weiter bin ich als bekannter Big-Blocker ebenso an LN fundamental / sicherheitstechnisch / kundenschutzseitg interessiert, ich denke es gibt vernünftige Anwendungen, z.B. Netting von TRX bei immer denselben Gegenparteien wir z.B: HF Trading, Mirco-Payments für online content (Musik , Filme usw). Leider glaube ich nicht, dass es annähernd ausreicht, um die Skalierung zu lösen und es genügend Zeit gib (Horizont 2-3 Jahre, damit alles für Finanzsysteme sauber genug ist) , irgendetwas damit 'schnell' zu retten

Hier noch mein konstruktiven Input an alle Versuchskaninchen: Denkt an die Regularien als Payment Processor - dies ist BAFIN Gebiet und könnte manche recht schnell wieder auf den Boden bringen.

In der Schweiz sollte die FINMA relative gute Einstiegs-Regularien haben, das ist evtl hilfreicher als in D....

Naja aber im Artikel ist ja auch beschrieben, dass die Zeit beliebig verlängert werden kann. Das heißt wenn man es z.B. auf eine Woche festlegt sollte es für die meisten Leute locker möglich sein den Channel ausreichend zu prüfen. Einziger Nachteil wäre, dass die Funds im Channel eher unflexibel sind.


Außerden könnte ich mir vorstellen, dass es dafür in zukunft Services geben könnte, die deinen Channel für dich prüfen. Das wäre nur ein möglicher Lösungsansatz, aber ich glaube nicht, dass es durch den Online Zwang langfristig zu problemen kommen wird.


Ich denke da haben sich die Entwickler aktuell gegen entschieden, damit alles möglichst anonym abläuft. Im moment sind die LN-Transationen ja verschlüsselt und sind nur von den beiden Teilnehmern einzusehen. Deinen Ansatz mit den Kontrollknoten finde ich aber auch nicht schlecht. Vielleicht ja irgendwann

Naja, eigentlich versuch ich nur den Thread oben zu halten, damit der nicht so schnell verschwindet  . Heute kann ich aber keine Statistik machen, da der eine Link nicht funktioniert.

Das habe ich noch gefunden:

https://bitcoinblog.de/2018/01/24/die-lightning-faq-fuer-fortgeschrittene/

Was mir gerade am LN nicht so gefällt, ist die Sache mit dem Onlinebleibenmüssen, d.h. einen Channel am Laufen lassen bzw. ständiges Überprüfen, dass die Partei am anderen Ende eines Channels keinen Schindluder treibt (siehe auch der bitcoinblog.de-Artikel). Selbst wenn man Schindludertreiben bestraft, so kann man sicherlich Angriffe fahren, sodass man nicht rechtzeitig wieder online ist um das Schindluder zu entdecken. Warum hat man das nicht anders gelöst?

Z.B. könnte man beim Öffnen eines Channels mit einem Gegenknoten immer auch noch eine Anzahl von Kontrollknoten aus dem Netzwerk definieren, welche die Korrektheit der Channelbenutzung überwachen. Dann wäre es Wurst ob man online ist oder nicht. Diese Kontrollknoten müssten natürlich Einsicht in den Channel haben. Finde ich aber nicht so problematisch. Auch ein Angriff wäre kaum zu fahren, da man möglicherweise die Identität der Kontrollknoten geheimhalten kann. Ich denke aber, dass diese oder eine ähnliche Methode sehr leicht auf das LN-Protokoll draufgesetzt werden kann.

Danke, dass du das hier fest hältst. Es wäre noch spannend eine Statistik über die Anzahl der Transaktionen und Nutzer im Netzwerk zu sehen.

Heute: 162 Knoten im Mainnet mit 397 Channels und ca. 3 gebundenen BTC.

Was mir aufgefallen ist ist, dass auf https://explorer.acinq.co auch Knoten angezeigt werden, welche aktuell nicht online sind. D.h. dies kann auch ein Grund dafür sein dass ihr euch nicht mit einem Knoten verbinden könnt.

Die IP muss händisch in der eclair.conf ausgetauscht werden falls sich die IP über Nacht ändert und Eclair muss neu gestartet werden, damit sie auf oberer Seite korrket angezeigt wird. Das dauert dann ein Weilchen bis das upgedatet ist. Funktioniert aber.

Gestern waren es 97 Knoten im Mainnet.
Heute sind es 134 Knoten im Mainnet bei 312 Channels.
(https://lnmainnet.gaben.win/)

Und das Netzwerk bindet etwa 2.3 BTC.
https://p2sh.info/dashboard/db/lightning-network?orgId=1

Aktuell liegt die Wachstumsrate zwischen 10%-40% pro Tag. Unter der Annahme, dass das Netzwerk im Schnitt um 10% pro Tag wächst so hätten wir in 30 Tagen ca. 2300 Knoten.

Danke für die Links. Ich finde das auch ziemlich spannend.

Manche hier im Forum sind ja eher pessimistisch was die Annahme von Lightning angeht. Besonders, weil ja auch die Verbreitung von Segwit ziemlich schleppend voran geht. Meiner Meinung nach ist aber ein entscheidender Unterschied, dass ich als Nutzer bei der Nutzung von Segwit erstmal keinen Unterschied merke. Ich tue zwar etwas gutes fürs Netzwerk, aber gefühlt hat das kaum einen Einfluss.

Bei Lighting bin ich ab der ersten Transaktion so gut wie Kostenlos und um ein vielfaches schneller. Z.B. für Exchanges, die ein hohes Transaktionsvolumen haben, könnte das schon ein ausreichender Anreiz sein.

Meinst Du den Link von -doubleU-? Ich denke schon:

http://bitcoinist.com/lightning-network-happening-first-physical-item-purchased-ln/

Edit: Schon spannend, vor zwei Tagen waren es noch 29 Knoten (https://www.reddit.com/r/Bitcoin/comments/7rhuje/29_nodes_already_running_lightning_network_on/), in dem Artikel ist von 67 Knoten die Rede, heute morgen waren es etwas zwischen 80 und 90 Knoten, und jetzt sind es 97 Knoten. Bin mal gespannt wie sich das weiter entwickelt. Siehe auch

https://p2sh.info/dashboard/db/lightning-network?orgId=1

für den LN-Mainnet-Ausbau.

Super Sache, vielen Dank curiosity81!


Wie ist die mainnet Statistik zu interpretieren? Sind das hier tatsächliche Implementierungen des Lightning Systems?

Was ich heute rausgefunden habe (steht alles nun auch oben drin):

Damit sich jemand mit eurem Knoten verbinden kann muss Port 9735 geöffnet sein!

Oder anders ausgedrückt, wenn alle nur anrufen und keiner abnimmt, dann ist das Telefonnetz nutzlos! Soll heissen, wenn alle ihren Port 9735 schliessen, dann gibt es schlicht kein Lightning Netzwerk. Wenn nur ein paar Knoten Port 9735 offen haben, dann ergibt das ein zentralisiertes Netzwerk, weil dann alle anderen sich mit diesen Knoten verbinden müssen. Und am besten wäre es, wenn alle Port 9735 geöffnet haben.

Desweiteren, damit man euren Knoten auf https://explorer.acinq.co sehen kann, so muss in der eclair.conf in der Zeile


eure IP eingetrage sein. Natürlich muss Eclair danach neu gestartet werden.

Ein paar Phantasiekaffees (https://starblocks.acinq.co) habe ich mir heute auch gekauft. Wobei ich aber keine Transaktion mit mehr als einem Kaffee hinbekam. Ich bekam nämlich immer die Fehlermeldung: Route not found. Meine Channels enthalten aber alle genug Geld. Da muss wohl noch nachgebessert werden.

Sind ja bereits ein paar Nodes und Channels im Mainnet, tendenz steigend  - https://lnmainnet.gaben.win/

ja, das ist im Bitcoin testnet. mal aus anwendersicht mit screenshots dokumentiert.

Bitcoin testnet LN Online Wallet: https://htlc.me/

Coffee-to-go Shop: https://starblocks.acinq.co

Habe die Anleitung um eine Spieladresse erweitert:

https://starblocks.acinq.co

Dort kann man wohl mit dem LN bezahlen. Ich gehe davon aus, dass das auch das Testnetz ist 

Cool wäre, wenn einer von euch Mitlesern das nach exerzierte, sich auch mit dem Netzwerk verbände und wir uns ein paar Payments schickten. 

Ich muss sagen, wenn man die Installation gemeistert hat (Bitcoin Core, JRE1.8, Eclair und Konfiguration) und es geschafft hat, sich die Netzwerkinformationen aus dem Netzwerk (Henne-Ei-Problem) über https://explorer.acinq.co zu ziehen, so scheint Eclair, von dem was ich gesehen habe, ganz brauchbar zu sein . Sehr aufgeräumtes Menü, man kann praktisch nichts verkehrt machen.

Danke Gyrsur, bookmarked.

Related: Im Bitcoinblog-Artikel habe ich was drüber gelesen, dass die Entwickler "noch Geld verlieren" würden mit ihren LN-Experimenten im Mainnet.

Weiß jemand Näheres? Mich würden nämlich Angriffsszenarien - kein FUD wie auf /r/BTC! - interessieren. Sind das alles Fälle, in denen der Payment Channel-Status zurückgesetzt wurde?

statistik vom mainnet:

https://p2sh.info/dashboard/db/lightning-network

So, habe das soweit zum Laufen bekommen, dass man das LN in Eclair zu sehen bekommt. An Payment-Channels habe ich mich noch nicht rangetraut.

Ich bin auch dabei Ich folge der "schwierigen" Anleitung von curiosity81. Bin aber noch ganz am Anfang.

Persönlich denke ich, dass Lightning dann Erfolg haben wird, wenn die Exchanges es unterstützen und gebührenfreie Auszahlungen über LN anbieten. Denn dann hätte man einen ganz einfachen Weg seine Channels aufzuladen, und vielleicht kommen die Exchanges sogar für die Transaktionsgebühr auf (Kundenbindung, hehe). Wenn alles gut läuft, wird das Konzept dadurch populär. Es wäre dann erst mal ein zentralisierteres Netzwerk, aber die Dezentralisierung kann danach ja noch kommen, wenn LN-Atomic Swaps usw. kommen.

Hallo,

tolle Idee eine vernünftige Anleitung für Lightning zu erstellen! Auch ich versuche gerade mit dem Lightning-Netzwerk zu spielen und es gibt noch einen einfachere Möglichkeit einen Node aufzusetzen:

http://dev.lightning.community/guides/docker/

Im Wesentliches ist es, dass Git-Repository unter https://github.com/lightningnetwork/lnd zu klonen:


und dann den Instruktionen aus dem Guide zu folgen. Achtung: das Beispiel dort läuft auf dem vereinfachten simnet. Um auch auf dem testnet bzw. mainnet mitmischen zu können, muss die Umgebungsvariable am Anfang entsprechend gesetzt bzw. weggelassen werden.

Aus dem gleichen Grund, aus dem Du heute nicht mit Deinem MarkupEthernet Client hier im Forum bist. Deshalb hat man für das Routing IP auf Ethernet aufgesetzt und versucht nicht, Ethernet im weltweiten Internet skalierbar zu machen. Danach hat man TCP auf IP aufgesetzt um eine Sicherungsschicht zu bekommen. Danach hat man HTTP auf TCP aufgesetzt, um Information mit Markup zu übertragen. Niemand kommt auf die Idee, Ethernet, IP und TCP zu verwerfen, sobald er HTTP benötigt.

Genausowenig kommt niemand auf die Idee, ein Geldsystem zu verwerfen, sobald neue Anforderungen dazukommen oder das System in grösserem Massstab skalieren soll. Im übrigen gibt es auch gar kein Konkurrenzsystem, welches Funktionalität und Sicherheit und Freiheit von der Enstehung an und Zukunftssicherheit im Grundsystem für die absehbaren Anwendungsfälle sicherstellt. Sprich, es gibt kein fundamental besseres Geldsystem.

Du kannst ja einen parallelen Thread aufmachen:

"Lightning Netzwerk - lightning-cli: Aufsetzen eines LN-Knoten im Test- und Hauptnetz"

Und dort eine Anleitung posten. Je mehr Anleitungen desto besser! Kann sich dann jeder raussuchen was ihm besser gefällt.

Super Idee. Ich habe mich in den letzten zwei Tagen mit c-lightning beschäftigt und einen Node im Testnet und Mainnet () laufen und die ersten Channels aufgesetzt. Gerne beteilige ich mich hier und gebe meine Erfahrungen weiter.
Die Dokumentation zu lightning-cli ist leider noch sehr spärlich, das war die größte Schwierigkeit beim Aufsetzen, so viel sei gesagt. Am Wochenende geht's weiter, eventuell mit einem ausführlicheren Post zur Installation.

Noch ein paar News:

https://bitcoinblog.de/2018/01/18/die-ersten-lightning-transaktionen-auf-dem-echten-bitcoin-netz/

Super. Das freut mich. Wir können das ja zum offiziellen LN-Thread machen.

Es wäre nämlich schön wenn wir ein paar Knoten auf die Beine stellen könnten. Ich hoffe, dass die Idee von Eclair ist, ein stabiles LN-Subnetzwerk im Testnetz aufzustellen, welches dem Protokoll folgt. Und wenn es soweit ist, man nur noch in der bitcoin.conf auf das Hauptnetz umstellen muss. Vorausgesetzt man hat die Hauptblockchain.

Aber wie gesagt, ich mache erst heute Abend weiter. Wer Lust und Muse hat kann ja da ergänzen wo ich aufgehört habe, ansonsten müsst ihr warten.

danke! ich bin dabei! 

Hallo,

ich probiere mich gerade im Lightning Netzwerk aus und will das hier dokumentieren. Auch, weil es zum LN nichts online gibt was selbst für erfahrene Computernutzer ohne Weiteres zu bewältigen wäre. Wenn schon die Installation von Eclair kaum hinzubekommen ist, dann ist vollkommen klar, dass das LN nicht aus den Puschen kommt. Deshalb diese Anleitung um die Einstiegshürden zu überwinden. Diesen Text werde ich nach und nach erweitern. Mein Ausganspunkt ist hierbei dieser Beitrag:

https://medium.com/@ajs1287/setting-up-bitcoin-lightning-network-node-on-macos-is-peanuts-eclair-5afbef553d71

D.h., wenn ich mit meiner Anleitung noch nicht fertig bin und ihr weiterspielen wollt, dann halten euch an obigen Beitrag.

---

Sonstige Referenzen

Lightning Network Megathread:

https://www.reddit.com/r/Bitcoin/comments/7pwna9/lightning_network_megathread/

Frage zu Eclair lassen sich mit Github-Account am besten hier beantworten:

https://gitter.im/ACINQ/eclair

---

Voraussetzungen

• Ein Rechner mit genug Leistung und 64bit, läuft natürlich analog auch für ein 32bit System, sind dann aber andere Dateien
• Ubuntu 16.04 LTS (http://de.releases.ubuntu.com/16.04.3/), geht aber bestimmt auch mit einer anderen Version
• Der Rechner sollte eigenständig, Betriebssystem frisch installiert und getrennt von wichtigen Daten sein
• Erfahrung mit Linux, Netzwerk etc. pp.
• Eine zügige Netzwerkverbindung
• Etwa 2h Zeit da mindestens 2 Bitcoin Transaktionen durchgeführt werden

• Der Nutzer hier ist "curiosity81", der muss entsprechend angepasst werden
• Platzhalter sind z.B. "" und müssen entsprechend ersetzt werden

---

Zu Beginn gehen wir in den Download-Ordner (den gibt es bei Ubuntu standardmäßig):

---

Bitcoin Core (vor Synchronisierung)

Und laden Bitcoin Core (https://bitcoin.org/en/download) herunter:


Zusätzlich besorgen wir uns die Signatur von van der Laan:


Wir importieren den Schlüssel:


Zu guter Letzt besorgen wir uns die Hashsummen der Dateien:


Nun verifizieren wir Bitcoin Core bevor wir es entpacken:


Die lange Hex-Zahl stammt aus SHA256SUM.asc und entspricht der Hashsumme der runtergeladenen Datei. Wenn grep ein Ergebnis ausgibt, dann ist alles ok. Gibt bestimmt elegantere Lösungen das zu prüfen als meine.

Jetzt entpacken wir Bitcoin Core:


Und passen die Bitcoin Konfigurationsdatei an:


Wir füllen die Datei folgendermaßen:


Die Platzhalter und müssen mit einem entsprechenden Werten ersetzt werden. Wir speichern und verlassen nano mit Strg+X.

Nun können wir Bitcoin Core starten:

Code:

/home/curiosity81/Downloads/bitcoin-0.15.1/bin/bitcoin-qt

Bitcoin Core wird sich nun mit dem Testnetz synchronisieren. Das dauert ein Weilchen, aber nicht solange wie im Hauptnetz. Bei mir waren das ca. 1.5h.

---

JRE 1.8

Nun müssen wir das Java Runtime Environment von Oracle installieren, damit Eclair auch läuft. Wir gehen also den Weg des geringsten Widerstands. Fragt mich aber nicht zu den Lizenzen und was sich Eclair dabei gedacht hat Oracle zu nutzen. Dies hier ist nur eine Anleitung. Jeder installiert also auf eigene Entscheidung hin dieses Oracle-Produkt.

Wir gehen zu Beginn per Browser (Firefox) auf http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html. Dort wählen wir

jre-8u162-linux-x64.tar.gz

aus, bestätigen das License Agreement und beginnen den Download. Die Datei landet in unserem Download-Ordner. Da Bitcoin Core wahrscheinlich noch synchronisiert so öffenen wir ein neues Terminal und gehen wieder in den Download-Ordner:

Code:

cd /home/curiosity81/Downloads

Dann verifizieren wir die Hashsumme der runtergeladenen Datei. Dazu klicken wir oben auf der Oracle Seite (http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html) bei

JRE 8u162 Checksum

auf "Checksum" und merken uns den sha256-Wert für die entsprechende Datei:

dfa25ebd1f90bf74ad7ba2dacb0e08d884594e733c9a522b58256778031341a4

Jetzt testen wir den Hash:

Code:

sha256sum jre-8u162-linux-x64.tar.gz | grep -o dfa25ebd1f90bf74ad7ba2dacb0e08d884594e733c9a522b58256778031341a4

Wenn alles ok ist so entpacken wir die Datei:

Code:

tar -xzfv jre-8u162-linux-x64.tar.gz

Und installieren java (https://wiki.ubuntuusers.de/Java/Installation/Oracle_Java/Java_8/):

Code:

sudo mkdir /opt/Oracle_Java
sudo cp jre1.8.0_162/ /opt/Oracle_Java/ -R
sudo update-alternatives --install "/usr/bin/java" "java" "/opt/Oracle_Java/jre1.8.0_162/bin/java" 1
sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/opt/Oracle_Java/jre1.8.0_162/bin/javaws" 1
sudo update-alternatives --set "java" "/opt/Oracle_Java/jre1.8.0_162/bin/java"
sudo update-alternatives --set "javaws" "/opt/Oracle_Java/jre1.8.0_162/bin/javaws"
java -version

Wenn das letzte Kommando die Version wie folgt ausgibt:

Code:

java version "1.8.0_162"
Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)

So haben wir auch diesen Schritt bewältigt. Weiter geht's.

---

Eclair

Wir sind immer noch im Download-Ordner, im zweiten Terminal. Nun besorgen wir uns Eclair (https://github.com/ACINQ/eclair). Wir sind immer noch faul und wollen das nicht selbst kompilieren oder bauen. So werden wir uns mit dem jar begnügen (https://github.com/ACINQ/eclair/releases):

Code:

wget https://github.com/ACINQ/eclair/releases/download/v0.2-alpha8/eclair-node-gui-0.2-alpha8-8edb2a4.jar

Das war es auch schon. Hier gibt es leider nichts zu verifizieren. Wir wollen aber auch nur im Testnetz spielen. Wir müssen also das Risiko eingehen. Wichtig: Damit Eclair korrekt läuft muss Bitcoin Core nebenher laufen! Nach:

Code:

java -jar eclair-node-gui-0.2-alpha8-8edb2a4.jar

Sollte sich dann auch schon was tun, auch wenn das Programm noch nicht konfiguriert ist und deshalb mit Fehlermeldung beendet.

---

Bitcoin Core (nach Synchronisierung)

In der GUI:

Help -> Debug window -> Console

Dort:

Code:

getnewaddress

Die Adresse, in meinem Fall:

mtDmzMz7NvuRjptrLWwbdVBs4j7Y3eXvCV

merken wir uns. Dann

Code:

addwitnessaddress mtDmzMz7NvuRjptrLWwbdVBs4j7Y3eXvCV

Erzeugt Segwit-Adresse, in meinem Fall:

2MswDJ1kf9aqiC6twrDyUbLqGmtnjtFG4XX

Auch diese merken wir uns.

Nun besorgen wir uns Geld auf:

https://testnet.manu.backend.hamburg/faucet

Indem wir unsere Segwit-Adresse dort angeben. Ich bekam z.B. 1.3 BTC auf 2MswDJ1kf9aqiC6twrDyUbLqGmtnjtFG4XX geschickt . Natürlich dauert es hier ca. 1h bis die Transaktion 6x bestätigt und somit nutzbar ist.

---

Eclair Konfiguration

Wir gehen zu Beginn wieder in den Download-Order

Code:

cd /home/curiosity81/Downloads

Falls der Konfigurationsordner von Eclair noch nicht existiert so erzeugen wir ihn:

Code:

mkdir /home/curiosity81/.eclair

Dann editieren wir die eclair.conf:

Code:

nano /home/curiosity81/.eclair/eclair.conf

Und füllen die Datei wie folgt:

Code:

eclair.server.port=9735
eclair.node-alias="curiosity81"
eclair.node-color="9716b7"
eclair.bitcoind.rpcuser=""
eclair.bitcoind.rpcpassword=""
eclair.bitcoind.zmq="tcp://127.0.0.1:29000"
eclair.server.public-ips=["xx.xx.xx.xx"]

Für und nutzen wir die Werte, welche wir auch in der bitcoin.conf nutzen. Strg+X speichert die Datei und beendet nano. Damit man später den eigenen Knoten mit den entsprechenden Information auf https://explorer.acinq.co zu sehen bekommt (siehe auch weiter unten), so muss bei eclair.server.public-ips die eigenen IP eingetragen werden. Nur so können sich andere Teilnehmer im Netzwerk mit dem eigenen Knoten verbinden. Wie das abläuft, wenn sich Nachts die ip ändert ... das weiss ich auch nicht. Möglicherweise muss man dann erst den Knoten stoppen, per Skript die Konfiguration entsprechend ändern, und dann den Knoten wieder hochfahren. Das ist aber nur eine Vermutung. Man kann aber, um Testzahlungen durchzuführen, auch "xx.xx.xx.xx" stehen lassen.

Jetzt versuchen wir erneut Eclair zu starten:

Code:

java -jar eclair-node-gui-0.2-alpha8-8edb2a4.jar

Und tada, die Eclair-GUI öffnet sich.  

---

Verbindung mit dem Lightning Netzwerk

Wir öffnen im Browser folgende Adresse:

https://explorer.acinq.co

Und suchen uns dort einen Knoten im rechten Scrolldownmenü aus (also nicht in der Karte sondern rechts davon) mit welchem wir uns verbinden können. Wenn man einen Knoten anklickt, dann sieht man weitere Infos wie Alias, Publickey und IP. Für den Anfang begnügen wir uns mit den Knoten, welche eine IP anzeigen. Ich habe mir einen Knoten rausgesucht, der den Alias "pikefloyd" hat. Dessen Daten sind wie folgt, werden sich aber wohl mit der Zeit ändern oder der Knoten verschwindet ganz, seid also flexibel:

Code:

Alias:         pikefloyd
Publickey:     03c4b20397d476a0d008e61022c96803ada3c11918fff8133db4f7d27273710e03
IP und Port:   81.149.149.156:9735

Daraus bauen wir uns folgende ID aus dem Publickey, IP und Port zusammen:

Code:

03c4b20397d476a0d008e61022c96803ada3c11918fff8133db4f7d27273710e03@81.149.149.156:9735

In der Eclair-GUI wählen wir: Channels -> Open channel ...

Dort, bei "Target Node URI", kopieren wir obere ID rein. Zusätzlich klicken wir noch "Simple connection (no channel)" an und drücken "Connect". Nach etwas warten sollte sich die GUI mit Infos zu Channels und Nodes füllen. Wenn ihr eure Bitcoin Core Testnetzwallet wie oben beschrieben mit Faucetcoins gefüllt habt so sind nun auch sicherlich Payment-Channels möglich.

---

Öffnen eines Payment-Channels

Wie im vorherigen Schritt suchen wir uns einen Knoten im Lightning Netzwerk aus und geben die ID bei "Target Node URI" ein. Heute habe ich mir einen anderen Knoten ausgesucht. Diesmal klicken wir aber NICHT "Simple connection (no channel)" an! Zusätzlich wählen wir eine Bitcoin Betrag aus und geben diesen im Feld "Capacity" ein. Der Betrag muss natürlich kleiner/gleich dem Betrag auf eurer Bitcoin Core Testwallet sein. Ich habe dort mal 100 milliBTC eingegeben. Dann auf "Connect" drücken. Sofort sollte in Bitcoin Core die Meldung einer Transaktion von 0.1 BTC + Transaktiongebühr aufpoppen. Ihr habt also nun 2 Transaktionen in eurer Testwallet. Eine Eingehende von der Faucet und eine Ausgehende um den Channel zu öffnen. Nach dem Drücken von "Connect" handelt Eclair mit dem Channel-Partner etwas aus. Dann sollte in Eclair, bei den "Local Channels" bei "STATE" stehen:

Code:

WAIT_FOR_FUNDING_CONFIRMED

Jetzt heisst es etwa eine halbe Stunde zu warten, also 3 Bitcoin-Bestätigungen bis der Channel geöffnet ist. Bei Eclair scheinen nämlich 3 Bestätigungen auszureichen. Solange ist auch euer Knoten noch nicht sichtbar, siehe auch https://explorer.acinq.co/#/faq. Dann sollte in Eclair, bei den "Local Channels" bei "STATE" stehen

Code:

NORMAL

Sehen kann ich meinen Knoten auch nach 6 Bestätigungen nicht, liegt wahrscheinlich an den geschlossenen Ports. Ansonsten hat bisher alles fehlerfrei funktioniert.

---

Mit Lightning Netzwerk bezahlen

Wenn ich mich richtig entsinne, muss einer von den Beiden, der Bezahlende oder der Zubezahlende, dem anderen ein Geheimnis direkt, also nicht über das Lightning Netzwerk, schicken. Fragt mich jetzt nicht wie das genau geht, das war irgendwas mit einer Zufallszahl und deren Hash, welche/r dann durch das Netzwerk propagiert wird und ich habe die Details vergessen (ungefähr bei 9:00 in https://www.youtube.com/watch?v=wIhAmTqXhZQ). D.h. also, dass es sowas wie öffentliche Adressen in einer Blockchain nicht mehr gibt, der Zubezahlende muss einen Zahlungsaufruf generieren, den er dann dem Bezahlenden zu kommen lässt (https://medium.com/@btc_coach/lightning-network-in-action-b18a035c955d). So mein momentanes Verständnis. Ich könnte aber auch falsch liegen. Also korrigiert mich wenn nötig.

Um einen Zahlungsaufruf zu erzeugen geht man in Eclair wie folgt vor: Channels -> Receive Payment. Dort bei "Optional amount to receive" gibt man einen validen Betrag ein (oder auch nicht, ist ja optional) und drückt auf "Generate". Das Ergebnis muss man wohl seinem Gegenüber zukommen lassen.

Hier kann man wohl Phantasiekaffee kaufen:

https://starblocks.acinq.co

 

---

Port forwarding und Ähnliches

Gefunden habe ich auf https://explorer.acinq.co/#/faq folgendes dazu, siehe den letzten Punkt:

Quote

I cannot connect to a node listed in the explorer.

Connection can fail due to one of the following reasons:

    The node is currently offline right now (any channels it might have are temporarily unavailable but stay open).
    The node does not announce a public IP.
    The public IP announced by the node is not accurate.
    The node is not reachable (misconfiguration in port forwarding, firewall...).
    ...

Bis jetzt hat alles ohne Portforwarding funktioniert. Und raustelefonieren d.h. schlichtes Bezahlen wird auch immer so funktionieren, auch mit geschlossenem Port 9735. Wenn aber euer Port 9735 geschlossen ist und die entsprechenden Pakete nicht an den entsprechenden Computer weitergeleitet werden (Portforwarding), dann bekommt derjenige, der sich mit euch verbinden will, eine Fehlermeldung, obwohl euer Knote wie ein ganz normaler aussieht. Aktuell kann man nämlich nicht unterscheiden, welche Knoten einen offenen Port 9735 haben und bei welchen dieser geschlossen ist. D.h. es wird passieren, dass auch ihr euch mit manchen Knoten nicht verbinden könnt, da diese Port 9735 geschlossen haben. Also nochmal:

Damit sich jemand mit eurem Knoten verbinden kann muss Port 9735 geöffnet sein!

Oder anders ausgedrückt, wenn alle nur anrufen und keiner abnimmt, dann ist das Telefonnetz nutzlos! Soll heissen, wenn alle ihren Port 9735 schliessen, dann gibt es schlicht kein Lightning Netzwerk. Wenn nur ein paar Knoten Port 9735 offen haben, dann ergibt das ein zentralisiertes Netzwerk, weil dann alle anderen sich mit diesen Knoten verbinden müssen. Und am besten wäre es, wenn alle Port 9735 geöffnet haben.