Hier gibt es an der Wallet auch Kritikpunkte – insbesondere hinsichtlich der Verwahrung der privaten Schlüssel, der Zentralisierung und der hohen Gebühren für den Empfang von Zahlungen. In diesem Bericht gehen wir detailliert auf die Funktionsweise, Sicherheit, Gebührenstruktur und Alternativen ein, um eine umfassende Einschätzung der Wallet of Satoshi zu geben.

Was ist die Wallet of Satoshi

Die Wallet of Satoshi ist eine mobile App, die für iOS und Android verfügbar ist. Sie ermöglicht es, Bitcoin über das Lightning Network zu senden und zu empfangen, ohne sich um technische Details wie Kanäle, Liquidität oder Routing kümmern zu müssen. Die Wallet ist custodial, was bedeutet, dass der Anbieter die privaten Schlüssel für den Nutzer verwaltet.

Hauptmerkmale der Wallet of Satoshi

• Extrem einfache Bedienung: Perfekt für Anfänger, da kein technisches Wissen erforderlich ist.
• Lightning- und On-Chain-Zahlungen: Unterstützt sowohl das Lightning Network als auch klassische Bitcoin-Transaktionen.
• Sofortige Nutzung ohne Backup: Kein Seed-Wiederherstellungssatz oder komplizierte Einrichtung notwendig.
• Bezahlen per QR-Code und LNURL: Einfacher Empfang und Versand von Zahlungen.
• Fiat-Kaufmöglichkeit: Nutzer können Bitcoin direkt per Kreditkarte oder Banküberweisung erwerben.
• Gute Integration mit Lightning-fähigen Diensten: Unterstützt Lightning-Zahlungen für Spenden, Trinkgelder oder E-Commerce.
• Zentralisierte Verwahrung der Coins: Die Wallet ist custodial – Nutzer haben keinen Zugriff auf ihre privaten Schlüssel.
• Sehr sehr hohe Onchaingebühren - Achtung, das versenden von Onchain Sats ist mit der WalletofSatoshi sehr teuer, die Grundgebühr beträgt 1%, dazu kommt beim versenden noch ein Fixbetrag dazu.

Custodial vs. Non-Custodial – Was bedeutet das

Ein wesentlicher Aspekt der Wallet of Satoshi ist, dass es sich um eine custodial Wallet handelt. Das bedeutet, dass der Anbieter die privaten Schlüssel verwahrt und nicht der Nutzer selbst.

Vorteile von Custodial Wallets

• Kein Risiko, den Seed zu verlieren: Da der Anbieter die Schlüssel speichert, kann ein Nutzer seine Wallet nicht durch den Verlust einer Seed-Phrase verlieren.
• Einfachste Nutzung: Die Wallet funktioniert direkt nach der Installation, ohne dass der Nutzer Kanäle verwalten oder eine Back-up-Strategie entwickeln muss.
• Kein technisches Wissen erforderlich: Im Gegensatz zu Non-Custodial Wallets muss sich der Nutzer nicht um das Routing oder die Verwaltung von Liquidität kümmern.

Nachteile und Risiken von Custodial Wallets

• Kein Zugriff auf Private Keys: „Not your keys, not your coins“ – wer die privaten Schlüssel nicht selbst besitzt, hat keine vollständige Kontrolle über seine Bitcoin.
• Zensur-Risiko: Der Anbieter kann Transaktionen blockieren oder Konten sperren.
• Regulatorische Abhängigkeit: Da WoS eine zentrale Plattform ist, könnte sie durch regulatorische Vorgaben gezwungen werden, KYC-Daten zu verlangen oder Nutzern aus bestimmten Ländern den Zugang zu verweigern.
• Anfällig für Hacks oder Geschäftsaufgabe: Sollte der Betreiber gehackt werden oder insolvent gehen, könnten alle Coins der Nutzer verloren sein.

Alternative: Non-Custodial Lightning Wallets

Für Nutzer, die volle Kontrolle über ihre Coins behalten möchten, gibt es Non-Custodial Alternativen, wie z. B.:

• Phoenix Wallet – Perfekte Mischung aus Benutzerfreundlichkeit und Selbstverwaltung.
• Zeus Wallet – Für Node-Betreiber mit Fokus auf maximale Kontrolle.
• Breez Wallet – Guter Kompromiss zwischen Einfachheit und Dezentralität.

Gebühren und Kosten

Ein positiver Aspekt der Wallet of Satoshi ist, dass sie keine eigenen Gebühren für das Senden oder Empfangen von Lightning-Zahlungen erhebt. Es fallen lediglich die üblichen Routing-Gebühren des Lightning-Netzwerks an, die jedoch von den beteiligten Nodes und nicht von Wallet of Satoshi selbst erhoben werden.

Gebührenstruktur

💡 Zusammenfassung: Für Lightning-Transaktionen ist Wallet of Satoshi gebührenfrei, allerdings können bei On-Chain-Transaktionen und Fiat-Käufen Gebühren durch externe Anbieter entstehen.

Benutzerfreundlichkeit & Features

Die Wallet of Satoshi bietet eine der intuitivsten und einfachsten Benutzeroberflächen, die es im Bitcoin-Space gibt.

Positives

• Einfache Installation & sofortige Nutzung ohne Anemeldung
• Übersichtliches Design, verständlich für Einsteiger
• Gute Integration von Lightning & QR-Code-Zahlungen
• Kein Backup oder technisches Setup notwendig
• Email Adresse reicht, um euren Account wiederherzustellen

Negatives

• Kein Zugriff auf eigene Private Keys
• Nur eingeschränkte Funktionen für fortgeschrittene Nutzer
• Keine Möglichkeit, Lightning-Kanäle selbst zu verwalten
• Sehr hohe Onchain Gebühren!!

Anwendung der Wallet of Satoshi

Die Anwendung der Wallet of Satoshi ist komplett simple. Ihr braucht euch nicht einmal irgendwo anmelden. Es muss kein Push Dienst wie bei Phoenix laufen, die Wallet funktioniert also auf Phones ohne G-Play und ihr bekommt eine zufällig generierte Lightning Adresse zugewiesen.

Empfangen von Sats Onchain und Offchain

Lightning Sats empfangen

Das Empfangen geht relativ einfach. Ihr geht links unten auf den Button Empfangen, wählt dann Betrag / Notiz aus, und erstellt hier eine Rechnung/Invoice über einen Betrag den ihr festlegt. Ausserdem könnt ihr dem Empfänger eine Rechnungsnotiz hinterlassen, damit er weiss, wofür die Invoice ist. Diese Invoice sendet ihr dann einfach an den Empfänger. Dieser scannt die Invoice mit seiner App, und begleicht somit die Rechnung. Ihr erhaltet die Sats direkt auf eure Wallet.

Eigene Lightning Adresse

Unter der Option erhaltet ihr auch eine automatisch generierte Lightning Adresse. Anstatt eine Invoice zu kreieren, könnt ihr diese Adresse auch an euren Partner schicken. Mit einer LNURL kompatiblen Wallet, kann euer Gegenüber dann einfach Sats an diese Adresse schicken. Hier muss vorher kein Betrag festgelegt werden!

Onchain Sats empfangen

Wollt ihr Onchain Sats empfangen, dann klickt ihr einfach auf das Bitcoin Symbol, und ihr erhaltet eine BTC Adresse, die ihr eurem Partner schicken könnt.

Achtung, vom Betrag den ihr erhaltet, werden euch 1% Gebühren abgezogen!

Versenden von Sats Onchain und Offchain

Das Versenden von Sats ist quasi noch einfacher. Ihr geht wieder auf den Main Screen, und wählt einfach unten Senden. Nun könnt ihr mit dem QR Scanner einen QR Code abscannen. Ausserdem habt ihr mit den Buttons unten die Möglichkeit die Adresse manuell einzugeben, aus der Zwischenablagen einzufügen, oder aus einem Screenshot zu entnehmen.

Die App erkennt automatisch ob es sich um eine Onchain Adresse, oder eine Lightning Invoice handelt.

Onchain Sats zu erhalten kostet bei der WalletofSatoshi relativ viel, euch werden 1% plus ein fixer Betrag in Sats abgezogen. Achtet also auf die Gebühren! Das kann bei grösseren Beträgen schnell sehr teuer werden!

Handelt es sich um eine Lightning Invoice, so wird euch der zu bezahlende Betrag anzeigt, und auch eine Beschreibung, für was ihr da bezahlt. Mit senden gebt ihr die Invoice frei, und der Betrag wird dem Empfänger praktisch sofort zugestellt.

Einstellungen und weitere Optionen der Wallet of Satoshi

Ihr habt die Möglichkeit, direkt über die WalletofSatoshi Bitcoin zu kaufen, oder zu Verkaufen. Das geht direkt über die Einstellungen. Allerdings sei hier gesagt, dass der Anbieteter MoonPay KYC verlangt, ihr euch also einen Account anlegen müsst, und eure Personaldaten hinterlegen müsst. Anti-KYC Nutzer werden hier also keine Freude haben.

Desweiteren könnt ihr in den Einstellungen die Sprache ändern, die Standardwährung festlegen, und auch Hädnler finden die BTC akzeptierten über die Opensource Map BTCMap. Unter Kontakte könnt ihr User hinzufügen, die eine Lightning Adresse besitzen.

In den erweiterten Einstellungen gibt es weniger interessantes zu sehen:

Ihr könnt den Betrag in BTC oder Sats anzeigen lassen, und auch festlegen dass euer PIN oder euer Fingerabdruck gefordert wird, wenn ihr Rechnungen bezahlt.

LNURL-Auth Login

Die Wallet hat auch die Möglichkeit, dass ihr euch über euren WalletofSatoshi Account auf Seiten mit LNURL-Auth Login einloggen könnt. Dazu geht ihr einfach auf den Senden Button, und scannt den LNURL-Auth QR Code ab, und ihr seid auf der jeweiligen Seite eingeloggt.

Ist die Wallet of Satoshi sicher

Die Sicherheit einer Wallet hängt davon ab, ob der Nutzer oder der Anbieter die Kontrolle über die Coins hat, Schlüssel wir also etwas auf, ob die Wallet sicher ist, oder nicht:

🔒 Technisch sicher: Die Wallet nutzt eine verschlüsselte Infrastruktur und Lightning-Zahlungen sind kryptografisch abgesichert.
❌ Nicht sicher aus Sicht der Verwahrung: Da es eine custodial Wallet ist, verliert der Nutzer seine Coins, falls der Anbieter gehackt wird oder den Dienst einstellt.
⚠ Kein Open-Source-Code: Im Gegensatz zu vielen anderen Bitcoin-Wallets ist WoS nicht Open Source, sodass der Code nicht unabhängig überprüft werden kann.

Wie lade ich Sats auf meine Wallet

Wie bereits erwähnt, verfügt die App über die Moon Integration die es euch erlaubt, Sats zu über die App zu kaufen und direkt auf die Wallet zu laden. Moon erfordert aber Full-KYC und hat dazu noch relativ hohe Gebühren von 2-3%. Wem das KYC nicht stört, kann deutlich günstiger an Börsen wie Binancen, Kraken, Bitpanda und Co für 0.01% kaufen, oder man nimmt Boltz als komplett KYC freie Option, oder Pocketbitcoin.com als Light-KYC Variante. Dazu haben wir einen eigenen Beitrag geschrieben. Schaut dazu am besten mal hier vorbei!

Sollte man Wallet of Satoshi nutzen

Das hängt von euren eigenen Präferenzen, und eurem Risiko-Management ab, hier dazu einige Gedanken:

Für wen ist Wallet of Satoshi geeignet

✅ Ideal für Einsteiger, die Lightning ausprobieren wollen.
✅ Geeignet für spontane Zahlungen, Trinkgelder und kleinere Beträge.
✅ Praktisch für temporäre Nutzung, aber keine langfristige Lösung, vor allem nicht für höhere Beträge.

Wer sollte Wallet of Satoshi meiden

❌ Nutzer, die ihre Coins selbst verwalten wollen („Not your keys, not your coins“).
❌ Personen, die eine langfristige und sichere Bitcoin-Lösung suchen.
❌ Nutzer die nur OpenSource Software verwenden wollen.

Empfohlene Alternativen

• Phoenix Wallet (Non-Custodial, einfach, geringe Gebühren)
• Zeus Wallet (Für erfahrene Nutzer mit eigener Lightning Node oder Non-Custodial mit einer embedded LND Node in der App)
• Breez Wallet (Guter Mittelweg zwischen Einfachheit & Kontrolle)
• Bitbanana: sehr gute Wallet um die eigene Node zu verwalten.

Zusammenfassung

Die Wallet of Satoshi ist eine gute Anfänger-Wallet, aber langfristig nicht empfehlenswert. Wer sich mit Bitcoin beschäftigt, sollte Non-Custodial Alternativen nutzen, um volle Kontrolle über seine Coins zu behalten. Ausserdem ist die Wallet nicht Opensource.

The post Lightning ohne Full Node mit der Wallet of Satoshi appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

In diesem Beitrag stellen wir euch die verschiedenen LNURL-Funktionen genauer vor. Unser Ziel ist es, euch die vielseitigen Einsatzmöglichkeiten zu zeigen und euch zu inspirieren, wie ihr LNURL in eurem Alltag oder sogar in euren eigenen Projekten nutzen könnt.

Was kann LNURL?

Mit LNURL stehen euch praktische Funktionen zur Verfügung, die das Lightning-Erlebnis bereichern, darunter:

• LNURL-withdraw: Zahlungen empfangen, indem ihr Geld von einem Dienst abhebt.
• LNURL-auth: Einfaches Anmelden und Einloggen bei externen Diensten.
• LNURL-pay: Bezahlungen durchführen, ohne dass eine Rechnung erstellt werden muss.
• Lightning-Adresse: Zahlungen so einfach senden wie das Schreiben einer E-Mail.
• LNURL-Channel: Sich mit einem eingehenden Lightning-Channel verbinden.

Warum LNURL nutzen?

LNURL macht den Austausch zwischen Zahlern und Zahlungsempfängern unkomplizierter und intuitiver. Die Bedienung ist so einfach, dass man nur einen QR-Code scannen muss – vorausgesetzt, die eigene Wallet unterstützt LNURL.

Wie funktioniert LNURL?

Ein Dienstanbieter erstellt eine speziell formatierte Anfrage (bech32-codiert), die über einen QR-Code an den Nutzer übermittelt wird. Dieser QR-Code enthält alle notwendigen Informationen, damit eure Lightning-Wallet direkt mit dem Dienst kommunizieren kann. Einmal gescannt, wird die gewünschte Funktion ausgeführt – schnell, sicher und ohne technisches Fachwissen.

LNURL Withdraw

Um eine Lightning-Zahlung zu erhalten, erstellt der Zahlungsempfänger eine Rechnung (Invoice) mit Betrag und Verwendungszweck, die an den Zahler übermittelt wird. Mit LNURL kann dieser Prozess nutzerfreundlicher gestaltet werden, indem der Zahlungspflichtige selbst die Zahlungsanforderung initiiert.

Anwendungsfälle für LNURL Withdraw

• Abheben von Guthaben aus einer Wallet, z. B. zur Übertragung auf eine andere Wallet.
• Auszahlung von verdientem Guthaben, z. B. durch Aktivitäten oder Affiliate-Programme.
• Nutzung auf Börsen oder Gaming-Seiten.

Ihr scannt einen QR-Code mit einer LNURL-kompatiblen Wallet, und der Betrag wird direkt gutgeschrieben.

Beispiel: Pocketbitcoin.com

Pocket bietet LNURL Withdraw an, um gekaufte Sats über Lightning direkt auf eure Wallet zu übertragen. Einfach den QR-Code mit der Receive-Funktion scannen, und die Sats werden euch auf eure Lightning Wallet oder Node gutgeschrieben.

LNURL-Auth

Mit Hilfe von LNURL-Auth lassen sich Autorisierungen, Registrierungen oder Anmeldungen bei externen Diensten und Webseiten vornehmen. Der Vorteil für den Anwender ist es, dass keine persönlichen Informationen preisgegeben werden müssen. Bei satoshiskleinanzeigen.space kann man sich beispielsweise mit LNURL-Auth anmelden:

Man bekommt einen QR-Code angezeigt, den man mit einer Lightning wallet scannen kann, welche LNURL-Auth unterstützte wie zum Beispiel Breez und Phoenix oder Bitbanana und Zeus LN welche mit der eigenen Node verbunden sind.

Nachdem ihr den QR Code gescannt habt, seid ihr angemeldet und bekommt einen eindeutige User-ID angezeigt. Ihr müsst keinerlei persönliche Daten und email-Adressen hinterlegen.

Wenn man sich erneut auf seinem Account anmelden will, dann verwendet man die gleiche Lightning Wallet erneut und ist wieder eingeloggt als der selbe Benutzer. Als User identifiziert man sich ausschliesslich über seinen Public Key und sonst nichts. Kein Passwort, keine EMail-Adresse, kein Username oder etwas ähnliches.

Es findet auch keine Weiterleitung der Informationen zu anderen Webseiten statt. Ihr könnt bei jeder anderen Webseite, die LNURL-Auth verwendet, mit der gleichen Lightning Wallet ein Account aufmachen und euch darüber immer wieder einloggen.

LNURL Pay

Für eine Lightning-Zahlung erstellt der Empfänger eine individuelle Lightning Invoice, die dem Zahler alle nötigen Informationen zur Zahlung und Zuordnung bereitstellt. Da jede Zahlung einzigartig ist, können keine statischen QR-Codes verwendet werden.

Mit LNURL-Pay wird der Ablauf vereinfacht: Der Zahler initiiert die Zahlung, indem er den Empfänger auffordert, eine Rechnung zu erstellen. Der Zahler kann Betrag und Kommentar hinzufügen, bevor die Zahlung abgeschlossen wird.

Beispielanwendung: Die Donation Button vom BTCPay Server der euch einen QR Code generiert, der automatisch eine Invoice erstellt, in der höhe des von euch angegeben Betrags, oder ein Strassenkünstler stellt einen statischen QR-Code auf. Spender können den Code scannen, den Betrag in ihrer Lightning-Wallet festlegen und direkt spenden.

Lightning Adresse

Mit LNURL-Pay lassen sich Lightning-Zahlungen bequem an eine sogenannte Lightning-Adresse senden, die wie eine E-Mail-Adresse aussieht. Eine Lightning-Adresse (z. B. mario@btcpay.yourdevice.ch) wird in Lightning-Wallets, die LNURL-Pay unterstützen, wie eine Zahlungsadresse eingegeben. Die Wallet generiert automatisch eine Lightning Invoice, die an den Empfänger geschickt und von diesem verarbeitet wird.

So funktioniert's:

1. Gebt die Lightning-Adresse in eurer Wallet ein, wo sonst LNURLs hinterlegt werden.
2. Eure Wallet kommuniziert mit dem Server hinter der Lightning-Adresse, um eine Zahlungsanforderung zu generieren.
3. Bestätigt den Betrag und sendet die Zahlung.

Beispiel:

• Möchtet ihr es ausprobieren? Sende einen Sat an mario@btcpay.yourdevice.ch und erfahrt wie einfach es ist, Lightning Adressen zu verwenden.
• Nutzer der sats.mobi Telegram Wallet erhalten ebenfalls automatisch eine Lightning-Adresse in der Form tg-username@sats.mobi

Tipp: Viele moderne Lightning-Wallets unterstützen Lightning-Adressen, darunter Phoenix, Wallet of Satoshi, und Breez. Prüft eure Wallet auf diese Funktionalität, um Lightning-Zahlungen noch einfacher zu gestalten! Viele Wallets beherschen auch ein Kontaktbuch, mit der ihr eure Kontakte mit Lightning Adressen auch einfach ablegen könnt. Hier ein Beispiel der Bitbanana Wallet:

LNURL-Channel

LNURL-Channel dient dazu, den Prozess der Kanalöffnung durch einen anderen Node zu vereinfachen und zu automatisieren. Es ermöglicht, dass ein Node, der euch Liquidität zur Verfügung stellen möchte, eine Verbindung zu deinem Node herstellt und einen Kanal eröffnet, ohne dass du dies manuell anstoßen werden muss. Dies kommt meisst dann zur Anwendung, wenn ihr einen Kanal kauft, zum Beispiel bei einem LSP (Liquid Service Provider)

Wie funktioniert es?

1. Der Betreiber eines Nodes, der Kanäle anbietet (z. B. eben ein Service-Provider oder ein Freund), generiert einen LNURL-Channel QR-Code.
2. Ihr scannt diesen QR-Code mit eurer Lightning-Wallet, die LNURL-Channel unterstützt.
3. Eure Wallet sendet automatisch die nötigen Informationen an den anderen Node (wie zum Beispiel eure Node-ID).
4. Der andere Node eröffnet daraufhin einen Kanal zu euch und stellt euch die gewünschte Liquidität bereit.

Wann ist LNURL-Channel sinnvoll?

• Erleichterung für neue Nutzer: Neue Lightning-Nutzer können so unkompliziert einen ersten Kanal eröffnen lassen, ohne technische Details wie die Node-ID manuell einzugeben.
• Förderung von Lightning-Adoption: Anbieter, Börsen oder Services können LNURL-Channel anbieten, um Nutzern mit einem Klick Liquidität bereitzustellen.
• Automatisierung: Der Prozess spart Zeit und reduziert Fehler, da keine manuelle Interaktion mit der Node nötig ist.

Wichtiger Hinweis:
LNURL-Channel ist nicht zwingend notwendig für Nodes hinter Tor oder Firewalls, die bereits öffentlich erreichbar sind. Stattdessen zielt es darauf ab, den Prozess der Kanalöffnung für Nutzer einfacher, schneller und intuitiver zu gestalten.

Lightning Wallets mit LNURL Unterstützung

Folgende Lightning Wallets unterstützen LNURL bzw. Funktionen von LNURL

Quelle: https://coincharge.de

Wir versuchen, diese Liste aktuell zu halten. Gibt es neue Funktionen oder Lightning Wallets, die hier aufgeführt werden sollten? Teilt uns das gerne mit unter info@yourdevice.ch

Fazit

LNURL ist eine leistungsstarke Erweiterung des Lightning-Netzwerks, die den Alltag mit Lightning-Zahlungen erheblich erleichtert. Es bietet vielseitige Funktionen, um bisherige Einschränkungen zu überwinden und Nutzererlebnisse zu verbessern:

1. Nutzerfreundlichkeit: LNURL-Mechanismen wie LNURL-Pay, LNURL-Withdraw und LNURL-Channel machen Lightning-Zahlungen intuitiver und zugänglicher – selbst für technisch weniger versierte Nutzer.
2. Flexibilität: Mit LNURL lassen sich sowohl Zahlungen empfangen (LNURL-Pay) als auch Guthaben abheben (LNURL-Withdraw) oder Kanäle eröffnen (LNURL-Channel). Lightning-Adressen ermöglichen zudem einfache Zahlungen über eine E-Mail-ähnliche Adresse.
3. Automatisierung: Komplexe Abläufe, wie die Erstellung von Invoices oder Kanalverbindungen, werden automatisiert. Das reduziert Fehler und spart Zeit.
4. Vielfältige Einsatzmöglichkeiten: Von Spenden über Börsenauszahlungen bis hin zu benutzerfreundlichen Onboarding-Prozessen – LNURL eröffnet viele neue Anwendungsfelder im Lightning-Netzwerk.

LNURL ist also ein entscheidender Schritt in Richtung einer barrierefreien und massentauglichen Nutzung von Lightning. Es reduziert technische Hürden und schafft eine solide Basis für die breitere Akzeptanz und Verbreitung des Lightning-Netzwerks. Ich hoffe der Artikel "Was versteht man unter LNURL bei Lightning" hat euch gefallen und konnte etwas Licht ins dunkle bringen.

The post Was versteht man unter LNURL bei Lightning appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist der Unterschied zwischen BTC und LN BTC

Bitcoin (BTC) basiert auf der Haupt-Blockchain, die Transaktionen weltweit dezentral und sicher verarbeitet. Dieser Prozess stellt sicher, dass jede Transaktion transparent und unumkehrbar ist, bringt jedoch eine relativ lange Bestätigungszeit und Netzwerkgebühren mit sich, die je nach Nachfrage erheblich schwanken können. Diese Merkmale machen BTC besonders sicher, aber für alltägliche, schnelle Transaktionen weniger ideal.

Lightning-Bitcoin (LN BTC) hingegen läuft über das Lightning Network – eine „zweite Ebene“ (Layer-2) des Bitcoin-Netzwerks. Hierbei werden Zahlungen in „Payment Channels“ abgewickelt, ohne dass jede Transaktion direkt auf der Bitcoin-Blockchain aufgezeichnet wird. Das reduziert die Gebühren erheblich und macht LN BTC extrem schnell – oft in Sekundenschnelle. Erst wenn ein Kanal geschlossen wird, wird der endgültige Saldo in einer einzigen on-chain Transaktion auf der Bitcoin-Blockchain festgeschrieben.

Die Methoden für den Transfer

Schauen wir uns nun die schnellsten und besten Methoden an, wie man seine BTC in Lightning BTC umwandeln kann!

1. Phoenix Wallet – Nahtlos und unkompliziert

Eine der einfachsten Methoden, um Bitcoin in Lightning BTC zu wechseln, ist die Phoenix Wallet. Diese Wallet ist besonders nutzerfreundlich und eignet sich sowohl für Einsteiger als auch für fortgeschrittene Nutzer. Der Vorteil von Phoenix liegt darin, dass sie on-chain Bitcoin automatisch in Lightning BTC umwandelt, sobald du eine Lightning-Adresse als Ziel angibst. Dafür müsst ihr zuerst ein paar Onchain BTC auf die BTC Wallet der Phoenix Wallet laden:

Vorteile

• Automatische Konvertierung: Ihr sendet Bitcoin Onchain Guthaben an die Phoenix Wallet, und die Phoenix Wallet wird euch automatisch anbieten, einen entsprechenden Kanal zu eröffnen, um euch Lightning Guthaben zu erstellen wenn ihr eine Lightning Invoice bezahlen möchtet.
• Nutzerfreundlich: Die App ist relativ einfach zu bedienen und nimmt euch den technischen Aufwand ab Lightning Kanäle zu verwalten
• Geringe Gebühren: Die Umwandlung erfolgt zu fairen Gebühren.

Nachteile

• Nur mobile App: Phoenix ist nur als App für mobile Geräte verfügbar, was die Nutzung am Desktop einschränken kann.
• Push Voraussetzung: Funktioniert nur mit Phones auf dem Google Play installiert ist, auf GrapheneOS Phones mit Sandboxed Google Play oder auf Calyx Phones mit Micro-G

Eine Anleitung zur Phoenix Wallet findet ihr hier!

2. Pocket Bitcoin Lightning – Direkt von Fiat zu Lightning

Pocket Bitcoin bietet einen Service an, bei dem ihr Bitcoin direkt mit Fiat-Geld kaufen und an eine Lightning-Wallet senden könnt. Am besten eignen sich dabei die Phoenix, und die Breez Wallet. Der Umweg über on-chain Bitcoin entfällt hier komplett, da Pocket Bitcoin eure gekauften Bitcoin direkt als LN Bitcoin zurücksendet. Dies spart Zeit und Gebühren, da ihr den Umwandlungsprozess umgeht.

Vorteile

• Direkter Kauf in Lightning: Ihr kauft mit Fiat direkt Lightning-Bitcoin, ohne zuerst on-chain Bitcoin zu erhalten.
• Kein Umwandlungsprozess: Dieser Weg spart Zeit und Gebühren, da kein zusätzlicher Wechsel nötig ist.
• Einfacher Kaufprozess: Pocket Bitcoin bietet eine benutzerfreundliche Oberfläche, die den Kaufprozess angenehm macht.

Nachteile

• Fiat-Einschränkungen: Die Verfügbarkeit des Dienstes ist abhängig vom Land und den angebotenen Zahlungsmethoden. Ausserdem kann pro Monat seit 2025 nur bis zu 1000CHF in BTC/Lightning umgewandelt werden, danach fällt ein KYC Prozess an.

Anleitung dazu hier: https://pocketbitcoin.com/de/learn/lightning/top-up-lightning-wallet

3. Boltz – Ohne Registrierung und schnell

Boltz ist ein Non-Custodial-Exchange-Service, der es euch erlaubt, ohne Registrierung und ohne KYC (Know Your Customer) Bitcoin gegen Lightning-Bitcoin zu tauschen. Boltz bietet sogenannte "Atomic Swaps" an, bei denen ihr eure Bitcoin on-chain einzahlen und im Gegenzug Lightning-Bitcoin erhalten könnt. Ihr könnt eure LN BTC danach an eine Lightning Wallet eurer Wahl schicken, indem ihr einfach zuerst mit der Wallet eine Invoice in einer gewünschten höhe erstellt, und danach in das Invoice Fenster von Boltz kopiert. Boltz fordert euch dann auf, die umgerechnete Menge an BTC an den Dienst zu senden.

Vorteile

• Keine Registrierung: Ihr benötigt kein Benutzerkonto und könnt den Service völlig anonym nutzen.
• Schnelle Abwicklung: Die Konvertierung erfolgt schnell, sobald eure on-chain Bitcoin in einer Transaktion bestätigt wurden.
• Privatsphäre: Da keine KYC-Verifizierung erforderlich ist, bietet Boltz hohe Anonymität.

Nachteile

• Transaktionsgebühren: On-chain Transaktionen verursachen immer Netzwerkgebühren, die zusätzlich zu den Wechselgebühren anfallen.
• Servicegebühren - die Nutzung des Services beinhaltet zudem eine Service Gebühr, die in der Regel um die 0.1% beträgt.

Der Link zur Boltz Exchange: https://boltz.exchange/

4. Breez Wallet – Integrierte Dienste und einfache Konvertierung

Die Breez Wallet ist eine weitere beliebte Lightning-Wallet, die es euch erlaubt, direkt von Bitcoin zu Lightning BTC zu wechseln. Breez ermöglicht es euch, Bitcoin On-chain zu empfangen und diese in eurer Wallet zu halten, und danach sie direkt ins Lightning-Netzwerk zu übertragen. Die App eröffnet für euch selbstständig Lightning Kanäle ähnlich wie die Phoenix Wallet.

Vorteile

• Integrierte Funktionalität: Ihr könnt nahtlos zwischen Bitcoin und Lightning-BTC wechseln.
• Zahlreiche Zusatzfunktionen: Breez bietet integrierte Dienste wie Point of Sale (POS) für Händler.
• Open Source: Die App ist quelloffen, was sie transparent und sicher macht.
• Keine Push; Push ist nicht notwendig wie bei der Phoenix Wallet
• Kleinere Gebühren: Die Umwandlung zwischen on-chain und Lightning kosten Gebühren.

Nachteile

• soweit keine

Anleitung dazu hier: https://coincharge.io/en/breez-wallet/

5. Blue Wallet – Einfacher In-App-Swap

Die Blue Wallet ist besonders für ihre einfache Bedienung bekannt und erlaubt es Nutzern, Bitcoin sowohl on-chain als auch off-chain (Lightning) zu verwalten. Der In-App-Swap ermöglicht es, on-chain Bitcoin direkt in Lightning-BTC umzuwandeln. Dazu müsst ihr aber via LNDHub eine Lightning Wallet verbinden. Danach könnt ihr auf der Lightning Wallet auf Manage Funds, und wählt anschliessend Refill als Option. Es müssen ein paar BTC auf die BTC Wallet vorher überwiesen worden sein. Für die Lightning Wallet bietet sich unsere LNBits Wallet an.

Vorteile

• Einfacher Swap: Die Blue Wallet macht es sehr einfach, zwischen den beiden Netzwerken zu wechseln.
• Benutzerfreundlich: Dank der simplen Oberfläche ist die Wallet besonders einsteigerfreundlich.
• Multi-Wallet-Unterstützung: Ihr könnt mehrere Wallets erstellen und verwalten.

Nachteile

• Custodial: Die Lightning-Funktion der Blue Wallet ist custodial, d.h., ihr vertraut eure Lightning-Funds dem Betreiber der Wallet an.

Anleitung dazu hier: https://bluewallet.io/lightning/

6. Umtausch via Exchange

Habt ihr euch bei einer Exchange angemeldet, zum Beispiel Kraken, Bitfinex, Binance oder etc, könnt ihr natürlich auch dort BTC kaufen, und diese direkt über die Plattform in LN-BTC umwandeln. Dazu müsst ihr die Swap Tools verwenden, eure BTC in LN-BTC tauschen, und diese dann per Invoice an eure Wallet auszahlen lassen. Eine Anleitung wie das ungefähr aussieht, findet ihr hier ebenfalls im Phoenix Tutorial an Ende des Beitrags.

Vorteile

• relativ einfache Handhabung
• schnelle Swaps
• praktisch kostenlose Swaps möglich
• Auszahlung ebenso fast kostenlos
• hohe Liquidität

Nachteile

• Anmeldung und KYC auf der Börse notwendig
• tägliche Auszahlungslimite, danach Meldung der Transaktionen aufgrund der Travelrule

7. Robosats

Robosats bietet euch eine anonyme Möglichkeit, ohne KYC Fiat Money in LN Bitcoin umzutauschen. Es gibt eine TOR Seite von Robosats, es benötigt keinerlei Anmeldungen, auch nicht mit einer Email, und das ganze funktioniert über Session-Tokens. Allerdings ist die Handhabung etwas kompliziert. Dazu gibt es eine Art Orderbook, und es gibt teilweise höhere Aufschläge auf den üblichen Marktpreis. Die LN-BTC könnt ihr danach an via Invoice an eine Wallet eurer Wahl senden. Ein Anleitung findet ihr dazu hier.

Vorteile

• KYC-frei und anonym
• sicher durch Escrow Verfahren
• keine Anmeldung erforderlich
• mehre Zahlungsmethoden möglich

Nachteile

• etwas komplex in der Anwendung
• hohe Auschläge zum üblichen Marktpreis
• eher geringe Liquidität vorhanden

Fazit

Es gibt verschiedene Wege, um Bitcoin in Lightning BTC umzuwandeln – von Wallets wie Phoenix und Breez, die den Prozess nahtlos und einfach machen, über anonyme Dienste wie Boltz, bis hin zu direktem Kauf über Pocket Bitcoin. Welche Methode die beste für euch ist, hängt davon ab, wie ihr eure Bitcoin verwalten möchtet, ob euch Privatsphäre wichtig ist und welche Gebühren ihr in Kauf nehmen möchtet.

Für schnelle und unkomplizierte Umwandlungen sind Phoenix und Boltz besonders geeignet, während Pocket Bitcoin die ideale Lösung ist, wenn ihr direkt mit Fiat in Lightning einsteigen möchtet.

Probiert die Methoden aus und findet heraus, welche am besten zu euch passt!

The post Die schnellsten Möglichkeiten Bitcoin in Lightning BTC umzuwandeln appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist Satoshis Kleinanzeigen?

Satoshis Kleinanzeigen ist eine Online-Plattform, die es ihren Nutzern ermöglicht, Waren und Dienstleistungen im Peer-to-Peer-Stil zu handeln, ähnlich wie bei traditionellen Kleinanzeigenportalen. Der große Unterschied? Hier wird ausschließlich mit Bitcoin gehandelt. Die Plattform vereint die Anonymität und Sicherheit von Bitcoin mit den Vorteilen eines lokalen Marktplatzes, der ohne Zwischenhändler oder Banken auskommt. Die Idee dahinter ist simpel: Käufer und Verkäufer können sich direkt miteinander verbinden und Zahlungen in Bitcoin abwickeln, ohne auf zentrale Plattformen oder Zahlungsdienstleister angewiesen zu sein.

Peer-to-Peer Plattform

Da es sich um eine Peer-to-Peer-Plattform handelt, liegt die Verantwortung für die Sicherheit und die Abwicklung der Transaktionen direkt bei euch. Um Betrug zu vermeiden, können verschiedene Sicherheitsmechanismen genutzt werden, wie z. B. Treuhandservices, bei denen das Bitcoin-Guthaben eines Käufers erst freigegeben wird, wenn die Ware erhalten wurde. Dies gibt sowohl Käufern als auch Verkäufern ein gewisses Maß an Vertrauen in die Plattform.

Funktionen und Vorteile von Satoshis Kleinanzeigen

• Zahlungen in Bitcoin: Die Plattform ermöglicht ausschließlich Zahlungen in Bitcoin, was insbesondere für Krypto-Enthusiasten attraktiv ist, die eine Alternative zu herkömmlichen Fiat-Währungen suchen. Durch die Nutzung von Bitcoin entfällt die Notwendigkeit, sich mit Banken oder anderen zentralen Finanzinstitutionen auseinanderzusetzen.
• Privatsphäre und Anonymität: Anders als bei traditionellen Plattformen müssen Nutzer bei Satoshis Kleinanzeigen keine sensiblen persönlichen Daten preisgeben. Lediglich eine Bitcoin-Wallet-Adresse und eine Lightning Wallet sind nötig, um Transaktionen durchzuführen. Dies garantiert ein hohes Maß an Privatsphäre. Der Login is direkt über die eigene Lightning Node möglich.
• Gebührenfrei: Die Plattform ist grundsätzlich gebührenfrei, die User handeln untereinander und einigen sich über den Preis.

Herausforderungen und Zukunftsperspektiven

Obwohl Satoshis Kleinanzeigen zahlreiche Vorteile bietet, gibt es auch einige Herausforderungen, die die Plattform bewältigen muss. Eine der größten Hürden ist die allgemeine Akzeptanz von Bitcoin im Alltag. Während immer mehr Menschen Kryptowährungen nutzen, bleibt Bitcoin für viele immer noch ein Investment-Asset, anstatt eines tatsächlichen Zahlungsmittels. Die meissten Nutzer zögern immer noch, ihre Sats auszugeben, da die Hoffnung auf steigende Kurse im Vordergrund steht.

Ein weiteres potenzielles Problem ist die Anonymität der Nutzer. Obwohl diese ein Vorteil für den Schutz der Privatsphäre ist, kann sie auch von Betrügern ausgenutzt werden. Hier könnten verbesserte Sicherheitsmaßnahmen, wie z. B. Verifizierungen oder Bewertungen von Nutzern, in Zukunft eine Rolle spielen und die Handelssicherheit verbessern.

Nichtsdestotrotz bietet Satoshis Kleinanzeigen eine vielversprechende Alternative zu herkömmlichen Handelsplattformen und hat das Potenzial, besonders in der Krypto-Community Fuß zu fassen. Mit der wachsenden Akzeptanz von Bitcoin als Zahlungsmittel und dem steigenden Bewusstsein für die Vorteile dezentraler Plattformen könnte Satoshis Kleinanzeigen ein Vorreiter für den Handel in der digitalen Ära werden.

Nutzung von Satoshis Kleinanzeigen

Um Inserate anbieten zu können, müssen sich Nutzer aktuell mit einer Lightning Wallet anmelden. Klickt dazu oben rechts auf das Profilbild, und scannt dazu einfach mit einer Lightning Wallet eurer Wahl den Login-Code, und ihr werdet anhand eurer Private Keys eurer Lightning Wallet authentifziert. Diese Login-Methode nennt sich LN-Auth, und ist sicherer und zudem privater als jedes Google Login. Es funktionieren alle gängigen Lightning Wallets, wie zum Beispiel die Phoenix Wallet, die Wallet of Satoshi, die Breez Wallet sowie auch eine Alby oder Strike Wallet mit Lightning Funktion. Natürlich könnt ihr auch eure eigene Lightning FullNode für die Authenfizierung verwenden. Nach der erfolgreichen Authenfizierung, könnt ihr auch schon direkt Inserate erstellen.

Profil bearbeiten

Bevor ihr loslegen könnt, ist es am schlausten, sich sein Profil kurz zurecht zu machen. Klickt auf das Profilbild und geht auf Profil bearbeiten.

Ihr legt am besten ein Profilname fest, und fügt euren Telegram Link im Format @euer_tg_name hinzu damit man euch kontaktieren kann. Ein Profilbild kann genutzt werden, muss aber nicht. Eine Email Adresse kann optional auch angegeben werden. Klickt danach auf Profil Speichern.

Inserat erstellen

Auf oben in der Toolleiste findet ihr unter INSERIEREN ihr auch gleich die Funktion, um Inserate zu erstellen. Wählt die Option und lasst uns ein neues Inserat erstellen:

Fügt ein paar Bilder hinzu, gebt dem Produkt eine entsprechende Bezeichnung und Beschreibung, und setzt ein paar passende Hashtags. Danach kann noch der Angebotstyp festgelegt werden. Möglich sind beginnt bei, Festpreis, oder Verhandlungsbasis. Legt einen Preis in Satoshis fest, und wählt ob der Preis inklusive, oder exklusive Versand ist. Danach noch die entsprechende Kategorie wählen, und schon ist das Inserat fertig!

Das Inserat wird von den Admins noch geprüft, und danach, sollte es keine illegale Inhalte beinhalten, freigegeben. Ihr findet es danach unter den vorhandenen Inseraten.

Selber etwas kaufen

Dazu muss eigentlich nicht viel gesagt werden, da es ziemlich selbsterklärend ist. Durchstöbert die Inserate, und sucht euch etwas nettes aus. Danach könnt ihr den Inserent durch die bereit gestellten Kontaktmöglichkeiten kontaktieren.

Ein paar Sicherheitshinweise zum Handeln

Der Handel, Kauf und Verkauf basiert auf Satoshis Kleinanzeigen rein auf Vertrauen. Das hört sich zuerst gefährlich an, jedoch kommt es wirklich selten vor, dass Betrüger unterwegs sind. Die Bitcoin Community ist wirklich vertrauensvoll. Ich selber kaufe, und verkaufe immer mal wieder was auf Satoshis Kleinanzeigen, und benutze dabei auch meinen gesunden Menschenverstand. Hier ein paar Tipps für einen sicheren handeln:

• Seid kritisch wenn euch das Gegegenüber schnell zu Zahlungen auffordert, da er beispielsweise schnell weg muss und den Handel schnell über die Bühne bringen möchte.
• bevorzugt bei grösseren Beträgen lieber ein persönliches Treffen
• Schätzt die Art und Weise, wie der Gegenüber kommuniziert ein, wie bereits erwähnt, sind Zeit-Limits, Druck und Stress kein gutes Zeichen.
• Lasst euch Bilder der Waren schicken, oder bei Unsicherheit auch ein Ausweis des gegenübers.
• Solltet ihr über Telegram kommunzieren, checkt doch mal, ob das Gegenüber in bekannten Bitcoin Gruppen ist (Raspiblitz & Raspiblitz German, PlebNet, Nodestrich) und etc. Das erhöht das Vertrauen gleich um einiges.

Spenden an Satoshis Kleinanzeigen

Das Projekt wird quasi nur mit eigenen Ressourcen finanziert, in der Freizeit entwickelt, und ist deshalb auf Spenden der Nutzer und Anwender angewiesen. Satoshis Kleinanzeigen ist eine Graswurzel-Bewegung. Getrieben von der Leidenschaft, Bitcoin in der Praxis zu erproben, sind die Mitglieder eng vernetzt und handeln bereits aktiv miteinander. Das langfristiges Ziel ist die Entwicklung eines dezentralen Marktplatz-Protokolls, das als echte Alternative zu den mächtigen, zentralen Plattformen dient. Um weitere Funktionen wie eine User Bewertung, einen Treuhand-Service, oder weitere Ideen zu entwickeln und auch zu integrieren, braucht das Projekt eure Unterstützung. Die Betreiber und das Team, würden sich deshalb um eine Spende freuen!

Fazit

Satoshis Kleinanzeigen ist eine innovative Plattform, die die Möglichkeiten von Bitcoin voll ausschöpft. Sie bietet euch die Freiheit, Waren und Dienstleistungen ohne die Einmischung von Dienstleistern die horrende Gebühren kassieren, Banken oder zentralen Behörden zu handeln und garantiert dabei ein hohes Maß an Privatsphäre. Trotz der bestehenden Herausforderungen hat die Plattform das Potenzial, in einer Welt, die zunehmend auf Dezentralität und digitale Währungen setzt, eine wichtige Rolle zu spielen.

Für alle Bitcoin-Enthusiasten, die nach einer einfachen Möglichkeit suchen, mit ihrer bevorzugten Kryptowährung zu handeln, ist Satoshis Kleinanzeigen auf jeden Fall einen Blick wert!

The post Satoshis Kleinanzeigen - Die Bitcoin Handelsplattform appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitungen

Das Tutorial basiert auf dem Artikel eigenen IP2Tor Server für den Rapsiblitz einrichten. Damit ihr einen groben Überblick habt, lesst euch den Artikel vorher durch, damit ihr vorbereitet seid, und die entsprechenden Bedienungen installiert habt. Die im Artikel beschriebene Einrichtung vom LND Dienst muss nicht eingerichtet werden, sie galt nur als Beispiel.

Installiert euch zudem den BTCPay Server, und / oder LNBits auf eurem Raspiblitz. Schreibt euch die Onion Adressen der jeweiligen Dienste auf. Die findet ihr im cli-menu unter den jeweiligen Einträgen:

Die Onion Addresse für LNBits findet ihr 2 Einträge unter BTCPay Server Info.

Domain einrichten

Damit ihr euren BTCPay Server über eine Domain via https erreichen könnt, müsst ihr eine Domain haben, die auf den Server zeigt, dass kann auch eine gratis DynDNS Addresse sein, falls ihr kein Geld ausgeben möchtet. Bei einem VPS Server mit statischer IP bietet es sich aber an, eine eigene fixe Domain zu kaufen, und diese auf den Server zeigen zu lassen. Das könnt ihr zum Beispiel bei https://strato.de, oder in der Schweiz bei https://hostpoint.ch tun.

Falls ihr kein Bock auf sowas habt, könnt ihr auch eine Domain bei uns kaufen. Wir erledigen die Einrichtung mit einem A-Record auch gerne gleich mit dazu.

In den DNS Records müsst ihr einen A-Record setzen, der auf die VPS IP zeigt. Dies sieht in der Regel bei Hostpoint zum Beispiel so aus:

Name: eure Subdomain, zum Beispiel btcpay oder btcpay-raspibliblitz, und für LNBits zum Beispiel einfach lnbits
TTL: Bleibt bei 300
IP-Adresse: die IP Adresse eurer VPS

Danach Record hinzufügen und bestätigen.

Einrichtung auf eurem IP2Tor Server

Ihr habt euch im bestenfall schon einen IP2Tor Server eingerichtet, falls nicht, lesst den oben verlinkten Beitrag, und richtet kurz Tor und Socat ein. Hier nochmals der Beitrag:

BTCPay Server IP2Tor Dienst einrichten

Erstellt euch einen neuen IP2TorDienst auf dem VPS mit:

sudo nano /etc/systemd/system/ip2tor_btcpay.service

und fügt folgenden Inhalt hinzu:

[Unit]
Description=Tor2IP Tunnel Service
After=network.target

[Service]
User=root
Group=root
ExecStart=/usr/bin/socat TCP4-LISTEN:23002,bind=127.0.0.1,fork SOCKS4A:localhost:eure_btcpay_onion_addresse.onion:80,socksport=9050
StandardOutput=journal

PrivateTmp=true
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true

[Install]
WantedBy=multi-user.target

Der Port ist frei wählbar, ihr könnt einen nehmen, der euch passt. Dieser muss dann einfach mit dem SystemD Dienst weiter übereinstimmen. Ersetzt den fett markierten Teil mit eurer BTCPay Onion Adresse die ihr euch von eurem Raspiblitz notiert habt. Speichert die Datei mit strg+o und beendet mit strg+x

Startet den Dienst mit neu mit sudo systemctl start ip2tor_btcpay.service und checkt den Dienst mit sudo systemctl status ip2tor_btcpay.service:

Mit sudo systemctl enable ip2tor_btcpay.service aktiviert ihr den Dienst bei Systemstart.

Nginx installieren, einrichten und SSL Zertifikat beantragen

Damit wir die Seite über unsere Domain erreichen können, müssen wir uns Nginx auf dem VPS installieren und einen Reverse Proxy einrichten, der die Anfrage an socat weiterleitet.

Installiert euch nginx mit

apt install nginx

Entfernt die Standard Konfigurationen mit

rm /etc/nginx/sites-available/default
rm /etc/nginx/sites-enabled/default

Fügt eine neue nginx Konfiguration hinzu mit:

nano /etc/nginx/sites-available/ip2tor_btcpay 

und fügt folgenden Eintrag ein:

server {
    server_name eure_domain.de;

    location / {
        proxy_pass http://127.0.0.1:23002;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Ersetzt den fett markierten Text mit eurer Domain die ihr bei eurem Hoster festgelegt habt und gebt den selben Port hier an!

Erstellt einen syslink in den sites-enabled Ordner:

ln -s /etc/nginx/sites-available/ip2tor_btcpay /etc/nginx/sites-enabled/

checkt ob alles korrekt ist mit dem Befehl nginx -t und falls ihr ein Syntax OK bekommt, ladet nginx mit sudo systemctl reload nginx neu.

SSL Zertifikat holen

Für die Domain brauchen wir ein SSL Zertifikat um eine gesicherte Verbindung herstellen zu können. Dafür müssen wir uns ein SSL-Zertifikat holen. Das geht am besten mit certbot. Damit lassen sich einfach Lets Encrypt Zertifikate beantragen, und direkt die entsprechende nginx Konfiguration anpassen.

Installiert euch certbot auf dem VPS mit:

apt install certbot python3-certbot-nginx

und beantragt anschliessend nach der Installation eine Zertifikat mit:

certbot --nginx -d eure_domain.de -m eure_mail_addresse

Ersetzt eure_domain.de mit eurer gekauftet Domain, und gebt eure Mail-Addresse an. Die Domain muss die selbe sein wie in der nginx Konfiguration, welche wir angelegt haben!

Ihr bekommt 2 Fragen von Letsencrypt. Einmal ob ihr mit den Vertragsbediengungen einverstanden seid, und einmal ob ihr Neuigkeiten von Letsencrypt erhalten wollt. Stimmt den Vertragsbediengungen hinzu, und nehmt den Newsletter an, oder nicht. Falls alles geklappt habt, bekommt ihr folgende Meldung:

Das SSL Zertifikat wird automatisch erneuert, falls es abläuft. Die Zertifikate sind in der Regel 90 Tage gültig.

Hat alles geklappt, könnt ihr nun euren BTCPay Server via Domain und https Verbindung aufrufen:

LNBits Server IP2Tor Dienst einrichten

Die Ablauf ist der selbe wie beim BTCPay Server. Natürlich müsst ihr auf eurem Hoster eine neue Subdomain erstellen, zum Beispiel lnbits.eure_domain.de. Erzeugt eine neuen LNBits Dienst auf dem VPS mit:

sudo nano /etc/systemd/system/ip2tor_lnbits.service

Fügt folgenden Inhalt hinzu:

[Unit]
Description=Tor2IP Tunnel Service
After=network.target

[Service]
User=root
Group=root
ExecStart=/usr/bin/socat TCP4-LISTEN:5002,bind=0.0.0.0,fork SOCKS4A:localhost:eure_lnbits_addresse.onion:80,socksport=9050
StandardOutput=journal

PrivateTmp=true
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true

[Install]
WantedBy=multi-user.target

Speichert die Datei ab, startet den Dienst mit sudo systemctl start ip2tor_lnbits.service und aktiviert den Dienst bei Systemstart mit sudo systemctl enable ip2tor_lnbits.service

Erstellt eine neue Nginx Kongifurationsdatei mit

nano /etc/nginx/sites-available/ip2tor_lnbits 

und fügt folgenden Inhalt hinzu:

server {
    server_name eure_lnbits_domain.de;

    location / {
        proxy_pass http://127.0.0.1:5002;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Achtet darauf dass ihr den selben Port nehmt, wie in eurer Nginx Konfiguration! Fügt einen neuen symlink hinzu mit:

ln -s /etc/nginx/sites-available/ip2tor_lnbits /etc/nginx/sites-enabled/

Testet die Konfiguration mit nginx -t und ladet Nginx neu mit systemctl reload nginx

Danach wieder das SSL Zertifikat beantragen mit:

certbot --nginx -d lnbits-eure_domain.de -m info@yourdevice.ch

Passt die fett markierten Einträge entsprechend an.

Anschliessend solltet ihr über die URL auf eure LNBits Instanz kommen:

Damit ihr auf euren Server Account kommt, fügt die Wallet Addresse am Ende der URL hinzu, die euch der Info-Screen des Raspiblitzes gibt:

Abschluss

Die Einrichtung von Tor-Diensten über socat, Tor und Nginx mit SSL-Zertifikat bietet eine sichere und anonyme Methode, um verborgene Dienste im Clearnet zugänglich zu machen. Dieser Prozess ermöglicht es euch, die Vorteile des Tor-Netzwerks zu nutzen, während ihr gleichzeitig die Benutzerfreundlichkeit und Sicherheit einer HTTPS-Verbindung gewährleistet. Ich hoffe der Artikel <BTCPay und LNBits auf Raspiblitz über Clearnet erreichen mit IP2Tor> hat euch gefallen. Habt ihr Fragen, hinterlasst sie in den Kommentaren!

Keine Lust da selber einzurichten? Wir bieten ein IP2Tor Dienst in unserem Webshop direkt an:

The post BTCPay und LNBits auf Raspiblitz über Clearnet erreichen mit IP2Tor appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was richten wir hier genau ein

Wir richten einen sogenannten Tor-to-IP-Tunnel-Dienst ein. Dabei wird der Datenverkehr von einem Tor Hidden Service über einen VPS geleitet, sodass er über eine normale IP-Adresse oder Domain zugänglich ist. Der VPS fungiert hierbei als Brücke zwischen dem Tor-Netzwerk und dem öffentlichen Internet.

Wie es funktioniert

1. Tor Hidden Service: Ein Dienst, der nur über das Tor-Netzwerk erreichbar ist, wird auf deinem lokalen Rechner betrieben.
2. VPS: Ein Virtual Private Server, der als öffentlich zugänglicher Einstiegspunkt dient.
3. socat: Ein Tool, das den Datenverkehr zwischen dem VPS und dem Tor Hidden Service weiterleitet.

Vorteile

• Verbirgt die IP-Adresse des Hosts vor der Öffentlichkeit und dem VPS.
• Kein Port-Forwarding im lokalen Netzwerk (LAN) des Hosts erforderlich.
• Zusätzliche Verschlüsselung durch Tor zwischen dem Host und dem VPS.

Nachteile

• Die Lösung ist elegant, um die eigenen Dienste via Clearnet zu erreichen, die Verbindung danach erfolgt aber weiterhin über Tor, ist also nicht so schnell wie zum Beispiel die VPN Lösung Tunnelsats.

Voraussetzungen

• SSH-Zugang zu einem Virtual Private Server (VPS) - Zum Beispiel ein minimales Paket bei IONOS oder Hetzner für für ca. 2-4 Euro pro Monat.
• Ein Rapsiblitz der voll synchronisiert ist. Die Dienste müssen eingerichtet sein, und funktionieren.
• Portfreigabe auf dem VPS Server: Der entsprechene Port muss in der Firewall des VPS Servers freigegeben sein!

Schritt-für-Schritt Anleitung

Einrichtung von Tor und Socat auf dem VPS Server

Meldet euch mit SSH als root-Benutzer an:

ssh root@VPS_IP_ADDRESSE

Bringt eures System auf den neusten Stand mit:

apt update && apt upgrade -y && apt autoremove -y && apt autoclean -y

Installiert socat:

apt install socat

Installiert danach Tor:

$ apt install apt-transport-https

$ sh -c 'echo "deb [arch=amd64 signed-by=/usr/share/keyrings/deb.torproject.org-keyring.gpg] https://deb.torproject.org/torproject.org $(lsb_release -sc) main" >> /etc/apt/sources.list.d/tor-project.list'

$ apt update

$ apt install tor

Einrichtung eines systemd-Dienstes

Erstellt einen separaten Prozess für jeden verbundenen Hidden Service, um zu vermeiden, dass jede Verbindung neu gestartet werden muss, wenn ein Dienst hinzugefügt oder entfernt wird. Vorteilhaft wäre es, den verwendeten Port und den Dienstnamen im Namen des Dienstes anzugeben, z.B. tor2ip<VPS_PORT>_<lnd>.

Erstellt die Dienstdatei

nano /etc/systemd/system/tor2ip9236_lnd.service

Fügt den folgenden Inhalt ein und passt die Variablen an:

• VPS_PORT: Der Port, der öffentlich zugänglich sein soll (in diesem Beispiel: 9236).
• TOR_HIDDEN_SERVICE_ADDRESS.onion: Die Adresse des Hidden Services.
  • Die Adresse erhaltet ihr auf dem Raspiblitz für Lightning zum Beispiel mit:
    lncli getinfo
• TOR_PORT: Der Port, den der Hidden Service verwendet (in diesem Beispiel für LND: 9735).

[Unit]
Description=Tor2IP Tunnel Service
After=network.target

[Service]
User=root
Group=root
ExecStart=/usr/bin/socat TCP4-LISTEN:9236,bind=0.0.0.0,fork SOCKS4A:localhost:TOR_HIDDEN_SERVICE_ADDRESSE.onion:9735,socksport=9050
StandardOutput=journal

[Install]
WantedBy=multi-user.target

TOR_HIDDEN_SERVICE_ADRESS ist dabei die Adresse vom Raspiblitz die ihr mit lncli getinfo auf dem Raspiblitz erhalten habt:

Die Tor Adresse ist der Teil nach dem @!

Dienst aktivieren und starten

systemctl enable tor2ip9236_lnd
systemctl start tor2ip9236_lnd

Überprüfung und Überwachung

Überprüft, ob der Tunnel aktiv ist mit:

netstat -tulpn

Achtet auf die Zeile:

tcp        0      0 0.0.0.0:9236            0.0.0.0:*               LISTEN      13684/socat  

Dienst überwachen

   systemctl status tor2ip9236

Beispielausgabe:

   ● tor2ip9236_lnd.service - Tor2IP Tunnel Service
      Loaded: loaded (/etc/systemd/system/tor2ip9236.service; enabled; vendor preset: enabled)
      Active: active (running) since Sun 2024-06-20 14:58:43 BST; 2min 23s ago
    Main PID: 13684 (socat)
       Tasks: 1 (limit: 1078)
      Memory: 540.0K
      CGroup: /system.slice/tor2ip9236.service
              └─13684 /usr/bin/socat TCP4-LISTEN:9236,bind=0.0.0.0,fork SOCKS4A:localhost:TOR_HIDDEN_SERVICE_ADDRESS.onion:9735,socksport=9050

   Jun 20 14:58:43 VPS_hostname systemd[1]: Started Tor2IP Tunnel Service.

Port freigeben auf dem VPS Server

In den Server Einstellungen bei eurem VPS Provider muss der Port 9236 wie in diesem Beispiel freigegeben werden. Bei Ionos findet ihr die Einstellungen unter Netzwerk -> Firewall Richtlinien:

Abschluss

Herzlichen Glückwunsch! Ihr habt erfolgreich einen Tor-to-IP-Tunnel-Dienst eingerichtet. Ihr könnt nun weitere Dienste hinzufügen, indem ihr unterschiedliche Ports auf dem VPS verwendet. Um auf die Ports/Dienste des Host-Computers zuzugreifen, verwendet dazu einfach die VPS_IP_ADRESSE:VPS_PORT.

Beispiel für die Verbindung zu LND. Eure Peers können sich nun mit der IP Adresse eures VPS und dem entsprechenden Port mit euch verbinden:

lncli connect NODE_PUBLIC_KEY@VPS_IP_ADRESSE:9236

Mit dieser Konfiguration im Artikel "Tor Dienste mit IP2Tor auf dem Raspiblitz via Clearnet ansprechen" habt ihr eine sichere und anonyme Möglichkeit geschaffen, Tor Hidden Services im Clearnet zugänglich zu machen. Achte darauf, die Sicherheit deiner Dienste stets im Auge zu behalten und die Regeln deines VPS-Anbieters zu beachten.

Resourcen:

https://github.com/openoms/bitcoin-tutorials/blob/master/tor2ip_tunnel.md

The post Tor Dienste mit IP2Tor auf dem Raspiblitz via Clearnet ansprechen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Denn der Gewinn ist real, und der Preis auch. Wer viele Kanäle betreibt, kennt das Problem: Tor-Verbindungen brauchen länger, brechen häufiger ab, und bei zeitkritischen HTLC-Weiterleitungen entscheidet das darüber, ob eine Zahlung über euch läuft oder über jemand anderen. Wer dagegen in Ruhe ein paar Kanäle für den Eigenbedarf hält, hat von Clearnet wenig und verschenkt dafür den Standort seines Anschlusses. Dieser Artikel zeigt, wie ihr den Hybridmodus einrichtet — und woran ihr vorher erkennt, ob ihr ihn überhaupt wollt.

Was der LND Hybrid Mode macht — und was nicht

Eingeführt wurde die Betriebsart mit LND 0.14.0-beta. In den Release Notes steht dazu wörtlich: „A new flag has been added to enable a hybrid tor connectivity mode, where tor is only used for onion address connections, and clearnet for everything else." Dieses Flag heisst tor.skip-proxy-for-clearnet-targets, und mehr ist es im Kern nicht.

Wichtig ist der Unterschied zwischen ausgehend und eingehend. Ausgehend entscheidet LND ab sofort je Gegenstelle, welchen Weg es nimmt. Eingehend ändert sich erst dann etwas, wenn ihr der Node zusätzlich eine öffentliche Adresse mitgebt und der Port von aussen erreichbar ist. Die Onion-Adresse bleibt in beiden Fällen bestehen — ihr verliert sie nicht, ihr bekommt eine zweite Adresse dazu.

Achtung: Clearnet und die Privatsphäre

Eine Node hinter Tor zu betreiben hat gute Gründe, und für kleinere Nodes ist es weiterhin die naheliegende Wahl. Sobald ihr eine öffentliche Adresse ankündigt, steht sie im Netzwerkgraphen des Lightning-Netzes, und jeder, der den Graphen liest, kann sie einer groben geografischen Lage zuordnen. Das ist keine Randnotiz, sondern die eigentliche Entscheidung dieses Artikels.

LND selbst formuliert das in der Beispielkonfiguration unmissverständlich: „WARNING: This option will reveal the source IP address of the node, and should be used only if privacy is not a concern." Dazu kommt, dass ihr mindestens einen Port (Vorgabe: 9735) von aussen erreichbar machen müsst und damit für die Absicherung des darunterliegenden Systems selbst verantwortlich seid.

Setzt den Hybridmodus also dann ein, wenn Erreichbarkeit, Stabilität und Latenz für euch schwerer wiegen als die Anonymität des Standorts. Wenn ihr das umgekehrt seht, aber trotzdem Clearnet-Vorteile wollt, springt weiter unten zum Abschnitt über Tunnelsats. Und wer sich zuerst grundsätzlich sortieren möchte, findet im Ratgeber zum Schutz der Privatsphäre die Abwägung in allgemeiner Form.

Voraussetzungen: Port, feste IP-Adresse — und kein DS-Lite

Damit eure Node von aussen angesprochen werden kann, müssen drei Dinge stimmen.

1. Zugriff auf den Router. Ihr braucht Zugang zu den Einstellungen, um eine Portweiterleitung anzulegen. Für die NAT-Variante weiter unten muss der Router zusätzlich UPnP beherrschen.
2. Offener Port. Der Standardport für Lightning ist 9735. Er muss auf die lokale IP-Adresse eures RaspiBlitz weitergeleitet sein.
3. Feste lokale IP-Adresse. Bekommt der RaspiBlitz beim nächsten Neustart eine andere Adresse aus dem DHCP-Bereich, zeigt die Weiterleitung ins Leere.

Wie ihr eine Portweiterleitung einrichtet, steht in der Anleitung zur Port-Weiterleitung für Dienste.

Feste IP-Adresse für den RaspiBlitz vergeben

• Netzwerkeinstellungen öffnen. Sucht im Menü eures Routers nach den Netzwerk- oder DHCP-Einstellungen. Die Bezeichnung unterscheidet sich je nach Modell.
• DHCP-Reservierung anlegen. Je nach Hersteller heisst die Funktion „DHCP-Reservierung", „Statische IP" oder „IP-Adressen-Zuweisung".
• Gerät auswählen. Der RaspiBlitz wird meist über seine MAC-Adresse identifiziert. Auslesen könnt ihr sie auf der Node selbst.
• Adresse festlegen und neu starten. Die Adresse muss im Subnetz eures Routers liegen. Danach den RaspiBlitz neu starten, damit er sie auch bezieht.

ip addr
sudo systemctl reboot

Wenn euer Anschluss hinter DS-Lite hängt

Dieser Punkt fehlte in der ursprünglichen Fassung dieses Artikels und ist der häufigste Grund, warum der Hybridmodus am Ende trotzdem nicht funktioniert: Bei einem DS-Lite-Anschluss teilt ihr euch die öffentliche IPv4-Adresse mit anderen Kunden desselben Anbieters. Eine Portweiterleitung auf IPv4 ist dann schlicht nicht möglich, egal was im Routermenü steht. Prüft das, bevor ihr anfangt — welche Wege es in diesem Fall gibt, steht in der Anleitung zu Diensten hinter DS-Lite.

Wo die lnd.conf auf dem RaspiBlitz wirklich liegt

Korrektur gegenüber der früheren Fassung: Dort stand /mnt/hdd/lnd/ als Ablageort der lnd.conf. Das stimmt heute nicht mehr. Das Installationsskript des Projekts legt die Datei unter /mnt/hdd/app-data/lnd/ ab und startet den Dienst mit --configfile=/mnt/hdd/app-data/lnd/lnd.conf.

Ihr müsst euch den Pfad aber gar nicht merken. Dasselbe Skript legt eine Abkürzung an, die immer auf die richtige Datei zeigt — auch dann, wenn ihr Testnet oder Signet parallel betreibt:

lndconf

Das öffnet die Konfiguration im Editor nano. Legt vorher eine Kopie an, dann habt ihr einen Rückweg:

sudo cp /mnt/hdd/app-data/lnd/lnd.conf /mnt/hdd/app-data/lnd/lnd.conf.bak

Der eine Eintrag, auf den es ankommt

In den Abschnitt [tor] der lnd.conf gehört diese Zeile:

[tor]
; Allow the node to connect to non-onion services directly via clearnet. This
; allows the node operator to use direct connections to peers not running behind
; Tor, thus allowing lower latency and better connection stability.
; WARNING: This option will reveal the source IP address of the node, and should
; be used only if privacy is not a concern.

tor.skip-proxy-for-clearnet-targets=true

Dazu gehört eine zweite Bedingung: Die Stream-Isolation muss aus sein. Sie gibt jeder Verbindung einen eigenen Tor-Kanal und verträgt sich mit dem Hybridmodus nicht. Im Leitfaden von blckbx, auf den sich die meisten Anleitungen zu diesem Thema stützen, steht dazu: „tor.streamisolation=false must be turned off/not present when using hybrid-mode".

Auf dem RaspiBlitz müsst ihr euch darum nicht selbst kümmern, und das ist der angenehmste Befund dieser Überarbeitung. Das Prüfskript lnd.check.sh, das vor jedem Start von LND läuft, erkennt euren Eintrag und zieht die passende Einstellung selbst nach:

if [ $(cat ${lndConfFile} | grep -c "^tor.skip-proxy-for-clearnet-targets=true") -gt 0 ] ||
   [ $(cat ${lndConfFile} | grep -c "^tor.skip-proxy-for-clearnet-targets=1") -gt 0 ]; then
  setting ${lndConfFile} ${insertLine} "tor.streamisolation" "false"
fi

Dasselbe Skript setzt auch tor.active, tor.v3 und den listen-Eintrag auf Port 9735. Einen eigenen Menüpunkt für den Hybridmodus hat der RaspiBlitz dagegen bis heute nicht — der Wunsch danach steht seit Jahren als offenes Issue 2787 im Projekt. Die Handarbeit an der lnd.conf bleibt euch also, das Skript nimmt sie euch nur nicht wieder weg.

Die externe Adresse: drei Wege, einer davon fällt weg

Damit eingehende Verbindungen möglich werden, muss LND wissen, unter welcher Adresse eure Node von aussen erreichbar ist. Dafür gibt es drei Möglichkeiten — und auf dem RaspiBlitz scheidet ausgerechnet die einfachste aus.

externalip: auf dem RaspiBlitz nicht haltbar

Bei einer festen öffentlichen IP-Adresse wäre externalip der direkte Weg. Auf dem RaspiBlitz hat dieser Eintrag jedoch keinen Bestand, sobald Tor aktiv ist — und aktiv ist Tor im Hybridmodus immer. Das erwähnte Prüfskript entfernt die Zeile bei jedem Start wieder:

# enforce PublicIP if (if not running Tor)
if [ "${runBehindTor}" != "on" ]; then
  setting ${lndConfFile} ${insertLine} "externalip" "${publicIP}:${lndPort}"
else
  # when running Tor a public ip can make startup problems - so remove
  sed -i '/^externalip=*/d' ${lndConfFile}
fi

Wer sich also wundert, warum die von Hand eingetragene IP-Adresse nach einem Neustart verschwunden ist: Das ist kein Fehler, sondern Absicht. Für nat und externalhosts enthält das Skript keine solche Regel, diese beiden Einträge bleiben stehen.

Variante 1: NAT über UPnP

Mit nat=true versucht LND, die externe Adresse selbst zu ermitteln und bei einem Wechsel nachzuziehen. Die Beispielkonfiguration von LND nennt dazu gleich die Einschränkungen: Beide Techniken „require proper hardware support", und wird sie nicht erkannt, beendet sich LND mit einem Fehler. Ausserdem: „This does not support devices behind multiple NATs."

[Application Options]
listen=0.0.0.0:9735
nat=true

[tor]
tor.active=true
tor.v3=true
tor.skip-proxy-for-clearnet-targets=true

externalip und nat werden dabei nie zusammen gesetzt; LND kommt mit der Kombination nicht zurecht. Der Leitfaden von blckbx geht noch weiter und rät nach Rückmeldungen aus der Praxis ganz davon ab: „Concluding from feedback on this, nat really doesn't work well and should be avoided!" Das ist eine Einschätzung dieses Leitfadens und keine Aussage des LND-Projekts — sie deckt sich aber mit den Einschränkungen, die LND selbst aufführt. Probiert diese Variante, wenn euer Router UPnP zuverlässig beherrscht, und wechselt auf die zweite, wenn es hakt.

Variante 2: DynDNS über externalhosts

Der stabilere Weg bei wechselnder IP-Adresse ist eine DynDNS-Domain. Ein Dienst aktualisiert dabei den DNS-Eintrag auf eure jeweils aktuelle Adresse, und LND löst den Namen regelmässig auf. Wie ihr eine solche Domain anlegt, steht in der Anleitung zum DynDNS-Eintrag bei dynamischer IP. Der gewählte Name spielt keine Rolle.

Die zuständige Option heisst externalhosts. LND beschreibt sie als „A list of domains for lnd to periodically resolve, and advertise the resolved IPs for the backing node".

[Application Options]
listen=0.0.0.0:9735
externalhosts=eure_dyndns_domain:9735

[tor]
tor.active=true
tor.v3=true
tor.skip-proxy-for-clearnet-targets=true

Eine Stolperfalle, die schnell zu einer verlorenen Stunde führt: Der RaspiBlitz hat unter SETTINGS einen eigenen Menüpunkt DynamicDNS. Der ist nützlich, macht aber etwas anderes. Er hinterlegt Domain und Aktualisierungsadresse in der raspiblitz.conf und trägt die Domain in das TLS-Zertifikat von LND ein — damit ihr eure Node unter diesem Namen fernsteuern könnt. In die lnd.conf schreibt er nichts. Den Eintrag externalhosts setzt ihr weiterhin selbst.

Nach jeder Änderung startet ihr LND neu:

sudo systemctl restart lnd.service

Funktionstest: zwei URIs statt einer

Ob die Umstellung gegriffen hat, beantwortet ein einziger Befehl:

lncli getinfo

Im Feld uris müssen jetzt zwei Einträge stehen, einer davon mit eurer öffentlichen Adresse. Die IP-Adresse im folgenden Beispiel ist ein Platzhalter:

"uris": [
    "<euer_pubkey>@203.0.113.17:9735",
    "<euer_pubkey>@<eure_adresse>.onion:9735"
]

Steht dort nur die Onion-Adresse, hat die Ankündigung nicht funktioniert. Die drei häufigsten Ursachen: Die Portweiterleitung zeigt auf die falsche lokale Adresse, der Anschluss liegt hinter DS-Lite, oder es wurde externalip gesetzt und beim Start wieder entfernt. Eine Gegenprobe von aussen liefert eine Gegenstelle, die euch direkt anspricht:

lncli connect <euer_pubkey>@<eure_adresse>:9735

Wer noch keine Gegenstellen hat, die das übernehmen könnten, findet im Beitrag zu Channel Peers finden und Lightning Kanäle eröffnen den Weg dorthin.

Betreibt ihr LNDg, taucht die Clearnet-Adresse dort ebenfalls auf:

Tunnelsats: Clearnet, ohne die eigene Adresse zu zeigen

Tunnelsats ist ein VPN-Dienst, der eigens für Lightning-Nodes gebaut wurde. Statt eurer eigenen IP-Adresse kündigt die Node die Adresse des Tunnelendpunkts an. Ihr bekommt damit eine gleichbleibende öffentliche Adresse und die Latenzvorteile des Clearnets, ohne den eigenen Anschluss offenzulegen — und ohne eine Portweiterleitung im Router, was den Weg auch für DS-Lite-Anschlüsse öffnet.

Bezahlt wird über Lightning im Abonnement; der Monatspreis lag beim Abruf am 13.09.2026 bei rund 3900 Sat, für ein Jahr gibt es einen Rabatt. Die Einrichtung ist aufwendiger als der eine Eintrag oben, aber entlang der Projektanleitung machbar. Der Haken bleibt derselbe wie bei jedem VPN: Ihr tauscht das Wissen eures Internetanbieters gegen das Wissen des Tunnelanbieters.

Wer diesen Tausch nicht eingehen will, kann denselben Aufbau mit einem eigenen kleinen Server nachbauen — die Grundlagen dazu stehen im Beitrag Schnell und einfach einen Wireguard VPN betreiben. Der Aufwand ist deutlich höher, die Kontrolle dafür vollständig.

Worauf ihr achten solltet

• Zuerst DS-Lite prüfen, dann alles andere. Ohne eigene öffentliche IPv4-Adresse führt keine Portweiterleitung zum Ziel, und der ganze Rest ist verlorene Zeit.
• Die Adresse bleibt im Netz, auch nach dem Rückbau. LND kündigt zuvor gesetzte Adressen weiter an, wenn ihr den Eintrag einfach löscht. Sie müssen ausdrücklich zurückgenommen werden — die LND-Beispielkonfiguration nennt dafür lncli peers updatenodeannouncement --address_remove=.
• Legt vor der Änderung eine Kopie der lnd.conf an. Ein Tippfehler im Abschnittsnamen reicht, damit LND nicht mehr startet.
• Erwartet keine neuen Kanäle über Nacht. Der Hybridmodus verbessert Erreichbarkeit und Latenz. Ob jemand einen Kanal zu euch öffnet, entscheiden Gebührenpolitik und Liquidität, nicht die Transportschicht.
• Die Sicherung der Kanäle bleibt Pflicht. Eine besser erreichbare Node ist keine sicherere Node. Wie ihr die channel.backup aus dem Haus bekommt, steht im Backup- und Restore-Leitfaden für Lightning Fullnodes und im Beitrag zum SCB-Backup auf einer Nextcloud.
• Haltet die Node aktuell. Die Angaben hier beziehen sich auf RaspiBlitz 1.12.1; wie ihr aktualisiert, steht in der Anleitung zum Aktualisieren des RaspiBlitz.

Fazit: Der Hybridmodus ist ein Tausch, kein Upgrade

Technisch ist der LND Hybrid Mode eine der unaufwendigsten Verbesserungen, die eine Lightning Node erfahren kann: eine Zeile in der lnd.conf, eine Adresse für eingehende Verbindungen, ein Neustart. Die Wirkung ist messbar — direkte Verbindungen statt Tor-Umwege bedeuten kürzere Laufzeiten und weniger Abbrüche, und wer viele Kanäle führt, merkt das an der Zahl der Weiterleitungen.

Gratis ist das aber nicht. Bezahlt wird nicht in Sat, sondern mit der Preisgabe des eigenen Anschlusses: Die Adresse steht im öffentlichen Netzwerkgraphen, dauerhaft, und lässt sich grob verorten. Wer eine Node aus Neugier oder für den eigenen Zahlungsverkehr betreibt, hat davon wenig und verliert etwas — für den bleibt Tor die richtige Wahl. Wer Routing betreibt und an Verfügbarkeit gemessen wird, kommt an dieser Zeile kaum vorbei. Und wer beides will, findet in Tunnelsats oder einem eigenen Tunnelserver den Mittelweg, der monatlich etwas kostet statt einmalig die Anonymität.

Die einzige falsche Antwort ist, den Schalter umzulegen, ohne die Frage gestellt zu haben.

Quellen und weiterführende Links

• lightningnetwork/lnd — sample-lnd.conf: Wortlaut der Optionen nat, externalip, externalhosts, listen und der Tor-Einstellungen.
• lightningnetwork/lnd — Release Notes 0.14.0: Einführung des Hybridmodus.
• raspiblitz/raspiblitz — lnd.check.sh: Prüfskript vor dem Start von LND, setzt tor.streamisolation und entfernt externalip bei aktivem Tor.
• raspiblitz/raspiblitz — lnd.install.sh: Ablageort der lnd.conf und die Abkürzung lndconf.
• raspiblitz/raspiblitz — internet.dyndomain.sh: was der Menüpunkt DynamicDNS tatsächlich setzt.
• raspiblitz/raspiblitz — Issue 2787: offener Wunsch nach einem eigenen Menüpunkt für den Hybridmodus.
• blckbx/lnd-hybrid-mode: der Leitfaden, auf dem die meisten Anleitungen zum Thema aufbauen.
• tunnelsats.com: Preise und Regionen, abgerufen am 13.09.2026.

The post Raspiblitz Lightning LND via clearnet im Hybrid Mode appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitungen

Auf eurer Lightning Full Node muss LND laufen, und es müssen natürlich ein paar Kanäle vorhanden sein, damit das ganze Sinn ergibt. Lightningshell für LND benötigt ihr nicht. Das ganze lässt sich normal via SSH Zugang installieren. Loggt euch via SSH auf euer Umbrel System ein. Zuerst erstellen wir uns ein paar Standard Ordner, und notieren uns die LND Container IP:

sudo mkdir -p /mnt/data/upgrades/charge-lnd
sudo touch /mnt/data/upgrades/charge-lnd/charge.config

Der erste Befehl erstellt den Ordner, indem wir unseren Konfigurationsdatei ablegen, der zweite Befehl die Konfigurationsdatei charge.config

Danach müssen wir uns die IP des LND Containers notieren, das geht mit dem Befehl:

sudo cat ~/umbrel/.env

Wir bekommen eine Übersicht aller Verbindungsdaten zum den Diensten wie Bitcoin Core und LND. Wir notieren uns die LND IP Adresse:

Das wäre in meinem Fall die IP 10.21.21.9 und der Standard LND gRPC Port 10009

Charge LND installieren und ausführen

Charge LND müssen wir nicht direkt installieren. Das ganze kommt fertig in einem Docker Container. Da Umbrel bereits Docker komplett eingerichtet hat, müssen wir auch nichts mehr installieren. In einem nächsten Artikel zum Blitz, zeigen wir euch die Installation auf einem System ohne Docker.

Um Charge LND auszuführen benötigen wir nur einen einzigen Befehl. Dieser stellt sicher dass sich charge-lnd mit dem Umbrel Docker Netzwerk verbinden kann, sich mit LND selber befinden kann und ausserdem weiss wo sich wichtige Dateien wie die admin.macaroon befinden. Mit diesem Befehl führt ihr charge-lnd einmal aus, und ruft die Konfigurationsdatei ab:

docker run --rm -it --network=umbrel_main_network -e GRPC_LOCATION=LND_IP:10009 -e LND_DIR=/data/.lnd -e CONFIG_LOCATION=/app/charge.config -v /root/umbrel/app-data/lightning/data/lnd:/data/.lnd -v
/mnt/data/upgrades/charge-lnd/charge.config:/app/charge.config accumulator/charge-lnd:latest

In diesem Beispiel müsst ihr die LND_IP mit eurer notierten LND IP Adresse ersetzen! Führt ihr diesem Befehl aus, wird erstmal nicht viel passieren, da eure charge.config noch leer ist.

Charge-lnd konfigurieren

Die Konfigurationsmöglichkeiten für charge-lnd sind wirklich enorm. Deshalb zeigen wir euch erstmal nur eine Konfiguration, die verhindert, dass der Kanal unter die Kanal-Reserve leergezogen wird, was zu einem Force-Closure führen wird. Dies ist ein LND Bug der erst mit der Version 0.18 behoben wird.

Öffnet mit

sudo nano /mnt/data/upgrades/charge-lnd/charge.config

die Konfigurationsdatei, und platziert folgenden Inhalt hinein:

[default]
# no strategy, just defaults
# not setting min automatically to allow manually setting some channels
# min_htlc_msat = 1000
max_htlc_msat_ratio = 1

[inbound_only]
# these are channels that we are either setting up to close (we have opened bigger channels)
# or that we are using for rebalance out only
# ACINQ: 916131780004872194
chan.id = 916131780004872194
base_fee_msat = 0
fee_ppm = 0
strategy = disable

[100%-5%]
chan.min_ratio = 0.05
strategy = static
# only allow up to 95% of channel capacity to be used in a single HTLC
max_htlc_msat_ratio = 0.95

# to prevent draining channel too much, disable when it gets to 5% or lower
# this also will hopefully catch it before the LND pre-0.18 bug of hitting below-reserve limit and force-closing
[5%-0%]
chan.max_ratio = 0.05
strategy = disable

Dies ist die Standard Konfiguration von Zapo-Matic, einem befreundetem Node-Runner aus dem Lightning Netzwerk. Der Link dazu hier!

Weitere Konfigurations Beispiele gibts bei charge-lnd auf der Github Seite selber:

https://github.com/accumulator/charge-lnd/tree/master/examples

Schaut euch mal die Konfigurationen an, ihr könnt damit alle möglichen Szenarien abdecken auf Basis von vorgegeben Werten und Variablen.

https://github.com/accumulator/charge-lnd?tab=readme-ov-file#more-examples

Crontab erstellen

Bei jedem ausführen des Befehls, wird die charge.config nur einmal abgerufen, und charge-lnd führt die darin enthaltenen Konfigurationen aus. Damit HTLC Anpassungen die auf vorhandene Kapazität zum Beispiel regelmässig angepasst werden, muss charge-lnd regelmässig ausgeführt werden. Bei dynamischen HTLC Anpassungen, wie zum Beispiel in dieser Konfiguration, ist eine ausführung alle 5 Min bei einer Node, auf der sich viel bewegt, empfehlenswert. Bei einer kleineren Node, reicht auch eine Ausführung alle 60 Minuten.

Öffnet mit sudo crontab -e den Crontab Editor, und fügt am Ende folgende Zeile hinzu:

5/* * * * * docker run --rm -it --network=umbrel_main_network -e GRPC_LOCATION=LND_IP:10009 -e LND_DIR=/data/.lnd -e CONFIG_LOCATION=/app/charge.config -v /root/umbrel/app-data/lightning/data/lnd:/data/.lnd -v
/mnt/data/upgrades/charge-lnd/charge.config:/app/charge.config accumulator/charge-lnd:latest

Möchtet ihr eine stündliche ausführen, wäre dass zum Beispiel 0 */1 * * * also:

0 */1 * * * docker run --rm -it --network=umbrel_main_network -e GRPC_LOCATION=LND_IP:10009 -e LND_DIR=/data/.lnd -e CONFIG_LOCATION=/app/charge.config -v /root/umbrel/app-data/lightning/data/lnd:/data/.lnd -v
/mnt/data/upgrades/charge-lnd/charge.config:/app/charge.config accumulator/charge-lnd:latest

Mit dem crontab guru könnt ihr mit die Crontab Zeitangaben etwas herumexperimentieren.

Nun wird die Konfiguration entsprechend des Zeitintervals regelmässig ausgeführt.

Abschluss

Das Tool charge-lnd erweist sich als eine wertvolle Ressource für Lightning Node Betreiber im Lightning Network, indem es eine flexible und effiziente Verwaltung von Gebühren ermöglicht. Die Installation des Tools ist durch die detaillierten Anweisungen im Bericht klar und unkompliziert gestaltet, wodurch Nutzer auch ohne tiefgreifende technische Vorkenntnisse in der Lage sind, "charge-lnd" erfolgreich einzurichten. Die Vielfalt der Konfigurationsmöglichkeiten, darunter die Einstellung von Gebühren für Autobalancing, die Nutzung von On-Chain-Gebühren als Referenz und die Anpassung an die Kanalaktivität, bietet Nutzern die Flexibilität, ihre Gebührenstrategien präzise auf ihre spezifischen Bedürfnisse und Ziele abzustimmen. Abschließend lässt sich sagen, dass "charge-lnd" nicht nur eine Lösung zur Optimierung von Gebührenstrukturen bietet, sondern auch dazu beiträgt, die allgemeine Effizienz und Rentabilität von Lightning-Netzwerkaktivitäten zu verbessern. Wer mehr lieber mit einer Weboberfläche Fee Anpassungen tätigt, der ist mit LNDg besser beraten, jedoch muss dort, für dynamische HTLC Anpassung, auch das Algorythmus, welcher in Python geschrieben ist, anpassen.

Interessiert Ihr euch für eine Fullnode? Schaut bei uns im Shop vorbei, wir bieten vorinstallierte Lightning Full Nodes auf Basis vom Raspi 4 und 5 an.

The post Charge-lnd auf Umbrel installieren appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Wer gerade erst eine Node aufsetzt, legt sich diese Anleitung für später zur Seite. Eine Datenbank, die nie aufräumt, benimmt sich wie ein Keller: Lange fällt nichts auf, und dann passt eines Tages das Fahrrad nicht mehr hinein. Die Anleitung erschien erstmals im März 2024 und ist im September 2026 gegen die aktuelle LND-Beispielkonfiguration, den Quelltext von LND sowie die Repositories von RaspiBlitz und BTCPay Server geprüft worden.

Warum die channel.db wächst und wann ihr sie verkleinern solltet

Die channel.db ist die zentrale Datenbank einer LND-Node im Lightning-Netzwerk, der Zahlungsschicht auf Bitcoin. Darin liegen Kanalzustände, Rechnungen, Zahlungen und der Netzwerkgraph. Sie liegt im Unterordner data/graph/mainnet/ des LND-Verzeichnisses und wächst mit der Zeit immer weiter an.

Der Grund liegt im Speicherformat. LND verwendet standardmässig die Datenbank bbolt; laut der Beispielkonfiguration sample-lnd.conf ist bolt weiterhin das voreingestellte Backend, Postgres und SQLite sind Alternativen. Die Projektbeschreibung von bbolt hält fest, dass die Datenbank ihre Datei nicht kürzen und freie Seiten nicht an das Dateisystem zurückgeben kann; sie führt sie intern in einer Freiliste und verwendet sie später wieder. Die Datei wird also nicht kleiner, auch wenn darin weniger steht. Erst eine Kompaktierung schreibt den Inhalt dicht gepackt in eine neue Datei. Eine kleinere Datei heisst weniger Arbeit beim Start und weniger Speicherbedarf; wer in letzter Zeit merkt, dass seine Node träge reagiert, findet hier oft eine Ursache.

Eine Einschränkung vorweg: Seit einigen Versionen kann LND Rechnungen und den Graphen auch in nativen SQL-Tabellen führen (db.use-native-sql, Vorgabe false). Wer seine Node auf Postgres oder SQLite betreibt, hat keine bbolt-Kanaldatenbank und kann diese Anleitung überspringen. Für die üblichen Node-Pakete wie Umbrel, RaspiBlitz und BTCPay Server gilt sie.

Warum ich diesen Artikel geschrieben habe: Auf GitHub gibt es etliche Beiträge über grosse Datenbankdateien und immer langsamere Nodes, aber kaum eine zusammenhängende Anleitung, wie ihr die Kompaktierung selbst einrichtet.

channel.db Grösse überprüfen

Die Grösse der channel.db prüft ihr mit ls -lh. Als Faustregel aus meinem eigenen Betrieb: Ab rund 3 GB lohnt sich die erste Kompaktierung. Das ist ein Erfahrungswert, keine Vorgabe von LND. Je nach System liegt die Datei hier:

Umbrel (Pfad aus der Zeit vor umbrelOS 1.x, siehe Hinweis unten)

ls -lh /root/umbrel/app-data/lightning/data/lnd/data/graph/mainnet/

RaspiBlitz

sudo ls -lh /mnt/hdd/app-data/lnd/data/graph/mainnet/

BTCPay Server

ls -lh /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/graph/mainnet/

Beim RaspiBlitz stand hier früher /mnt/hdd/lnd/. Die aktuellen Installations- und Prüfskripte des Projekts (lnd.install.sh, lnd.check.sh) arbeiten durchgehend mit /mnt/hdd/app-data/lnd/. Beim Umbrel-Pfad gilt: Er stammt aus der Zeit vor umbrelOS 1.x. Ob er auf einem heutigen umbrelOS noch genau so lautet, liess sich für diese Überarbeitung nicht prüfen.

Exemplarisch, bei mir war die channel.db nach der Kompaktierung 2,6 GB gross, vorher rund 4,7 GB:

Wie LND die Datenbank kompaktiert

Bevor es an die einzelnen Systeme geht, lohnt ein Blick darauf, was die Kompaktierung tatsächlich tut. Das erklärt nämlich zwei Aussagen, die in älteren Anleitungen — auch in der ersten Fassung dieser hier — falsch standen.

Gesteuert wird sie über zwei Optionen im Abschnitt [bolt] der lnd.conf. db.bolt.auto-compact schaltet sie ein; laut sample-lnd.conf ist sie ab Werk aus, weil sie während des Vorgangs zusätzlichen Speicherplatz braucht. db.bolt.auto-compact-min-age legt fest, wie lange die letzte Kompaktierung zurückliegen muss, bevor LND beim nächsten Start erneut kompaktiert. Die Vorgabe ist 168h, also eine Woche. Wer 0 einträgt, kompaktiert bei jedem Start.

Daraus folgt: Wer nur db.bolt.auto-compact=true setzt, kompaktiert nicht bei jedem Neustart, sondern höchstens einmal pro Woche. Die Zeile db.bolt.auto-compact-min-age=168h schadet nicht, wiederholt aber nur den Standardwert. Und wer die Kompaktierung ausschaltet, bekommt keine Kompaktierung — nicht etwa eine bei jedem Start.

Den Ablauf beschreibt der Quelltext in kvdb/backend.go: LND schreibt den verdichteten Inhalt in eine temporäre Datei namens temp-dont-use.db und tauscht sie erst danach per Umbenennen gegen die alte aus. Vorher prüft kvdb/bolt_compact.go, ob auf dem Datenträger genug Platz für eine vollständige Kopie plus zehn Prozent Reserve frei ist; sonst beginnt die Kompaktierung gar nicht erst. Den Zeitpunkt der letzten Kompaktierung merkt sich LND in einer Datei neben der Datenbank, channel.db.last-compacted. Fehlt diese Datei, kompaktiert LND beim nächsten Start.

channel.db kompaktieren auf Umbrel, BTCPay Server und RaspiBlitz

Wir schauen uns die Kompaktierung auf drei Systemen an: BTCPay Server, Umbrel und dem RaspiBlitz. Welche Zusatzoptionen dabei sinnvoll sind, steht gesammelt im Abschnitt danach.

Umbrel Fullnode

Auf Umbrel geschieht das über die Oberfläche der Lightning-Node-App. Öffnet die App und geht oben rechts über die drei Punkte in die Einstellungen. Die folgenden Bildschirmfotos stammen vom März 2024 und zeigen die Oberfläche vor umbrelOS 1.x; wie die Einstellungen heute genau heissen und wo sie sitzen, liess sich für diese Überarbeitung nicht prüfen.

Navigiert hinunter zu den Optimierungen und aktiviert diese Einstellungen:

db.bolt.auto-compact=true
db.bolt.auto-compact-min-age=168h
gc-canceled-invoices-on-startup=true
gc-canceled-invoices-on-the-fly=true
ignore-historical-gossip-filters=true
stagger-initial-reconnect=true

Achtet auf die kleine, rot markierte Beschriftung, dann findet ihr die richtigen Schalter:

Die erste Fassung dieser Anleitung empfahl hier zusätzlich sync-freelist und payments-expiration-grace-period=9999h. Beides steht nicht mehr in der Liste; warum, erklärt der Abschnitt über die übrigen Optionen.

BTCPay Server

Auf dem BTCPay Server gibt es für die Kompaktierung ein fertiges Fragment namens opt-lnd-autocompact. Es tut genau eines: Es hängt die Zeile db.bolt.auto-compact=true an die LND-Konfiguration. Loggt euch per SSH ein, werdet root und wechselt in das Verzeichnis, in das btcpayserver-docker bei der Installation geklont wurde — nach der Installationsanleitung im Repository ist das BTCPayServer/btcpayserver-docker im Home-Verzeichnis von root:

sudo su -
cd BTCPayServer/btcpayserver-docker
export BTCPAYGEN_ADDITIONAL_FRAGMENTS="$BTCPAYGEN_ADDITIONAL_FRAGMENTS;opt-lnd-autocompact"
. ./btcpay-setup.sh -i

Vergesst den Punkt vor ./btcpay-setup.sh nicht. Danach erzeugt das Skript die Docker-Konfiguration neu und startet die Container mit den neuen Einstellungen. Die aktuelle Dokumentation im Repository nennt dafür inzwischen auch den kürzeren Befehl btcpay-fragments add opt-lnd-autocompact; im Fragmentkatalog steht das Fragment als „Enable LND database auto-compaction“.

In der ersten Fassung stand hier, der Server kompaktiere mit diesem Fragment bei jedem Neustart, und db.bolt.auto-compact-min-age lasse sich nur über einen Umweg setzen. Das stimmt nicht: Weil LND ohne weitere Angabe den Standardwert von 168 Stunden nimmt, kompaktiert der Server höchstens einmal pro Woche.

Wer weitere Optionen setzen will, legt ein eigenes Fragment an. Wichtig, und in der ersten Fassung falsch: Ein Fragment ist eine YAML-Datei im Format von Docker Compose, keine lnd.conf. Die LND-Zeilen gehören in die Variable LND_EXTRA_ARGS des Dienstes lnd_bitcoin, genau so wie im mitgelieferten Fragment. Laut der Anleitung zur Anpassung enden eigene Fragmente auf .custom.yml, damit Git sie bei Updates in Ruhe lässt:

nano docker-compose-generator/docker-fragments/opt-lnd-additionals.custom.yml

services:
  lnd_bitcoin:
    environment:
      LND_EXTRA_ARGS: |
        gc-canceled-invoices-on-startup=true
        gc-canceled-invoices-on-the-fly=true
        ignore-historical-gossip-filters=true
        stagger-initial-reconnect=true

Speichert mit Strg+O und beendet mit Strg+X. Der Generator hängt mehrzeilige Werte aus mehreren Fragmenten aneinander, statt sie zu überschreiben; die Zeilen landen also zusätzlich zu den bestehenden. Aktiviert das Fragment wie oben:

export BTCPAYGEN_ADDITIONAL_FRAGMENTS="$BTCPAYGEN_ADDITIONAL_FRAGMENTS;opt-lnd-additionals.custom"
. ./btcpay-setup.sh -i

Die Liste aller mitgelieferten Fragmente steht im Fragmentkatalog der BTCPay-Dokumentation.

RaspiBlitz Fullnode

Auf dem RaspiBlitz ist die Kompaktierung bereits eingeschaltet. Das Installationsskript schreibt in den Abschnitt [bolt] der lnd.conf die Zeilen db.bolt.auto-compact=true und db.bolt.auto-compact-min-age=672h; kompaktiert wird also höchstens alle vier Wochen, jeweils beim Start von LND. Die übrigen empfehlenswerten Optionen — gc-canceled-invoices-on-startup, gc-canceled-invoices-on-the-fly, ignore-historical-gossip-filters und stagger-initial-reconnect — setzt es bei Neuinstallationen ebenfalls schon.

Die erste Fassung empfahl an dieser Stelle, die Zahl in der lnd.conf herunterzusetzen. Das hält nicht: Vor jedem Start von LND läuft lnd.check.sh prestart und setzt beide Werte im Abschnitt [bolt] wieder auf true und 672h zurück. Eine Handänderung ist nach dem nächsten Neustart weg.

Wollt ihr die Kompaktierung sofort auslösen, statt bis zu vier Wochen zu warten, geht das über die Zeitstempeldatei aus dem Abschnitt oben. Fehlt sie, kompaktiert LND beim nächsten Start. Stoppt zuerst LND:

sudo systemctl stop lnd.service

Prüft, ob die Datei vorhanden ist, und entfernt sie:

sudo ls -l /mnt/hdd/app-data/lnd/data/graph/mainnet/
sudo rm /mnt/hdd/app-data/lnd/data/graph/mainnet/channel.db.last-compacted

Startet LND wieder:

sudo systemctl start lnd.service

Den Verlauf verfolgt ihr im LND-Log, das der RaspiBlitz hier ablegt:

sudo tail -f /mnt/hdd/app-data/lnd/logs/bitcoin/mainnet/lnd.log

LND meldet den Beginn mit „Compacting database file at …“ und den Abschluss mit „DB compaction of … successful“ samt Grösse vorher und nachher. Wenn LND gar nicht erst hochkommt, hilft sudo journalctl -u lnd weiter; mehr dazu steht in der Anleitung zur Problembehebung im systemd.

Das folgende Bildschirmfoto vom März 2024 zeigt, wo die Optionen in der lnd.conf stehen. Die db.bolt-Zeilen gehören unter [bolt], die übrigen unter [Application Options]; so ist auch die sample-lnd.conf aufgebaut. Die Datei liegt heute unter /mnt/hdd/app-data/lnd/lnd.conf.

Wer seinen RaspiBlitz ohnehin aktualisieren will, findet die Schritte in der Anleitung RaspiBlitz auf die neueste Version aktualisieren. Welches der beiden Node-Pakete zu euch passt, klärt RaspiBlitz VS Umbrel.

Was die übrigen Optionen tun — und welche ihr weglasst

In vielen Anleitungen, auch in der ersten Fassung dieser hier, wird ein ganzer Block an Optionen mitkopiert. Was jede davon laut sample-lnd.conf tut:

• gc-canceled-invoices-on-startup=true räumt beim Start abgebrochene Rechnungen aus der Datenbank. Sinnvoll für alle, die viele Rechnungen erzeugen.
• gc-canceled-invoices-on-the-fly=true löscht neu abgebrochene Rechnungen sofort, statt sie aufzubewahren.
• ignore-historical-gossip-filters=true beantwortet Anfragen anderer Nodes nach historischen Gossip-Daten nicht. Laut Beschreibung senkt das Speicher- und Bandbreitenbedarf.
• stagger-initial-reconnect=true verteilt die Wiederverbindung zu festen Peers beim Start zufällig über 0 bis 30 Sekunden; die ersten zehn Verbindungen laufen trotzdem sofort.

Zwei Optionen aus der ersten Fassung sind gestrichen:

sync-freelist stand dort als start sync-freelist=1. Das Wort „start“ davor gehört nicht zum Optionsnamen; so eingetragen ist die Zeile schlicht ungültig. Wichtiger ist die Sache selbst: Laut sample-lnd.conf verkürzt die Option die Startzeit, kann aber bei sehr grossen Datenbanken die Leistung verschlechtern und den Speicherbedarf erhöhen — also genau bei den Nodes, für die diese Anleitung gedacht ist. Das RaspiBlitz-Projekt hat sie nach Issue 3251 („don't use sync-freelist=true in lnd.conf“) aus der Vorgabe genommen; ein Nutzer berichtet dort von einer channel.db, die mit der Option um 600 MB bis 1 GB pro Tag wuchs und ohne sie um 100 MB in sieben Tagen. Das Installationsskript kommentiert die Option inzwischen mit dem Rat, sie bei Nodes mit vielen Kanälen auf false zu setzen.

payments-expiration-grace-period=9999h hat mit der Datenbankgrösse nichts zu tun. Laut Beschreibung ist das die Wartezeit, bevor LND einen Kanal schliesst, in dem eine selbst ausgelöste Zahlung abgelaufen ist; die Vorgabe ist 0s, das Beispiel in der Dokumentation 30s. 9999 Stunden sind gut 416 Tage und schalten diese Schutzreaktion für eigene Zahlungen damit praktisch ab. Wer das will, soll es bewusst entscheiden — in einer Anleitung zum Aufräumen der Datenbank hat es nichts verloren.

Achtung: Kompaktierung braucht Zeit und freien Speicher

Auf einem kleinen System kann die Kompaktierung lange dauern. Auf einem RaspiBlitz mit mehreren Dutzend Kanälen und einer channel.db von mehreren Gigabyte habe ich ein bis drei Stunden erlebt. Solange sie läuft, ist LND noch nicht gestartet und die Node nicht erreichbar. Wartet ab. Startet die Node in dieser Zeit nicht neu und zieht nicht den Stecker.

In der ersten Fassung stand hier, bei einem Abbruch seien alle Kanäle mit hoher Wahrscheinlichkeit beschädigt. Das gibt der Quelltext nicht her: Weil LND in eine temporäre Datei schreibt und die alte erst nach erfolgreichem Abschluss ersetzt, bleibt die ursprüngliche channel.db bei einem Abbruch unangetastet, und beim nächsten Kompaktierungslauf löscht LND die halbfertige Kopie, bevor es neu beginnt. Ein harter Stromausfall bleibt trotzdem ein Risiko für jede Datenbank und jede SSD — dafür braucht es keine Kompaktierung.

Der RaspiBlitz gibt LND beim Start übrigens TimeoutStartSec=1200, also zwanzig Minuten, und begründet das in der Unit-Datei ausdrücklich mit der Datenbankkompaktierung. Wer eine sehr grosse Datenbank hat und beobachtet, dass LND während der Kompaktierung neu gestartet wird, findet hier den ersten Anhaltspunkt.

Bevor ihr LND neu startet

• Freien Platz prüfen. Auf dem Datenträger muss mindestens die Grösse der channel.db plus zehn Prozent frei sein, sonst bricht LND die Kompaktierung vor dem Start ab. Bei einer vollen SSD hilft zuerst mehr Platz, etwa mit der Anleitung Fullnode 1TB SSD auf 2TB SSD klonen.
• Kanalsicherung aktuell halten. Die Kompaktierung ist kein Backup und ersetzt keines. Wie ihr eine Node richtig sichert und warum eine alte channel.db nie zurückgespielt werden darf, steht im Backup- und Restore-Leitfaden für Lightning Fullnodes; eine automatische Sicherung der Kanal-Notfalldatei beschreibt RaspiBlitz SCB Backup auf einer Nextcloud.
• Zeit einplanen. Löst die Kompaktierung nicht mitten in einer Phase aus, in der ihr die Node dringend braucht, etwa vor einer erwarteten Zahlung.
• Keine Optionen doppelt setzen. Auf dem RaspiBlitz sind die meisten Optionen schon gesetzt; wer sie ein zweites Mal in die lnd.conf schreibt, erzeugt nur Verwirrung beim nächsten Nachsehen.
• Das Log mitlesen. Nur die Meldung „DB compaction of … successful“ sagt euch, dass es geklappt hat und wie viel es gebracht hat.

Fazit: Die Kompaktierung ist ein Schalter, kein Eingriff

Die channel.db zu verkleinern ist kein riskantes Handwerk an der offenen Datenbank. Es ist eine Funktion, die LND selbst mitbringt, die ab Werk ausgeschaltet ist und die mit einer Zeile dauerhaft läuft. Auf dem RaspiBlitz ist sie schon an, auf dem BTCPay Server reicht ein Fragment, auf Umbrel ein Schalter. Mit den ls -lh-Befehlen oben prüft ihr anschliessend, was es gebracht hat.

Die Kanaldatenbank wächst trotzdem weiter. Nach einem Jahr Routing mit vielen Kanälen habe ich Datenbanken von 15 bis 20 GB gesehen. Wichtig ist, regelmässig zu kompaktieren und dafür genug Ressourcen zu haben. Für grössere Routing-Nodes ist ein RaspiBlitz auf einem Raspberry Pi deshalb nicht die richtige Hardware; mehr zur Frage, was eine Bitcoin Full Node leisten muss, steht im Grundlagenartikel. Und wer von der Kompaktierung die Lösung aller Probleme erwartet, sollte wissen: Sie räumt den Keller auf, sie baut keinen grösseren.

Quellen und weiterführende Links

• LND: sample-lnd.conf (Beschreibung und Vorgabewerte aller genannten Optionen)
• LND: kvdb/backend.go (Ablauf der Kompaktierung, temporäre Datei, .last-compacted)
• LND: kvdb/bolt_compact.go (Prüfung des freien Speichers)
• LND: Releases
• bbolt: Projektbeschreibung, Abschnitt zu Einschränkungen (Datei schrumpft nicht)
• RaspiBlitz: lnd.install.sh und lnd.check.sh
• RaspiBlitz: Issue 3251, „don't use sync-freelist=true in lnd.conf“
• BTCPay Server: Fragment opt-lnd-autocompact, Anleitung zu eigenen Fragmenten und Fragmentkatalog
• BTCPay Server: btcpayserver-docker, Installationsanleitung

The post channel.db auf LND Lightning Nodes verkleinern appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Phoenix Wallet im Detail

Phoenix ist bewusst einfach gehalten. Ihr müsst kein Lightning-Experte sein, um sie zu nutzen: Die App öffnet und verwaltet die Zahlungskanäle selbst, ihr seht im Alltag nur Guthaben, Empfangen und Senden. Das Setup ist in wenigen Minuten erledigt. Was dahinter passiert, lohnt sich trotzdem zu verstehen, weil es bestimmt, was die Wallet kostet und wem ihr dabei vertraut.

Self-Custodial: die Schlüssel liegen bei euch

Der Begriff "Self-Custodial" bedeutet, dass nur ihr als Nutzer den Zugriff auf eure Coins habt. Beim Anlegen einer Wallet erzeugt Phoenix eine Wiederherstellungsphrase aus zwölf Wörtern; die App bezeichnet sie als "BIP39 seed with standard BIP84 derivation path". Das README des Projekts sagt es unmissverständlich: Nur ihr habt diese Phrase, ihr seid für die Sicherung verantwortlich, und wer sie verliert, verliert das Guthaben. Im Gegensatz zu einer Custodial-Lösung wie der Wallet of Satoshi, bei der der Anbieter die Schlüssel verwaltet, behaltet ihr bei Phoenix die Kontrolle.

Ein einziger Kanal, der mitwächst

Im Lightning Netzwerk braucht es Zahlungskanäle, um Zahlungen senden und empfangen zu können. Phoenix verbindet euch dafür mit einem Kanal direkt zum Knoten von ACINQ, der die Zahlungen weiterleitet. Seit dem Umbau auf Splicing im Juli 2023 hat jeder Nutzer laut ACINQs Ankündigung nur noch einen einzigen Kanal ("each user has only one channel"), der bei Bedarf vergrössert oder verkleinert wird, statt dass neue Kanäle danebengelegt werden. Ihr müsst also keine Kanäle von Hand öffnen oder schliessen.

On-Chain und Lightning in einer App

Phoenix kann sowohl On-Chain-Bitcoin empfangen als auch über Lightning bezahlen. On-Chain-Einzahlungen landen zuerst in einer sogenannten Swap-in-Wallet und werden von dort automatisch in den Lightning-Kanal übertragen, sobald die Gebühr unter der von euch festgelegten Grenze liegt. Ihr müsst also nicht zwischen zwei Wallets wechseln. Ausgehende On-Chain-Zahlungen laufen ohne Tauschdienst direkt aus dem Kanal; ACINQ beschreibt das in der Splicing-Ankündigung als "trustless", die Gebühr setzt ihr selbst und könnt sie nachträglich erhöhen.

Eigener Electrum-Server und Tor

Um die Kanäle abzusichern, beobachtet Phoenix die Bitcoin-Blockchain über Electrum-Server. Ab Werk nimmt die App dafür zufällige öffentliche Server; unter Einstellungen → Electrum-Server lässt sich ein eigener Server eintragen, laut App über den TLS-Port, Vorgabe 50002, oder bei Onion-Adressen über den einfachen TCP-Port. Wer eine eigene Node mit Electrum-Server betreibt, findet im Vergleich ElectRS vs ElectrumX vs Fulcrum die passende Software. Zusätzlich gibt es eine Einstellung für Tor; ist sie aktiv, warnt die App, wenn der eingetragene Electrum-Server keine Onion-Adresse hat.

Installation der Phoenix Wallet

Laut README gibt es Phoenix für iOS im App Store (ab iOS 15) und für Android bei Google Play oder als APK direkt von der Release-Seite auf GitHub (ab Android 8). Wer Google Play ohne Google-Konto nutzt, bekommt dieselbe App über den Aurora Store. Bei Wallets, die echtes Geld verwalten, gilt eine einfache Regel: nur aus diesen Quellen installieren, nie aus einer Spiegelseite oder einem fremden Repository. Wer das APK von GitHub nimmt, prüft es vor der Installation; die Release-Seite liefert dafür eine signierte Prüfsummendatei, wie das geht, steht in der Anleitung Sicher downloaden auf Github mit ASC Verifizierung. Stand 04.10.2026 führt die Release-Seite Phoenix 2.8.1 als jüngste Version.

Einrichtung der Phoenix Wallet

Beim ersten Start erzeugt die App eure Wiederherstellungsphrase aus zwölf Wörtern. Sie ist der Schlüssel zur Wallet und zum Guthaben im Kanal und wird gebraucht, um die Wallet bei Verlust des Telefons wiederherzustellen. Ohne diese Phrase ist das Guthaben verloren, und auch ACINQ kann es nicht wiederherstellen, weil ACINQ die Schlüssel nie hatte. Schreibt die Phrase nach Anleitung der App auf und bewahrt sie an einem sicheren Ort auf. Sie gehört nicht in eine Datei auf dem Rechner und nicht in ein Foto, sondern auf Papier. Die Bildschirmfotos in diesem Artikel stammen vom Februar 2024; Bezeichnungen und Anordnung können in aktuellen Versionen abweichen.

Bestätigt am Schluss, dass ihr eure Wiederherstellungsphrase gesichert habt. Unter Einstellungen → Zugriffskontrolle lässt sich der Zugang zur App zusätzlich mit einer sechsstelligen PIN oder mit der Systemsperre des Telefons schützen, samt automatischer Sperre nach einigen Minuten Inaktivität. Nutzt das.

Anwendung der Phoenix Wallet

Kanal-Verwaltung und Gebühren

Eingehende Zahlungen brauchen manchmal eine On-Chain-Transaktion, nämlich dann, wenn im Kanal nicht genug Platz für den Betrag ist und er vergrössert werden muss. Die App sagt dazu selbst: "Incoming payments sometimes require on-chain transactions. This does not always happen, only when needed." Die Kosten dafür setzen sich laut Zahlungsdetails aus zwei Teilen zusammen: einer Servicegebühr für die Liquidität, die ACINQ bereitstellt, und der Gebühr an die Miner für die On-Chain-Transaktion. Wie hoch die Mining-Gebühr ausfällt, hängt von der aktuellen Auslastung der Blockchain ab; deshalb lohnt es sich, Phoenix eher seltener mit grösseren Beträgen aufzuladen als ständig mit kleinen.

Damit euch keine teure Kanalvergrösserung überrascht, gibt es unter Einstellungen → Kanal-Verwaltung eine Maximale Gebühr. Die App erklärt sie so: "Zahlungen, deren Gebühren diesen Wert überschreiten, werden abgelehnt." Ist die Gebühr gerade zu hoch, wartet Phoenix laut ACINQ und versucht es später erneut. Der Bildschirm zeigt auch, wie hoch die Gebühren aktuell geschätzt werden. Liegt eure Grenze dauerhaft darunter, kommen Zahlungen, die eine Vergrösserung brauchen, nicht an; dann die Grenze anheben oder auf ruhigere Zeiten warten. Lasst das Automatische Kanal-Management eingeschaltet: Ist es aus, werden laut App alle eingehenden Zahlungen abgelehnt, die eine On-Chain-Operation brauchen, und On-Chain-Einzahlungen bleiben On-Chain liegen.

Sats aufladen

Um die Wallet verwenden zu können, gibt es zwei Wege: On-Chain, also direkt über die Bitcoin-Blockchain, oder über das Lightning Netzwerk. Eine Übersicht weiterer Wege bietet der Artikel Die schnellsten Möglichkeiten Bitcoin in Lightning BTC umzuwandeln.

Methode 1: Mit On-Chain-Guthaben aufladen

Ihr sendet euch Sats, zum Beispiel von eurer Hardwarewallet, auf die On-Chain-Adresse von Phoenix. Diese findet ihr, wenn ihr auf der Hauptseite einmal nach links wischt:

Sobald die Einzahlung bestätigt ist, überträgt Phoenix sie automatisch in den Lightning-Kanal. Das geschieht nur, wenn die Gebühr unterhalb der Maximalen Gebühr in der Kanal-Verwaltung liegt; bis dahin zeigt die App die Einzahlung als wartend an. Wichtig: Eine Einzahlung, die nicht übertragen wird, wartet nicht ewig. Die App hält fest, dass sie nach vier Monaten Wartezeit nicht mehr auf Lightning umgetauscht werden kann und dann von Hand On-Chain ausgegeben werden muss. Wer eine Einzahlung lange in der Warteschlange sieht, prüft also die Gebührengrenze.

Methode 2: Direkt via Lightning von einer Börse aufladen

Viele Börsen unterstützen Lightning, zum Beispiel Bitfinex oder Kraken. Dort lassen sich gekaufte Bitcoin über die internen Umwandlungswerkzeuge in Lightning-Guthaben umwandeln und dann an eine Lightning-Rechnung auszahlen. Die folgenden Bildschirmfotos zeigen das bei beiden Börsen im Februar 2024; die Oberflächen der Börsen ändern sich häufig.

Am Beispiel Bitfinex, wie es im Februar 2024 ablief: Auf dem Börsenkonto lagen 100'000 Lightning-Sats. In Phoenix erstellt ihr unter Empfangen eine Rechnung, ändert dort den Betrag und tragt die Menge ein, die ihr auszahlen wollt. Bitfinex zog damals eine eigene Lightning-Gebühr von 100 Sats ab und akzeptierte deshalb nur eine Rechnung, die um diese Gebühr kleiner war als das Guthaben. Wie hoch die Gebühr heute ist, zeigt die Börse beim Auszahlen an; rechnet sie bei der Rechnung ab, sonst lehnt die Börse ab.

Die Rechnung fügt ihr bei Bitfinex unter der Auszahlung per Lightning ein:

Anschliessend werden die Sats auf eurer Phoenix Wallet gutgeschrieben. Braucht die Zahlung eine Vergrösserung des Kanals, gehen davon die Servicegebühr und die Mining-Gebühr ab:

Methode 3: Guthaben via RoboSats aufladen

Diese Methode ist die privateste der vier vorgestellten, aber auch mit Abstand die aufwändigste. RoboSats verlangt keine Identifizierung, und ihr könnt eure Lightning Wallet direkt dort aufladen. Absolut anonym ist das trotzdem nicht automatisch: Die Zahlung in Franken oder Euro hinterlässt auf der anderen Seite des Handels Spuren, und wie viel davon übrig bleibt, hängt von eurem Vorgehen ab. Warum der Verzicht auf KYC keine Garantie für Anonymität ist, steht im Artikel Ist no-KYC wirklich eine Garantie für Anonymität. Die Anleitung zu RoboSats selbst wäre hier zu lang; sie steht im Artikel Mit RoboSats anonym Bitcoin kaufen und verkaufen.

Methode 4: Auftrag bei Pocket

Bei Pocket kauft ihr Bitcoin per Banküberweisung und lasst sie über Lightning direkt an Phoenix auszahlen. Laut Pockets eigener Anleitung wählt ihr dafür beim Einrichten Phoenix als Wallet und bestätigt die Auszahlung später in der App; nach der ersten Auszahlung ist eure Phoenix Wallet dauerhaft mit eurer Zahlungsreferenz verknüpft. Wie der Kauf bei Pocket abläuft, steht in unserer Anleitung Bitcoin mit Light KYC bei Pocketbitcoin kaufen.

Sats ausgeben

Ihr habt nun Sats auf eurer self-custodial Phoenix Wallet und könnt sie überall dort ausgeben, wo Bitcoin über Lightning akzeptiert wird. Auch kleine Beträge lassen sich so bezahlen, ohne jedes Mal eine On-Chain-Gebühr zu zahlen. Mit dem Senden-Knopf scannt ihr eine Rechnung und bezahlt sie mit einem Klick auf Bezahlen.

Scannt ihr mit Phoenix eine On-Chain-Bitcoinadresse, führt die App eine normale On-Chain-Transaktion durch. Hier gilt: Achtet auf die On-Chain-Gebühren!

Zum Empfangen bietet Phoenix inzwischen auch eine Lightning-Adresse im Format ₿name@domain nach dem Standard BIP-353, die mit Bolt12-Zahlungsanforderungen arbeitet. Die App beschreibt sie als privater als LNURL-basierte Lightning-Adressen, warnt aber zugleich, das sei "bleeding edge tech": Manche Wallets und Dienste verstehen sie noch nicht und können darauf nicht zahlen. Was LNURL ist, erklärt der Artikel Was versteht man unter LNURL bei Lightning.

Was passiert, falls ACINQ von der Bildfläche verschwindet

Wer eine Wallet nutzt, deren Gegenstelle eine einzelne Firma ist, sollte wissen, was passiert, wenn diese Firma plötzlich nicht mehr da ist. Die Antwort unterscheidet sich zwischen self-custodial Wallets wie Phoenix und Custodial-Wallets wie der Wallet of Satoshi grundlegend.

Self-custodial Wallets wie Phoenix

Bei Phoenix behaltet ihr die Kontrolle über eure Schlüssel. Verschwindet ACINQ, ist das Geld im Kanal nicht weg, aber es ist zunächst blockiert: Der Kanal führt zu ACINQ, und ohne Gegenstelle lässt sich darüber nicht mehr bezahlen. Für diesen Fall gibt es unter Einstellungen → Kanäle force-closen einen Notausgang. Er läuft nicht von selbst ab, ihr müsst ihn auslösen. Die App erklärt den Bildschirm ausdrücklich zum Werkzeug für den äussersten Notfall, "for example, if your peer (ACINQ) disappears permanently, preventing you from spending your money". In allen anderen Fällen verweist sie auf den Support.

Force-Closes im Lightning Netzwerk

• Was ein Force-Close ist: Ist die Gegenpartei nicht erreichbar, könnt ihr den Kanal einseitig schliessen. Dabei wird der letzte Stand des Kanals auf die Bitcoin-Blockchain geschrieben, und euer Anteil geht an eine On-Chain-Adresse, die die App vorher anzeigt.
• Was es kostet: Laut App kostet ein Force-Close Geld für die On-Chain-Gebühren, und das Guthaben ist danach für Tage gesperrt, bevor ihr darüber verfügen könnt.
• Was ihr nicht tun dürft: Die App warnt in Fettschrift: "Do not uninstall the app until your channels are fully closed, or you will lose money." Phoenix bleibt also installiert, bis der Kanal vollständig geschlossen ist.
• Der normale Weg: Solange ACINQ erreichbar ist, gibt es keinen Grund für einen Force-Close. Wer Phoenix verlassen will, nutzt Kanäle schliessen oder überweist das Guthaben einfach an eine andere Wallet.

Custodial Wallets wie die Wallet of Satoshi

Bei Custodial-Wallets wie der Wallet of Satoshi verwaltet der Betreiber die Schlüssel. Verschwindet er, gibt es keinen Notausgang, weil ihr nie eigene Schlüssel hattet. Es gibt dann keine Möglichkeit, selbstständig an das Guthaben zu kommen. Also wie immer: Not your Keys, not your Coins!

Warum Phoenix in diesem Fall besser dasteht

• Kontrolle: Mit Phoenix habt ihr die Schlüssel. Für den Alltag braucht ihr ACINQ als Gegenstelle, für den Notausgang nicht.
• Notausgang: Der Force-Close führt das Guthaben auch ohne Mitwirkung von ACINQ auf die Blockchain zurück, kostet aber Gebühren und Wartezeit und setzt voraus, dass die App noch installiert ist.
• Nachprüfbarkeit: Der Quelltext von Phoenix ist offen. Bei einer Custodial-Lösung bleibt euch nur, dem Anbieter und seinen Sicherheitsvorkehrungen zu vertrauen.

Phoenix bietet damit deutlich mehr Kontrolle als eine Custodial-Wallet. Ein Notausgang ist aber kein Komfortausgang: Wer ihn braucht, zahlt Gebühren, wartet Tage und darf in der Zwischenzeit das Telefon nicht neu aufsetzen.

Was ACINQ über eure Zahlungen weiss

Self-custodial heisst: ACINQ kann nicht über euer Geld verfügen. Es heisst nicht, dass ACINQ nichts sieht. Phoenix hat genau einen Kanal, und der führt zu ACINQ. Ausgehende Zahlungen laufen über sogenanntes Trampoline-Routing: Nicht die App berechnet den Weg durchs Netz, sondern der Trampoline-Knoten von ACINQ. Im eigenen Blogbeitrag zur Einführung hat ACINQ im Dezember 2019 offen geschrieben, was das bedeutet: "ACINQ learns both the payer and recipient of those trampoline payments (just like custodial wallets)", und es selbst als "a liability" bezeichnet (Phoenix Wallet Part 4: Trampoline payments). Die Lösung, mehrere Trampoline-Knoten verschiedener Betreiber hintereinanderzuschalten, hing nach demselben Beitrag davon ab, dass andere solche Knoten betreiben. Dass die aktuelle App weiterhin über Trampoline sendet, zeigt ihr Quelltext; ob ACINQ dabei heute weniger erfährt als 2019, dokumentiert ACINQ nicht an einer Stelle, die sich prüfen liess.

Dazu kommt die Blockchain-Seite: Ab Werk fragt Phoenix zufällige öffentliche Electrum-Server ab, und die erfahren, welche Adressen euch interessieren. Mit einem eigenen Electrum-Server und Tor lässt sich das schliessen, siehe oben. Für eine Wallet im Portemonnaie-Format ist das ein vertretbarer Tausch. Wer aber Lightning nutzt, gerade weil er Zahlungen privat halten will, sollte wissen, dass Phoenix die Bequemlichkeit mit einem Gegenüber erkauft, das viel sieht.

Sicherheitshinweise im Umgang mit Lightning und Phoenix

Eine self-custodial Wallet wie Phoenix bietet viele Vorteile, vor allem bei Kontrolle und Sicherheit. Sie bringt aber auch Verantwortung mit sich. Diese Punkte solltet ihr beachten:

1. Sichere Aufbewahrung der Wiederherstellungsphrase

Die zwölf Wörter sind der Schlüssel zu euren Coins. Verliert ihr sie, könnt ihr den Zugriff auf eure Wallet verlieren. Bewahrt sie an einem Ort auf, zu dem nur ihr Zugang habt. Schreibt sie auf Papier und vermeidet digitale Kopien, die gehackt werden könnten.

2. Phishing-Angriffe vermeiden

Seid immer auf der Hut vor Phishing. Kriminelle versuchen, euch die Wiederherstellungsphrase zu entlocken, indem sie sich als Support, als Wallet-Anbieter oder als Börse ausgeben. Kein seriöser Dienst fragt jemals nach diesen Wörtern. Prüft die Adresse jeder Website und seid vorsichtig bei E-Mails oder Nachrichten, die nach sensiblen Informationen fragen.

3. Haltet die Wallet-Software aktuell

Entwickler aktualisieren Wallet-Software regelmässig, um Sicherheitslücken zu schliessen und neue Funktionen hinzuzufügen. Haltet eure Wallet-App deshalb immer auf dem neuesten Stand.

4. Nutzt starke und einzigartige Passwörter

Für die Börsen und Dienste, über die ihr Phoenix aufladet, gilt: starke und einzigartige Passwörter, nie dasselbe Passwort für mehrere Konten. Ein Passwortmanager hilft, sie sicher zu speichern und zu verwalten.

5. Nutzt Zwei-Faktor-Authentifizierung und die App-Sperre

Wo verfügbar, aktiviert bei Börsen die Zwei-Faktor-Authentifizierung (2FA). In Phoenix selbst schützt die Zugriffskontrolle mit PIN oder Systemsperre die App vor jemandem, der euer entsperrtes Telefon in die Hand bekommt. Schaltet sie ein.

6. Seid vorsichtig mit öffentlichen WLANs

Öffentliche WLANs können unsicher sein. Wer dort Transaktionen durchführt oder sich bei einer Börse anmeldet, achtet auf HTTPS-Verschlüsselung oder nutzt zusätzlich eine sichere Verbindung, zum Beispiel ein VPN.

7. Vermeidet es, grosse Mengen in Hot Wallets zu speichern

Phoenix ist für den täglichen Gebrauch gemacht. Bewahrt darin nur kleinere Beträge für den Alltag auf. Grössere Beträge gehören in eine Cold Wallet, die nicht ständig mit dem Internet verbunden ist. Handhabt das wie euer Portemonnaie: nehmt nur so viel mit, wie ihr unbedingt benötigt!

8. Behaltet wartende Einzahlungen im Blick

Eine On-Chain-Einzahlung, die wegen der Gebührengrenze nicht in den Kanal übertragen wird, verfällt nach vier Monaten für den Umtausch und muss dann von Hand ausgegeben werden. Schaut also nach, wenn die App eine Einzahlung länger als wartend anzeigt.

Fazit: Phoenix ist eure Lightning-Geldbörse, nicht euer Tresor

Die Phoenix Wallet ist eine hervorragende Option für alle, die Lightning nutzen wollen, ohne eine eigene Node zu betreiben und ohne die Schlüssel abzugeben. Ein einziger Kanal, automatische Verwaltung und ein echter Notausgang über den Force-Close machen sie für Einsteiger und erfahrene Nutzer gleichermassen brauchbar. Der Preis dafür ist ein Gegenüber, das eure Zahlungen weiterleitet und dabei viel sieht, und ein Notausgang, der Tage dauert und Gebühren kostet. Wer das weiss, nutzt Phoenix für das, wofür sie gebaut ist: als Geldbörse für den Alltag. Für das Ersparte bleibt die Cold Wallet zuständig; ACINQ mag freundlich sein, ein Tresor ist ACINQ nicht.

Quellen und weiterführende Links

• ACINQ/phoenix auf GitHub: README mit Bezugsquellen, Mindestversionen und Lizenz
• Phoenix-Releases auf GitHub: APK und signierte Prüfsummen
• Phoenix-Quelltext, Texte der Android-App: Kanal-Verwaltung, maximale Gebühr, Force-Close-Warnungen, Ablauf von Einzahlungen nach vier Monaten
• Phoenix-Quelltext, weitere Texte der Android-App: Wiederherstellungsphrase, Electrum-Server, Tor, Zugriffskontrolle, BIP-353-Adresse, Trampoline-Gebühr
• ACINQ: Phoenix Splicing Update (Juli 2023, ergänzt Dezember 2023)
• ACINQ: Phoenix Wallet Part 4, Trampoline payments (Dezember 2019)
• Pocket: Lightning top-up service tutorial

The post Lightning ohne Fullnode mit der Phoenix Wallet appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Betreiber mit einer Lightning Node kommen ab einer bestimmten Anzahl an Kanälen zwangsläufig zur Frage, wie man sich am besten , beziehungsweise die Node und die Kanäle darauf, bestmöglichst absichert, und die Kanäle nach einem Ausfall wieder herstellen kann. Das Thema ist etwas komplex, aber wir schauen uns heute an, wie wir eine Lightning Node am besten absichern können, und wie wir Kanäle bei einem Totalausfall wiederherstellen können. Hier gibt es nämlich ein paar Dinge, die sehr wichtig sind, und auch ein Paar Dinge, die man auf keinen Fall machen darf, wie ich es selber schmerzlichst lernen musste. Damit euch keine Fehler passieren, besprechen wir in diesem Artikel die wichtigsten Schritte.

Wir schauen uns die besten Strategie für die Systeme Raspiblitz, Umbrel und BTCPay Docker an. Ziel ist es eine möglichst sichere Umgebung für unsere Fullnode herzustellen, um in Falle eines Platten- oder Systemausfalls schnell wieder Online zu sein und gegebenfalls alle Kanäle wiederherzustellen. Wichtig zu verstehen ist, das aktuell noch keine reinen Datenbackups aktuell nicht möglich sind. Ihr könnt also nicht eure komplette Platte klonen oder backupen, und einen Server wieder herstellen falls es zu einem Ausfall kommt.

Hintergründe und wichtiges zuerst bei Single Disk Deployments

Es gibt einige Verwirrung und Mythen darüber, wie man Off Chain Funds der eigenen Nodes am besten sichert. Ein Fehler hierbei stellt immer noch das größte Risiko dar, diese Gelder zu verlieren, obwohl alles getan wird, um diese Risiken zu minimieren. Es gibt nur ein Szenario, bei dem man das Guthaben sichert, und auf einer neuen Node wieder komplett wieder herstellen kann, inklusive allen Kanälen, und zwar dann, wenn der Server noch nicht abgeschmiert ist. In den meissten Fälle ist es aber eher umgekehrt: Der Server beziehungsweise die Node ist tot, und ihr steht da wie vom Blitz getroffen.

Welche Daten dürfen in regelmässigen backups gesichert werden

Die wichtigste Datei, die immer gesichert werden muss, ist die Datei <lnddir>/data/chain/bitcoin/mainnet/channel.backup. Diese Datei enthält die Statischen Kanal-Backups (SCBs). Sie wird nur aktualisiert, wenn die Node gestartet wird und wenn ein Kanal geöffnet oder geschlossen wird. Alle anderen Dateien auf der Node sind mehr oder weniger egal.

Die meisten Lightning-Wallet-Apps wie die WalletofSatoshi oder Phoenix laden diese Datei automatisch in die Cloud hoch.

Wie wir diese Datei sichern, und bei einem Ausfall der Node verwenden, um unsere Kanäle wiederherzustellen, schaue wir uns weiter unten dann genau an.

Welche Dateien sollte man nicht in regelmässigen Backups sichern

Das ist eine etwas trickreiche Frage, denn das Anfertigen des Backups ist nicht das Problem. Das Wiederherstellen/Verwenden einer alten Version der channel.db zu finden unter <lnddir>/data/graph/mainnet/ ist sehr riskant und sollte niemals gemacht werden!

Das erfordert etwas Erklärung:

Die Art und Weise, wie LN-Kanäle derzeit eingerichtet sind (bis eltoo/SQL) implementiert wird), ist, dass beide Parteien immer einem aktuellen Saldo zustimmen. Um sicherzustellen, dass keiner der beiden Peers in einem Kanal jemals versucht, einen alten Zustand dieses Saldos zu veröffentlichen, geben sie beide ihre Schlüssel an den anderen Peer weiter. Dies gibt ihm die Möglichkeit, alle Gelder (nicht nur ihren vereinbarten Anteil) aus einem Kanal zu nehmen, wenn ein falscher oder veralteter des Channelstates veröffentlicht wird. Daher bedeutet das Vorhandensein eines alten Kanalzustands im Grunde, dass man den Saldo an die andere Partei verlieren kann.

Da Zahlungen in LND mehrmals pro Sekunde getätigt werden können, ist es sehr schwierig, jedes Mal ein Backup der Kanaldatenbank zu machen, wenn sie aktualisiert wird. Und selbst wenn es technisch möglich ist, kann das Vertrauen, dass ein bestimmter Zustand sicher der aktuellste ist, nie absolut sein. Deshalb sollte der Fokus darauf liegen, sicherzustellen, dass die Kanaldatenbank (also die channel.db) nicht beschädigt wird, die Zombie-Kanäle zu schließen und die SCBs sicher aufzubewahren.

Ausnahmefall noch laufende Node

Kommen wir zur Ausnahme, wann eine Node doch von einem kompletten Backup wiederhergestellt werden darf: Im Ausnahmefall, und nur wirklich in diesem speziellen Fall darf man den kompletten /.lnd Ordner (in der sich die channel.db befindet) sichern, und zwar genau dann, wenn die Node noch nicht den Geist aufgegeben hat. Das komplett Backup darf also nur erzeugt werden, wenn die Node direkt nachher offline genommen wird. Raspiblitz bietet dazu die Funktion LNDRESCUE, oder die komplette Migration an. Die Scripte erstellen Backups welche beim aufsetzen einer neuen Node später verwendet werden, um alle Guthaben inklusive aller Kanäle, wieder herzustellen.

LNDRESCUE sichert nur die Lightning Node, während das Migrationsbackup vom Rapspiblitz beispielsweise eure komplette Node sichert, inklusive installierter Anwendungen und Einstellungen der Node.

Die Node wird direkt nach dem erstellen des Backups vom System selber offline genommen und heruntergefahren. BTCPay bietet ein ähnliche funktion, Umbrels OS bietet dagegen keine vollständige Sicherung von LND an. Bereitet euch also immer auf euer jeweiliges System gut vor!

Die mit Abstand beste Sicherung eurer Node

Die einfachste Methode, eure Lightning Node, beziehungsweise eure Kanäle zu sichern, ist ein einfaches RAID1 Setup. Damit sichert ihr euch gegen ein Plattenausfall ab, und könnt bei einem Plattenausfall die Node ganz normal weiterlaufen lassen, bis ihr einen Ersatz für die ausgefallene Platte habt. Das bietet sich aber leider nicht auf dem Pi4 an, da das Netzteil zu schwach ist, 2 SSDs über das Standard Netzteil zu betreiben. Habt ihr Umbrel, den RaspiBlitz oder BTCPay Docker aber auf einem Linux Server System auf dem ein Hypervisor wie Proxmox läuft, empfiehlt es sich hier unbedingt eine zweite Platte zu nutzen. Dabei empfiehlt es sich, das komplette Betriebssystem ebenfalls auf dem RAID Verbund zu haben, damit das System auch gesichert wird.

Ist es bei einem Single Disk Setup zu einem Crash eurer Node gekommen, schauen wir uns jetzt die wichtigsten Methoden an, um unsere Onchain sowie auch Kanalguthaben, falls vorhanden, wiederherzustellen. Fangen wir doch gleich mit dem Ausnahmefällen an, und zwar dann, wenn die Node noch nicht gecrasht ist.

Wiederherstellung aus Backups

Raspiblitz Backup & Restore mit LNDRESCUE

Der Raspiblitz kommt mit einer äusserst nützlichen komplett Backup & Restore namens LNDRESCUE. Dabei wird eine komplette Sicherung des kompletten .lnd Ordners durchgeführt. Heisst also, ihr könnt diese Funktion nutzen, wenn die Node noch nicht komplett abgestürzt ist, eure Festplatte bald voll ist, oder andere Dinge passiert sind die eine Neuinstallation bzw. ein Transfer voraussetzen. LNDRESCUE fährt auch eure Node nach dem Backup automatisch herunter nachdem ihr das Backup heruntergeladen habt. Dabei kann beinahe fast nichts schiefgehen

Wichtig ist, dass möglichst zur selben Raspi Version migriert wird, und es keine grossen Versionsunterschiede zwischen dem alten, und dem neuen gibt. Falls auf dem alten System noch eine 1.90 läuft, und ihr das neuste Image flasht, wie zum Beispiel 1.11, dann stehlt sicher, dass die alte Node vorher auch noch geupdated wird!

Backup Starten

Geht in das CLI Menü des Raspiblitzes mit menu und geht in die Repair Options, danach Backup / Repair LND und wählt danach Backup your LND data (Rescue-File) aus:

Der Raspi startet danach eine umfassende Sicherung der Lightning Node und stellt euch am Schluss einen Befehl zur Verfügung, der euch die Datei von einem Windows- oder Linux Rechner herunterladen lässt. Autocompact Channels könnt ihr aktivieren, um die Grösse etwas zu reduzieren. Danach ladet ihr euch mit den entsprechenden Links die Backups herunter:

Ladet die Datei herunter, bestätigt danach mit Enter, da die Node anschliessend heruntergefahren wird.

LNDRescue Backup Wiederherstellen

Nachdem ihr eine frisch installierte Node habt, könnt ihr nun die alte Node mit LNDRESCUE komplett wiederherstellen. Heisst auch den LND Seed, die Kanäle und eure komplette Transaktionshystorie. Damit ihr schnellstmöglich wieder online seid, empfielt es sich wie bereits erwähnt die Blockchain vom alten Pi zu übernehmen.

Startet den Pi mit einem frischen Image auf einem synchnronisertem, oder nicht synchronisiertem Hardwaresetup. Die LNDRESCUE Datei habt ihr optimalerweise bereits auf einem USB Stick gespeichert. Diesen benötigen wir für den LNDRESCUE Restore:

Wählt hier Restore from a rescue file aus. Im nächsten Fenster könnt ihr das Backup eurer frischen Raspiblitz Installation getrost überspringen. Folgt den Anweisungen der Konsole, und gebt den Pfad zu eurem LNDRESCUE Backup an. Das Backup wird eingespielt, die Node anschliessend neugestartet. Ihr könnt, falls ihr bereits synchronisiert seid, danach direkt eure Kanäle wieder verwenden. Habt ihr keine Kopie der Blockchain, dann müsst ihr warten, bis sich der neue Blitz synchronisiert hat, danach gehen die Kanäle wieder online.

Seid ihr zu lange offline, da ihr kein Blockchain Backup habt, kann es sein dass Kanäle aufgrund von pending htlc's geschlossen werden. Es empfiehlt sich also in diesem Fall den Raspiblitz übers Clearnet zu synchronisieren.

Raspiblitz komplete Migration auf ein neues Gerät

Wie bereits erwähnt, haben wir dazu ein eigenes Tutorial geschrieben. Dies könnt ihr nutzen, falls eure Node noch funktioniert, und ihr sie auf ein komplett neues Gerät übertragen wollt:

BTCPay Server Backup & Restore Funktion benutzen

Der BTCPay Server in der eigenständigen Docker Variante kommt mit einen eigenen Backup and Restore Script welches ihr im Home Verzeichnis von vom BTCPay Server also unter btcpayserver-docker/btcpay-backup.sh findet. Wollte ihr eure Blockchain Daten sichern, müsst ihr das separate tun z.B rsync oder direkt auf eine Sicherungsplatte.

Skript Sicherung durchführen

Loggt euch als root user ein gebt folgendenden Befehl ein:

cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
./btcpay-backup.sh

Das Skript wird folgende Schritte durchführen:

1. Sicherstellen, dass der Datenbank-Container läuft.
2. Ein Backup (Dump) der Datenbank erstellen.
3. Den BTCPay Server stoppen.
4. Die Docker-Volumes und das Datenbank-Backup archivieren.
5. Die Blockchain-Blöcke und Chainstate-Verzeichnisse ausschließen.
6. Optional: Das Archiv verschlüsseln.
7. Den BTCPay Server neu starten.
8. Aufräumen: Temporäre Dateien wie das Datenbank-Backup entfernen.

Falls alles klappt, seht Ihr folgendes: ✅ Backup done => /var/lib/docker/volumes/backup_datadir/_data/backup.tar.gz

Die Datei backup.tar.gz könnt ihr auf einem USB Stick oder auf einem anderen Medium speichern um später wieder herzustellen falls der Server die komische Anzeichen macht oder ihr auch beispielsweise einfach das System migrieren möchtet. Ihr könnt auch das Backup mit rsync z.B auf ein anderes Netzwerkgerät syncen und sichern. Fahrt den Server nach Sicherung der Datei auf ein Medium, oder auf einen Netzwerkspeicher herunter.

Skript Wiederherstellung

Ähnlich zum Skript btcpay-backup.sh aber umgekehrt: der btcpay-restore.sh Skript muss mit der Pfadangabe ausgeführt werden. also z.B

./btcpay-restore.sh /mnt/usb/backup.tar.gz

Bei einem erfolgreichem Restore bekommt Ihr: ✅ Restore done

Bedenkt dabei, dass bei einem Restore die Kanäle ebenfalls wiederhergestellt werden, und deshalb der Server direkt nach dem erstellen des Backups unbedingt heruntergefahren werden muss!

On Chain Guthaben wiederherstellen

Dies ist der einfachste und unproblematischste Schritt auf allen 3 System. Um eure Onchain-Guthaben zu sichern, braucht ihr nur den Seed bzw. die 24 Wörter für eure Bitcoin-Core Wallet oder eure Lightning On-Chain Wallet. Sollte ein System ausfallen, müsst ihr nichts anderes tun, als die Seedphrase eingeben und ihr habt eurer Guthaben zurück. Das betrifft nochmals gesagt, nur Guthaben, die nicht in Lightning Kanälen sind!

Umbrel Node

Beim Aufsetzen einer neuen Node kann beim ersten Zugriff auf die Lightning Node eine neue Wallet erstellt werden, oder eine Wallet aus einer Seedphrase wiederhergestellt werden. Um euer Onchain Guthaben wieder herzustellen, müsst ihr eure Seedphrase eingeben, die ihr beim erstellen eurer Lightning Wallet erstmalig aufgeschrieben habt.

Wählt also RECOVER YOUR PREVIOUS NODE aus, und gebt danach eure 24 Wörter ein. Damit habt ihr die Onchain Funds eurer Node wiederhergestellt. Hattet ihr vorher diverse Lightningkanäle, springt zur Umbrel Kanal Wiederherstellung um die Kanäle wieder her zu stellen.

BTCPay Server Docker

BTCPay Docker verfügt über mehrere Wallets, eine Shop Wallet, welches eine reine Onchain Wallet ist, und die Lightning Wallet auf der Lightning Node. Beide müssen separate wiederhergestellt werden.

Die Bitcoin Shop Wallet wiederherstellen

Um die Bitcoinn Shop Wallet wiederherzustellen, klickt einfach auf den Bitcoin Button links in der Menüspalte und klickt danach auf connect an exisiting Wallet

Auf der nächsten Seite habt Ihr die Möglichkeit, die Art der Wiederherstellung auszuwählen:

Habt ihr keine Wallet File, müsst ihr eure Wallet Adresse manuell eingeben. Macht das am besten auf einem frischen System bei dem ihr wisst, dass ihr womöglich keine bösartige Software oder Viren drauf habt. Ihr könnt die Guthaben natürlich auch auf einer Software Wallet wie Sparrow wiederherstellen. Diese könnt ihr dann auf ein frisch erstellte Wallet auf dem BTCPay Server senden.

LND Wallet von BTCPay Docker wiederherstellen

Die oben vorgestellte Backup Methode vom BTCPay Server stellt auch eure LND Wallet wieder her, solltet ihr also ein Backup erstellt haben, könnt ihr damit eure Wallet wiederherstellen. Falls ihr kein Backup habt, und nur eure 24 Wörter für die LND Wallet, folgt dem folgendem Leitfaden:

Das Wiederherstellen der Lightning Wallet beim reinem BTC-Pay Server ist etwas umständlich. Die Wiederherstellung der LND Wallet geschieht auf der Kommandozeile.

Der anfängliche Ausgangspunkt, um die Wiederherstellung von On-Chain-Geldern über die Kommandozeile auszulösen, ist der Befehl lncli create. Dieser funktioniert auf dem BTCPay Server etwas anders. Zuerst müsst ihr den Stack komplett herunterfahren indem ihr auf der Kommandozeile folgenden Befehl ausführt:

btcpay-down.sh

Danach müsst ihr den Unlockscript von BTCPay kurz deaktivieren, indem ihr folgendermassen vorgeht:

Sucht zuerst den docker-initunlocklnd.sh Script mit dem folgendem Befehl:

find /var/lib/docker/overlay2/ -name "docker-initunlocklnd.sh" 2>/dev/null

Kopiert euch dem Pfad der den Ordner merged beeinhaltet:

Ändert den namen des docker-initunlocklnd.sh Scripts kurzfristig ab:

mv /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh.bak

Löscht den kompletten Inhalt des LND Ordners auf dem BTCPay Server:

rm -r /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/*

Startet den BTCPay Server mit:

btcpay-up.sh

Führt den folgenden Befehl aus:

docker exec -it btcpayserver_lnd_bitcoin lncli --tlscertpath /root/.lnd/tls.cert.tmp create

Jetzt kommt ihr in den interaktiven Modus um die Wallet wiederherzustellen. Als Nächstes kann man ein neues Wallet-Passwort eingeben, um alle neu abgeleiteten Schlüssel als Ergebnis des Wiederherstellungsprozesses zu verschlüsseln. Diesen Schritt könnt ihr mit Enter überspringen.

Input wallet password:
Confirm wallet password:

ACHTUNG, das Walletpasswort auf dem BTCPAY Server muss hellorockstar sein! Verwendet hier also hellorockstar als Wallet Passwort!

Sobald ein neues Wallet-Passwort erstellt wurde, werdet ihr aufgefordert, die vorhandenen Chiffrierschlüssel (Cipher Seed) einzugeben:

Input your 24-word mnemonic separated by spaces: ability noise lift document certain month shoot perfect matrix mango excess turkey river pitch fluid rack drill text buddy pool soul fatal ship jelly

Wenn beim Erstellen des Seeds ein Passwort für den Chiffrierschlüssel verwendet wurde, MUSS es jetzt eingegeben werden, das ist auf dem BTCPAY Server beim Standardsetup aber nicht der Fall, also ENTER:

Input your cipher seed passphrase (press enter if your seed doesn't have a passphrase):

Schließlich habt ihr die Möglichkeit, ein Wiederherstellungsfenster zu wählen:

Input an optional address look-ahead used to scan for used keys (default 2500):2500

Das Wiederherstellungsfenster ist ein Maß, das der On-Chain-Scanner verwendet, um zu bestimmen, wann alle "benutzten" Adressen gefunden wurden. Wenn das Wiederherstellungsfenster zu niedrig ist, wird LND keine Gelder in Adressen finden, die nach dem Punkt erzeugt wurden, an dem zwei aufeinanderfolgende Adressen generiert, aber nie verwendet wurden. Wurde eine LND On-Chain-Wallet umfangreich genutzt, möchtet ihr möglicherweise den Standardwert erhöhen.

Sollten alle bereitgestellten Informationen gültig sein, wird euch der Seed erneut präsentiert:

!!!YOU MUST WRITE DOWN THIS SEED TO BE ABLE TO RESTORE THE WALLET!!!

---------------BEGIN LND CIPHER SEED---------------
 1. ability   2. noise   3. lift     4. document
 5. certain   6. month   7. shoot    8. perfect
 9. matrix   10. mango  11. excess  12. turkey
13. river    14. pitch  15. fluid   16. rack
17. drill    18. text   19. buddy   20. pool
21. soul     22. fatal  23. ship    24. jelly
---------------END LND CIPHER SEED-----------------

!!!YOU MUST WRITE DOWN THIS SEED TO BE ABLE TO RESTORE THE WALLET!!!

lnd successfully initialized!

Ist die Wiederherstellung durch, muss der docker-initunlocklnd.sh Script wieder unbenannt werden:

mv /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh.bak /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh

Startet den BTCPay Server neu mit:

btcpay-restart.sh

Danach habt ihr eure Onchain Funds der LND Wallet erfolgreich auf dem BTCPay Server wiederhergestellt. Wie hier die Kanäle wiederherstellt erfahrt ihr weiter unten.

Raspiblitz Fullnode

Der Raspiblitz hat nur eine LND Wallet mit Onchain Funds. Deshalb gehts gleich weiter, wie die LND Wallet wieder hergestellt werden kann. Vorausetzung dafür ist ein frisch installiertes Blitzimage, und ein synchronisierter Bitcoincore Client. Die Node muss also vollständig synchronisiert sein, damit die Funds wieder auftauchen.

LND Onchain Wallet wiederherstellen

Achtung: diese Option ist nur auszuwählen, falls ihr keine Kanäle hattet! Weiter unten findet ihr die Anleitung um Kanäle wiederherzustellen. Das Raspiblitzmenu bietet im Menu eine extra Option an, um nur die Onchain Funds der LND Wallet wiederherzustellen. Loggt euch per SSH auf dem wiederhergestellten RaspiBlitz ein und begebt euch mit dem Befehl menu ins CLI Menü des Blitzes, dort wählt ihr dann Repair Options und danach Repair/Backup LND:

Im nächsten Fenster wählt Ihr dann Restore from a seed (onchain funds only)

Im nächsten Fenster fragt euch der Blitz ob ihr LND vorher sichern wollt, da ihr neu aufgesetzt habt, müsst ihr nichts sichern, könnt also einfach mit <skip> fortfahren. Anschliessend startet der Blitz die entsprechende Konfiguration. Ihr könnt dann in den folgenden Schritten euren alten LND Azeed eingeben. Folgt einfach den Anweisungen.

Offchain Guthaben oder Lightning Kanäle sichern

Wir kommen nun zu dem Teil des Tutorials, der euch zeigt, wie ihr eure Kanäle mit der wichtigen, euch nun bereits bekannten SCB Datei channel.backup, sichert.

Die SCB-Datei in LND (Lightning Network Daemon) steht für "Static Channel Backup". Sie ist quasi die Lebensversicherung bei einem Totalausfall des Lightning Knotens. Die grösste Konzentration liegt darauf, dass diese Datei unter allen Umständen regelmässig gesichert werden muss.

Hier wichtige Details zur SCB-Datei:

1. Zweck der SCB-Datei: Die SCB-Datei ist dazu gedacht, Informationen über eure Lightning-Kanäle zu speichern, allerdings in einer statischen Form. Das bedeutet, sie speichert die grundlegenden Infos zu den Kanälen, wie die Kanal-IDs und die Knoten, mit denen ihr verbunden seid.
2. Nutzung im Notfall: Die Hauptfunktion der SCB-Datei ist die Wiederherstellung eurer Kanäle im Falle eines Totalausfalls eures Knotens, wie z.B. bei einem Hardwarefehler oder Datenverlust. Wenn ihr also einen neue LND Node aufsetzt, könnt ihr die SCB-Datei verwenden, um eure Kanäle wiederherzustellen.
3. Limitationen: Es ist wichtig zu verstehen, dass die SCB-Datei nicht dazu dient, Kanäle "am Leben zu erhalten" oder den aktuellen Zustand eurer Kanäle zu sichern. Sie hilft nur bei der Wiederherstellung der Existenz der Kanäle, nicht aber bei der Wiederherstellung des Kanalzustandes oder der Transaktionshistorie. Nach der Verwendung der SCB Datei, werden also alle ehemaligen Kanäle zwangsgeschlossen, und ihr bekommt eure Lightning Guthaben nach eineriger Zeit zurück. Das heißt, sie ist eine Art Sicherheitsnetz, aber keine umfassende Backup-Lösung.
4. Vorsichtsmaßnahmen: Es ist entscheidend, dass ihr die SCB-Datei sicher und getrennt von eurem Knoten aufbewahrt. Sollte jemand unbefugt Zugriff darauf erhalten, könnte dies ein Sicherheitsrisiko darstellen. Zusammen mit dem Seed kann eurer gesammtes Lightning Guthaben abgegriffen werden.

Zusammenfassend ist die SCB-Datei in LND also das wichtigste Werkzeug für die Notfallwiederherstellung eurer Lightning-Kanäle bei einem Ausfall eurer Node. Sie ist jedoch kein Allheilmittel und kann nicht den laufenden Betrieb oder den aktuellen Zustand Eurer Kanäle sichern. Es ist also wichtig, zusätzlich zu den SCB-Backups auch andere Vorsichtsmaßnahmen zu treffen, um die Sicherheit eurer Lightning-Kanäle zu gewährleisten.

Umbrel SCB Datei sichern

die SCB Datei findet ihr auf der Umbrel Lightning Node oben rechts unter den 3 Strichen:

Die Datei könnt ihr direkt downloaden und an einem Ort eurer Wahl speichern. Eine Automatische Sicherung gibt es nicht, wie die Einstellung Automatic backups suggeriert! Zumindest finde ich nirgends eine Option aus einem Online Backup von Umbrel wiederherzustellen.

BTCPay Server Docker SCB Datei sichern

Auf dem BTCPay Server gibt es keine automatische SCB Backup Funktion, deshab machen wir uns einen eigenen Script, der die channel.backup regelmässig bei Änderungen sichert, ähnlich bzw gleich der SCB Backup Funktion des Blitzes.

LND backup script für die channel.backup mit inotify

Installiert euch zuerst das Tool inotify auf dem Host.

sudo apt install inotify-tools

Skript erstellen

Erstellt einen Script der die channel.backup Datei überwacht mit nano /pfad/copy-channel-backup-on-change.sh mit folgendem Inhalt:

#!/bin/bash

# Pfade und Einstellungen
SOURCE_FILE="/var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/chain/bitcoin/mainnet/channel.backup"
BACKUP_PATH="/backuppfad/channel.backup"
DELAY=10  # Verzögerung in Sekunden nach Erkennung von Änderungen

while true; do
    # Warte auf eine Änderung (modify) an der Datei
    inotifywait -e modify $SOURCE_FILE
    
    # Warte nach der Erkennung einer Änderung
    echo "$(date): Modification detected. Waiting for $DELAY seconds before copying..."
    sleep $DELAY

    # Kopiere die Datei zum Backup-Pfad
    cp $SOURCE_FILE $BACKUP_PATH

    echo "$(date): File copied to $BACKUP_PATH"
done

Bitte passt den BACKUP_PATH an einen enstsprechenden Pfad an (z.B an einen gemounteten USB Stick oder einen Netzwerkspeicher)

Macht die Datei ausführbar mit:

chmod +x /pfad/copy-channel-backup-on-change.sh

als Service hinzufügen

Erstellt eine neue Service Datei mit sudo nano /etc/systemd/system/backup-channels.service mit folgenden Inhalt:

[Service] 
ExecStart=/pfad/copy-channel-backup-on-change.sh 
Restart=always 
RestartSec=1 
StandardOutput=syslog 
StandardError=syslog 
SyslogIdentifier=backup-channels 
User=ubuntu 
Group=ubuntu 
[Install] 
WantedBy=multi-user.target

Den Dienst startet ihr mit:

sudo systemctl start backup-channels

Überwachen könnt ihr in mit:

journalctl -fu backup-channels

Beim booten des Servers den Service automatisch mit starten:

sudo systemctl enable backup-channels

rsync backup mit crontab

Eine einfache Variante ist auch das sichern dern SCB Datei mit einem einfach rsync cronjob. Dafür braucht ihr keine Scripte und keinen extra Service, ist aber nicht ganz so sauber wie die inotify methode.

Erstellt einen crontab mit sudo crontab -e mit folgendem Inhalt:

15 * * * * rsync -avz /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/chain/bitcoin/mainnet/channel.backup /mnt/usbstick/

Damit wird die SCB Datei alle 15 Minuten auf den Stick gesichert. Ihr könnt natürlich auch das besagte NFS Share benutzen oder einen externen ftp/sftp Host verwenden.

Raspiblitz SCB Datei sichern

Lokale Sicherung

Für den Raspiblitz gibt es eine automtische Backup Funktion der SCB Datei (channel.backup) unter Funktion im Raspiblitz Menu. Dies findet ihr unter Node Settings & Options:

Hier könnt ihr die SCB über auf ein USB Speicher speichern. Habt ihr eine Nextcloud, wäre dies natürlich auch eine Option.

Ihr könnt einen UBS Stick an der Node lassen, oder auf einen nfs Share sichern, zb. einem Netzwerkspeicher. Wie sowas funktioniert, erfahrt ihr z.B hier. Der Raspi oder der ist dann einfach der NFS Client. Am einfachsten wäre aber für den Heimgebrauch die USB Stick Methode die an einen entsprechenden Ort gemountet wird.

Ihr müsste dafür ein USB Stick an euren Raspiblitz anstecken, welcher als Speicherort für das Backup dient. Nach der Ausführung des Dienstes SCB/Emergency Backup führt der Blitz die Sicherung regelmässig bei der Änderung der SCB Datei durch.

Fügt den Stick nach Ausführung des SCB/Emergency Backup tools noch unbedingt in die Datei fstab mit ein, damit der Stick automatisch beim erneuten starten der Node, an den richtigen Ort gemounted wird. Schaut mit lsblk, nach dem ausführen des Services bitte nach, wo der Stick gemounted wurde ist. Der Stick muss in der Datei fstab unter /mnt/backup gemounted werden. Benutzt dazu am besten die UUID. Wie das funktioniert, erfahrt ihr am Ende des nächsten Abschnittes.

Der nächste Abschnitt aktiviert die Auto Backup Funktion über die Kommandozeile, und fügt den Stick mit in die Datei /etc/fstab mit hinzu:

Manuelle Konfiguration Auto-SCB Backup

Für die manuelle Konfiguration des Autobackup der SCB Datei via USB Stick, geht ihr am besten so vor:

Stick am PI einstecken

Am Blitz via SSH anmelden und mit CTRL+C auf die Shell wechseln.
Prüfen, ob er einen verwendbaren Stick erkannt hat:

sudo ./config.scripts/blitz.backupdevice.sh status

ungefähre Ausgabe wäre

blitz.backupdevice.sh
backupdevice=0
backupCandidate[0]='sdb 7 GB JetFlash'
backupCandidates=1

Backup aktivieren:

sudo ./config.scripts/blitz.backupdevice.sh on

Im erscheinenden Dialog FORMAT wählen

Prüfen, ob der Stick unter /mnt/backup eingehengt wurden ist:

sudo ./config.scripts/blitz.backupdevice.sh mount

UUID Ausfindig machen und in die Datei /etc/fstab hinzufügen

UUID des Sticks anzeigen lassen (Achtung! Das ist mein Stick - sieht bei euch anders aus)

Entweder ganz einfach via

blkid

oder den Status des Services nochmals abrufen nachdem ihr das Backup manuel aktiviert habt:

sudo ./config.scripts/blitz.backupdevice.sh status

Ausgabe wäre:

blitz.backupdevice.sh
backupdevice=1
UUID='1B08-0CE4'
isMounted=1

UUID kopieren und /etc/fstab editieren:

sudo nano /etc/fstab

In der Datei am Ende diese Zeile einfügen (hier wieder eure UUID eintragen):

UUID='1B08-0CE4' /mnt/backup vfat defaults 0 2

Datei speichern mit strg+o ,Y und ENTER. Beenden mit strg+x

Jetzt wird der Stick nach einem reboot automatisch gemountet und ein Backup der channel.backup erstellt sobald diese sich bei einer Channel State modifzierung verändert.

Remote Sicherung

In einer Nextcloud

Via Nextcloud könntet ihr eure SCB Datei auch remote sichern, schaut dazu in diesem gesonderten Beitrag vorbei:

Backups via Netzwerkanbindungen direkt z.b. mit NFS

Schaut mal hier vorbei, wie ihre z.B einen Ordner aus eurer Synology direkt auf einem Linux System mounten könnt.

Wiederherstellung Lightning Kanäle mit SCB

Diese Methode kommt zur Anwendung, wenn eure Node durch einen Plattenausfall verloren ist, oder aus anderen Gründen nicht mehr wiederherzustellen ist. Ihr benötigt dafür die channel.backup und eure LND Seed.

Seit Version v0.6-beta besitzt lnd ein Feature namens Statische Kanal-Backups (SCBs). Diese sind statisch, da sie nur einmal benötigt werden: beim Erstellen des Kanals. Ein Backup bleibt gültig, bis der Kanal geschlossen wird. Es enthält alle notwendigen Informationen, um die Datenverlustschutz-Funktion (DLP) im Protokoll zu aktivieren, was letztlich zur Wiederherstellung der Gelder des Kanals auf der Blockchain führt. Dies ist ein ausfallsicherer Backup-Mechanismus.

Dieser Weg gilt als sicher, weil darauf geachtet wurde, dass es keine Fallstricke gibt, wie es beispielsweise beim regelmäßigen Kopieren der channel.db Datei der Fall sein könnte. Solche Methoden können riskant sein, da man nie sicher weiß, ob man den neuesten Stand eines Kanals hat. Stattdessen bieten SCBs eine einfache, sichere Methode, um Nutzern die Wiederherstellung der Gelder in ihren Kanälen, im Falle eines teilweisen oder vollständigen Datenverlusts, zu ermöglichen. Die Backups selbst sind mit einem Schlüssel verschlüsselt, der aus dem Seed der Wallet abgeleitet ist. Dadurch können andere beim klau der channel.back Datei nicht einfach Eure Kanäle auf anderen Nodes wiederherstellen.

Voraussetzungen für einen erfolgreichen SCB

Der Peer muss online sein, ist der Peer nicht online, bewirkt der Befehl nichts, da dieser voraussetzt, dass der Peer mit dem wir Kanäle hatten, online ist und auf unseren Restore-Anfrage reagiert. Ausserdem müsst ihr eure channel.backup bereits auf das jeweilige Systen geladen haben. Die kann z.B. vom regelmässig gesicherten channel.backup USB-Stick kommen, oder ihr habt diese aus eurem Netzwerkspeicher bereits zurück auf das System transferiert.

Was passiert bei einem SCB Restore

In dem gegebenen Prozess zur Wiederherstellung von Kanälen wird der Server eine Reihe von "Kanal-Kerndaten" in die Datenbank einfügen. Diese enthalten nur die Informationen, die notwendig sind, um das Datenverlustschutz-Protokoll (DLP) zu starten, und nichts weiter. Als Ergebnis werden sie in der Datenbank als "wiederhergestellte" Kanäle markiert (ChanStatusLocalDataLoss|ChanStatusRestored), und es wird nicht zugelassen, sie für andere Prozesse zu verwenden.

Sobald die Kanal-Kern Daten wiederhergestellt sind, versucht das Chanbackup-Paket, einen LinkNode einzufügen, der alle früheren Adressen enthält, mit der unsere Node den Peer erreichen kann.

LND startet dann wie üblich und versucht, Verbindungen zu allen Peers herzustellen, mit denen wir offene Kanäle hatten. Läuft LND bereits, wird ein neuer, beständiger Verbindungsversuch initiiert.

Sobald wir eine Verbindung zu einem Peer herstellen, startet das DLP-Protokoll. Der entfernte Peer wird feststellen, dass wir Daten verloren haben, und dann sofort seinen Kanal zwangsschließen. Bevor er dies tut, sendet er jedoch die Nachricht für den Kanal-Wiederherstellungshandshake, welchen wir benötigen, um Schlüssel abzuleiten um zu beweisen das wir die originalen Besitzer sind.

Sobald die Verpflichtungstransaktion bestätigt ist, leitet unsere Node, basierend auf den Informationen im SCB, alle benötigten Schlüssel neu ab um die Guthaben dann zu bergen.

SCB Wiederherstellung mit Raspiblitz

Seid euch im klaren dass das Recovern mit SCBs einer der letzte Massnahme darstellt, um seine Kanäle bzw die Funds darin wieder zu bekommen. Beim Recovering Prozess werden alle Kanäle seitens der Peers geschlossen via forceclose. Alle Schritte gehen von einem frisch installierten RaspiBlitz Image aus, und dass die Node vollständig eingerichtet und synchronisiert ist.

Um die die Kanäle wiederherzustellen, müsst ihr in den LND Repair Options vom Blitz folgende Option verwenden:

Ein Backup müsst ihr im nächsten Fenster nicht erstellen, da ihr ja frischt installiert seid. In den folgenden Fenstern gebt Ihr Eure LND Seed an, und gebt dem Blitz an, wo Ihr Eure channel.backup gespeichert habt.

Nach der Eingabe des Seeds der LND Wallet, und dem lokalisieren der channel.backup wird der Raspiblitz den SCB Restore einleiten. Das kann je nach Anzahl Kanäle einige Zeit dauern. Die Kanäle tauchen dann wieder in der Übersicht z.B in RTL auf, stehen dann aber in der Pending Close Warteschlange. Die Closing TXs seht ihr auf eurer Node nicht aufgrund der Notfallwiederherstellung die damit einhergeht, da der Peer, und nicht ihr, einen Force Close auslösst. Die Guthaben tauchen erst auf, nachdem der Force Close bestätigt worden ist, und die blocks_until_maturity vorüber sind, und die Funds erfolgreich gesweept wurden sind.

SCB Wiederherstellung BTCPay Docker

Um Kanäle wiederherzustellen, also genauer gesagt die Force Closures für alle Channels einzuleiten, müssen wir zuerst die alte ursprüngliche LND Onchainwallet wiederherstellen, und den Wiederherstellungsbefehl erfolgreich manuell ausführen. Wie ihr die LND Wallet wiederherstellt, habt ihr bereits hier erfahren. Springt nochmals zurück, falls ihr das noch nicht getan habt.

Auf dem BTC-Pay Server müssen wir die Wiederherstellung manuel via lncli ausführen. Dafür benötigen wir den Script, der die Befehle in den LND Docker Container schickt. Die Skripte befinden sich all im btcpay-docker Ordner.

Um einen SCB Restore auszuführen benötigen wir also den Befehl bitcoin-lncli.sh restorchanbackup und die SCB Datei auf dem Server.

Wir führen also folgenden Befehl aus:

bitcoin-lncli.sh restorechanbackup --multi_file=/pfad/channel.backup

Das kann je nach Anzahl Kanäle eine weile Dauern. Bittet beachtet nochmals, dass ihr Weile warten müsst. Überprüft mit den Hinweisen hier, ob die Closing Transaktion vom Peer ins Netzwerk gesendet worden ist.

SCB Wiederherstellung Umbrel

Umbrel verfügt nicht über eine komplette Backup & Restore wie der RaspiBlitz oder BTCPay Docker. Das heisst es können nur die Kanäle via SCB gesichert und wiederhergestellt werden.

Die Wiederherstellung der Kanäle auf der Umbrel Node ist relativ einfach. Vorausetzung ist ebenso, dass die Node mit dem originalen Seed eurer alten Node wiederhergestellt worden ist. Gebt eure Seed ein nachdem ihr die Neue Lightning Node online habt, und wählt dann oben rechts die 3 Punkte. Wählt dann Recover Channels aus:

Die Node wird dann mit den Seeds und dem Channelbackup die Kanäle wiederherstellen. Dabei führt sie einfach nur lncli restorechanbackup aus. Nachdem die Umbrel Node die Kanäle wiederhergestellt hat, werden die Kanäle auftauchen, aber automatisch geschlossen, falls eure Peers den rescue Befehl eurer Node erhalten.

SCB Restore ausgeführt aber keine Schliessung in Sicht?

Als erstes sei zu erwähnen, dass bei erfolgreichem SCB keine Rückerstattungen angezeigt werden, bis die Closing Transaktion bestätigt worden ist. Laut Aussagen der LND Entwicklern ist das normal bei einem Recovery.

Die nächste Problematik: möglicherweise ist die die Transaktion nicht in den Mempool gewandert, wahrscheinlich, weil die commit-fee der Node des Peers zu niedrig angesetzt waren und sie in High-Fee Zeiten vom Mempool gepurged werden. In einem High-Fee Environment schickt LND nur channel closes in den mempool, wenn die Fee grösser als die aktuelle Purging Rate ist. In diesem Fall muss der Peer kontaktiert werden, welcher die Transaktion anstossen muss. Trettet am besten mit dem Peer in Kontakt und sucht zusammen nach einer Lösung und ob der Peer den Kanal nochmals schliessen kann. Der Peer muss dies als Force-Close tun, und nicht als Cooperative-Close!

Eine ein weiteres Problem das wir weiter oben bereits angesprochen haben, ist das der SCB Restore nicht funktioniert, wenn der Peer nicht Online ist. Der SCB Restore lösst ein Notsignal aus, dass die Peers dazu veranlasst einen Force Close auszulösen. Falls der Peer offline ist, und im dümmsten Fall nicht mehr Online kommt ist das SCB Recovery wirkungslos.

Wie finde ich die Closing Transaktionen im mempool

Öffnet zuerst mal mit lncli pendingchannels oder auf dem btcpay Server mit bitcoin-lncli.sh pendingchannels die aktuelle Kanalübersicht und sucht euch den Kanal raus, den ihr untersuchen wollt. Hier sucht hier nach den Kanälen mit ChanStatusLocalDataLoss|ChanStatusRestored und dem gesuchten Guthaben. Wir benötigen den channel_point

Diesen Kanal geben wir auf https://mempool.space ein und suchen uns die Closing-Transaktion heraus. Dafür gehen wir auf die opening TX, und suchen danach nach einer unbestätigten Transaktion:

Nach einem Klick auf den Channel-Open sehen wir die darin enthaltene Adressen und Transaktionen und dort sollten wir die Closing Transaktion gleich zu oberst finden: Diese ist eine Multi-Sig Transaktion da wir via SCB Restore signiert haben, und der Peer mit seinen private Keys ausgelösst durch unsere Anfrage.

Bei sehr hohen Onchainfees kann es sehr lange dauern, bis die Transaktion durchgeht. Entweder man wartet bis die Transaktion durch ist, oder man hilft etwas nach. Wie das geht, erfahrt ihr jetzt:

Force Closing Transaktion nach SCB Restore mit zu niedrigen Fees anstossen

Dafür gibt es ein Set an Tools von den Lightning Entwicklern namens Chantools. Die Chantools von Lightning Labs sind ein Set an Werkzeugen für die Verwaltung und Wartung von Lightning Network Nodes. Sie bieten verschiedene Funktionen, die für Nutzer von Lightning Nodes nützlich sind. Die Tools können auf einem anderen Rechner laufen und müssen nicht auf der betroffenen Node installiert werden.

Die Installation ist vor allem für Anfänger wirklich etwas komplex aber machbar. Um chantools nutzen zu können, kompilieren wir uns das Tool am besten schnell selbst. Ihr benötigt dafür einen Linux Computer und eine aktuelle Linux Distribution basieren auf Debian/Ubuntu. Chantools lässt sich auch auf dem Blitz installieren, von einigen Usern habe ich jedoch erfahren, dass dies nicht immer fehlerfrei funktioniert.

Gebt den Befehl chantools auf dem Blitz in die Konsole ein, bekommt ihr eine Befehlsübersicht. Wenn nicht, kompilieren wir uns chantools auf einem anderen Linux Rechner, oder einer virtuellen Maschine eurer Wahl selber.

Chantools installieren

Um selber zu kompilieren müssen wir zuerst die Prammiersprache Go und den Compiler Make installieren. Das geht mit folgenden Befehlen:

sudo apt install golang-go
sudo apt install make

Führt danach noch folgenden Befehl in der Komandozeile aus:

export PATH=$PATH:/usr/local/go/bin

Ladet euch die chantools mit dem git Befehl herunter:

git clone https://github.com/lightninglabs/chantools.git

wechselt in den Ordner chantools den ihr heruntergeladen habt mit cd chantools, danach kompiliert ihr das Programm mit dem einfachen Befehl make install

Schiebt die ausführbare chantools Datei dann mit:

mv ~/go/bin/chantools /usr/local/bin/

an die richtige Stelle um den chantools Befehl direkt an jedem Ort der Konsole ausführen zu können.

Danach habt ihr die Chantools auf eurem Rechner installiert und könnt den Befehl direkt verwenden.

Chantools ausführen

Die Bedienung bzw der Befehl ist etwas komplex, und wir benötigen vorher einiges an Information und zwar:

chantools pullanchor \
  --sponsorinput txid:vout \  --> ein UTXO aus Eurer LND Wallet welcher bereits bestätigt worden ist
  --anchoraddr bc1q….. \      --> die 330sats grösse Adresse aus dem Channel Closing siehe unten
  --changeaddr bc1q….. \      --> eine neue Adresse aus Eurer LND Wallet (p2wkh) z.B via RTL generieren
  --feerate 30                --> die Feerate die neu effektiv angesetzt werden soll

Möglicherweise gibt es 2 Anchor Outputs mit der grösse von jeweils 330Sats, notiert euch falls ja, beide Adressen

Kommen wir zum Ausführen des Befehls. Alle Befehle müssen in den Befehl mit den Flaggen gesetzt werden. z.B so

chantools pullanchor --sponsorinput 052a4b3fc363e1a045baa010cd5bf99024cce1d40a9a78741460934fc580aced:0 --anchoraddr bc1q9xn9wthafk4
sgp3hnuuf79twe7mpm43uzukt09t9v0m8cs8hs3fsj80zwa --changeaddr bc1qpeha3xv0m6k4u72p5sdv3e2vxsunhjzrgyp3qv --feerate 100

Anmerkung zur Feerate da es sich hier um einen CPFP Anstoss handelt, gelten nicht die eingestellten Fees. Das Thema ist etwas komplex, merkt euch aber dass bei einer eingestellten Fee von 100, zirka 55% also etwas mehr als die Hälfte als effektive Feerate für die neue Transaktion ausgeführt wird. Dies kann je nach grösse der Transaktion aber varieren.

Das Programm wird euch nach eurer LND Seedphrase fragen. Gebt die Seedphrase ein, und falls ihr keine Passphrase habt, drückt bei der Passphrase Abfrage einfach auf Enter. Das Tool erstellt euch nun einen PSBT-Output für eure Node, auf welcher ihr dem Befehl dann absetzen müsst.

Falls die Generierung der PSBT fehl schlägt, benutzt die andere Anchor Adresse mit 330Sats. Keine Angst, es passiert nichts, da Chantools merkt, wenn die andere Anchor Adresse nicht der eigenen LND Seed Wallet zugehörig ist.

Kopiert Euch die lange Zeichenfolge (PSBT), und loggt euch per SSH auf eurem Pi, dem BTCPay Server oder auf der Umbrel ein. Unter Umbrel müsst ihr, um lncli Befehle absetzen zu können, in den Docker Container wechseln (docker exec -it docker_id bash). Im Umbrel Appstore gibt es auch eine App mit der ihr direkt LND Befehle absetzen könnt:

Befolgt den Befehlen von chantools: gebt zuerst die PSBT aus dem chantools Programm ein

lncli wallet psbt finalize <psbt>

und dann:

lncli wallet publishtx <final_tx>

Ein, die final _tx ist die Transaktionsnummer die euch der Befehl wallet psbt finalize erstellt. Mit Enter setzt ihr das ganze ab, nun wird die Transaktionsgebühr aus dem UTXO, den ihr angegeben habt, erhöht.

Ihr erhaltet danach eine neue TX. Diese könnt ihr im z.B auf mempool.space eingeben und beobachten. Wird die Transaktion bestätigt, bekommt ihr eure Guthaben ohne weiters zutun zurück.

SCB durchgeführt aber der Peer ist nicht mehr online

Dies ist die allerletze Methode und sollte wirklich nur dann ausgeführt werden, wenn der Peer lange nicht mehr online war. Kommt der Peer Online, während wir versuchen die Transaktion mit einem alten State zu forceclosen, bekommt der Peer alle unsere Guthaben.

Dafür benötigen wir aber die channel.db aus dem abgestürzten System. Habt ihr diese nicht, funktioniert diese Methode hier nicht. Ausserdem benötigen wir wieder die chantools, welche wir uns auf einem System unserer Wahl installieren können.

Alten Channel State veröffentlichen falls Peer dauerhaft offline ist

Dafür müssen wir mit den chantools arbeiten, installiert, diese wie oben beschrieben, Falls noch nicht getan. Ausserdem benötigen wir die Datei channels.db, aus der gecrashten Node. Falls diese nicht mehr wiederherzustellen ist, könnt ihr diesen Abschnitt hier übersringen.

Kopie der Kanal-DB erstellen: Um sicherzustellen, dass wir auf die Kanal-DB zugreifen können, erstellen wir eine Kopie im sicheren Modus. Führt einfach folgenden Befehl aus:

chantools compactdb --sourcedb /pfad/zur/channel.db --destdb ./results/compacted.db

Wir gehen davon aus, dass die kompaktierte Kopie der Kanal-DB sich in ./results/compacted.db befindet für die folgenden Befehle.

chantools summary: Zuerst muss chantools den Zustand jedes Kanals in der Blockchain ermitteln. Dafür wird eine Blockchain-API (standardmäßig blockstream.info) abgefragt. Das Ergebnis wird in einer Datei namens ./results/summary-yyyy-mm-dd.json geschrieben. Diese Ergebnisdatei wird für den nächsten Befehl benötigt.

chantools --fromchanneldb ./results/compacted.db summary

chantools rescueclosed: Es ist möglich, dass die entfernten Peers einige der verbleibenden Kanäle bereits erzwungenermaßen geschlossen haben. Was wir jetzt tun, ist, die privaten Schlüssel zu finden, um unseren Anteil dieser Kanäle zu übernehmen. Dafür benötigen wir ein gemeinsames Geheimnis, das commit_point genannt wird und sich jedes Mal ändert, wenn ein Kanal aktualisiert wird. Wir haben die neueste bekannte Version dieses Punktes in der Kanal-DB. Der folgende Befehl versucht, alle privaten Schlüssel für Kanäle zu finden, die von der anderen Partei geschlossen wurden. Der Befehl muss wissen, auf welchen Kanälen er operiert, daher müssen wir die durch den vorherigen Befehl erstellte summary-yyy-mm-dd.json angeben:

chantools --fromsummary ./results/<summary-file-name>.json rescueclosed --channeldb ./results/compacted.db

Dies wird eine neue Datei namens ./results/rescueclosed-yyyy-mm-dd.json erstellen, die alle gefundenen privaten Schlüssel enthält und auch für den nächsten Befehl benötigt wird. Verwendet z.B. bitcoind oder das Electrum Wallet, um alle privaten Schlüssel zu übernehmen.

chantools forceclose: Dieser Befehl wird nun alle Kanäle schließen, von denen chantools annimmt, dass sie noch offen sind und deren Peers nicht mehr online sind. Dies wird erreicht, indem der zuletzt bekannte Kanalzustand aus der channel.db-Datei veröffentlicht wird. Bitte lies den vollständigen Warnungstext des forceclose-Befehls unten, da dieser Befehl eure Gelder gefährden kann, wenn der Zustand in der Kanal-DB nicht der aktuellste ist. Dieser Befehl sollte nur für Kanäle ausgeführt werden, bei denen der entfernte Peer lange mehr online war.

chantools --fromsummary ./results/<rescueclosed-file-vom-letzten-schritt>.json forceclose --channeldb ./results/compacted.db --publish

Dies wird eine neue Datei namens ./results/forceclose-yyyy-mm-dd.json erstellen, die für den nächsten Befehl benötigt wird.

Warte auf Timelocks: Der vorherige Befehl hat die verbleibenden offenen Kanäle geschlossen, indem er den Zustand deines Knotens des Kanals veröffentlicht hat. Durch das Design des Lightning-Netzwerks müsst ihr jetzt warten, bis die euch gehörenden Kanalgelder nicht mehr zeitlich gesperrt sind. Abhängig von der Größe des Kanals müsst ihr irgendwo zwischen 144 und 2000 Bestätigungen der Zwangsschließungstransaktionen abwarten. Führt den nächsten Schritt erst aus, nachdem der Kanal mit der höchsten csv_verzögerung so viele Bestätigungen seiner Schließungstransaktion erreicht hat. Ihr könnt dies überprüfen, indem ihr jede zwangsweise geschlossene Kanaltransaktion auf einem Block-Explorer (wie blockstream.info oder mempool.space zum Beispiel) nachschlagt. Öffnet die resultierende JSON-Datei des letzten Befehls (./results/forceclose-yyyy-mm-dd.json) und sucht jede TXID in "force_close" -> "txid" auf dem Explorer. Wenn die Anzahl der Bestätigungen gleich oder größer ist als der in "force_close" -> "csv_delay" für jeden der Kanäle angezeigte Wert, könnt ihr fortfahren.

chantools sweeptimelock: Sobald alle Zwangsschließungstransaktionen die Anzahl der Transaktionen erreicht haben, wie im JSON als csv_timeout gefordert, können diese zeitlich gesperrten Gelder nun übernommen werden. Verwendet den folgenden Befehl, um alle Kanalgelder an eine Adresse eurer Wallet zu übertragen:

chantools --fromsummary ./results/<forceclose-file-vom-letzten-schritt>.json sweeptimelock --publish --sweepaddr <bech32-addresse-aus-eurer-lnd-wallet>

Danach könnt ihr eure Wallets überprüfen, ob die Guthaben gutgeschrieben worden sind.

Backup & Restore auf ein anderes System

Ein sonderer Fall besprechen wir noch hier, hier könnt bei einem Node Crash, und falls schon lange gewünscht von Umbrel auf ein anderes System switchen, auf dem LND direkt läuft. Die Anleitung findet dazu hier:

https://github.com/indomitorum/Baremetal-Migration-LND

Was tun wenn gar kein Backup vorliegt und praktisch keine Daten vorhanden sind

Peer kontaktieren

Sollten absolut gar keine Backups vorliegen haben, ist noch nicht alles verloren. Versucht den Kanal-Peer zu erreichen auf irgendeine Art die euch einfällt. Dafür könnt ihr z.B https://lightningnetwork.plus/ nutzen, und dort die Node aufsuchen, und ihre eine Nachricht schicken, oder ihr nutzt die Seite auf dem sich Peers mit dem selben Problem anschreiben können: https://node-recovery.com/

Schaut unter Zombie Channel Recovery Matcher (alpha) nach und gebt eure Daten an, hat der Peer das selbe Problem, dass der Close nicht durchkommt und er auch Sats auf seiner Seite hat, wird er sicht mit etwas Glück auch hier registrieren. Falls ein Match instande kommt, werden die Daten beider Parteien durch den Maintainer der Seite zusammen geführt. Die Datenbank sucht nach Peers die beide ein Force Close hatten.

Peer erfolgreich kontaktiert, FC per remote ausgelösst

Ihr konntet euren Peer erreichen, und dieser hat den Force Close per remote durchgeführt. Da ihr keinen SCB Restore durchgeführt habt, weiss eure Nodes nichts mehr von irgendwelchen Kanälen und kann deswegen auch die Funds aus dem Force Close nicht sweepen. Wir müssen die Sats deshalb manuell sweepen, und auf eine Wallet Adresse unserer Lightning Node überweisen. Die Gelder in Force Close Transaktionen landen nämlich nicht automatisch auf der eigenen Wallet, nachdem der FC bestätigt worden ist.

Wir benötigt hier deshalb nochmals die chantools, und zwar die Funktion sweepremoteclosed:

Wir benötigen dafür unsere 24 Wörter der Lightning Node, und eine Adresse, auf denen die Funds landen sollen. Hier der Befehl mit seinen Optionen:

chantools sweepremoteclosed [flags]

Examples

chantools sweepremoteclosed \
	--recoverywindow 300 \
	--feerate 20 \
	--sweepaddr bc1q..... \
  	--publish

Options

      --apiurl string           API URL to use (must be esplora compatible) (default "https://blockstream.info/api")
      --bip39                   read a classic BIP39 seed and passphrase from the terminal instead of asking for lnd seed format or providing the --rootkey flag
      --feerate uint32          fee rate to use for the sweep transaction in sat/vByte (default 30)
  -h, --help                    help for sweepremoteclosed
      --publish                 publish sweep TX to the chain API instead of just printing the TX
      --recoverywindow uint32   number of keys to scan per derivation path (default 200)
      --rootkey string          BIP32 HD root key of the wallet to use for sweeping the wallet; leave empty to prompt for lnd 24 word aezeed
      --sweepaddr string        address to recover the funds to; specify 'fromseed' to derive a new address from the seed automatically
      --walletdb string         read the seed/master root key to use fro sweeping the wallet from an lnd wallet.db file instead of asking for a seed or providing the --rootkey flag

Der Daten welche wir brauchen: feerate, die sweepaddr (kann eine Adresse aus der Lightning Wallet sein, aber auch eine Adresse von einer anderen Wallet sein )und einen apiurl string der uns nicht Rate limitiert. Die Feerate ergibt sich aus den aktuellen mempool.space Transaktionsgebühren, wählt hier eine geeignet hohe Gebühr aus. Die sweepaddr ist die Adresse, auf der die Funds landen sollen. Generiert euch hier euch Bech32 Adresse zum Beispiel via RTL und schreibt euch diese auf. Die apiurl ist eher optional, aber wir nehmen hier eine andere, da die Standard API, die chantools verwendet, häufiger mal probleme macht. Machen wir uns an den Befehl:

chantools sweepremoteclosed --recoverywindow 300 --feerate 8 --sweepaddr bc1_adresse --apiurl=https://electrs.gugger.guru --publish

Hier bekommt die Meldung dass ihr eueren Azeed eingeben müsst:

2024-08-17 12:25:24.784 [INF] CHAN: chantools version v0.12.0 commit 
Input your 24-word mnemonic separated by spaces: ...
Input your cipher seed passphrase (press enter if your seed doesn't have a passphrase): 

Danach erklärt euch dass chantools Adressen gefunden hat, auf die ihr Zugriff habt, verwendet den Privatekey durch den angegeben Azeed um die Adressen zu sweepen und sendet sie an die von euch angegeben Adresse:

024-08-18 13:38:53.604 [INF] CHAN: Found 1 unspent outputs for address bc1qkvtux0xxxxxxxxxxxxxxxxxxs0ejm6z520sz4xkqe
2024-08-18 13:39:18.405 [INF] CHAN: Fee 443 sats of 4996530 total amount (estimated weight 443)
2024-08-18 13:39:18.426 [INF] CHAN: Published TX 53523ffc74fe7854298283a0f103f959742fc175efe478d0e100330b9609169c

Die Published TX könnt ihr nun in einen Mempool werfen, und warten bis sie bestätigt wird. Sobald die TX durch ist, sind die Sats wieder auf eurer Wallet.

Fake SCB restore durchführen

Eine weitere Möglichkeit, seine Funds zu retten, wenn der Peer noch Online ist, ist sich selber ein SCB File zusammen zu bauen. Dies besprechen wir in einem separaten Artikel. Verasst wird dieser von einem Kollegen in einem Gastbeitrag.

Abschluss

Ihr kennt nun die wichtigsten Mittel und Wege eure Lightning Node abzusichern und im Katastrophenfall wiederherzustellen. Mir war es wichtig, dass es im Netz einen Artikel gibt, in dem quasi alle Informationen enthalten sind, und Nutzer, in einer prekären Lage sich die Informationen nicht quer auf x verschiedenen Seiten zusammen suchen müssen. Im Anhang findet ihr nochmals alle Quellen, Links und Github Seiten, aus denen die Informationen stammen. Viel Erfolg!

Quellen

https://github.com/lightningnetwork/lnd/blob/master/docs/safety.md

https://github.com/lightningnetwork/lnd/blob/master/docs/recovery.md

https://docs.lightning.engineering/lightning-network-tools/lnd/disaster-recovery

https://node-recovery.com/

https://github.com/lightninglabs/chantools

https://gist.github.com/alexbosworth/2c5e185aedbdac45a03655b709e255a3

Dank an Zett für die Bereitstellung einiger Hinweise und Bilder auf dem RaspiBlitz!

The post Der Backup & Restore Leitfaden für Lightning Fullnodes appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Wofür sind HTLCs?

• Sicherer und schneller Transfer von Zahlungen: HTLCs ermöglichen es, Zahlungen über mehrere Kanäle im Lightning-Netzwerk zu senden, ohne dass die Blockchain für jede einzelne Transaktion aktualisiert werden muss. Das macht Transaktionen schneller und effizienter.
• Vertrauensfreie Transaktionen: Sie erlauben Transaktionen zwischen Parteien, die sich gegenseitig nicht vertrauen müssen. Die Sicherheit wird durch den Mechanismus des HTLCs gewährleistet, nicht durch das Vertrauen in die Gegenpartei.

Wofür werden sie benötigt?

1. Routing von Zahlungen: Im Lightning-Netzwerk werden Zahlungen oft über mehrere Knoten (Nodes) geleitet. HTLCs helfen dabei, dass diese Zahlungen sicher und verlässlich von einem Ende zum anderen gelangen.
2. Verhinderung von Betrug: Durch die Zeitbindung in HTLCs (der "Time-Lock") wird sichergestellt, dass eine Zahlung entweder vollständig durchgeführt oder nach Ablauf der Frist automatisch rückgängig gemacht wird. Das verhindert, dass jemand das Geld nimmt und sich weigert, die Transaktion abzuschließen.

Praktisches Beispiel

Um zu verstehen, wie ein HTLC beim Routing im Lightning-Netzwerk entsteht schauen wir uns ein Beispiel an. Stellt Euch vor, Alice möchte Bob über das Lightning-Netzwerk eine Zahlung senden, aber sie haben keinen direkten Zahlungskanal zueinander. Stattdessen nutzen sie Carol als Zwischenknoten. Hier ist, wie das funktioniert. Wichtig dabei ist, das nur Bob die Zahlung auslösen kann, und kein Knoten dazwischen.

Ausgangssituation

• Alice möchte 1 Bitcoin (BTC) an Bob senden.
• Alice hat einen Zahlungskanal mit Carol, und Carol hat einen mit Bob.

Erstellung des Zahlungsgeheimnisses

• Bob generiert ein Geheimnis und daraus einen Hashwert.
• Bob sendet den Hashwert an Alice, ohne das Geheimnis preiszugeben.

HTLC von Alice zu Carol

• Alice richtet ein HTLC auf ihrem Kanal mit Carol ein.
• Sie sagt: "Carol, ich sende dir 1 BTC, aber du bekommst ihn nur, wenn du mir das Geheimnis zu diesem Hashwert innerhalb eines bestimmten Zeitraums liefern kannst."
• Dieses HTLC ist nun auf der Blockchain gesperrt, aber noch nicht an Carol ausgezahlt.

HTLC von Carol zu Bob

• Carol wiederholt den Prozess mit Bob.
• Sie richtet ein HTLC ein und sagt: "Bob, ich sende dir 1 BTC, aber nur, wenn du mir das Geheimnis zu diesem Hashwert innerhalb eines kürzeren Zeitraums als Alice mir gibt, liefern kannst."

Bob löst das HTLC aus

• Bob kennt das Geheimnis und gibt es an Carol weiter, um den 1 BTC von ihrem HTLC zu erhalten.
• Indem er das Geheimnis offenbart, erlaubt er Carol, das gleiche zu tun, um den 1 BTC von Alice zu erhalten.

Abschluss des Prozesses

• Carol verwendet nun das Geheimnis, um das HTLC mit Alice zu lösen und ihren 1 BTC zu erhalten.
• Alle HTLCs werden abgerechnet, und die Zahlung von Alice an Bob über Carol ist abgeschlossen.

Wichtig zu merken

• Zeitliche Begrenzung: Die HTLCs haben eine Zeitbegrenzung. Wenn das Geheimnis nicht rechtzeitig geliefert wird, wird die Transaktion automatisch abgebrochen, und das Geld kehrt zu seinem ursprünglichen Besitzer zurück.
• Sicherheit: Durch die Verwendung von HTLCs muss Carol das Geheimnis von Bob erfahren, um ihr Geld zu erhalten. Das bedeutet, dass sie die Zahlung nicht einbehalten kann, ohne Bob zu bezahlen.
• Netzwerkeffizienz: Dieser Prozess ermöglicht es dem Lightning-Netzwerk, effizient Zahlungen über mehrere Kanäle zu leiten, ohne dass jeder Knoten ein direktes Vertrauensverhältnis haben muss.

In diesem Beispiel erleichtern die HTLCs eine sichere und effiziente Übertragung von Werten über indirekte Wege, ohne dass alle Beteiligten sich gegenseitig vertrauen müssen. Sie sind der Schlüssel für das Routing und die Skalierbarkeit des Lightning-Netzwerks.

Warum Time-locked Contracts?

Rückerstattung – Verhinderung von Fehlern

Beim Routing einer Zahlung können Probleme auftreten: Einer der Peers auf dem Weg kann offline gehen und unerreichbar werden, während die HTLCs weitergeleitet werden. Auch kann nicht ausgeschlossen werden, dass ein Knoten auf dem Weg böswillig handelt. Was wenn Carol sich weigert, das Geheimnis an den vorherigen Peer weiterzugeben und das HTLC so lange zurückhält, bis das Opfer Lösegeld zahlt?

Es muss eine Möglichkeit geben, zu garantieren, dass das Geld nicht für immer eingefroren wird, falls etwas schiefgeht. Wir müssen eine Rückerstattungsklausel in den Vertrag aufnehmen:

"Wenn Carol, also der Zwischenknoten das Geheimnis nicht innerhalb von 24 Stunden preisgibt, kann Alice die Mittel zurückfordern."

Diese zeitlich begrenzte Rückerstattungsklausel hilft auch, die Vollständigkeit zu erreichen. Man muss sich keine Sorgen über einen teilweisen Zahlungszustand machen. Im Falle eines Fehlers kann jeder Teilnehmer entweder mit seinem Kanalpartner zusammenarbeiten, um das HTLC rückgängig zu machen, oder er kann individuell die zeitlich begrenzte Rückerstattungstransaktion auf die Blockchain setzen, um seine Mittel zurückzuerhalten.

Bestimmte Funktionen erlauben eine bestimmte Blockhöhe oder einen Zeitstempel in der Zukunft anzugeben, wann die Transaktion der Blockchain hinzugefügt werden kann und gültig wird. Bis dahin bleibt die Transaktion unbestätigt und kann nicht zur Blockchain hinzugefügt werden. Im Kontext von HTLCs wird dieser Opcode mit Blockhöhen verwendet. Daher muss der Sender, um die Rückerstattungsklausel nutzen zu können, warten, bis der Block im Sperrskript erreicht ist, und eine gültige Signatur zu seinem oder ihrem öffentlichen Schlüssel vorlegen.

Welche weiteren Möglichkeiten gibt es Betrug auszuschliessen

Ein wichtiges Detail in Lightning-Netzwerkkanälen ist die Möglichkeit, Betrug zu verhindern. Wenn man einen Kanal mit einem Peer öffnet, ist es üblich, über die Lebensdauer des Kanals mehrere Transaktionen durchzuführen und den Kanalsaldo kontinuierlich zu aktualisieren, anstatt nach der ersten Zahlung das HTLC in die Blockchain zu schreiben.

Aber was, wenn ein Peer eine Transaktion mit einem alten Kanalzustand, der ihm zugutekommt, in die Blockchain schreibt, anstatt den neuesten Zustand zu verwenden? Es muss einen Weg geben, dieses Verhalten zu verhindern.

Man könnte eine weitere Klausel in den Vertrag aufnehmen:

"Wenn Bob versucht, von mir zu stehlen, habe ich 24 Stunden Zeit zu beweisen, dass er betrügt. Wenn ich das beweisen kann, darf ich das gesamte Geld, das wir unserem Kanal zugesichert haben, alleine behalten."

Wie beweisen wir, dass unser Peer betrogen hat?

Wenn jemand den Kanalzustand mit einem falschen State aktualisieren möchte, gibt er dem anderen Peer eine aktualisierte Commitment-Transaktion mit dem neuen Kanalsaldo. Der andere Peer antwortet mit einem "revocation-key", der als Beweis verwendet werden kann, dass der Kanalzustand nicht korrekt ist ist. Diese gegenseitige Überprüfung geschieht bei jeder Lightning-Transaktion, sodass bei 1000 Transaktionen 1000 Widerrufsschlüssel gespeichert werden müssen, bis der Lightning-Kanal geschlossen wird.

Es gibt mehrere Aktionen die ausgeführt werden können. Die erste ist die Straftransaktion: Sie ermöglicht es jedem, der den <Widerrufsöffentlicherschlüssel> signieren kann, und wird von der betrogenen Partei verwendet eine Aktion einzuleiten. Wenn Alice betrogen wird, kann sie den Widerrufsschlüssel, den Bob ihr gegeben hat, als sie ihren Kanalzustand aktualisiert haben, verwenden, um das gesamte Geld aus dem Kanal für sich zu beanspruchen. Der Zustand wird sofort in die Blockchain geschrieben und der Kanal mit dem Zustand von Alice auf die Blockchain geschrieben.

Die zweite Aktion verhindert es der Partei, die den HTLC hält und daher eine gültige Signatur für den <Local Delayed Public Key> hat, die Bitcoin auszugeben (Also damit ist Bob der Betrüger gemeint). Damit das nicht passiert gibt es eine Schutzfunktion: Der Ausgebende muss warten, bis die festgelegte Verzögerung abgelaufen ist. Die Verzögerung wird vor der Eröffnung des Kanals vereinbart und ist normalerweise umso größer, je mehr Geld dem Kanal zugesichert wird. So geben wir Alice Zeit zu beweisen, dass sie beraubt wird. Damit wird verhindert, sollte Alice kurz offline sein, oder Netzwerkprobleme haben, um Ihren echten Kanalzustand offen zu legen, ansonsten könnte das Bob schnell tun und den falschen Kanalzustand settlen und den Kanal closen.

Da die Bitcoin-Blockchain Nutzer vor Doppelausgaben schützt und die betrügerische Partei warten muss, um die Transaktion in der Blockchain zu bestätigen, kann die betrogene Partei die Straftransaktion veröffentlichen, sobald sie die Transaktion mit dem falschen Kanalsaldo im Mempool sieht, und sie schneller bestätigen lassen, als der Betrüger seine Transaktion bestätigen kann, da dieser ja eine Verzerzögerung gebunden ist

HTLCs sind also ein cleveres Instrument im Lightning-Netzwerk, das schnelle, kostengünstige und sichere Transaktionen ermöglicht, aber es erfordert auch einiges an Management und Verständnis, um sie effektiv zu nutzen. Ihr werdet aber als normer Node Betreiber, der ab und zu ein paar Zahlungen tätigten, eher weniger aktiv mit HTLCs zu tun haben, das übernimmt Eure Node automatisch im Hintergrund.

The post Was sind HTLC im Lightning Netzwerk und wozu werden sie benötigt appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Grundlagen des Lightning-Netzwerks

Bevor wir uns auf Outbound- und Inbound-Liquidität konzentrieren, nochmal ein kurzer Überblick über das Lightning-Netzwerk. Das Hauptziel des Lightning-Netzwerks ist es, die Effizienz von Bitcoin-Transaktionen zu erhöhen. Es ermöglicht Nutzern, Off-Chain-Transaktionen durchzuführen, was bedeutet, dass diese Transaktionen nicht auf der Bitcoin-Blockchain aufgezeichnet werden. Stattdessen werden sie in privaten oder öffentlichen Kanälen abgewickelt, die zwischen zwei Parteien eingerichtet werden. Diese Kanäle können für mehrere Transaktionen zwischen denselben Parteien verwendet werden, bevor der endgültige Zustand auf die Blockchain zurückgeführt wird.

Ein ausführlicher Artikel zum Thema Lightning findet Ihr hier.

Outbound-Liquidität

Outbound-Liquidität im Lightning-Netzwerk bezieht sich auf die Fähigkeit eines Netzwerkteilnehmers, Zahlungen an andere Teilnehmer zu senden. Wenn du einen Lightning-Kanal eröffnest, entspricht die Menge an Bitcoin, die du in den Kanal einzahlst, deiner Outbound-Liquidität. Mit anderen Worten: Es ist der Betrag, den du potenziell an andere überweisen kannst.

Beispiel

Angenommen, Ihr eröffnet einen Lightning-Kanal und hinterlegt dabei 0,1 BTC. Diese 0,1 BTC repräsentieren deine Outbound-Liquidität. Du kannst bis zu diesem Betrag an andere Netzwerkteilnehmer senden, solange beim Gegenüber die entsprechende Inbound-Liquidität vorhanden ist.

Inbound-Liquidität

Inbound-Liquidität ist das Gegenstück zur Outbound-Liquidität. Es ist die Fähigkeit, Zahlungen von anderen Netzwerkteilnehmern zu empfangen. Um Zahlungen über das Lightning-Netzwerk empfangen zu können, muss ein Nutzer über genügend Inbound-Liquidität verfügen.

Beispiel

Wenn jemand anderes einen Kanal zu Euch mit 0,1 BTC eröffnt, habt Ihr 0,1 BTC an Inbound-Liquidität. Das bedeutet, Ihr könnt bis zu 0,1 BTC über diesen Kanal empfangen.

Die Balance von Outbound- und Inbound-Liquidität

Für effektive Transaktionen im Lightning-Netzwerk ist ein Gleichgewicht zwischen Outbound- und Inbound-Liquidität notwendig. Wenn ein Kanal eröffnet wird, fließt die Liquidität in eine Richtung – von dem, der den Kanal finanziert, zu dem, mit dem der Kanal eröffnet wird. Sobald Transaktionen über den Kanal fließen, verschiebt sich diese Liquidität.

Beispiel

Wenn Ihr in unserem früheren Beispiel 0,05 BTC an jemand anderen sendet, reduziert sich Eure Outbound-Liquidität auf 0,05 BTC, und Eure Inbound-Liquidität steigt auf 0,05 BTC. Umgekehrt erhöht sich die Inbound-Liquidität der anderen Partei um 0,05 BTC und deren Outbound-Liquidität sinkt entsprechend.

Wie man Outbound-Liquidität erhält

1. Kanalöffnung: Ihr erhaltet Outbound-Liquidität, indem Ihr einen Lightning-Kanal zu einem anderen Nutzer eröffnet und dabei Bitcoin in den Kanal einzahlt.
2. Einlagebetrag: Der Betrag, den Ihr einzahlt, entspricht Eurer Outbound-Liquidität. Dies ist der Betrag, den Ihr über diesen Kanal senden könnt.

Wie man Inbound-Liquidität erhält

1. Von anderen Nutzern: Inbound-Liquidität entsteht, wenn ein anderer Nutzer einen Kanal zu Euch eröffnet und Bitcoin in diesen Kanal einzahlt.
2. Durch Transaktionen: Wenn Ihr Zahlungen über Euren Kanäle empfängt, erhöht sich ebenfalls Eure Inbound-Liquidität. Zum Beispiel, wenn Ihr zuerst Outbound-Liquidität hattet und damit Zahlungen an andere gesendet habt, wird ein Teil deiner Outbound-Liquidität zu Inbound-Liquidität für Euch.

Zusätzliche Methoden

• Liquiditätspools und Swaps : Einige Dienste im Lightning-Netzwerk bieten Liquiditätspools an, wo Ihr gegen eine Gebühr Inbound-Liquidität erwerben könnt. Ein bekannter seriöser Betreiber währe hier z.B https://lightningnetwork.plus/
• Rebalancing: Durch das Rebalancing von Kanälen kannst du deine Outbound- und Inbound-Liquidität ausgleichen. Dies geschieht meistens durch spezialisierte Tools oder manuelle Transaktionen via RTL, Thunderhub, Lightning Terminal und etc

Lesst weiter unten etwas mehr über die zusätzlichen Methoden im Liquiditätsmanagement.

Herausforderungen und Lösungen

Eines der Aufgaben im Lightning-Netzwerk ist das Management von Liquidität. Netzwerkteilnehmer, insbesondere diejenigen, die als Knotenpunkte fungieren und Transaktionen weiterleiten, müssen ständig ihre Kanäle überwachen und anpassen, um sowohl Outbound- als auch Inbound-Liquidität zu optimieren. Lösungen hierfür beinhalten die Eröffnung neuer Kanäle, das Ausbalancieren von Bestehenden über sogenannte "Rebalancing"-Transaktionen und die Nutzung spezieller Dienste, die Liquidität gegen eine Gebühr anbieten.

Liquiditätsmanagement

Beim Liquiditätsmanagement im Lightning-Netzwerk gibt es verschiedene Ansätze zur Automatisierung, die dazu beitragen, Eure Kanäle in einem gesunden Gleichgewicht zu halten. Ist ein Kanal leer oder hat nur noch Outbound und kein Inbound mehr, stellen Lightning Management Applikationen wie RTL oder Thunderhub Dienste bereit, die automatisiert die Kanäle wieder ausbalanzieren können. Da das Management von Outbound- und Inbound-Liquidität eine kontinuierliche Herausforderung darstellt, können automatisierte Tools und Mechanismen entscheidend sein. Hier sind einige der gängigsten Automatisierungsmöglichkeitenmethoden.

1. Rebalancing-Tools

• Funktionsweise: Diese Tools automatisieren den Prozess des Ausgleichs von Liquidität in den Kanälen. Sie verschieben Mittel zwischen verschiedenen Kanälen eines Knotens, um ein optimales Gleichgewicht zwischen Inbound- und Outbound-Liquidität zu erreichen.
• Ziel: Das Ziel ist, die Fähigkeit des Knotens zu maximieren, sowohl Zahlungen zu senden als auch zu empfangen, ohne manuelles Eingreifen.

2. Algorithmische Routenfindung

• Dynamische Anpassungen: Einige Tools verwenden Algorithmen, um die effizientesten Pfade für Transaktionen zu finden, wobei die Liquiditätslevels der beteiligten Kanäle berücksichtigt werden.
• Vorteile: Dies erhöht die Wahrscheinlichkeit erfolgreicher Transaktionen und verringert die Abhängigkeit von manueller Überwachung und Anpassung.

3. Liquiditätspools

• Konzept: Liquiditätspools sind eine Art von gemeinschaftlichen Ressourcen, die von mehreren Knoten genutzt werden können. Sie ermöglichen es Knoten, auf gemeinsame Liquiditätsreserven zuzugreifen, um ihre eigenen Kanäle zu unterstützen.
• Flexibilität: Sie bieten eine flexible Lösung, um temporäre Liquiditätsengpässe auszugleichen, ohne ständig eigene Kanäle anzupassen.

Solche Tools und Applikationen benötigen aber nur grössere Routing Nodes und evt Shop Betreiber um sicherzustellen dass sie Inbound- und outbound-technisch immer liquide sind.

In einem weiteren Beträg demnächst schauen wir uns an wie wir via lightningnetworks+ Inbound Liquität bekommen oder via RTL Circuallar Rebalancing unsere Kanäle etwas ausgleichen können. Dieser Beitrag sollte in erster Linie mal dazu dienen, Euch das Konzept von Inbound und Outbound zu veranschaulichen.

The post Was ist Inbound und Outbound Liquidität im Lightning Netzwerk appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitungen um mit einer Bitcoin Full Node Lightning Kanäle finden und erstellen zu können

Eure Bitcoin Full Node muss zu 100% synchronisiert sein. Die Erstellung von Lightning Kanälen bei nicht fertig synchronisierten Nodes ist nicht möglich. Am besten wartet ihr noch, wenn Electrum oder Electrs gerade synchronisert, bis die Indexierung fertig ist, damit die Belastungen dadurch wegfallen.

Umbrel Bitcoin Full Node Vorausetzungen

Ihr benötigt eine Bitcoin Full Node mit einem Lightning Backend installiert. Bei Umbrel könnt ihr Lightning ganz einfach über den App Store installieren:

Wir empfehlen Anfängern die Standard Lightning Node mit dem Lightning Network Daemon (LND). Wer sich etwas mit der Materie auskennt, und c-lightning ausprobieren möchte, der installiert sich Core Lightning anstatt Lightning Node:

Die Wallet muss eingerichtet werden, indem die App geöffnet wird, und euer Azeed, bzw. eure 24 Wörter aufgeschrieben werden. Danach ist die Lightning Node bereits betriebsbereit.

Ausserdem müsst ihr natürlich ebenso ein paar Sats auf die Lightning Onchainwallet schicken, bevor ihr Kanäle öffnen könnt. Das geht mit dem Button Receive, welcher euch eine Adresse generiert, an die ihr ein paar Sats senden könnt.

RaspiBlitz Bitcoin Full Node Voraussetzungen

Die Lightning Node muss beim Setup eurer Raspi Node installiert sein. Falls ihr Lightning nicht installiert habt, könnt ihr das im Nachhinein immer noch tun.

Stellt eine SSH Verbindung zu eurer Node her. Der Benutzername ist admin, das Passwort ist das Passwort A bzw. das Webinterface Passwort. Ihr landet in der Statusübersicht, beendet diese mit strg+c. Öffnet das Raspi Menu mit dem Befehl menu. Wählt die SETTINGS aus und danach wählt ihr mit der Leertaste LND LIGHTNING LABS NODE aus und wählt anschliessend OK aus indem ihr mit der Enter Taste bestätigt.

Der Blitz installiert anschliessend LND. Ihr müsst nach der Installation eine Seedphrase festlegen, so wie ihr es von Walleterstellungen kennt. Bewahrt eure Seedphrase unbedingt sicher auf!

Startet anschliessend den Raspi mit sudo systemctl reboot neu.

Ihr müsst natürlich ebenso auch beim Raspiblitz ein paar Sats auf die Lightning Onchainwallet schicken, bevor ihr Kanäle öffnen könnt.

Das könnt ihr im WebUI einfach mit dem Button Erhalten/Receive erledigen.

Lightning Kanal Partner finden

Eine sehr gut Seite mit der Übersicht aller verfügbaren Lightning Nodes ist https://1ml.com/
Ihr könnt dort oben in der Suchleiste direkt nach IP Adressen, Public Node Keys, Orten und vielen mehr suchen. Beispielsweise können wir direkt mal Switzerland eingeben und nach verfügbaren Lightning Nodes in der Schweiz suchen.

Wir bekommen eine Übersicht mit einigen Orten in der Schweiz, wir klicken aber direkt auf Switzerland und können uns alle Lightning Nodes in einer Liste ansehen.

Wir sehen rechts eine Übersicht aller Kanäle mit den Lightning Nodes in der Schweiz der Grösse nach sortiert. Ihr seht in der Übersicht die Kapazität in BTC und die Anzahl an Kanälen. Klicken wir auf einen der Nodes bekommen wir weitere Informationen. Die wichtigste Information die wir benötigen ist der Node Public Key:

Links findet ihr nochmals Kapazitätsinfos, unterhalb des QR Codes die Node im Vergleich zu anderen Nodes und darunter die aktuellen Kanäle der Node.

Wählt euch eine Node ,welche euch sympathisch erscheint. Nehmt evt. nicht die grössten Node Betreiber da diese oft eine Mindestkanalgrösse an Sats voraussetzen, um sich mit ihnen verbinden zu können.

Eine weitere Seite um Nodes zu finden wäre beispielsweise amboss.space. Dort könnt ihr jedoch nicht nach Locations suchen, was ich persönlich als Nachteil empfinde, die Seite ist oft jedoch aktueller, und sie bietet einem noch viele weitere Möglichkeiten, zum Beispiel gibt es auch Optionen, um dort direkt Inbound Liquidität kaufen zu können, vor allem für Shop Betreiber interessant.

Umbrel Full Node mit der ausgewählten Node verbinden

Wir stellen hier im Beispiel eine Verbindung mit fairly.cheap her. Wir gehen auf unsere Lightning Node in der App Übersicht und scrollen nach unten und klicken auf Open Channel rechts bei der Kanalübersicht.

Wir geben hier die Public Node ID ein, wählen eine Grösse von 1 Millionen Sats und wählen unten dann eine Transaktionsgebühr nach unserer Priorität. Wollt ihr dass der Kanal in den nächsten 10min sicher eröffnet wird, schiebt den Regler ganz nach rechts. Bitte achtet aber unbedingt auf die aktuellen Transaktionsgebühren. Es kann teilweise je nach Auslastung der Blockchain mehre Franken im ersten Block zu landen. Achtet also auf die errechneten Gebühren. Wenn es nicht eilt, könnt ihr auch den Schieber bei 4hrs oder ähnlich setzen. Habt ihr eure Einstellungen gewählt, klickt anschliessend auf Open Channel.

Bitte überprüft die aktuellen Transaktionsgebühren immer zuerst auf mempool.space. Die Angaben sind nicht immer aktuell.

Nachdem ihr auf OPEN CHANNEL geklickt habt, seht ihr den Kanal in eurer Kanalübersicht:

Ihr könnt die aktuelle Position der Kanaleröffnung in der Transaktionsübersicht überprüfen: Ihr seht dass ich leider eine etwas zu geringe Gebühr gewählt habe. Unter Umständen kann dies nun gut un gerne 12 bis 24h gehen bis die Transaktion durchkommt.

Nachdem die Transaktion 1-3 Blöcke bestätigt worden ist, habt ihr nun euren ersten Kanal erfolgreich eröffnet!

RaspiBlitz Full Node mit der ausgewählten Node verbinden

Die Erstellung von Lightning Kanälen auf dem Blitz ist ebenso sehr einfach. Loggt euch im Webinterface ein und klickt auf dem Hauptbildschirm.

Danach tätigt die Einstellungen ähnlich wie bei Umbrel. Gebt die Public Key ID ein, die Menge an Sats und die Dringlichkeit. Bei Raspi entsprechen Langsam, Normal und Dringend den Durschnittsgebühren von Niedrige Priorität, Mittlere Priorität und die Hohe Priorität im Mempool.space Blockexplorer.

Habt ihr alles richtig eingestellt, wird der Kanal eröffnet und ist verwendbar sobald die Transaktion 1-3 Blöcke bestätigt worden ist. Ich habe jetzt kein Beispielkanal, erstellt da ich den RaspiBlitz nur als Testnode verwende.

Wichtige Hinweise von der Benutzung von Lightning auf der Bitcoin Full Node

1. Offline-Dauer: Wenn eure LN-Node längere Zeit offline ist, besteht die Gefahr, dass euer Kanalpartner versucht, eine ältere Kanalzustandsausgabe zu übertragen, die ihm mehr Coins zuweist. Daher ist es wichtig, Eure Node regelmäßig online zu halten.
2. Watchtowers: Ein Watchtower ist ein Drittanbieter-Service, der den Zustand eures Kanals überwacht, während ihr offline seid. Ihr könnt darauf reagieren, wenn ein Kanalpartner versucht, euch zu betrügen, sollte er eine älteren Kanalstand zu senden um den Kanal zu schliessen. Es ist sehr empfehlenswert, einen Watchtower zu verwenden, wenn ihr nicht sicherstellen können, dass Eure Node ständig online ist.
3. Backups: Es ist wichtig, regelmäßige Backups eurer LN-Node und eurer Kanalzustände zu machen. Wenn ihr euren Kanalzustand verliert, kann dies dazu führen, dass ihr nicht mehr so einfach auf eure Funds zugreifen könnt oder sogar Geld verliert. Halte euch an unseren Backup & Restore Leitfaden.
4. Channel-Funding: Wenn ihr einen Kanal eröffnet, stellt sicher, dass ihr nicht mehr Bitcoin verwendet, als ihr euch leisten könnt zu verlieren, besonders während ihr euch mit dem Netzwerk vertraut macht.
5. Gebühren: Stellt sicher, dass ihr angemessene Gebühren festlegt, wenn ihr einen Kanal eröffnet (nicht so wie ich im Beispiel) oder schließt. Wenn die Gebühren zu niedrig sind, kann eure Transaktion hängen bleiben, und sehr lange dauern insbesondere wenn das Bitcoin-Netzwerk ausgelastet ist.
6. Experimente: Vermeidet es, größere Beträge in experimentellen Implementierungen wie Taproot Channels oder neu veröffentlichten LN-Wallets zu speichern.
7. Kanal-Schließung: Schließt Kanäle nicht unnötig, da dies On-Chain-Gebühren erzeugt und das Hauptziel von Lightning darin besteht, Off-Chain-Transaktionen zu fördern.
8. Routing: Wenn ihr ein Routing-Node werden möchten, benötigt ihr genügend Liquidität, technische Expertise und eine konstante Online-Präsenz.
9. Updates: Haltet eure LN-Software stets aktuell. Entwickler arbeiten kontinuierlich daran, Sicherheitslücken zu schließen und das Netzwerk zu verbessern.
10. Private vs. Öffentliche Kanäle: Denkt daran, dass öffentliche Kanäle für jeden im Netzwerk sichtbar sind. Wenn ihr mehr Privatsphäre wünscht, könnt ihr private Kanäle verwenden.

Informiert euch, falls möglich vorher etwas über die Nodes mit denen ihr euch verbindet wollt. Am allerbesten ist es, wenn ihr vorher Kontakt mit den jenigen aufbaut und die Öffnung kurz absprecht. Wichtig ist, vertrauenswürdige und zuverlässige Peers zu haben. Peers die ständig offline gehen, bringen mehr Ärger als nutzen. Versucht auch bei günstigen Fees Kanäle zu öffnen. Weitere Transaktionsgebühren werden bei der Schliessung der Kanäle wieder fällig.

Lightning Peer Tipps und Vorschläge

Coingate - keine Mindestkanalgrösse, sehr gut vernetzte Node, leider teilweise mit etwas hoher Latenz

https://amboss.space/node/0242a4ae0c5bef18048fbecf995094b74bfb0f7391418d71ed394784373f41e4f3

Boltz | CLN - 500'000 Sats Mindesteskanalgrösse, sehr schnelle und gut vernetzte Node

https://amboss.space/node/02d96eadea3d780104449aca5c93461ce67c1564e2e1d73225fa67dd3b997a6018

NikolaTesla - sehr gut vernetzte Plebnode, 100'000 Sats Mindestkanalgrösse

https://amboss.space/node/035cf526f4c01ed693bacd7434461b9dc53d65b910fb3006110d8b42a574858fb2

LNBig Hub 1 - sehr grosse, gut vernetzte Node ohne Mindestkanalgrösse

https://amboss.space/node/034ea80f8b148c750463546bd999bf7321a0e6dfc60aaf84bd0400a2e8d376c0d5

Wyssblitz - Schweizer PlebNode - schnell und zuverlässige Node, jedoch mit Mindestkanalgrösse von 2'000'000 Sats

https://amboss.space/node/02ad4afb6e50ae4635ec5ddf5a57c44d4cc4b376ac6580f78cda0454a86e5fa6c2

Fehlermeldungen und Kanäle öffnen nicht

Es kann sein, dass die Node eine Mindestkanalgrösse verlangt, oder sogar eine gewisse Anzahl an Kanälen eurerseits voraussetzt. Wenn ein Kanal nicht öffnen will, liegt das zu 99% an den Einstellungen des Peers, und nicht daran, dass eure Node nicht funktioniert oder probleme hat.

Private vs Public Channel

Auf dem Lightning Network gibt es zwei Haupttypen von Kanälen: private Channels und public Channels. Diese unterscheiden sich hauptsächlich in ihrer Sichtbarkeit und ihrem Verwendungszweck. Hier eine ausführliche Erklärung der Unterschiede:

Public Channels

Eigenschaften:

• Öffentlich sichtbar: Public Channels sind im gesamten Lightning Network sichtbar. Ihre Existenz und Eigenschaften, wie Kapazität, Node-IDs der Teilnehmer und Gebühreneinstellungen, werden in der Netzwerkgraph-Datenbank propagiert, die von allen Nodes synchronisiert wird.
• Routingfähig: Public Channels können für das Routing von Zahlungen zwischen anderen Nodes genutzt werden. Wenn beispielsweise zwei Nodes über einen Public Channel verbunden sind, können sie Zahlungen anderer Nodes weiterleiten und dafür Gebühren erheben.
• Typische Nutzung: Public Channels werden von Routing-Nodes genutzt, um Liquidität bereitzustellen und Routing-Gebühren zu verdienen. Sie sind ein zentraler Bestandteil des Lightning Networks und sorgen für die Zahlungsweiterleitung.

Vorteile:

• Netzwerkunterstützung: Public Channels tragen aktiv zum Lightning Network bei, da sie Zahlungsrouten für andere Nodes ermöglichen.
• Gebühreneinnahmen: Nodes, die Public Channels betreiben, können durch Weiterleitungen Gebühren verdienen.
• Sichtbarkeit: Sie fördern die Verbindungsfähigkeit der eigenen Node und machen sie zu einem aktiven Teilnehmer im Netzwerk.

Nachteile:

• Erhöhte Angriffsfläche: Da Public Channels öffentlich sichtbar sind, kann ein Angreifer potenziell Informationen über die Node sammeln und gezielt angreifen.
• Veröffentlichte Liquidität: Die Liquiditätsverteilung (lokal/remote) ist öffentlich einsehbar, was zu potenziellen Privatsphäreproblemen führen kann.

Private Channels

Eigenschaften:

• Nicht sichtbar: Private Channels sind nicht im öffentlichen Lightning-Netzwerkgraphen sichtbar. Ihre Existenz ist nur den beiden verbundenen Nodes bekannt.
• Nicht-routingfähig: Private Channels können nicht für das Routing von Zahlungen Dritter genutzt werden. Sie dienen ausschließlich für Zahlungen zwischen den beiden verbundenen Nodes.
• Typische Nutzung: Private Channels werden häufig für persönliche oder spezifische Verwendungszwecke genutzt, z. B. um Zahlungen zu einem befreundeten Node oder zu einem Händler zu senden, ohne dass andere Nodes davon erfahren.

Vorteile:

• Privatsphäre: Da ein Private Channel nicht im Netzwerkgraphen erscheint, bleibt seine Existenz und Liquidität verborgen.
• Einfachheit: Für den Aufbau eines Private Channels sind weniger administrative Einstellungen nötig, da keine Gebührenstrukturen für Routing eingerichtet werden müssen.
• Gezielte Verwendung: Ideal für Zahlungen zu einem bestimmten Ziel, z. B. zwischen einer persönlichen Wallet und einem Zahlungsdienst.

Nachteile:

• Keine Routing-Funktionalität: Private Channels tragen nicht zur Weiterleitung von Zahlungen im Lightning Network bei.
• Limitierte Nutzung: Zahlungen sind nur zwischen den beiden Nodes des Kanals möglich oder über eine spezielle Route, bei der eine Node einen "Hint" zur Route gibt (z. B. durch eine BOLT-11-Invoice mit Routing-Hinweisen).

Zusammenfassung der Unterschiede

In der Praxis hängt die Wahl zwischen einem Public oder Private Channel stark vom Ziel der Node-Betreiber ab. Wer aktiv zum Lightning Network beitragen oder Gebühren verdienen möchte, setzt auf Public Channels. Wer hingegen Wert auf Privatsphäre und die Node nur für persönliche Zahlungen verwendet, wählt Private Channels.

Mit wieviel Peers sollte ich mich verbinden

Das hängt von mehreren Faktoren ab. Grundsätzlich erstmal, umso mehr, umso besser. Verbindet ihr euch mit einer Node, die bereits Kanäle zu hundert anderen Nodes hat, ist die Chance relativ hoch, dass eure Zahlung einen Weg durch das Netzwerk findet. Verbindet ihr euch nur mit kleineren Plebnodes mit nur wenigen Kanälen, kann es sein, dass die Zahlungen nicht durchgehen, weil die Liquidität der kleinen Node keine Pfad ergibt, oder keine Route gefunden wird. Wer sich gerne mit Plebnodes verbindet, sollte ruhig 3-4 Kanäle eröffnen. Wenn ihr das nötige Kleingeld habt, um euch mit WalletofSatoshi zu verbinden (5 Millionen Sats Minchansize) braucht ihr theoretisch nur einen Kanal. Aber auch hier kann es hin und wieder mal zu Problemen kommen, z.B wenn WoS überlastet ist, die Liquidität suboptimal liegt, oder die Node einfach nur offline ist.

Lightning Fullnode mit Smartphone verbinden

Damit ihr von unterwegs mit euren Lightningsats bezahlen könnt, müsst ihr die Node mit einem Client wie Bitbanana oder Zeus verbinden. Dann könnt ihr mit den Apps QR Codes für Zahlungen scannen, und eure Node führt die Zahlungen dann aus. Hier ein exemplarisches Tutorial für die App Bitbanana.

Fazit

Das Lightning Network bietet eine großartige Möglichkeit, Bitcoin-Zahlungen schnell, kostengünstig und effizient abzuwickeln. Mit einer vollständig synchronisierten Bitcoin Full Node und den richtigen Tools, wie Umbrel oder RaspiBlitz, ist es möglich, Lightning-Kanäle mit gezielt ausgewählten Peers zu eröffnen und die Vorteile des Netzwerks voll auszuschöpfen.

Die Wahl zwischen Public und Private Channels hängt von den individuellen Bedürfnissen ab: Public Channels bieten Netzwerkunterstützung und Routing-Möglichkeiten, während Private Channels mehr Privatsphäre garantieren. Die Verwendung von Plattformen wie 1ml.com oder amboss.space erleichtert das Finden geeigneter Peers erheblich. Dabei ist es essenziell, auf die Mindestanforderungen der Nodes zu achten und vertrauenswürdige Partner zu wählen.

Regelmäßige Backups, aktuelle Software und die Nutzung von Watchtowers sind entscheidend, um Sicherheit und Zuverlässigkeit zu gewährleisten. Mit der richtigen Vorbereitung und einem durchdachten Vorgehen ist das Lightning Network ein leistungsstarkes Werkzeug, um Bitcoin-Zahlungen flexibel und innovativ zu gestalten.

Ich hoffe der heutige Artikel Bitcoin Full Node Lightning Kanäle finden hat euch gefallen, habt ihr Fragen, schreibt sie in die Kommentare! Habt ihr Interesse an einer eigenen Bitcoin Full Node? Dann schaut hier vorbei!

The post Channel Peers finden und Lightning Kanäle eröffnen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Funktionsweise des Lightning Netzwerks

Das Bitcoin Lightning Network ist also eine so genannte "Second-Layer"-Lösung auf der Bitcoin-Blockchain, die eine erhebliche Erhöhung der Transaktionsgeschwindigkeiten und der Gesamttransaktionskapazität ermöglicht. Aber was bedeutet das jetzt genau, und welche Vorteile erreicht Bitcoin dadurch? Die Grundidee besteht darin, die Notwendigkeit einer globalen Übereinstimmung für alle Transaktionen zu eliminieren, indem Zahlungskanäle geschaffen werden, die nur zwei Teilnehmer involvieren und nicht auf jeder einzelnen Transaktion beruhen.

Die Hauptkomponenten des Lightning Netzwerkes

1. Zahlungskanäle: Ein Zahlungskanal ist eine private Verbindung zwischen zwei Teilnehmern im Lightning-Netzwerk. Dieser Kanal wird auf der Blockchain erstellt und ermöglicht den Austausch von Bitcoin zwischen den beiden Parteien, ohne dass jede Transaktion auf der Blockchain registriert werden muss. Stattdessen werden die Transaktionen innerhalb des Kanals verarbeitet und nur der Endsaldo wird schließlich auf der Blockchain registriert. Die Erstellung eines Zahlungskanals erfordert eine Anfangstransaktion auf der Blockchain, die als "Commitment-Transaktion" bekannt ist. Diese Transaktion ist so strukturiert, dass beide Parteien Kontrolle über die im Kanal gesperrten Bitcoin haben, obwohl sie technisch gesehen noch nicht ausgegeben wurden.
2. Commitment-Transaktionen: Im Laufe der Zeit können die beiden Teilnehmer im Zahlungskanal so viele Transaktionen durchführen, wie sie möchten, indem sie die Gelder hin und her schicken. Jede dieser Transaktionen wird als "Commitment-Transaktion" bezeichnet, da sie die Verpflichtung der beiden Parteien zur Aufteilung der Gelder widerspiegelt. Wichtig ist, dass diese Commitment-Transaktionen nicht sofort auf der Blockchain gesendet werden. Stattdessen werden sie von den beiden Parteien unterzeichnet und privat gehalten, bis einer der beiden Teilnehmer sich dazu entschließt, den Kanal zu schließen.
3. Das Schließen eines Kanals: Wenn einer der Teilnehmer den Zahlungskanal schließen möchte, sendet er die neueste Commitment-Transaktion an die Blockchain. Dieser Prozess wird als "Settlement" bezeichnet und erfordert eine On-Chain-Transaktion. Sobald diese Transaktion bestätigt ist, sind die Bitcoin für jede Partei entsprechend dem Endsaldo aus dem Kanal verfügbar.

Eines der wichtigsten Merkmale des Lightning-Netzwerks ist die Fähigkeit, Zahlungen über mehrere Kanäle zu routen. Dies bedeutet, dass, wenn Alice eine Zahlung an Bob senden möchte, sie nicht unbedingt einen direkten Zahlungskanal mit Bob haben muss. Wenn Alice einen Kanal mit Carol hat und Carol einen Kanal mit Bob hat, kann Alice die Zahlung über Carol an Bob leiten.

Wir stellen fest, dass das Lightning-Netzwerk durch die Verlagerung von Transaktionen von der Bitcoin-Blockchain auf Off-Chain-Zahlungskanäle die Skalierbarkeit und Geschwindigkeit von Bitcoin verbessert. Es ermöglicht sofortige Zahlungen, verringert die Transaktionskosten und verbessert die Privatsphäre und Sicherheit der Benutzer.

Vorteile des Lightning Netzwerks

1. Schnelligkeit: Da die Transaktionen off-chain durchgeführt werden, sind sie fast sofortig und nicht an die Blockgenerierungszeit der Bitcoin-Blockchain gebunden. Dies ist ein großer Vorteil für Mikrotransaktionen und Situationen, in denen schnelle Transaktionen erforderlich sind.
2. Kosteneffizienz: Das Lightning Network erlaubt es Benutzern, Transaktionsgebühren zu sparen, da die meisten Transaktionen off-chain durchgeführt werden. Nur das Öffnen und Schließen von Kanälen erfordert Gebühren, die mit On-Chain-Transaktionen verbunden sind.
3. Skalierbarkeit: Das Lightning Network verbessert die Skalierbarkeit von Bitcoin, indem es die Anzahl der Transaktionen, die das Netzwerk handhaben kann, drastisch erhöht. Dies könnte Bitcoin einen Schritt näher an eine echte Peer-to-Peer-Elektronische Währung bringen.

Datenschutz im Lightning Netzwerk

Im Vergleich zu On-Chain-Transaktionen bietet das Lightning Network verbesserten Datenschutz. Da die meisten Transaktionen off-chain erfolgen und nur das Endresultat auf die Blockchain kommt, ist es schwieriger, die Bewegungen von Bitcoin zu verfolgen. Zudem verwendet das Lightning Network das Onion-Routing, ähnlich wie Tor, um die Privatsphäre der Benutzer zu schützen. Jeder Knoten im Pfad kennt nur seinen direkten Vorgänger und Nachfolger, aber nicht die gesamte Route, wodurch die Möglichkeit einer Überwachung oder Zensur verringert wird.

Lightning Netzwerk Software und Implementierungen

Es gibt mehrere Implementierungen des Lightning Protokolls, jede mit ihren eigenen Merkmalen und Vorteilen:

1. LND (Lightning Network Daemon): LND ist eine weit verbreitete Implementierung des Lightning-Protokolls. Sie ist benutzerfreundlich und bietet APIs für Entwickler, die auf Go basieren.
2. c-lightning: c-lightning ist eine leistungsorientierte Implementierung des Lightning-Protokolls von Blockstream. Sie bietet verschiedene Plugins und ist in der Programmiersprache C geschrieben, was sie extrem effizient und anpassbar macht.
3. Eclair: Eclair, entwickelt von ACINQ, ist eine weitere Implementierung des Lightning-Protokolls. Es bietet eine vollständige Lightning-Node-Implementierung und ist in Scala geschrieben.

Mit LND kompatible Apps:

1. Zap oder auch Bitbanana Wallet: Zap/Bitbanana ist eine einfache und sichere Bitcoin Wallet, die das Lightning Network nutzt, um sofortige Zahlungen zu ermöglichen. Es verwendet LND im Hintergrund und bietet eine intuitive und benutzerfreundliche Oberfläche.
2. Zeus: Zeus ist eine mobile Lightning Wallet, die LND, c-lightning und Eclair unterstützt. Sie ermöglicht den Benutzern, ihre eigene Lightning Node von ihrem Android-Gerät aus zu steuern.
3. Breez: Breez ist eine nicht custodial Bitcoin Wallet, die das Lightning Network nutzt, um sofortige Zahlungen zu ermöglichen. Breez integriert sich mit LND und bietet eine nahtlose Benutzererfahrung.

Mit c-lightning kompatible Apps:

1. Spark Wallet: Spark ist eine minimalistische Wallet-App für c-lightning. Es ermöglicht den Benutzern, ihre eigene Lightning-Node zu verwalten und Zahlungen über das Lightning Network durchzuführen.
2. Zeus: Wie oben erwähnt, unterstützt Zeus auch c-lightning.

Mit Eclair kompatible Apps:

1. Eclair Mobile Wallet: Diese App, entwickelt von ACINQ, ist eine einfach zu bedienende Bitcoin Wallet, die das Lightning Network unterstützt. Die Benutzer können mit dieser App Lightning-Transaktionen senden und empfangen.
2. Phoenix: Phoenix ist eine weitere App von ACINQ, die auf das beste Nutzererlebnis abzielt. Sie benötigt kein Setup und ermöglicht das Senden und Empfangen von Lightning-Zahlungen mit nur wenigen Klicks.

Hier die Apps Phoenix, Zeus und Bitbanana von links nach rechts

Einige Lightning-Netzwerk-Apps erfordern, dass ihr eure eigene Lightning-Node betreibt, während andere dies nicht tun. Hier ist eine Unterscheidung zwischen den oben genannten Apps:

Apps, die eine eigene Lightning Node erfordern

1. Zap/Bitbanana Wallet: Zap erfordert in der Regel, dass ihr eure eigene Lightning Node betreibt. Es gibt auch eine iOS-Version namens Zap iOS, die eine Verbindung zu einer Remote-Node herstellt, aber für die Android-Version wird in der Regel eine eigene Node benötigt.
2. Zeus: Zeus ist für fortgeschrittene Benutzer gedacht, die ihre eigene Lightning Node betreiben möchten. Es ermöglicht euch, von eurem mobilen Gerät aus auf eure Node zuzugreifen. Mitlerweile gibt es in Zeus auch einen eigens betriebenen LSP (Lightning Service Provider), der das Kanalmanagement für euch übernimmt.
3. Spark Wallet: Spark Wallet ist eine Remote-Control-Anwendung für c-lightning. Sie erfordert daher, dass ihr eine eigene c-lightning Node betreibt.

Apps, die keine eigene Lightning Node erfordern

1. Breez: Breez ist eine Nicht-Custodial-App, das bedeutet, ihr behaltet die Kontrolle über eure Bitcoin, aber die App betreibt die Lightning Node für euch.
2. Eclair Mobile Wallet: Eclair Mobile ist eine Light-Client-Anwendung, die keine eigene Node erfordert. Sie verbindet sich mit einem von ACINQ betriebenen Node.
3. Phoenix: Wie Eclair Mobile erfordert Phoenix keine eigene Node. Es ist eine benutzerfreundliche App, die das Senden und Empfangen von Lightning-Transaktionen einfach macht. Die Wallet ist vollständig Custodial. Allerdings zahlt Ihr für die Eröffnung eigener Lightning Kanäle, welche die App automatisch verwaltet, Gebühren in der Höhe der aktuellen Mining Gebühren
4. Wallet of Satoshi: ist super schnell eingerichtet, es benötigt keine Registrierung, es müssen keine Gebühren für Lightning Kanäle ausgegeben werden, allerdings ist die Wallet Custodial, dass heisst, der Betreiber verwaltet Eure Keys

Wichtig zu wissen ist, dass, obwohl Apps, die keine eigene Node erfordern, einfacher zu bedienen sind, sie weniger Kontrolle und möglicherweise weniger Datenschutz bieten, da die Lightning-Transaktionen über einen von Dritten betriebenen Node laufen. Apps, die eine eigene Node erfordern, erfordern mehr technisches Know-how und Ressourcen, bieten aber mehr Kontrolle und Datenschutz.

Schaut euch die Apps der Reihe nach mal an, sie bitten unterschiedliche Funktionen, unterschiedliche Bedienungen und Erfahrungen, haben ihre Vor und Nachteile und können mit unterschiedlichen Protokollen verwendet werden. Das ist ja das gute an Bitcoin und dem Lightning Netzwerk: Ihr seid nicht an ein Protokol, bzw. nur an eine App gebunden!

Das Bitcoin Lightning Netzwerk ist eine wirklicher Meilenstein in der Geschichte des Bitcoins, die das Potenzial hat, die Skalierbarkeit von Bitcoin zu verbessern, die Transaktionsgeschwindigkeit zu erhöhen und den Datenschutz zu verbessern. Mit verschiedenen Softwareimplementierungen und einer wachsenden Gemeinschaft von Entwicklern und Benutzern ist das Lightning Network ein wichtiger Schritt in Richtung einer effizienteren und privateren Nutzung von Bitcoin.

Ich hoffe euch mit dem Artikel das Lightning Netzwerk ein klein wenig näher gebracht zu haben, falls ihr Fragen habt, schreibt sie in die Kommentare! Seid ihr an einer eigenen Bitcoin/Lightning Node interessiert? Schaut doch in unserem Shop in der Kategorie BTC Nodes vorbei.

The post Was ist das Bitcoin Lightning Netzwerk appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.