Vorteile die Bitbox02 mit deiner eigenen Umbrel Bitcoin Full zu verbinden

• Privatsphäre: Wenn ihr eure BitBox02 mit einer öffentlichen Node (z.B. der Standard-Einstellung vieler Wallets) verwendet, könnten die Betreiber dieser Node theoretisch sehen, welche Adressen ihr abfragt und daraus Rückschlüsse auf euren Kontostand und eure Transaktionen ziehen. Mit einer eigenen Full Node bleiben diese Informationen privat.
• Sicherheit: Eine eigene Full Node überprüft jede Transaktion und jeden Block gegen die Konsensregeln von Bitcoin. Das bedeutet, ihr müsst euch nicht auf Dritte verlassen, um sicherzustellen, dass eure Transaktionen legitim sind.
• Souveränität: Mit einer eigenen Full Node habt ihr die vollständige Kontrolle über eure Transaktionen. Ihr seid nicht von Drittanbietern abhängig, die den Dienst einschränken, ändern oder beenden könnten.
• Verbesserte Netzwerkgesundheit: Das Betreiben einer eigenen Full Node stärkt das dezentrale Netzwerk von Bitcoin. Je mehr unabhängige Knoten existieren, desto widerstandsfähiger wird das Netzwerk gegenüber Angriffen oder Versuchen der Zensur.
• Geringere Gebühren: Wenn ihr eine Full Node betreibt, könnt ihr besser einschätzen, welche Transaktionsgebühr für eure Transaktion angemessen ist, da Ihr das gesamte Netzwerk überblickt. So könntet Ihr eventuell Gebühren sparen.
• Aktualität: Ihr erhaltet Updates über das Bitcoin-Netzwerk in Echtzeit, ohne euch auf Dritte verlassen zu müssen.
• Unterstützung des Netzwerks: Indem ihr eine eigene Full Node betreibt, tragt Ihr dazu bei, das Bitcoin-Netzwerk sicher und dezentralisiert zu halten.

Wenn ihr euch für den Betrieb einer eigenen Full Node entscheidet, solltet Ihr jedoch auch den zusätzlichen Aufwand und die potenziellen Kosten für Hardware, Strom und Bandbreite berücksichtigen. Es ist auch wichtig sicherzustellen, dass eure Node korrekt konfiguriert ist, um eure Privatsphäre und Sicherheit zu maximieren.

Wir richten den Zugang über das LAN Netzwerk, aber auch über das Tor Netzwerk ein um von einem möglichst hohem Mass an Privatspähre zu profitieren. Das den LAN Zugang nutzt ihr zuhause, und den Tor Zugang wenn ihr unterwegs seid und euch nicht in eurem LAn befindet, in der die Full Node operiert.

Vorausetzungen um eure Bitbox02 mit einer Raspiblitz Bitcoin Fullnode zu verbinden

Eine voll funktionsfähige und fertig synchronisierte Raspiblitz Bitcoin Full Node. Um die Bitbox App zu verbinden, muss auch auch ElectrumRS installiert sein, und der Electrum Server muss vollständig synchronisiert sein. Nach der Installation von Electrum kann es gut und gerne nochmals einen Tag gehen, bis der Server vollständig synchronisiert, und bereit für Verbindungen ist. Falls Ihr noch keinen Electrum Server auf eurer Fullnode habt, installiert euch Electrum (ElectRS) aus dem App Store.

Wählt im CLI Menu vom Raspiblitz Electrum Rust aus, und klickt anschliessend auf OK:

Die Installation kann einige Minuten dauern. Habt geduld, und wartet, bis ihr wieder auf der Befehlszeile seid. Alternativ kann Electrum Rust auch über das Web-UI installiert werden. Der Aufbau des Indexes kann auf einem Raspberry Pi 4 bis zu 2 Tage dauern, auf einem Raspberry 5 ca. 1 Tag.

Tor Konfiguration

Ihr habt verschiedene Möglichkeiten euch über das Tornetzwerk mit der Bitbox App zu verbinden:

Mit dem Browser als Tor Proxy

Um euch mit dem Tor Netzwerk zu verbinden, müsst ihr Zugang zu Tor haben, das geht am einfachsten mit dem Tor Browser, sobald dieser verbunden ist, habt über den Port 9150 verbindung zum Tor Netzwerk. Startet ihr die Bitbox App, muss der Tor Browser mit dem Internet verbunden sein. Installiert euch also zuerst den Tor Browser hier.

Danach könnt ihr in der Bitboxapp unter Einstellungen --> erweiterte Einstellungen --> Tor Proxy aktivieren die Verbindung zu einem Tor Proxy erlauben:

Gebt hier 127.0.0.1:9150 ein falls ihr den TorBrowser als Proxy verwendet. 127.0.0.1 ist die lokale Adresse des Geräts bzw. bedeutet, dass sich die App mit einem Dienst auf dem selben Gerät verbindet.

Für Linux Desktop User

Wer ein Linux Betriebssystem fährt, kann sich auch den Tor Proxy selber installieren. Dann muss der Browser nicht laufen damit die Verbindung besteht. Installiert Tor mit:

sudo apt install tor

und checkt den Dienst mit

sudo systemctl status tor

Wenn der Dienst auf active steht, könnt ihr eure Bitbox App so konfigurieren, dass es den TorProxy verwendet. Dieser hört auf Port 9050! Also in diesem Fall 127.0.0.1:9050 in der Bitbox App verwenden!

Für das Smartphone

Für Das Smartphone benötigt ihr die App Orbot, die euch den TorProxy zur Verfügung stellt.

Beim Smartphone mit Orbot verwendet ihr 127.0.0.1:9050

Für eine Verbindung über das eigene LAN Netzwerk, muss die Proxy Einstellung der Bitbox App deaktiviert sein!

Anleitung für die Verbindung

Im eigenen Netzwerk zuhause

Ruft ihr den Kontostand zuhause ab, empfiehlt es sich, direkt ohne Umwege über Tor mit der Node zu kommunizieren. Die Bitbox App auf dem Desktop sollte bestmöglichst auf diese weise konfiguriert werden. Die Anfragen für den Kontostand verlassen somit euer Haus nicht.

Tor Proxy Settings in der Bitbox App sind auf aus. Danach wählt ihr eine eigene Node hinzufügen aus. Gebt hier die lokale IP Adresse der Raspiblitz Node ein gefolgt vom Port 50002:

Klickt danach auf Remote-Zertifikate herunterladen, und falls das auftaucht gleich noch auf Überprüfen und wenn die Verbindung erfolgreich war, danach auf Hinzufügen.

Unterwegs für das Smartphone oder den Laptop über Tor

Loggt euch in das Webinterface eurer Raspiblitz Node ein. Geht auf euren Electrum Server. Sollte hier noch nichts angezeigt werde, ist ElectRs noch nicht fertig mit indexieren! Dann heisst es, noch etwas warten!

Startet den Tor Browser und öffnet als nächstes die Bitbox App. Geht unten links auf die Einstellungen und klickt hier auf Tor Proxy aktivieren. Gebt die Adresse 127.0.0.1 ein und den Port 9150. Für das Smartphone und Orbot nehmt ihr den Port 9050!
Bestätigt und verlasst das Fenster. Geht als nächstes auf das Feld Eigene Fullnode verbinden

Fügt nun den Adresse vom Electrum Server hier bei host:port ein. Fügt am Ende den Port 50002 hinzu! Lasst :s am Schluss der Adresse weg!

Klickt danach auf Remote-Zertifikat herunterladen, und danach auf Überprüfen. Habt ihr alles korrekt eingegeben, kommt die Meldung, dass die Verbindung erfolgreich hergestellt worden ist. Falls nicht, stellt sicher dass der Tor Browser wirklich an ist, und mit dem Tor Netzwerk verbunden ist.

Abschluss

Ihr könnt nun die beiden Shiftcrypto Server entfernen. Die benötigen wir nicht mehr. Sollte etwas nicht klappen, können die Standardeinstellungen jederzeit mit der Option In Werkszustand zurücksetzen wieder hergestellt werden.

Fazit

Nun seid ihr vollständig mit eurer eigenen Fullnode verbunden, und keiner, ausser euch, hat die vollständige Kontrolle und Einsicht über eure Transaktionen, Kontostände und etc. Habt ihr noch keine eigene Bitcoin Fullnode oder keine Bitbox02? Schaut bei uns im Shop vorbei:  Bitcoin Fullnodes & Bitbox02

Ich hoffe euch mit dem Tutorial den Umgang mit Bitcoin und und eurer Node etwas erleichtert zu haben. Falls ihr Fragen habt, schreibt sie in die Kommentare!

The post Bitbox02 mit Raspiblitz Bitcoin Fullnode verbinden appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dies bedeutet, dass Wallets und andere Software, die auf der Full Node laufen, innerhalb von Minuten mit dem Senden und Empfangen von Transaktionen beginnen können. Die bisher übliche Wartezeit von Stunden oder Tagen, um die Blockchain ab dem Genesis-Block vollständig zu synchronisieren und zu validieren, entfällt.

Wie funktioniert AssumeUTXO

Wenn AssumeUTXO genutzt wird, startet die Node die Synchronisation vom Snapshot bis zum Chain Tip. Parallel dazu wird die alte Blockchain-Geschichte im Hintergrund heruntergeladen und verifiziert. Sobald dies abgeschlossen ist, verifiziert die Node den initial geladenen UTXO-Zustand und erreicht somit dieselbe vertrauenswürdige Sicherheit wie eine Node, die ohne AssumeUTXO synchronisiert wurde. Bis jetzt ist der einzig erlaubte UTXO Snapshot in Bitcoincore hardkodiert und akzeptiert nur Snapshots bis zu einer Höhe von Block 840000.

Schritt-für-Schritt-Anleitung: UTXO-Snapshots nutzen

1. UTXO-Snapshot-Datei herunterladen
   Ladet eine Snapshot-Datei herunter. Einen Snapshot für die maximal mögliche Höhe von Block 840.000 gibt es beispielsweise bei uns am Ende des Beitrags zu finden. Ihr könnt den Snapshot auf einen USB Stick Speichern und zum Beispiel an euren Raspiblitz hängen. Vergesst nicht, den Stick zu mounten.
2. Bitcoin Core v28 (oder neuer) herunterladen und installieren
   Ladet die neueste Version von Bitcoin Core von der offiziellen Webseite herunter und installiert sie.
   Auf dem Raspiblitz updated ihr euren Blitz einfach im Menu UPDATE --> BITCOIN --> BITCOINCORE 28.0
3. Bitcoin Core starten bitcoind -daemon (Auf dem Raspiblitz automatisch)
4. Synchronisation der Blockheader abwarten
   Dies dauert nur ein bis zwei Minuten.
5. Snapshot laden bitcoin-cli loadtxoutset /pfad/zum/utxo-snapshot-height-840000.dat Je nach Geschwindigkeit des Systems kann dieser Schritt einige Minuten bis Stunden dauern.
6. Synchronisation abschließen
   Nach Abschluss des Befehls springt die Synchronisationshöhe eurer Node zur Blockhöhe des Snapshots und fährt von dort mit der normalen Synchronisation fort.
7. Hintergrund-Synchronisation des Genesis-Blocks
   Sobald die Node den Chain Tip erreicht, startet sie im Hintergrund die Verifizierung der Blockchain ab dem Genesis-Block. Während dieser Zeit bleibt die Node jedoch vollständig nutzbar.

Häufige Fragen zu AssumeUTXO

1. Ist es wichtig, woher ich die Snapshot-Datei beziehe?
Nein. Bitcoin Core lädt nur Snapshots, deren UTXO-Hash mit einem übereinstimmt, der fest in Bitcoin Core kodiert ist.

2. Kann ich meine eigenen Snapshots erstellen?
Ja, Snapshots können mit dem Befehl dumptxoutset oder einem Hilfsskript erstellt werden. Allerdings können nur Snapshots bei festgelegten Blockhöhen geladen werden. Derzeit ist nur die Blockhöhe 840.000 unterstützt.

3. Kann ich diese Funktion für pruned Nodes verwenden?
Ja.

4. Kann ich diese Funktion mit aktivierten Indexen nutzen?
Ja, allerdings beschleunigt dies die Erstellung der Indexe nicht. Diese müssen weiterhin linear ab dem Genesis-Block erstellt werden.

Wie viel schneller ist die Synchronisation

In einem Benchmark-Test wurden zwei Synchronisationen mit Bitcoin Core v28 durchgeführt:

• Die erste Synchronisation begann klassisch ab dem Genesis-Block.
• Die zweite verwendete einen Snapshot.

Ergebnisse:

• Mit Snapshot: 10 Minuten für das Laden des Snapshots + 84 Minuten, um den Chain Tip zu erreichen.
• Ohne Snapshot: 659 Minuten für eine vollständige Synchronisation ab Genesis im Clearnet bei nicht limitierender Bandbreite

Die Geschwindigkeit ist also um ein Vielfaches höher!

Lohnt sich AssumeUTXO

Die Entscheidung hängt von mehreren Faktoren ab:

• Dringlichkeit: Wie schnell müsst ihr eure Node verwenden können?
• Hardware-Leistung: Auf leistungsstarken Systemen, die die Blockchain in weniger als einem Tag synchronisieren können, sind die zusätzlichen Schritte möglicherweise nicht erforderlich. Für langsamere Systeme wie einen Raspberry Pi ist AssumeUTXO jedoch ein großer Vorteil.

UTXO Snapshot selber erstellen

Mit diesem Script erstellt ihr selber einen UTXO Snapshot. Anmerkungen dazu:

Das Skript utxo_snapshot.sh dient dazu, einen Snapshot des UTXO-Sets (Unspent Transaction Output) zu einer bestimmten Blockhöhe in Bitcoin Core zu erstellen. Es ermöglicht entweder die Erstellung einer Datei mit dem Snapshot oder die Ausgabe des Hash-Werts des UTXO-Sets. Im Detail funktioniert es wie folgt:

Schlüsselaufgaben des Skripts

1. Parameter validieren:
   • Der Script erwartet drei Argumente:
     • generate-at-height: Die Blockhöhe, für die der UTXO-Snapshot erstellt werden soll. Muss 840000 sein!
     • snapshot-out-path: Der Ausgabepfad für die Snapshot-Datei (oder - für keine Datei, nur den Hash ausgeben). (Pfad eurer Wahl)
     • bitcoin-cli-call: Der Befehl zum Aufruf von bitcoin-cli, z. B. inklusive -datadir-Angabe.
       (Zum beispiel ./src/bitcoin-cli -datadir=/data/bitcoin)
   • Gibt eine Fehlermeldung aus, wenn die Parameter nicht korrekt sind.
2. Prüfen des Pruning-Status:
   • Liest die Blockhöhe, bis zu der die Blockchain beschnitten (pruned) ist.
   • Beendet das Skript mit einer Fehlermeldung, falls die angegebene generate-at-height unterhalb der pruned Blockhöhe liegt (da die Blockchain-Daten fehlen).
3. Existenzprüfung für den Ausgabepfad:
   • Verhindert, dass ein vorhandener Ausgabepfad überschrieben wird.
   • Überprüft, ob das Zielverzeichnis existiert.
4. Netzwerkaktivität deaktivieren (optional):
   • Fragt den Benutzer, ob die Netzwerkaktivität der Node deaktiviert werden soll. Dies dient dazu, Konflikte bei der Synchronisation zu vermeiden, während der Snapshot erstellt wird.
5. Blockchain zurücksetzen und Snapshot erstellen:
   • Invalide erklärt (rewindet) den Block unmittelbar nach der gewünschten Höhe (generate-at-height + 1), um den Zustand der Blockchain an dieser Höhe wiederherzustellen.
   • Führt entweder einen der beiden folgenden Schritte aus:
     • Gibt den Hash des UTXO-Sets aus, wenn snapshot-out-path - ist.
     • Erstellt eine UTXO-Snapshot-Datei mit dem Befehl dumptxoutset.
6. Cleanup-Prozess:
   • Stellt die Blockchain wieder auf den ursprünglichen Zustand zurück, indem der invalide Block wieder berücksichtigt wird (reconsiderblock).
   • Aktiviert die Netzwerkaktivität, falls sie deaktiviert wurde.
7. Unterbrechungsbehandlung:
   • Fängt Ctrl-C (SIGINT) ab, führt den Cleanup-Prozess aus und beendet das Skript sauber.

Der vollständige Befehl um den Script zum Beispiel wäre auf dem Raspiblitz:

./utxo_snapshot.sh 840000 utxo.dat ./src/bitcoin-cli -datadir=/mnt/hdd/bitcoin

Zukunftsperspektiven

Während AssumeUTXO derzeit vor allem von technisch versierten Node-Betreibern genutzt wird, könnte Bitcoin Core in Zukunft eine Funktion anbieten, die Snapshots automatisch beim Start lädt. Dies würde die Nutzung auch für weniger erfahrene Nutzer vereinfachen.

• Sicherheitsaspekt: Auch wenn die initiale Synchronisation durch AssumeUTXO verkürzt wird, bleibt die vertrauenswürdige Sicherheit langfristig erhalten, da die vollständige Verifizierung im Hintergrund erfolgt.
• Energieeffizienz: Gerade für Nodes mit geringem Energieverbrauch, wie auf einem Raspberry Pi oder in einer Cloud-Umgebung, kann diese Funktion nicht nur Zeit, sondern auch Ressourcen sparen.

AssumeUTXO ist ein bedeutender Schritt in Richtung einer benutzerfreundlicheren Bitcoin-Infrastruktur und zeigt, wie kontinuierliche Innovation die Barrieren für den Betrieb von Full Nodes senken kann.

Download UTXO Snapshot

https://cloud.yourdevice.ch/s/JaHSXwcBFgNN8P5

Weitere Möglichkeiten die Node zu Syncen mit älteren Bitcoincore Versionen

Vollständige Kopie der Blockchain erstellen.

Blockchain über das Clearnet syncen.

The post Fullnode schneller syncen mit UTXO Snapshots appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Das Tutorial eignet sich sowie für den Raspiblitz, also auch für Umbrel, Start9, und MyNode Fullnode Betriebssysteme.

Vorausetzungen

Bevor ihr beginnt, stelle sicher, dass ihr folgende Dinge vorbereitet habt:

Computer mit Platz für 2 SSDs

• Ihr benötigt einen freien Computer, bzw. eine Arbeitsgerät, an dem ihr die 2 SSDs anklemmen könnt. Das kann auch ein Laptop sein, mit dem ihr die 2 SSDs via USB to SSD Adapter anschliesst.

GParted Live USB:

• Ladet das GParted Live-ISO von der offiziellen GParted Webseite herunter.
• Erstellt einen bootfähigen USB-Stick mit Rufus oder Balena Etcher.

SSD einbauen:

• Schließt beide SSDs an euren Rechner an.

Optional: Backup:

• Erstellt ein Backup der ersten SSD falls ihr auf Nummer sicher gehen wollt.

Vorbereitung

System vom GParted Live USB-Stick booten:

• Starte den Rechner neu und boote von deinem GParted Live USB-Stick. Achte darauf, im BIOS/UEFI den USB-Stick als erstes Bootmedium einzustellen.

GParted starten:

Im GParted Live-Boot-Menü wählt die Standardoptionen aus, bis ihr zur grafischen Oberfläche gelangt. Stellt sicher, dass ihr das richtige Tastaturlayout verwendet:

Wählt im nächsten Fenster eure Sprache aus, Deutsch ist in den meissten Fällen die Nummer 10. Nehmt danach den Modus 0:

Klonen der Partitionen

Quelllaufwerk auswählen

• Wählt die 1TB SSD aus dem Dropdown-Menü oben rechts in GParted aus. Ihr solltet die Partition(en) eurer 1TB SSD sehen.

Partition(en) kopieren

• Wählt die Partition, die ihr klonen möchtet (normalerweise die Hauptpartition mit euren Blockchaindaten und Diensten), und klickt mit der rechten Maustaste darauf. Wählt copy.

Ziellaufwerk auswählen

• Geht jetzt zur 2TB SSD im Dropdown-Menü. Klickt mit der rechten Maustaste auf den nicht zugewiesenen Speicherplatz auf der 2TB SSD und wählt paste.

Sollte auf der Ziel SSD bereits eine Partition bestehen, wählt diese einfach vorher aus, und löscht diese.

Anpassung der Partitiongrösse

Als nächst bekommt ihr ein Feld zu sehen, auf dem ihr die Partition gleich auf die Grösse der neuen SSD anpassen könnt:

Pakt den markierten Pfeil, und schiebt die neue Partition auf die volle Grösse der SSD. Klickt danach auf Paste.

Startet den Kopiervorgang mit dem grünen Haken:

Überprüfung und Testing

Hängt die neue SSD einfach an euren Raspiblitz an, er sollte automatisch alles erkennen, und dort weitermachen, wo er aufgehört hat. Anpassungen eurerseits sind nicht nötig.

Fazit

Mit GParted könnt ihr den Klonvorgang von einer 1TB auf eine 2TB SSD direkt und ohne zusätzliche Tools durchführen. Dies spart Zeit und erlaubt euch, alle notwendigen Schritte – vom Klonen bis zur Partitionserweiterung – in einer einzigen, vertrauten Umgebung durchzuführen. Indem ihr die Partition nach dem Klonen vergrößerst, stellt ihr sicher, dass ihr die volle Kapazität der neuen SSD nutzen könnt, sodass eure Blockchaindaten und Dienste weiterhin optimal funktionieren.

The post Fullnode 1TB SSD auf 2TB SSD klonen 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.

Aber warum sollte man Lightning auf einem Raspberry Pi via Clearnet konfigurieren? Die Antwort liegt in der besseren Verfügbarkeit und der Latenz! Das Clearnet, im Gegensatz zum Tor-Netzwerk, bietet geringere Latenzen und eine höhere Verfügbarkeit, was besonders für zeitkritische HTCL-Transaktionen im Lightning Netzwerk von Vorteil ist. Für Node-Runner die eine hohe Anzahl Kanäle betreiben, und die Node zuverlässig betreiben wollen, ist eine Clearnet Anbindung fast schon unabdingbar.

In diesem Artikel zeigen wir euch Schritt für Schritt, wie ihr euren Raspberry Pi zu einem leistungsfähigen Lightning-Node konfiguriert, die über das Clearnet erreichbar ist. Wir gehen dabei auf die nötige Hardware, Software und Konfigurationen ein und erläutern die Vorteile und potenziellen Herausforderungen dieses Setups. So seid ihr bestens gerüstet, um die Vorzüge des Lightning Networks voll auszuschöpfen und dein Wissen in der Welt von Bitcoin Lightning zu erweitern.

Achtung: Clearnet und die Privacy

Das Betreiben eines Nodes hinter dem Tor-Netzwerk bietet viele Vorteile (Anonymität, Sicherheit und Benutzerfreundlichkeit) und ist daher derzeit die am meisten empfohlene Methode kleinere Nodes. Für Nodes, die eine hohe Anzahl verbundener Kanäle aufrechterhalten und/oder hohe Verfügbarkeitsanforderungen haben, kann Tor jedoch hinderlich sein. LND ermöglicht auch das Betreiben von Clearnet-Nodes, die das Tor-Netzwerk nicht nutzen, sondern direkt mit Peers verbunden sind. Dies erfordert, dass Node-Administratoren sich um die Sicherheitsrichtlinien des zugrunde liegenden Systems kümmern. Mindestens ein Port (Standard: 9735) muss weitergeleitet und für Remotepeers zugänglich gemacht werden. Es geht nicht nur um Sicherheit, sondern auch um das Risiko, durch die Clearnet-IP grob lokalisiert zu werden. Verwendet den Hybridmodus nur, wenn Privacy keine so grosse Rolle spielt sondern die Performance, Erreichbarkeit und Stabilität der Verbindung im Vordergrund steht!

Als Alternative zur eigenen IP freigeben, stellen wir euch am Ende des Berichts noch kurz den Service Tunnelsats vor! Damit habt ihr Privacy und Clearnet Vorteile kombiniert, kostet aber etwas Gebühren!

Vorbereitungen für den Raspiblitz Hybrid Mode

Um einen Lightning Node im Clearnet zu betreiben, müssen einige grundlegende Voraussetzungen für das Port Forwarding erfüllt werden:

1. Zugriff auf den Router: Ihr musst Zugang zu eurem Router haben, um die Einstellungen für das Port Forwarding zu konfigurieren. Der Router sollte UPnP unterstützen für den NAT Modus.
2. Offener Port: Der Standardport für Lightning Nodes ist 9735. Dieser Port muss im Router für die IP-Adresse deines Raspberry Pi weitergeleitet werden.
3. Fixe IP Adresse des Raspiblitzes: der Raspiblitz benötigt eine fixe IP Adresse in eurem lokalen Netzwerk, ansonsten funktioniert das Portfowarding nicht mehr, sollte der Raspiblitz eine andere lokale IP Adresse bekommen.

Wie ihr ein Portforwarding einrichtet, erfahrt ihr in diesem Artikel.

Fixe IP Adresse für den Raspiblitz auf eurem Router einrichten

• Netzwerk-Einstellungen: sucht im Menü eures Routers nach den Netzwerkeinstellungen oder DHCP-Einstellungen. Dies kann je nach Router-Modell unterschiedlich sein.
• DHCP-Reservierung oder feste IP-Zuweisung: Findet die Option für "DHCP-Reservierung", "Statische IP", "IP-Adressen-Zuweisung" oder ähnliches. Wählt die Option, um eine neue Reservierung hinzuzufügen.
• Gerät auswählen: Wählt den Rasipblitz aus, dem ihr die feste IP-Adresse zuweisen möchtet. Dies wird oft durch die MAC-Adresse des Geräts identifiziert, die ihr in den Netzwerkeinstellungen des Geräts finden könnt. ( $ sudo ip addr )
• IP-Adresse festlegen: Gebt die gewünschte feste IP-Adresse ein, die im gleichen Subnetz wie euer Router liegen sollte. Speichert die Einstellungen.
• Raspiblitz neu starten: Startet den Raspiblitz neu mit sudo systemctl reboot , damit er die neue IP-Adresse vom Router erhält.

Optional: DynDNS Adresse

Mit einer DynDNS Adresse könnt ihr eure Node zuverlässig auf die wechselnde IP Adresse in Falle von dynamischen IP Adressen vorbereiten. Es benötigt nicht unbedingt eine DynDNS Adresse, der Raspiblitz kann auch mit dynamischen IP Adressen umgehen, dafür muss der Router aber UPnP beherschen und die Funktion NAT in der lnd.conf aktiviert werden. Wir schauen uns beide Möglichkeiten an, NAT und Dynanische DNS Adressen

Mit diesen Voraussetzungen seid ihr bereit, das Port Forwarding einzurichten und eure Lightning Node im Clearnet zu betreiben.

Tormodus anpassen

Die Option tor.streamisolation=false muss deaktiviert werden, wenn der Hybridmodus verwendet wird.

Der Hybridmodus wurde in LND von Lightning Labs in der Version lnd-0.14.0-beta eingeführt. Mit dieser Version wurde eine neue Option eingeführt, um die Konnektivität zu teilen und Tor-Only-Peers über Tor und Clearnet-Peers über Clearnet separat anzusprechen:

[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

In den jeweiligen Konfigurationen legen wir dann die Einstellungen fest.

Konfiguration des Hybridmodus

LND muss die externe IP-Adresse eines Nodes kennen. Dabei gibt es zwei verschiedene Fälle zu berücksichtigen: statische und dynamische IP-Verbindungen.

Eine statische IP ist in LND relativ einfach einzurichten. Die externe IP-Adresse muss in der LND-Option externalip angegeben werden. Das ist fast alles. Allerdings ändern die meisten Internetanbieter eure IPs regelmäßig oder zumindest bei einer erneuten Verbindung. Daher müsste die externalip in der lnd.conf jedes Mal geändert werden, wenn eine neue IP zugewiesen wird, gefolgt von einem Neustart des lnd.service, um die lnd.conf neu zu laden. Dies ist für einen kontinuierlichen Node-Betrieb nicht praktikabel. Zwei mögliche Lösungen, um das erneute Bearbeiten und Neustarten von LND zu verhindern:

1. Variante 1: NAT/UPnP
2. Variante 2: Dynamic DNS (DDNS)

Variante 1: NAT/UPnP

Der Umgang mit dynamischen IPs ist etwas komplexer. LND bietet hierfür einen integrierten Ansatz: NAT. NAT versucht, dynamische IPs mithilfe integrierter Techniken zu lösen, um die externe IP-Adresse eines Nodes abzurufen. Es ist wichtig zu beachten, dass LND nicht gut damit umgeht, externalip und nat gleichzeitig zu setzen. Wählt deshalb nur eine dieser Optionen, basierend auf den UPnP-Fähigkeiten eures Routers (nat traversal) beziehungsweise eurer persönlicher Präferenzen.

Um die Funktion NAT nutzen zu können, müsst, ist die lnd.conf unter /mnt/hdd/lnd/ zu öffnen und folgende Funktion zu aktivieren:

; Instead of explicitly stating your external IP address, you can also enable
; UPnP or NAT-PMP support on the daemon. Both techniques will be tried and
; require proper hardware support. In order to detect this hardware support,
; `lnd` uses a dependency that retrieves the router's gateway address by using
; different built-in binaries in each platform. Therefore, it is possible that
; we are unable to detect the hardware and `lnd` will exit with an error
; indicating this. This option will automatically retrieve your external IP
; address, even after it has changed in the case of dynamic IPs, and advertise
; it to the network using the ports the daemon is listening on. This does not
; support devices behind multiple NATs.
nat=true

Die fertige Konfiguration sieht dann folgendermassen aus:

[Application Options]
# specify an interface (IPv4/IPv6) and port (default 9735) to listen on
listen=0.0.0.0:9735 # listen on IPv4 interface or listen=[::1]:9735 for IPv6 interface
nat=true

[tor]
tor.active=true
tor.v3=true
# deactivate streamisolation for hybrid-mode
tor.streamisolation=false
# activate split connectivity
tor.skip-proxy-for-clearnet-targets=true

Startet danach LND mit sudo systemctl restart lnd.service neu. In einem Abschnitt weiter unten könnt ihr überprüfen, ob die Umstellung bereits geklappt hat.

Dynamische IP: Lösung 2 - Dynamic DNS (DDNS)

Dynamic DNS (DDNS) ist eine Methode, um einen Nameserver im Domain Name System (DNS) automatisch zu aktualisieren, oft in Echtzeit, mit der aktiven DDNS-Konfiguration seiner konfigurierten Hostnamen, Adressen oder anderer Informationen. Hier übernimmt der DynDNS Server die aktualisierung der IP Adressen, und nicht LND wie im NAT Modus. Der Router muss zudem kein UPnP können.

Damit ihr DynDNS nutzen könnt, müsst ihr euch eine Domain via DynDNS erstellen. Eine Anleitung dazu findet ihr hier. Die Wahl des Domain-Namens spielt hier keine Rolle.

Ein Skript des DynDNS Servers ruft regelmäßig die aktuelle IP-Adresse des Clients ab, die für spätere Anfragen gespeichert wird, und ändert die Zuweisung automatisch falls Änderungen registriert werden. LND kann dann mit der angegebene Domain/DDNS die tatsächliche IP-Adresse auflösen.

In diesem Fall muss LND anstelle einer externen IP-Adresse eine reservierte DNS-Domain kennen. Die Option externalhosts muss gesetzt werden:

[Application Options]
# specify DDNS domain (port optional)
externalhosts=eure_dyndns_domain:9735

Öffnet eure lnd.conf und fügt die Konfiguration anhand des folgenden Beispiels ein:

[Application Options]
# specify an interface (IPv4/IPv6) and port (default 9735) to listen on
listen=0.0.0.0:9735 # listen on IPv4 interface or listen=[::1]:9735 for IPv6 interface
externalhosts=eure_dyndns_domain:9735

[tor]
tor.active=true
tor.v3=true
# deactivate streamisolation for hybrid-mode
tor.streamisolation=false
# activate split connectivity
tor.skip-proxy-for-clearnet-targets=true

Startet danach wieder LND mit sudo systemctl restart lnd.service neu!

Funktionstest, Einstellungen überprüfen

LND bietet eine einfachen Befehl an, um zu überprüfen, ob LND auf eure Clearnet IP Adresse hört. Der Befehl lautet ganz einfach lncli getinfo:

"uris": [
        "028268dcb4c68311613dd3bbb0164f7685b6710022bfa6dcce639acd44695049a2@62.2.188.226:9735",
        "028268dcb4c68311613dd3bbb0164f7685b6710022bfa6dcce639acd44695049a2@5und3k5vpfowgdi27xueir522tk3e2vvmmset6b6kc2fwqnwveg7w4yd.onion:9735"

Habt ihr keinen Eintrag mit einer Clearnet IP, habt ihr was in der Konfiguratuon falsch gemacht. Stellt in diesem Fall nochmals sicher, dass das Portfowarding auf die IP Adresse eures Raspiblitzes zeigt.

Falls ihr LNDg betreibt, findet ihr neu nun auch eine Clearnet Adresse:

Ein weitere Methode wäre, euch einfach ein Peer der im Clearnet operiert, zu fragen, ob er sich mit euch via eure IP verbinden kann, der Befehl für den peer wäre dann:

lncli connect <euer_pubkey>@eure_ip:9735

Tunnelsats als Alternative zur eigenen IP Adresse freigeben

Tunnelsats ist ein Dienst, der speziell entwickelt wurde, um sichere und stabile Verbindungen für Lightning Nodes zu ermöglichen, insbesondere wenn es Herausforderungen bei der Verwendung von Tor oder Clearnet gibt. Dieser Dienst bietet eine Möglichkeit, die Erreichbarkeit und Zuverlässigkeit deines Nodes zu verbessern, indem er eine Art VPN-Tunnel bereitstellt.

Hauptmerkmale von Tunnelsats:

1. Sichere Verbindungen: Durch die Nutzung von VPN-Technologie stellt Tunnelsats sicher, dass deine Verbindungen sicher und vor Abhörversuchen geschützt sind.
2. Stabile IP-Adresse: Tunnelsats kann eine stabile IP-Adresse bereitstellen, die unabhängig von den dynamischen Änderungen durch deinen ISP ist, was die Verwaltung deines Nodes erheblich erleichtert.
3. Einfache Einrichtung: Die Konfiguration von Tunnelsats ist benutzerfreundlich und kann schnell eingerichtet werden, ohne dass tiefgehende technische Kenntnisse erforderlich sind.
4. Verbesserte Erreichbarkeit: Mit Tunnelsats wird dein Node über eine konstante und zuverlässige Verbindung erreichbar, was besonders wichtig für Nodes mit hohen Verfügbarkeitsanforderungen ist.
5. Kompatibilität: Tunnelsats ist mit den gängigen Lightning-Implementierungen kompatibel und kann nahtlos in bestehende Setups integriert werden.

Falls ihr eure eigene IP Adresse nicht freigeben wollt, und trotzdem die Vorteile einer Clearnet Verbindung geniessen wollt, schaut euch ihr mal Tunnelsats genauer an. Die Konfiguration ist etwas komplexer, aber auch bei genauem befolgen der Anleitung auch für Anfänger machbar. Tunnelsats ist jedoch nicht gratis und kostet ca 2 Euro Pro Monat.

Fazit: LND über das Clearnet

Das Betreiben eines Lightning Network Daemons (LND) über das Clearnet bietet eine Reihe von Vorteilen, die insbesondere für Nutzer mit hohen Anforderungen an Geschwindigkeit und Verfügbarkeit attraktiv sind. Diese Methode ermöglicht eine direkte und schnelle Verbindung zu anderen Nodes und bietet erhebliche Latenz und stabilitätsvorteile.

Vorteile:

1. Geringe Latenz: Direkte Verbindungen über das Clearnet bieten geringere Latenzen, was besonders für zeitkritische Transaktionen vorteilhaft ist.
2. Einfache Einrichtung: Die Konfiguration eines LND-Nodes im Clearnet ist meist einfacher und weniger komplex als über Tor.
3. Hohe Verfügbarkeit: Clearnet-Verbindungen sind stabiler und zuverlässiger, was für Nodes mit hohen Verfügbarkeitsanforderungen entscheidend ist.
4. Bessere Performance: Da das Clearnet weniger Schichten und Umwege hat, ist die Performance im Allgemeinen höher.

Nachteile:

1. Sicherheitsrisiken: Clearnet-Verbindungen sind anfälliger für Angriffe und erfordern zusätzliche Sicherheitsmaßnahmen wie Firewalls und Portweiterleitungen.
2. Öffentliche IP-Adresse: Die Nutzung einer öffentlichen IP-Adresse kann zu einer geringeren Anonymität führen und das Risiko einer Lokalisierung erhöhen.
3. Regulierungsanfälligkeit: Clearnet-Verbindungen sind anfälliger für staatliche Zensur und regulatorische Eingriffe.

Das Betreiben von LND über das Clearnet ist eine praktikable und oft bevorzugte Lösung für viele Nutzer, die Wert auf schnelle und zuverlässige Verbindungen legen. Während zusätzliche Sicherheitsmaßnahmen erforderlich sind, um die Risiken des Clearnets zu mindern, bietet diese Methode eine einfachere und leistungsfähigere Alternative zu Tor. Für Nutzer, die keine hohen Anforderungen an Anonymität haben und eine stabile Netzwerkverbindung benötigen, stellt das Clearnet eine attraktive Option dar.

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

Was ist nochmals ein SCB Backup

Ein SCB oder auch Static Channel Backup genannt, ist ein Backup eurer Kanaldaten, sie ist quasi die Lebensversicherung falls alles schief geht. Mit der SCB Datei namens channel.backup, könnt ihr bei einem Totalausfall der Node, all eure Kanäle wieder herstellen. Dafür benötigt ihr nur eure Seedphrase, und die SCB Datei selber, nichts weiter. Jedoch ist das Wort Backup in der Beschreibung Static Channel Backup etwas unglücklich gewählt, da sich die Kanäle nicht vollständig wiederherstellen lassen. Die Datei enthält nur die allernötigsten Information, wie die Pubkeys des Peers, die Kanalgrösse und das Eröffnungsdatum. Eine triggern eines SCB Recoveries, bedeutet dass die Kanaldaten geladen werden, und die Peers, mit denen ihr verbunden wart, erhalten ein Signal, dass ihr einen Ausfall hattet, mit den Informationen des Peers, wird der Kanal anschliessend zwangsgeschlossen, und ihr erhaltet eure Funds zurück.

Vorteile einer doppelten Sicherung

Im Backup und Restore Leitfaden habt ihr bereits erfahren, wie ihr die SCB Datei auf einen USB-Stick lokal sichern könnt. Das ist schonmal gut, da bei einem Festplattenausfall das Backup sicher ist. Leider schützt dies jedoch nicht für Einflüssen wie Bränden, Diebstahl oder wenn der Hund die ganze Node gefressen hat. Eine externe Sicherung schafft hier eine zusätzliche Schicht der Sicherheit.

Das Backup in der Nextcloud

Der Raspiblitz bietet eine Funktion, die euch die SCB Datei zusätzlich in einer Nextcloud eurer Wahl sichern lässt. Ihr müsst keine Angst haben, dass mit der SCB Unfug angestellt werden kann, da der Inhalt der Datei mit eurer Seedphrase verschlüsselt ist. Die Datei kann also nur, in Kombination mit eurer Seedphrase entschlüsselt werden. Deshalb sind SCB Dateien in einer Cloud kein Problem. Viele Lightning Wallets, sichern die SCB Datei auf den Servern der Betreiber, damit die Kanäle im Worst-Case Szenario wieder hergestellt werden können. Die Phoenix Wallet, tut dies zum Beispiel auch.

Den Backup Job der Nextcloud erstellen

Ihr benötigt einen Nextcloud Provider eurer Wahl. Wir stellen unseren Lesern 5GB Gratis Nextcloud Speicher zur Verfügung, ihr könnt also auch gern unsere Dienstleistung dafür verwenden. Registriert euch auf unserer Webseite, und erhaltet in eurem Konto Zugriff zur Nextcloud. Die Logindaten sind die Daten, die ihr zur Registrierung bei uns verwendet habt.

Stellt eine SSH Verbindung zur eurem Raspiblitz her. Öffnet das Konsolenmenu mit menu und geht in die SETTINGS:

Steuert auf SCB/Emergency Backup on Nextcloud, und markiert das Tool mit der Leertaste, und geht danach unten auf OK:

Anschliessend öffnet sich ein weiteres Fenster. Gebt die URL eurer Nextcloud Instanz ein, auf dem die SCB Datei gesichert werden soll:

https://cloud.yourdevice.ch wäre die URL unserer Nextcloud-Instanz. Bestätigt mit OK. Anschliessend werdet ihr in 2 weiteren Fenstern nach dem Username, und dem Passwort gefragt, gebt beide Daten ein, und bestätigt mit OK. Nach der Passworteingabe bekommt ihr ein Output, ob das Backup geklappt hat:

Ihr seht, dass die channel.backup erfolgreich hochgeladen worden ist.

Überprüfen des Backups auf eurer Nextcloud

Loggt euch auf eure Nextcloud Instanz ein, und geht in den Dateienexplorer in dem ihr auf der Arbeitsleiste oben auf Dateien geht. Ein neuer Ordner mit dem Namen rapsi wurde erstellt. Darin befindet sich die channel.backup:

Eure channel.backup befindet sich nun auf eurer gewählten Nextcloud Instanz. Die Datei bleibt wenige Kilobyte gross, und wächst auch nicht sonderlich an, wenn ihr immer die ungefähr gleiche Anzahl an Kanälen habt. Schliesst ihr einen Kanal, oder eröffnet ihr einen neuen, läd der Raspberry die Datei direkt wieder in die Nextcloud ohne euer zutun.

Fazit

Mit dem SCB Backup via Nextcloud fügt ihr eine zusätzliche Schicht an Sicherheit für eure Node hinzu. Das Remote Backup stellt eine sinnvolle Ergänzung zur lokalen Sicherung zuhause da. Wie sagt man so schön? Doppelt genäht, halt besser!

Schaut gerne hier vorbei, für den kompletten Backup & Restore Leitfaden für Fullnodes:

Schaut gerne für weitere Informationen in den offiziellen Raspiblitz-Docs vorbei.

The post Raspiblitz SCB Backup auf einer Nextcloud appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Einleitung

Die Rolle dieser Server besteht darin, eine Brücke zwischen dem Bitcoin-Netzwerk und Endanwendern zu bilden. Sie bieten eine schnittstelle, durch die Wallets Transaktionsdaten abfragen können, um den aktuellen Stand der Guthaben zu prüfen, ohne die gesamte Blockchain lokal verarbeiten zu müssen. Dies ist besonders wichtig für Nutzer, die nicht die Ressourcen oder die Neigung haben, zu ihren Wallets gleich noch vollständige Full Nodes zu betreiben. Die meissten Wallets, fragen öffentlich Electrum Server ab, um die Transaktionsdaten abfragen zu können.

Im Laufe der Zeit haben sich verschiedene Implementierungen von Electrum-Servern entwickelt, die jeweils unterschiedliche Ansätze hinsichtlich Leistung, Ressourcenverbrauch und Benutzerfreundlichkeit bieten. Diese Server variieren in ihrer Komplexität von solchen, die für den persönlichen Gebrauch mit minimalem Ressourcenbedarf gedacht sind, bis hin zu solchen, die für den Betrieb auf leistungsstarken Maschinen und die Bereitstellung von Diensten für eine große Anzahl von Nutzern konzipiert sind. Zu den prominenten Implementierungen gehören ElectrumX, Electrs und Fulcrum, die jeweils ihre spezifischen Vor- und Nachteile bieten und sich für verschiedene Einsatzszenarien eignen.

In diesem Bericht vergleichen wir diese drei Haupttypen von Electrum-Servern, um einen umfassenden Überblick über ihre Unterschiede, Performance und Anwendungsbereiche zu geben und so Nutzern zu helfen, die beste Wahl entsprechend ihren individuellen Bedürfnissen zu treffen, und um zum Beispiel bei der Frage, welche Version auf dem Server installiert werden soll, die Entscheidung zu erleichtern.

Vorteile des Selbst-Hostings eines Electrum-Servers

Das Hosting eines eigenen Electrum-Servers bietet zahlreiche Vorteile, insbesondere hinsichtlich Kontrolle, Privatsphäre und Leistung. Hier sind einige der wichtigsten Vorteile:

Verbesserte Privatsphäre

Wenn ihr euren eigenen Electrum-Server betreibt, werden eure Transaktionsanfragen nicht durch Server Dritter geleitet, was bedeutet, dass eure finanziellen Aktivitäten und euer Guthaben vor neugierigen Blicken geschützt bleiben. Dies ist besonders wichtig für euch, falls ihr Wert auf Datenschutz legt, da keine Informationen mit externen Parteien geteilt werden müssen.

Volle Kontrolle und Unabhängigkeit

Durch das Hosting eures eigenen Servers habt ihr die vollständige Kontrolle über die Software und deren Updates. Ihr könnt wählen, welche Blockchain-Daten verarbeitet und wie diese gespeichert werden, und sind nicht von der Verfügbarkeit oder den Sicherheitspraktiken externer Dienstanbieter abhängig. Dies reduziert das Risiko von Ausfallzeiten und gibt euch die Freiheit, den Server nach euren eigenen Sicherheits- und Leistungsstandards zu konfigurieren.

Erhöhte Sicherheit

Indem ihr euren eigenen Server betreibt, könnt ihr sicherstellen, dass die Sicherheitsmaßnahmen auf eure spezifischen Anforderungen zugeschnitten sind. Dies ist besonders wichtig in einem Ökosystem wie Bitcoin, wo die Sicherheit eurer Mittel von größter Bedeutung ist. Eigenes Hosting bedeutet, dass ihr nicht auf die Sicherheitsvorkehrungen Dritter vertrauen müssen, die möglicherweise nicht ausreichend sind.

Bessere Performance und Schnelligkeit

Ein selbst gehosteter Electrum-Server kann für schnelleren Zugriff und schnellere Antwortzeiten konfiguriert werden, besonders wenn ihr ihn in eurer lokalen Umgebung oder in einem nahegelegenen Datenzentrum hosten. Dies kann die Synchronisation Ihrer Wallets beschleunigen und euch einen zeitnahen Überblick über Transaktionen und Kontostände ermöglichen.

Unterstützung des Netzwerks

Durch das Betreiben eures eigenen Servers tragt ihr zur Dezentralisierung und Robustheit des Bitcoin-Netzwerks bei. Mehr unabhängige Server erhöhen die Redundanz und die Widerstandsfähigkeit des Netzwerks gegen Angriffe oder Ausfälle zentraler Punkte.

Lernmöglichkeiten und Community-Beitrag

Das Einrichten und Verwalten eines eigenen Electrum-Servers bietet wertvolle Lernmöglichkeiten in den Bereichen Netzwerkmanagement, Blockchain-Technologie und Sicherheit. Außerdem können ihr falls ihr das wollt, euren Server der Öffentlichkeit zugänglich machen, also auch einen direkten Beitrag zur Bitcoin-Community leisten.

Durch diese Vorteile bietet das Selbst-Hosting eines Electrum-Servers nicht nur praktische Vorzüge im täglichen Gebrauch, sondern stärkt auch das gesamte Bitcoin-Ökosystem durch erhöhte Sicherheit, Privatsphäre und Dezentralisierung.

Electrs

Electrs wurde primär für den persönlichen Gebrauch entwickelt, was sich in geringeren Speicheranforderungen niederschlägt, allerdings auf Kosten höherer CPU-Nutzung. Electrs kommt meissten auf fertigen Fullnodes zur Anwendung, wie zum Beispiel Umbrel, oder dem RaspiBlitz. Diese Version kann man sich meisst über den integrierten AppStore bei Umbrel, oder bei den zusätzlichen Diensten auf dem Raspiblitz installieren.

Resourcenanforderungen

• Datenbankgröße: 32 GB
• Hardware-Anforderungen: Indexaufbau dauert ca 24 Stunden auf der Testhardware (Raspi 4 8GB).
• Weitere Anforderungen: Keine txindex-Aktivierung in Bitcoin Core benötigt.

Verwendung
Optimal für individuelle Anwender, die einen Electrum-Server auf einem persönlichen Node betreiben wollen, insbesondere wenn geringere Hardware-Ressourcen verfügbar sind.

Vorteile

• läuft auch auf einem Raspberry Pi zuverlässig und schnell
• kein txindex=1 Setzung notwendig in der bitcoin.conf

Nachteile

• Keine Binärdateien verfügbar.
• Höhere CPU-Belastung während des Betriebs.

ElectrumX

ElectrumX ist eine Weiterentwicklung des ursprünglichen Electrum Server Projekts, das 2017 eingestellt wurde. Es ist speziell für den Einsatz auf öffentlichen Servern konzipiert worden.

Resourcenanforderungen

• Datenbankgröße: 75 GB
• Hardware-Anforderungen: Initialer Indexaufbau dauert etwa 2 Tage auf einem Server mit 4 CPU Kernen und 8 GB RAM, der Index kann auf leistungsfähigeren Rechnern vorbereitet und transferiert werden.
• Weitere Anforderungen: Erfordert eine txindex-Aktivierung in Bitcoin Core.

Verwendung
Ideal für Betreiber, die einen öffentlich zugänglichen Electrum-Server hosten möchten, insbesondere wenn sie bereits über die notwendige Hardware verfügen.

Vorteile

• weniger grosse Datenbank als Fulcrum benötigt
• deutlich schnellere Datenbankabfragen als Electrs
• auch auf NUCs und Mini-PCs lauffähig

Nachteile

• Keine Binärdateien verfügbar.
• Relativ hohe Anforderungen an die Speicherkapazität und längere Zeit zum Indexaufbau.
• Nicht für einen Raspberry Pi geeignet

Fulcrum

Fulcrum ist eine moderne Implementierung in C++, die zwar höhere Speicheranforderungen als ElectrumX und Electrs hat, jedoch eine bemerkenswerte Performance bietet.

Resourcenanforderungen

• Datenbankgröße: 102 GB
• Hardware-Anforderungen: Indexaufbau dauert 1-2 Tage auf der einem Server mit 4 CPU Kernen und 8GB RAM.
• Weitere Anforderungen: Erfordert eine txindex-Aktivierung in Bitcoin Core.

Verwendung
Sehr geeignet für Anwender, die Wert auf hohe Performance legen und bereit sind, die dafür notwendigen Ressourcen bereitzustellen.

Vorteile

• Bietet Binärdateien für Linux und Windows an.
• Hohe Performance nach Indexaufbau.

Nachteile

• hohe Hardware Anforderungen (höher als ElectrumX)
• relativ hoher RAM Verbrauch 3-6GB
• Hoher Speicherbedarf da grosse Datenbank

Performance Vergleich der Server Versionen

Sparrow hat Testergebnisse zur Verfügung gestellt, der die Server in der Performance direkt miteinander vegleicht. Diese Ergebnisse schauen wir uns in diesem Beitrag auch gleich noch genauer an.

Wallet initial Start

Wallet Refresh

Testergebnisse

Test 1: Initial Load

• Fulcrum ist mit Abstand der schnellste Server mit Ladezeiten von etwa 1,4 bis 2,3 Sekunden.
• ElectrumX zeigt moderatere Ladezeiten zwischen 40,7 und 54,1 Sekunden.
• Electrs ist mit Ladezeiten zwischen 322 und 428 Sekunden deutlich langsamer.

Zusammenfassung: Fulcrum ist ungefähr 22-mal schneller als ElectrumX und etwa 300-mal schneller als Electrs.

Test 2: Wallet Refresh

• Fulcrum führt auch hier mit Erfrischungszeiten zwischen 7,4 und 14,2 Sekunden.
• Electrs verbessert sich im Vergleich zum Initial Load erheblich mit Zeiten zwischen 11,2 und 17,6 Sekunden.
• ElectrumX bleibt weiterhin langsamer mit Zeiten zwischen 66,2 und 114,5 Sekunden.

Zusammenfassung: Fulcrum ist etwa 8-mal schneller als ElectrumX und 1,5-mal schneller als Electrs beim Wallet-Refresh.

Diskussion

Electrs speichert nicht alle notwendigen Daten, um Transaktionen schnell zuzuordnen, was zu längeren Ladezeiten führt. Jedes Mal, wenn eine Wallet geladen wird, müssen 3,5GB an Blöcken aus Bitcoin Core abgerufen und neu verarbeitet werden, was sowohl die CPU stark beansprucht als auch zu Verzögerungen führen kann, wenn gleichzeitig weitere Anfragen bearbeitet werden müssen.

ElectrumX und Fulcrum hingegen speichern Daten so, dass eine schnelle Abfrage aller Transaktions-IDs und Blockhöhen, die mit einer Adresse verbunden sind, ermöglicht wird. Dies führt zu einer effizienteren Verwaltung und schnelleren Antwortzeiten, insbesondere bei Fulcrum, das in modernem C++17 geschrieben ist und dadurch nicht nur schneller, sondern auch plattformübergreifend konsistent performant ist. ElectrumX, programmiert in Python, zeigt eine weniger geeignete Leistung für diese Anwendung, mit variabler Indexierungs- und Abfrageleistung, die stark von der Serverarchitektur abhängt.

Fazit

Die Wahl, einen Electrum-Server selbst zu hosten, hängt stark von den individuellen Bedürfnissen und technischen Fähigkeiten des Nutzers ab. Wie wir gesehen haben, bieten ElectrumX, Electrs und Fulcrum jeweils unterschiedliche Vorteile, die sie für verschiedene Anwendungen und Benutzerprofile geeignet machen. Unabhängig davon, für welche Serveroption ihr euch entscheidet, ist es wichtig zu erkennen, dass jeder dieser Schritte nicht nur technische Vorteile mit sich bringt, sondern auch eine tiefere Verbindung zum Bitcoin-Netzwerk und eine stärkere Kontrolle über eure digitale Autonomie. Eine kurze Zusammenfassung der Electrumserver wie wir erfahen haben:

• Electrs eignet sich für individuelle Nutzer, die einen effizienten, leichtgewichtigen Server für persönliche Zwecke suchen.
• ElectrumX ist am besten für diejenigen geeignet, die einen stabilen, öffentlich zugänglichen Server mit ausreichender Hardware hosten wollen.
• Fulcrum bietet die beste Performance und eignet sich für Anwender, die hohe Anforderungen an Geschwindigkeit und Effizienz stellen und entsprechende Hardware-Ressourcen haben. Bestens geeignet für öffentliche Electrum Server die viele Wallets mit Transaktionsdaten versorgen.

Mit diesem Bericht hoffe ich, euch die notwendigen Informationen an die Hand gegeben zu haben, um eine informierte Wahl zu treffen, die eure Interaktion mit dem Bitcoin-Netzwerk verbessert und gleichzeitig eure finanzielle Unabhängigkeit stärkt.

The post ElectRS vs ElectrumX vs Fulcrum 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.

Einleitung

Normerweilse verbindet sich RaspiBlitz auschliesslich mit dem Tor Netzwerk, um die die initiale Blockchain Synchronisation auszuführen. Das soll der Privatspähre dienlich sein, und verhindern, dass andere erspähen können, dass man sich die Blockchain herunterlädt, und somit auch Schlüsse gezogen werden könnten, dass man eine Node zuhause betreibt. Der Ansatz ist Privacy per Default, und auch absolut zu unterschreiben. Mann kann aber die initiale Synchronisation auch über das Internet beziehungsweise genauer gesagt, oder auch Clearnet genannt, durchführen, wobei die ich Nachteile davon eher weniger schwer gewichte. Die Blockchain wird von fest definierten trusted nodes heruntergeladen, welche in der Regel nicht interessiert sind, euch auszuspionieren. Auch wenn eine daten-sammelnde Node darunter wäre, wäre die Info weniger gefährlich, da sich tausende Nodes ständig ebenso die Blockchain über das Clearnet herunterladen.

Eure Internetgeschwindigkeit sollte unter 75Mbit einen RaspiBlitz 4 beim Sync nicht ausbremsen, sollten die auch tatsächlich voll zur Verfügung stellen. Eine Raspi 5 benötigt für sein volles Potential bereits an die 150-200Mbit an Interneteschwindigeit.

Vorbereitungen

Der Raspiblitz muss installiert sein, das Image geflasht und das Betriebsystem geladen haben. Danach könnt ihr euch via SSH auf dem Raspiblitz einloggen. Falls ihr dass das erste mal tut wäre das:

ssh admin@ip_addr

Das Initialpasswort lautet raspiblitz, wir gehen aber jetzt davon aus, dass ihr euch bereits einmal eingeloggt hattet, und der Blitz bereits schon bereits angefangen hat zu synchronisieren. Falls ihr euch im Menu befindet, beendet dieses mit strg+c damit ihr auf die Komandozeile kommt:

Änderung der Konfiguration

Danach befindet ihr euch auf der Befehlszeile. Stoppt mit dem Befehl sudo systemctl stop bitcoind.service den Synchronisationvorgang. Das kann, falls ihr bereits schon eine Weile dabei seid, etwas länger gehen, da die die gespeicherten Blockchaindaten aus dem Cache auf die Platte geschrieben werden müssen. Checkt mit sudo systemctl status bitcoind.service, ob der Service angehalten hat:

Danach öffnet ihr mit sudo nano /mnt/hdd/bitcoin/bitcoin.conf die bitcoind Konfigurationsdatei. Hier scrollt ihr ganz nachen unten zum Abschnitt # tor by default. Erledigt die Änderungen wie folgt und fügt oberhalb die Zeilen #ipv4sync und onlynet=ipv4 hinzu, falls nicht schon vorhanden. Falls onlynet=ipv4 bereits vorhanden ist, müsst ihr keinen gesonderten Bereich einrichten.

#ipv4sync
onlynet=ipv4

# tor by default
deprecatedrpc=addresses
#onlynet=onion
#proxy=127.0.0.1:9050
main.bind=127.0.0.1
test.bind=127.0.0.1
dnsseed=0
dns=0
debug=tor
debug=i2p
#i2psam=127.0.0.1:7656
#i2pacceptincoming=1
#onlynet=i2p
shrinkdebugfile=1

Kommentiert onlynet=onion, proxy=127.0.0.1, i2psam=127.0.0.1:7656, i2pacceptincoming=1 und onlynet=i2p aus.

Danach könnte es folgendermassen aussehen:

Danach speichert ihr die Datei mit strg+o und beendet mit strg+x

Startet bitcoind nun neu mit sudo systemctl start bitcoind.service
Bitcoin Core wird nun neu starten, und sich für die weitere Synchronisation mit Clearnet Clients verbinden.

Synchronisation checken

mit dem Befehl sudo tail -f /mnt/hdd/bitcoin/debug.log könnt ihr checken, ob sich die Node weiter synchronisiert:

Änderungen Rückgängig machen

Nachdem die Blockchain synchronisiert wurde, könnt ihr die Änderungen natürlich rückgängig machen. Das geht ganz einfach, indem ihr die Hashsymbole vor den Tor und i2p Optionen wieder entfernt:

onlynet=ipv4 kann aktiviert bleiben, da der Raspiblitz damit auch clearnetpeers über den Torproxy erreichen kann.

Startet danach Bitcoin Core wieder neu mit sudo systemctl restart bitcoind.service
Alle nachfolgenden Blöcke wird der RaspiBlitz nun wieder via Tor herunterladen.

Abschluss

Viele wundern sich, warum das teilweise auf dem Pi4 so extrem lange dauert, bis die Blockchain synchronisiert wird, und denken dabei schnell daran, dass der Raspiberry 4 extrem langsam ist. Das liegt aber nicht nur an der Hardware, sondern einfach am Tor Netzwerk. Mehr wie 1.5 - bis 3MB/sec Download sind da einfach nicht drin. Ich finde es sowieso besser, wenn das Tor Netzwerk nicht mit dem Download riesiger Datenmengen überlastet wird, wie z.B das herunterladen der Blockchain, oder das Streamen via Tor, den das sind unter anderem Gründe, wieso Tor auch sehr langsam ist. Da ihr wahrscheinlich sowieso Bitcoin Content im Internet betrachtet, weiss man sowieso schon, dass ihr euch für Bitcoin interessiert.

The post Raspiblitz deutlich schneller via Clearnet synchronisieren appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Wenn ihr gerade erst Neuling seid und einen frische Node startet, ist diese Anleitung etwas, dass man sich für später aufbewahren kann.

Um was geht es überhaupt

Die channel.db ist eine essentielle Datenbank auf Lightning Nodes im Lightning Network, einem Layer-2-Zahlungsprotokoll, das auf der Blockchain von Bitcoin aufbaut, um schnelle, skalierbare Transaktionen zu ermöglichen. Diese Datenbank spielt eine zentrale Rolle in der Verwaltung und dem Betrieb einer Lightning Node.

Die Datei channel.db, die sich in den Unterordnern von LND befindet, wächst mit der Zeit immer weiter an, bis sie ziemlich schwer zu verwalten ist und eine Dateikorruption bei einer größeren Datei wahrscheinlicher als bei einer kleineren ist. Zudem wird diese Datei in den Speicher geladen, sodass, je kleiner sie ist, umso weniger Speicher bzw RAM wird verwendet. Sie beeinflusst auch die Reaktionszeit eurer Node für das Routing von Zahlungen.

Zusammenfassend ist es also ziemlich sinnvoll, diese Datei so klein wie möglich zu halten.
Warum habe ich diesen Artikel geschrieben gemacht? Ich las mehrere Beiträge auf Github über das Problem, mit großen db-Dateien umzugehen und die zunehmende Verlangsamung der Nodes. Ausserdem gibt es ziemlich wenig Anleitungen, wie man selber die Kanal Datenbank kompaktiert, also habe ich beschlossen, eine Anleitung zu schreiben.

Diejenigen, die in letzter Zeit feststellen, dass ihre Nodes seltsam und langsamer reagieren, werden mit dieser kurzen Anleitung sicherlich etwas Erleichterung erfahren.

channel.db Grösse überprüfen

Die Grösse der channel.db kann man mit dem ls -lh schnell überprüfen. Empfehlenswert ist die Datenbank ab 3GB zum ersten mal zu kompaktieren. Je nachdem auf welchen System lautet liegt die channel.db an folgendem Ort und kann mit der flag -lh grössentechnisch gesichtet werden:

Umbrel

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

Raspiblitz

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

BTCPay Server

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

Exemplarisch, bei mir ist die channel.db bereits 2.6GB gross:

channel.db kompaktieren

Wir müssen zuerst ein paar Vorbereitungen erledigen und ein paar Änderungen durchführen, damit die kompaktieren möglich ist. Wir schauen uns die kompaktieren auf 3 verschiedenen Systemen an, BTCPay Server, Umbrel und dem Raspiblitz. Wenn wir schon dabei sind führen wir gleich noch ein paar weitere Optimierungen durch, welche die Performance der Nodes erhöht.

Umbrel Fullnode

Die Durchführung des kompaktieren auf einem Umbrel System ist ziemlich einfach. Öffnet eure Lightning Node, und geht oben rechts mit den 3 Punkten in die Einstellungen:

Navigiert runter zu Optimizations und aktiviert folgende Settings:

db.bolt.auto-compact=true
db.bolt.auto-compact-min-age=168h

gc-canceled-invoices-on-startup=1 
gc-canceled-invoices-on-the-fly=1
ignore-historical-gossip-filters=1
start sync-freelist=1
stagger-initial-reconnect=1
payments-expiration-grace-period=9999h

Haltet nach den richtigen Konfigurationen Auschau, indem ihr die kleine rot markierte Beschriftung beachtet:

db.bolt.auto-compact-min-age=168h beschreibt zum Beispiel, dass die kompaktierung der channel.db erst durchgeführt wird, wenn die Datei das letzte mal vor 168 Stunden verkleinert wurden ist. Wenn ihr die Einstellungen deaktiviert, wird die channel.db jedesmal bei neustart von LND kompaktiert. Das kann jedesmal zu langen Ladezeit führen bis die Node aktiv ist.

BTCPay Server

Auf dem BTCPay Server ist ein spezielles Fragment zu aktivieren, damit die Kompaktierung aktiv wird. Loggt euch auf dem Server via SSH ein, und führt folgenden Befehl aus:

export BTCPAYGEN_ADDITIONAL_FRAGMENTS="$BTCPAYGEN_ADDITIONAL_FRAGMENTS;opt-lnd-autocompact"

Dieser Befehl fügt die Kompaktierung dem BTCPay Server hinzu. Leider führt der Server die Kompaktierung nun jedesmal bei einem Neustart des Systems oder LND durch, die Einstellung db.bolt.auto-compact-min-age können wir aber durch einen kleinen Umweg setzen. Legt euch ein neues Fragment an mit dem Befehl:

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

Fügt hier wieder folgenden Inhalt hinzu, aber ohne die Einstellung db.bolt.auto-compact=true da dieses schon im autocompact Fragment enthalten ist:

db.bolt.auto-compact-min-age=168h 
gc-canceled-invoices-on-startup=1  
gc-canceled-invoices-on-the-fly=1 
ignore-historical-gossip-filters=1 
start sync-freelist=1 
stagger-initial-reconnect=1 
payments-expiration-grace-period=9999h

Speichert mit strg+o und beendet mit strg+x. Fügt das Custom Fragment mit der Export Funktion hinzu:

export BTCPAYGEN_ADDITIONAL_FRAGMENTS="$BTCPAYGEN_ADDITIONAL_FRAGMENTS;opt-lnd-additionals.custom"

Um die neuen Einstellungen zu laden, führt ihr einmal folgenden Befehl aus:

. /root/btcpay-server/btcpay-setup.sh -i

Vergesst nicht den Punkt mit einzufügen! Danach startet der Server neu, und läd die neuen Einstellungen mit in die entsprechenden Docker-Container.

Hier findet ihr ausserdem eine Liste aller Fragmente für den BTCPay Server.

Raspiblitz Fullnode

Auf dem Raspiblitz ist das Datenbank Compacting bereits aktiviert. Es wird standardmässig ausgeführt, sollte die channel.db ältern als 672 Stunden sein. Die Kompaktierung wird dann bei neustart von LND durchgeführt. Es kann sinnvoll sein, die Zahl etwas herunter zu setzen, da bei einer grossen Anzahl Kanälen, saumässig viel Arbeit auf den Raspiblitz zu kommt. Ausserdem setzen wir auch die anderen Optimierungen, wie bei Umbrel und dem BTCPay Server. Schauen wir uns an, wie wir das tun:

Stoppt als erstes LND mit dem Befehl:

sudo systemctl stop lnd.service

Öffnet danach eure lnd.conf mit

sudo nano /mnt/hdd/lnd/lnd.conf

Packt den folgenden Inhalt in die die Konfigurationsdatei mit rein, und zwar so wie im Beispiel danach geordnet:

db.bolt.auto-compact=true 
db.bolt.auto-compact-min-age=168h 
gc-canceled-invoices-on-startup=1  
gc-canceled-invoices-on-the-fly=1 
ignore-historical-gossip-filters=1 
start sync-freelist=1 
stagger-initial-reconnect=1 
payments-expiration-grace-period=9999h

Die Konfiguration müssen an die korrekten Stellen:

Speichert die Konfiguration mit strg+o und beendet wieder mit strg+x

Startet LND neu mit:

sudo systemctl start lnd.service

Achtung, aufgepasst!

Bei einem kleineren System kann es teilweise mehrere Minuten bis Stunden gehen, um die Datenbank zu kompaktieren. Ein Raspiblitz, auf dem mehrere dutzend Kanäle laufen, auf dem die channel.db bereits mehrere Gigabyte hat, kann es gut und gerne mal 1-3 Stunden dauern, bis die Datenbank kompaktiert worden ist. Es heisst also einfach; WARTEN! In diesem Moment braucht ihr Geduld, teilweise viel Geduld. Macht nichts Dummes, starte die Node nicht neu oder zieh ihn nicht aus der Steckdose. Es ist normal, dass der Start mehr Zeit in Anspruch nimmt.

Der Teil der Kompaktierung ist relativ heikel. Falls die Node während dieser Phase abgeschalten wird, sind all eure Kanäle nachher mit hoher wahrscheinlichkeit beschädigt. Katzen und Hunde am besten während dieser Zeit aus dem Zimmer sperren!

Abschluss

Mit den ls -lh Befehlen oben, könnt ihr anschliessend die Grösse der Datenbank nochmals überprüfen. Der Screenshot von mir war nach der Kompaktierung, die Datenbankgrösse betrug vorher ca 4.7GB. Eine regelmässige Ausführung der Kompaktierung hält eure Node, schnell, schlank, und verringert die Gefahr einer Datenbank Korruption. Die Kanaldatenbank wird natürlich trotzdem immer weiter anwachsen. Nach einem Jahr Routen, in Kombination mit vielen Kanälen kann die Datenbank auch gern mal 15 bis 20GB in Anspruch nehmen. Wichtig ist hier, die Datenbank regelmässig zu kompaktieren, und dass ihr dafür genug Resourcen zur Verfügung habt. Für grössere Routing Nodes, ist der Raspiblitz auf einem Pi, also nicht geeignet.

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

Was ist der Bitcoin Mempool?

Der mempool (kurz für Memory Pool) ist eine Art Wartezimmer oder Sammelstelle für alle unbestätigten Bitcoin-Transaktionen. Jedes Mal, wenn jemand eine Bitcoin-Transaktion sendet, landet diese zunächst im mempool, bevor sie in einen Block aufgenommen und von den Minern bestätigt wird. Wichtig zu verstehen: der mempool ist keine zentrale Sammelstelle aller Transaktionen, sondern ein Abbild aller aktuelle Transaktionen die im mempool des jeweiligen Knotenpunktes vorliegen. Jeder Miner, und jeden Full Node Betreiber hat seinen eigenen mempool, dieser kann vom mempool von der Seite https://mempool.space, ein öffentlich einsehbarer mempool, abweichen.

Funktion des Mempools

Kommen wir zu den wichtigsten Funktionen des mempools un seinem Nutzen:

1. Sammelstelle für Transaktionen: Der Mempool sammelt alle Transaktionen, die noch nicht in einen Block aufgenommen wurden. Diese Transaktionen warten darauf, von Minern ausgewählt und in den nächsten Block der Blockchain eingefügt zu werden.
2. Priorisierung nach Gebühren: Miner wählen Transaktionen aus dem Mempool basierend auf den angehängten Gebühren. Höhere Gebühren können eine schnellere Bestätigung bedeuten, da Miner natürlich daran interessiert sind, die rentabelsten Transaktionen zuerst zu bearbeiten.
3. Verwaltung des Netzwerkverkehrs: In Zeiten hoher Netzwerkaktivität kann der Mempool überfüllt sein, was zu Verzögerungen führt. Dieser Stau zeigt, wie das Netzwerk mit großem Transaktionsaufkommen umgeht.

Nutzen des Mempools

• Transparenz: Jeder kann den Mempool einsehen, um den Status einer Transaktion zu überprüfen. Das bietet Transparenz und ermöglicht es Nutzern, angemessene Transaktionsgebühren festzulegen.
• Netzwerkauslastung: Der Zustand des Mempools gibt Aufschluss über die Auslastung und Effizienz des Bitcoin-Netzwerks. Ein überfüllter Mempool kann auf einen ein sehr hohes Transaktionsvolumen hinweisen.

Verbindung mit Bitcoin-Wallets und Lightning Network

Bitcoin-Wallets:

• Gebührenschätzung: Moderne Wallets analysieren den Mempool, um eine Schätzung der erforderlichen Transaktionsgebühren vorzunehmen.
• Transaktionsstatus: Wallets nutzen den Mempool, um Nutzern Informationen über den Status ihrer Transaktion zu liefern (z.B. ob sie noch unbestätigt ist). Viele Apps lassen euch den mempool selber festlegen. Es kann z.B auch der eigene verwendet werden, der auf der eigenen Fullnode läuft.

Lightning Network (LN) und LND (Lightning Network Daemon):

• off-Chain-Transaktionen: Das Lightning Netzwerk ermöglicht Off-Chain-Transaktionen, die nicht direkt im Mempool erscheinen. LN-Transaktionen werden erst dann an den Mempool gesendet, wenn Kanäle geöffnet oder geschlossen werden.
• mempool Entlastung: Durch das Ausführen von Transaktionen außerhalb der Blockchain hilft LN, den Mempool zu entlasten und onchain Transaktionen im Bitcoin-Netzwerk zu reduzieren.

Verwendung des Mempools auf mempool.space

Auf der offziellen Webseite mempool.space gibts es einen öffentlich einsehbaren mempool. Dieser muss wie gesagt, nicht zu 100% mit dem mempool andere Netzwerknoten, oder mit eurem eigenem übereinstimmen. Es kann sein, dass ein Miner andere Blöcke validiert und bestimmte Transaktionen priorisiert, weil es dafür einen bestimmten Grund gibt. Ein Miner kann selber entscheiden, welche Transaktionen er validieren möchte, und welche nicht. ViaBTC führt z.B einen LowFee Accelerator. Sie bestätigen bestimmte Transaktion, die eine sehr niedrige Fee haben, obwohl die Gebühren eigentlich deutlich höher sind. Das soll helfen, stecken gebliebene Transaktionen zu bestätigen, wenn die Gebühren über längere Zeit stark ansteigen. Wir schauen uns nun im nachfolgenden den mempool etwas genauer an.

Die Übersicht

Schauen wir uns den Mempool in der Übersicht an, seid beruhigt, es gibt viele Zahlen, Informationen, viele Felder und Graphen, im Grunde funktioniert der mempool aber relativ einfach.

Ganz oben seht ihr die aktuelle Blockchain visualiert dargestellt. Links seht ihr die unbestätigten Transaktionen, rechts die bestätigten Transaktionen. Sobald ein Block validiert wurden ist, wandert er nach rechts, und ist nicht mehr veränderbar oder im Nachhinein anzupassen, ausser, es kommt zu einem Fall, in der 2 Miner genau zur gleichen Zeit einen gültigen Blocken finden, dann wird der Block der kürzeren Kette verworfen, ein sogenannter Chain Reorg kommt vor.

Genau genommen, gehört der bestätigte Teil nicht zum mempool sondern ist ein sogenannter Blockexplorer.

Auf der linken Seite kommen ständig neue Transaktionen hinzu, die Blöcke verändern sich, die Gebühren können steigen oder gar Transaktionen verschoben werden: dies ist der eigentliche mempool, beziehungsweise der Wartebereich, in dem sich die unbestätigten Transaktionen befinden. Die Transaktionen in den Blöcken werden in der Regel der Gebühr nach geordnet.

Die Gebühren

Hier seht ihr die aktuellen Gebühren des Netzwerkes. Die Einteilung geschieht in Prioritäten. Zahlungen mit Gebühren höher als das Minimum der höchsten Priotität haben die höchsten Chancen im ersten Block zu landen. Hier könnt ihr also die Gebühren abschätzen, zum Beispiel welche Gebühr ihr am besten für eure Transaktionen nehmen sollt. Bitte merkt euch, dass es hier zu Schwankungen nach oben kommen kann. Es ist also Möglich, das bei vielen einkommenden Transaktionen, die Minimalgebühr von 13 Sats pro Virtualbyte hier in diesem exemplarischen Beispiel nicht mehr ausreichen könnten, um in den ersten Block zu kommen. Bezahlt also lieber etwas mehr, um wirklich im ersten Block zu landen. Eine Zahlung mit zu niedrigen Gebühren, kann unter Umständen also lange im Mempool verhaaren, bis sie bestätigt wird.

Die Blockzusammensetzung

Unter den Gebühren seht ihr, wie der aktuelle Block aussieht. Dieser ändert sich quasi im Sekundentakt.

Es kommen neue Transaktionen hinzu, werden ersetzt, oder fallen aus dem Block heraus, da die Gebühren möglicherweise nicht mehr ausreichen.

Im markierten Bereich können wir die Transaktionen etwas genauner analysieren. Es kann zwischen der Normalansicht, also All, Consolidation, Coinjoins und Data gefiltert werden. Consolidation sind Transaktionen, die kleinere UTXOs in einen einzigen zusammen fassen, um zum Beispiel Gebühren zu sparen. Coinjoins sind Transaktionen, die er Erhöhung der Anonymität im Netzwerk dienlich sind. Wie ihr seht, sobald ihr darauf klickt, ist die Anzahl der Coinsjoins sehr gering. Data Transaktionen sind möglicherweise Ordinals, beziehungszweise Transaktionen, auf denen Affenbildchen und so ein Kram gespeichert sind.

Klickt ihr auf einen unbestätigen Block, seht ihr dessen Aufbau im Detail:

Mit der kleinen Brille bekommt Ihr noch weitere Einsichten zum aktuellen Block, und es lässt sich weiter nuancieren, welche Transaktionen enthalten sind. Links seht ihr die Gebührenverteilung im ausgewählten Block.

Klickt ihr einen bestätigten Block, seht etwas anderes:

Links seht ihr den Exptect Block, also den erwarteten Block, rechts den Actual Block, als so wie er vom Miner schlussendlich gemint wurden ist. Hier kann und darf es zu Unterschieden kommen. Jeder Miner darf einen Block so bauen, wie er es möchte. Manche Miner nehmen z.B. Blöcke auf mit niedriger Fee (siehe oben: Low Fee Accelerator) oder lehnen bestimmte Data Transaktionen (Ordinals, NFTs etc) ab. Der Ursprung ist hier das jeder Miner frei über seinen Mempool bestimmen darf und seine eigene Version des Mempool hat.

Ihr seht links auch die Healthangabe. Diese stellt da, inwiefern der Block vom Miner sich vom Expected Block unterscheidet. Ist die Zahl 100% hat der Miner keine eigens priorisierten Transaktionen mit in den Block aufgenommen, Ist die Zahl nicht 100%, hat der Miner eigens ausgewählte Transaktionen, die auch zum Beispiel von den Gebühren her stark vom aktuellen Blockdurschnitt abweichen, mit in den Block aufgenommen.

Die Difficulty beziehungsweise die aktuelle Schwierigkeitsanpassung

Rechts unter den Bestätigten Block seht ihr die voraussichtliche Schwierigkeitsanpassung. Hier findet ihr Angaben darüber, wie schnell ein Block im Durschnitt aktuell gemint wird, und in wiefern die Difficulty nach der Periode von 2 Wochen, oder genau 2016 Blöcken angepasst wird. Läuft die Blockchain schneller als 10 Minuten Blockzeit, wird die Schwierigkeit entsprechend erhöht, läuft die Blockchain langsamer als 10 Minuten Blockzeit, wird sie entsprechend gesenkt, damit anschliessend die 10 Minuten Blockzeit erreicht wird. Dies geschieht vollautomatisch, und benötigt keiner Steuerung seitens irgendeiner Entität.

Unter der Schwierigkeitsanpassung seht ihr die aktuelle Anzahl eingehender Transaktionen. Die gestrichelte Linie stellt die Transaktionsgeschwindigkeit dar. Die ist in der Regel fest. Das Bitcoincoin Netzwerk kann in der Regel ca 6000-7000 Transaktionen pro 10 Minuten Blockzeit abarbeiten. Die schwankende farbige Linie, sind die eingehenenden Transaktionen. Ist diese deutlich über der gestrichelten weissen Linie, kommen mehr Blöcke hinzu, als das Netzwerk verarbeiten kann. Das bedeutet auch, dasd die Gebühren tendienziell steigen könnten. Ist die Linie lange unter der gestrichelten, bedeutet dies, dass eher weniger Transaktionen hinzukommen, und dass die Gebühren eher fallen werden.

Transaktionen verfolgen

Habt ihr eine Transaktion, z.B aus einer Überweissung, könnt ihr die TxID oben rechts im Suchfeld eingeben. Danach zeigt euch der Blockexplorer die Transaktion an, und wo diese sich in der Warteschlange befindet aber natürlich auch wenn diese Transaktion bereits bestätigt worden ist:

Im oberen Feld seht ihr eine Übersicht, also zum Beispiel die aktivierten Features wie RBF, Segwit oder Taproot. Ausserdem, der Gebührensatz, die Gebühr selber und wer den Block gemint hat. Unten findet ihr das Flussdiagram. Rechts der Input, welcher aus einem UTXO eurer Wallet besteht, und links die Zieladressen. Wenn rechts mehrere Flüsse dargstellt sind, besteht die Transaktion aus mehreren UTXOs! Das heisst also, um die Bezahlung zu ermöglichen, wurden mehreren UTXOs verwendet, weil es keinen gab, der Überweissung vollständig decken konnte. Links findet ihr also die Outputs der Transaktion. Sie besteht in der Regel aus der Gebühr für den Miner (erster Outflow, der eigentlichen Zahlung für die Transaktion (zweiter Fluss) und dem Wechselgeld aus der Transaktion (dritter Outflow). Das Wechselgeld geht in der Regel auf die eigene Wallet zurück.

Die Transaktion mit der TxID faf4902204dd792428c4d65a1d5e9e4771f247659a2d3ec3511a8f014e319002 hat also 2 Outputs:

faf4902204dd792428c4d65a1d5e9e4771f247659a2d3ec3511a8f014e319002:0

und

faf4902204dd792428c4d65a1d5e9e4771f247659a2d3ec3511a8f014e319002:1

Die Zahl hinter der TxID ist der Output Index oder auch TxOut genannt. Der Outputindex hilft dabei, jeden einzelnen Output innerhalb einer Transaktion eindeutig zu identifizieren.

Das Feld unter den Flow gibt Angaben von wo, und wohin die Outputs gesendet werden:

Die Zahlung kommt von der Adress bc1430jx... mit einem UTXO der 0.09471465 BTC gross ist, und geht an die Adress bc1qhc... Die zweite Adresse darunter ist der Change, also das Wechselgeld der Zahlung, weil die Zahlung nur 4 Millionen Sats betrug.

Ein weiteres Beispiel, die Konsolidierung

Hier sehen wir kurz das Flussdiagram einer Konsolidierung:

Die Inputs sind viele kleine UTXOs, die zusammen in einen einzigen gebündelt werden. Rechts oben die Gebühr, links unten, der neue zusammengefasste UTXO. Das spart Gebühren, den die Gebühr erhöht sich mit der Anzahl an Inputs, und Outputs.

Verwendung des eigenen mempools

CLI Variante

Um euren eigenen Mempool im Bitcoin-Netzwerk zu nutzen, müsst ihr mit bitcoind, dem Bitcoin-Daemon, arbeiten. bitcoind ist das Programm, das im Hintergrund auf eurer Fullnode läuft und das Bitcoin-Protokoll implementiert. Es hält eine vollständige Kopie der Blockchain vor und verwaltet den Mempool, eine Sammlung von Transaktionen, die von anderen Knoten im Netzwerk empfangen wurden, aber noch nicht in einem Block enthalten sind.

Wenn ihr bitcoind verwendet, gibt es verschiedene Befehle und Konfigurationsoptionen, die euch helfen, euren eigenen Mempool zu verwalten und zu inspizieren. Hier einige der wichtigsten Befehle, die über die Bitcoin Core RPC-Schnittstelle verfügbar sind:

1. getmempoolinfo: Dieser Befehl gibt euch Basisinformationen über euren Mempool. Er zeigt unter anderem die aktuelle Größe des Mempools, die Anzahl der Transaktionen darin und den Speicherplatz, den sie verbrauchen.

bitcoin-cli getmempoolinfo

getrawmempool: Dieser Befehl liefert eine Liste aller Transaktions-IDs, die derzeit in deinem Mempool sind. Ihr könnt zusätzliche Details zu jeder Transaktion erhalten, indem ihr den Befehl mit dem true-Parameter für detaillierte Informationen ausführt.

bitcoin-cli getrawmempool true

getmempoolentry <txid>: Mit diesem Befehl könnt ihr spezifische Informationen zu einer Transaktion in eurem Mempool abfragen, indem ihr die Transaktions-ID (txid) angebt. Dies ist nützlich, um den Status und die Details einer bestimmten Transaktion zu überprüfen.

bitcoin-cli getmempoolentry <txid>

Mempool-Konfigurationsoptionen: Beim Starten von bitcoind könnt ihr verschiedene Optionen angeben, um das Verhalten eures Mempools anzupassen. Zum Beispiel:

• maxmempool=<n>: Legt die maximale Größe des Mempools in Megabytes fest.
• mempoolexpiry=<n>: Setzt die Zeitdauer (in Stunden), nach der eine Transaktion aus dem Mempool entfernt wird, falls sie nicht in einen Block aufgenommen wird.
• minrelaytxfee=<amt>: Definiert die minimale Gebühr in BTC/kB, die eine Transaktion zahlen muss, um von deinem Knoten angenommen zu werden.

Diese Optionen können in der Konfigurationsdatei bitcoin.conf festgelegt oder direkt beim Start von bitcoind als Befehlszeilenargumente angegeben werden.

1. bitcoind -maxmempool=300 -mempoolexpiry=72 -minrelaytxfee=0.00001

Diese Befehle und Optionen sind zentral, wenn es darum geht, euren eigenen Mempool im Bitcoin-Netzwerk via der Kommandozeile zu verwalten und zu überwachen. Sie können euch helfen, bitcoin besser, auf der ebene des Terminals, zu verstehen.

Visualisierter Mempool

Der mempool auf der eigenen Fullnode kann natürlich auch visualisiert verwendet werden, um Transaktionen zu analysieren oder zu begutachten. Für Anfänger empfiehlt sich deshalb, den visuallsierten Mempool auf der eigenen Fullnode zu installieren. Auf Umbrel und dem Raspiblitz zum Beispiel gibt es dafür Apps. Habt ihr diese installiert, so könnt ihr den internen Mempool der eigenen Fullnode visualisieren, und wie auf der Seite von mempool.space verwenden.

Der Mempool ist auf dem Raspi bei mir bereits installiert, deshalb steht bei mir Open. Bei einem nicht installiertem mempool, wird dort natürlich Install stehen.

Abschließende Gedanken

Ihr habt nun einen tieferen Einblick in die funktionsweise des mempools erhalten. Das macht die Benutzung der Seite doch gleich viel verständlicher. Benutzt ihr euren eigenen Mempool, so werdet ihr sogar noch einen Schritt unabhängiger, den ihr müsst der Seite mempool.space nicht mehr vertrauen, sondern verifziert eure Daten selber! Der Bitcoin Mempool spielt eine wichtige Rolle für die Funktionsweise und dem Verständnis von Bitcoin. Er ist nicht nur ein notwendiger Bestandteil für die Verarbeitung und Bestätigung von Transaktionen, sondern bietet auch Einblicke in die Netzwerkdynamik und -leistung.

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

Was sind UTXOs?

Bitcoin-Transaktionen funktionieren etwas anders als traditionelle Banktransaktionen. Wenn ihr Bitcoin sendet, nützt ihr im Grunde genommen frühere Transaktionen, die an euch gesendet wurden (also Beträge, die ihr bisher noch nicht ausgegeben habt), um neue Transaktionen zu erstellen. Diese unverbrauchten Eingaben werden als Unspent Transaction Outputs (UTXOs) bezeichnet. Wir hatten dazu bereits ein ausführlichen Artikel geschrieben. Schaut mal hier vorbei falls ihr im Allgemeinen mehr über UTXOs erfahren wollt.

Warum ist UTXO-Management wichtig?

Kostenoptimierung
Bitcoin-Transaktionen benötigen Gebühren, die von der Größe der Transaktion in Kilobyte (KB), nicht vom übertragenen Betrag, abhängen. Eine Transaktion, die viele kleine UTXOs als Eingaben verwendet, ist größer und daher teurer. Durch geschicktes Verwalten deiner UTXOs könnt ihr also Geld sparen.

Privatsphäre
Wenn ihr Transaktionen durchführt, die viele UTXOs zusammenfassen, kann das Muster euer Transaktionen eure Identität preisgeben. Durch das sorgfältige Auswählen von UTXOs für jede Transaktion könnt ihr eure finanzielle Privatsphäre besser schützen.

Tipps für effektives UTXO-Management

• UTXOs Konsolidieren bei niedrigen Gebühren
  Wenn die Netzwerkgebühren niedrig sind, ist es eine gute Strategie, mehrere kleine UTXOs in einer einzigen Transaktion zu konsolidieren. So zahlt ihr einmalig eine niedrigere Gebühr, anstatt später für Transaktionen mit vielen kleinen UTXOs höhere Gebühren zu zahlen.
  
• Nutzung von SegWit-Adressen oder Taproot Adressen
  Segregated Witness (SegWit) und Taproot Adressen reduzieren die Größe von Transaktionen, was wiederum die Gebühren senkt. Indem ihr Bitcoins auf SegWit- oder Taproot Adressen haltet und von dort sendet, optimiert ihr die Gebühren.
  
• Coin Control Features nutzen
  Einige Bitcoin-Wallets bieten Coin Control Features, die es euch ermöglichen, spezifische UTXOs auszuwählen, die du für eine Transaktion verwenden möchtet. Dies ist besonders nützlich, um die Privatsphäre zu erhöhen und Gebühren zu optimieren. Um Coin das Coin Controll Feature soll es hier aber heute nicht gehen.
  
• Achtet auf die Datenschutzaspekte
  Beim Zusammenführen von UTXOs in einer Transaktion können Muster entstehen, die Rückschlüsse auf eure Identität oder euer Verhalten zulässt. Überlegt daher genau, welche UTXOs Ihr zusammenführt, insbesondere wenn diese über verschiedene Quellen und Zeiträume hinweg gesammelt wurden. Zum Beispiel dürft ihr niemals UTXOs aus Coinjoins mit ungemischten Coins zusammen konsolidieren.
  
• Batch-Transaktionen
  Wenn Ihr mehrere Zahlungen gleichzeitig senden müsst, erwäge die Nutzung von Batch-Transaktionen, um mehrere Ausgaben in einer einzigen Transaktion zu bündeln. Dies spart Gebühren und kann auch die Privatsphäre verbessern, indem es die Zuordnung von Ausgaben zu bestimmten Empfängern erschwert.
  
• Gebühren-Tools und -Estimatoren nutzen:
  Es gibt verschiedene Tools und Dienste, die euch helfen können, die optimale Gebühr für eure Transaktion zu bestimmen. Die Nutzung solcher Ressourcen kann euch helfen, unnötig hohe Gebühren zu vermeiden. Hierzu lässt sich sagen, das ein Blick auf https://mempool.space euch eigentlich immer die aktuellsten Gebühren anzeigen. Die Gebührenberechnungen von Wallets, sind teilweise eher ungenau.

Konsolidierungen auf der Bitbox02 durchführen

Wir schauen uns an, wie wir UTXOs auf der Bitbox02 durchführen, wie wir die Gebühren bestimmen und wie wir Konsolidierungs-Transaktion schlussendlich ausführen. Öffnet eure Bitbox App, gebt euren Pin ein. Links findet ihr eure Wallets. Klickt auf eines das ihr konsolidieren möchtet. Das kann z.B eure Pocket Wallet sein, auf dem ein Sparauftrag läuft.

Klickt in eurer Wallet oben zuerst auf Erhalten. Wir benötigen zuerst eine interne Empfangsadresse die wir uns zuerst generieren müssen. Im nächsten Fenster wird euch eine neue Adresse angezeigt. Die müsst ihr kurz auf der Bitbox02 bestätigen, damit ihr diese kopieren könnt.

Überprüft kurz die Adresse, klickt danach einfach auf den kopieren Button neben der Adresse und bestätigt die Adresse auf der Bitbox02, sonst schliess sich das Fenster nicht mehr.

Nun geht ihr in eurer Wallet auf Senden. Fügt die Empfangsadresse ein, die ihr gerade kopiert habt, in das Feld der Empfangsadresse hinzu. Wichtig ist, das ihr unten den Haken bei Alles senden setzt.

Die Gebühren sind am besten immer manuel zu setzen, da die Schätzung für die Voreinstellungen manchmal sehr daneben sein können, vor allem wenn sich die Gebühren plötzlich schnell ändern. Geht dazu auf die Seite https://mempool.space und checkt die Gebühren dort:

Schaut euch den ersten Block an. Ihr seht das die minimale Gebühr um in den ersten Block zu kommen bei 11 sats/vybtebeträgt. Damit ihr im ersten Block landet, würde ich hier 13 Sats/vbyte nehmen. Umso höher ihr die Gebühren ansetzt, umso besser seid ihr gegen plötzliche starke Gebührensteigerungen geschützt.

Geht zurück zum Senden Tab der Bitbox app und gebt bei Gebühren eine eigene Gebühr ein mit dem Wert 13:

Klickt als nächtes unten auf Prüfen. Ihr bekommt ein neues Feld mit den Angaben eurer Transaktion. Hier könnt ihr nochmals eure Einstellungen anschauen, und falls alles gut ist, auf eurer Bitbox bestätigen. Nachdem ihr die Transaktion mit eurer Bitbox signiert habt, wird die abgesetzt und wandert in den Mempool der Miner. Die Transaktion sollte einige wenige Momente nach dem absetzen, in eurer Übersicht wieder auftauchen, aber als Konsolidierung. Nachdem die Transaktion gemint ist, wird sie als Bestätigt angezeigt. Ist diese noch unbestätigt, könnt ihr sie im Mempool sichten, indem ihr auf das Lupensymbol geht, dort dann ganz unten die TransaktionsID kopiert, und diese im Mempool eingebt.

UTXOs auf der Fullnode konsolidieren

Die Konslidierug auf der eigenen Fullnode ergibt natürlich auch Sinn. Habt ihr einige UTXOs angesammelt, die z.B aus Resten von eröffneten Kanälen bestehen, könnt ihr diese kleinen UTXOs bei geringen Gebühren konsolidieren. Damit werden Kanaleröffnungen z.B deutlich günstiger, da die Öffnung da nur aus einem einzigen UTXO besteht.

Die einfachste Möglichkeit ist, die UTXOs via RTL, bzw Ride the Lightning (Metallica lässt Grüssen) zu konsolidieren. Ride the Lightning is eine Managementsoftware für Eure Fullnode. Dafür benötigt Ihr natürlich zuerstmal RTL.

Umbrel

Die Installation von RTL via Umbrel ist schnell und einfach. Geht auf die Apps, und sucht nach Ride the Lightning. Links ist RTL für LND, und rechts für C-Lightning.

Raspiblitz

Die Installation auf dem Raspi ist ähnlich einfach. Loggt euch vial SSH ein, und gebt menu in die Befehlszeile ein. Hier geht ihr auf Services und installiert euch Ride the Lightning für LND:

Setzt den Stern mit Enter und bestätigt mit OK. Beachtet, das die Installation auf dem Blitz einige Zeit in anspruchen nehmen kann.

Die Installation kann auch im Web-GUI des Raspis durchgeführt werden. Geht dazu links auf Apps, und installiert euch unten Ride the Lightning. Der Raspi wählt die korrekte Installation für eure Lightning Implementation aus:

BTCPay Server

RTL ist auf dem BTCPay Server bereits von Haus aus installiert.

Konsolidierung via RTL durchführen

Öffnet dazu als nächstes RTL. Das Passwort für Umbrel findet ihr im Appstore selber wenn Ihr RTL öffnet. Auf dem Raspiblitz müsst Ihr kein Passwort eingeben, auf dem BTCPay Server ebenso nicht.

Geht auf den Tab Onchain links in der Übersichtsleiste, und klickt auf Generate Address:

Kopiert Euch die Adresse in die Zwischenablage. Klickt danach oberhalb Generate Address auf Sweep All, danach links nochmals auf das neue Feld Sweep All, und gebt hier die kopierte Adresse ein:

Wählt aus dem Drop-Down Menu Fee aus, und gebt anschliessend wieder die Fee ein, die Ihr von https://mempool.space entnommen habt, wie beim Beispiel der Bitbox beschrieben. Klickt danach auf Next, und bestätigt den Sweep.

Unter Onchain --> UTXO --> Transaktion --> View Info könnt Ihr Euch die TransaktionsID heraussuchen und diese wieder im Mempool sichten und überprüfen.

Gratulation, ihr habt nun eure UTXOs erfolgreich konsolidiert. Damit lassen sich vor allem bei hohen Onchain Fees einiges an Gebühren sparen, wir reden hier dann nicht nur von ein paar wenigen Cents.

Fazit

Effektives UTXO-Management ist ein wichtiger Aspekt der Nutzung von Bitcoin, der sowohl die Kostenoptimierung als auch den Datenschutz betrifft. Durch die Anwendung der oben genannten Strategien könnt ihr nicht nur Gebühren sparen, sondern auch eure finanzielle Privatsphäre besser schützen. Es erfordert allerdings ein wenig Aufwand und Verständnis für die Funktionsweise von Bitcoin. Mit der Zeit und etwas Übung wird das Management deiner UTXOs jedoch zur zweiten Natur.

The post Mit UTXO Management Bitcoin Onchain Gebühren sparen 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.

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 und Vorausetzungen

Ihr benötigt einen Raspiblitz oder eine Umbrel Full Node die zu 100% mit der Blockchain synchronisiert ist. Ausserdem muss ein Lighting Wallet eingerichtet sein, und bestenfalls bereits ein paar Kanäle vorhanden sein. Wie ihr zum Beispiel Lightning Kanäle eröffnet, und Kanalpartner findet, erfahrt ihr hier in diesem Beitrag!

Installiert euch erstmal die App Bitbanana aus dem Appstore oder dem Aurora Store.

Mit Umbrel Fullnode verbinden

Die Verbindungsdaten findet ihr auf der Umbrel Fullnode direkt in der Lightning Node App selber. Öffnet dazu eure Lightning Node und klickt oben rechts auf die 3 Punkte und klickt auf Connect Wallet.

Diesen QR Code könnt ihr dann bequem mit der App scannen.

Mit Raspiblitz Fullnode verbinden

Loggt euch via SSH ein, und öffnet das cli-menu mit menu und enter. Geht danach auf Connect:

Geht danach auf Connect Mobile Wallet:

Als nächstes wählt ihr ZAP_ANDROID: oder ZAP to LND für iOS Geräte:

Im nächsten Fenster müsst ihr die Erstellung der Verbindungsdaten zustimmen, danach wählt ihr Console QR falls ihr keinen LCD Bildschirm besitzt:

In der Konsole scheint nun der QR Code, mit dem ihr euch über die Bitbanana App verbinden könnt. Falls der QR zugross erscheint, verkleinert die Ansicht der SSH Sitzung.

Anwendung der App

Öffnet die App, ihr findet auf dem ersten Fenster gleich mal den Button Full Node verbinden. Klickt auf den Button und scannt den QR mit dem Phone. Ihr bekommt kurz eine Warnung dass ihr den Host überprüfen und kennen solltet. Schaut euch kurz eure Node_ID an und stellt sicher, dass es sich wirklich um eure Node handelt. Klickt danach auf OK

Danach solltet ihr auch nach einem kurzen Moment auch gleich mit eurer Node verbunden sein. Die App kann ab nun vollständig zum Zahlen mit Bitcoin und Lightning verwendet werden. Bevor wir das tun, kümmern wir uns noch um etwas Feintuning.

Nützliche Einstellungen

Klickt oben links auf die 3 Striche. Hier findet ihr eine Reihe nützlicher Informationen zur eurer Node wie z.B die Kanäle, das aktuelle Routing, falls ihr eine Routing Node betreibt, oder die UTXOs auf eurer Onchain Wallet. Ausserdem könnt ihr auch Nachrichten über eure Node signieren und verfizieren.

Namen Ändern der Node

Wir gehen mal auf die Einstellung Knoten, und wählen unsere Node aus. Hier findet ihr nochmals die Verbindungsdaten eurer Node, ausserdem könnt ihr der Node einen schöneren Namen, als die Onion Adresse, geben. Wählt dafür einfach Umbenennen aus.

Kontakte hinzufügen

Unter Kontakte könnte ihr andere Nodes, aber auch andere User mit Lightning Adressen hinzufügen. Das könnt ihr manuell tun, aber auch via einem QR Code.

App konfigurieren und Anpassen

Unter Einstellungen findet ihr jede Menge sinnvolle Einstellungen, z.B. könnt ihr auf der Mainpage gleich mal eure Währungseinheiten auswählen. Ausserdem könnt ihr Bitbanana so konfigurieren, dass es automatisch Bitcoin, Lightning Adressen und Zahlungsdaten erkennt und in die richtigen Felder einfügt, wenn ihr z.B auf einer Webseite eine Bezahl Adresse oder eine Invoice kopiert. Aktiviert dafür das scannen der Zwischenablagen.

Bitte legt unbedingt einen PIN für die App fest, auch wenn euer Smartphone bereits über einen PIN sichert. Das dient der Sicherheit, auch dafür falls Diebe in einem ungünstigen moment euer Smartphone entwenden.

Die App verfügt über einen eingebauten Tor Service welcher alle weiteren Daten die die App benötigt, über das Tor-Netzwerk abruft, für zusätzliche Privatsspähre aktiviert ihr diese Einstellungen

Erweiterte Einstellungen

Hier findet ihr weitere Einstellungen um die App nach euren Wünschen einzustellen. Ihr könnt z.B einen spezifischen Block Explorer auswählen, oder den Wechselkurs Anbieter spezifizieren. Desweiteren könnt ihr eure den Typ eurer Onchain Adresse festlegen und bestimmen, ob ihr via Segwit, Nativ Segwit oder gar Taproot empfangen wollt. Lasst die Einstellungen auf Native Segwit falls ihr euch nicht sicher seid.

Gebührenlimit für Lightning Zahlungen

Hier legt hier fest, wieviel ihr maximal für eine Lightning Transaktion bezahlen wollt. Verringert ihr diesen Wert, stehen der Zahlung weniger Routen zur Verfügung, da teure Routen nicht benutzt werden. Ein Wert zwischen 0.1 und max 0.5 ist akzeptabel.

Sicherheit

Legt eine biometrische Authentifzierung fest oder durchmischt die PIN Eingabe. Das ist sinnvoll, da es damit deutlich schwerer wird, den PIN durch beobachten herauszufinden.

Der Stealthmodus ist besonders interresant. Aktiviert ihr diesen, gibt sich die App als Taschenrechner aus. ihr müsst dann, um Zugang zu eurer App zu erhalten, eine bestimmte Rechnung ausführen. Somit erkennt niemand, der euer Smartphone entwedet hat, oder euer Bildschirm nicht gesperrt war, dass ihr eine Bitcoin App installiert habt.

Zahlen und Empfangen

Auf dem Hauptbildschirm findet ihr die beiden Buttons Senden und Empfangen. Wichtig zu wissen ist, dass ihr für beide Zwecke jeweils Onchain, und Offchain, also Lightning und direkte Bitcoinzalungen als Transaktionsmethode zur Verfügung habt. Dies könnt ihr direkt danach auswählen.

Senden von Zahlungen

Die Anwendung ist einfach, fügt eine Bitcoin Adresse, eine Lightning Adresse oder eine Lightning Invoice ein und die App erkennt automatisch ob es sich um eine Bitcoin Onchain oder um eine Lightning Zahlung handelt. Mit dem QR Scan Button auf dem Hauptbildschirm könnt ihr Zahlungsinformationen auch direkt einscannen. Bei Onchain Zahlungen könnten ihr zwischen Presets auswählen (schnell, mittel oder langsam) oder ihr legt eine individuelle Gebühr für die Transaktion fest.

Ihr könnt auch festlegen, dass der Betrag in eurer konfigurierten Währung angezeigt wird, um den aktuellen Wert überprüfen zu können und um die Umrechnung zu erleichtern. Zahlt ihr in Lightning, sind die Gebühren abhängig der Routen, die Verfügbar sind, um die Zahlungen durch das Netzwerk zu leiten, und betragen meisst ein Bruchteil der Onchain Gebühren.

Empfangen von Zahlungen

Wählt dazu einfach den Button Empfangen aus. Onchain Zahlungen zu empfangen ist selbsterklärend. Sendet eurem Gegenüber einfach die generierte Onchain Adresse und wartet bis die Zahlung eingegangen ist.

Lightning Zahlungen zu empfangen ist schon etwas komplizierter. Ihr müsst sogenannte Invoices Erstellung, als quasi Rechnungen die bezalt werden müssen. Vorrausetzung dafür ist, dass eure Lightning Node über Inbound Liquidität verfügt. Habt ihr andere Nodes die Kanäle zu euch geöffnet haben, könnt ihr Lightning Invoices erstellen. Das ist auch eigentlich garnicht so schwer: Betrag eingeben, Rechnungstitel erstellen, fertig. Den QR Code oder die Invoice könnt ihr via Copy & Paste an euer Gegenüber verschicken.

Weitere Hinweise zur Nutzung von Lightning bzw Bitbanana

• Achtet im allgemeinen darauf, nicht zuviele Funds auf eurer Lightning Wallet zu halten, der allgemeine Ratschlag: nur soviel drauf zu haben, wie ihr in eurem Portmonai mit euch rumtragen würdet, ist auch hier sinnvoll.
• Achtet darauf einen starken, 6-stelligen Pin zu verwenden und die PIN Eingabe zu vermischen.
• Verbindet wenn möglich, nur ein Node mit eurem Smartphone
• Achtet darauf dass die Node stabil läuft und immer erreichbar ist, ansonsten könnt ihr mit der App kaum etwas anfangen, wenn im gloreichen Moment, etwas in Bitcoin zu bezahlen, die Node ne Pause macht.
• Wollt ihr Lightning Zahlungen empfangen, benötigt ihr dafür wie beschrieben Inbound Liquidität, also Kanäle, die bereits etwas Zahlungen getätigt haben, und nicht mit komplett voll sind.

Wir haben nun dazu das wichtigste hinter uns, und die App ist nach euren Bedürfnissen eingerichtet. Mit der App seid ihr nun gerüstet, direkt von eurer Node aus, Zahlungen in Bitcoin und Lightning zu tätigen.

Fazit

Die Bitbanana-App ist eine praktische Lösung ist, um von unterwegs aus sicher und effizient auf eine eigene Full Node oder Lightning Node zuzugreifen. Die Verbindung über QR-Codes macht den Prozess einfach, und durch nützliche Features wie den integrierten Tor-Service, die Unterstützung von Onchain- und Lightning-Zahlungen sowie umfassende Sicherheitseinstellungen ist die App gut für den mobilen Einsatz geeignet. Die Anpassungsmöglichkeiten bieten Flexibilität, während die zusätzlichen Sicherheitseinstellungen wie PIN-Schutz und Stealth-Modus für Datenschutz sorgen. Insgesamt ist Bitbanana ein leistungsstarkes Werkzeug für jeden, der unterwegs Bitcoin oder Lightning-Zahlungen verwalten möchte.

The post Bitcoin Full Node mit Smartphone verbinden mit Bitbanana appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitungen

Für das Backup benötigt Ihr eine ausreichen grossen Datenträger oder eine NAS die Verbindung zur Node hat. Wichtig ist, dass wir nicht einfach die Blockchain kopieren, sondern rsync dafür verwenden. Dies stellt sicher das alle Berechtigungen und Besitzertüme beim kopieren genau so bleiben wie sie sind. Stellt also sicher dass auf auf der der Node und auf dem Zielgerät rsync installiert ist. Für Windows Computer gibt es dafür das Tool Delta Copy.

Stellt sicher dass auf Eurem Linux Zielrechner wie ein Linux Computer ein SSH-Server installiert ist, und dieser via SSH erreichbar ist. Auf dem Windowsrechner machen wir es später jedoch ohne SSH weil dass nicht immer funktioniert.

Der Befehl zur Installation eines SSH-Servers wäre:

sudo apt install openssh-server

Eine Konfiguration ist nicht weiter notwendig. Stellt einfach sicher das Port 22 auf Eurem Linux Client offen ist.

Erstellt auf den Zielgeräten einen Ordner der für das aufbewahren benutzt werden soll. Auf der einer Synology kann das z.B ein neuer gemeinsamer Ordner sein. Stellt sicher das Rsync auf der Eurer NAS bzw auf Eurer Synology aktiviert ist.

Beim Windows Client müsst Ihr ebenfalls einen Ordner für den Empfang eingerichtet und freigegeben werden. Hier müssen wir Delta Copy wie in diesem Beitrag hier eingerichtet haben. Die Rsync Einrichtung auf einem Linux Client ist hier nicht nötig!

Ob Rsync auf Eurem Linux Geräten, bzw der Node installiert ist, könnt Ihr mit rsync --version überprüfen. Falls nichts vorhanden, installiert es einfach mit:

apt install rsync

Umbrel Fullnode Blockchain sichern

Loggt Euch zuerst via SSH auf der Umbrel ein. Checkt nochmals ob rsync installiert ist. Wenn ja kann es bereits gleich losgehen.

Auf NAS sichern

Der Ordner auf der NAS muss exisiteren, und eine SSH Verbindung zum Ziel muss eingerichtet sein. Auf der Umbrel ist der Pfad zur Blockchain /root/umbrel/app-data/bitcoin/data/bitcoin/
Dort sind die 3 Ordner blockchain, chainstate und indexes gespeichert. Diese 3 Ordner müssen wir sichern.
Auf der Synology NAS wäre der Ziel Ordner unter /volume1/backups/blockchain/umbrel/ zu finden. Die Befehle wäre also:

rsync -avz --info=progress2 --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/blockchain  benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

rsync -avz --info=progress2 --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/chainstate  benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

und

rsync -avz --info=progress2 --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/indexes benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

Ihr könnt das ganze zuerst mal testen indem Ihr eine kleine Datei wie die debug.log auf den Zielrechner schiebt.

Auf einer externen Platte auf einem Linux Client sichern

Der Befehl ist der gleiche, der Zielort muss leicht angepasst werden. Schaut in der Konsole wie z.B ein externer Datenträger eingebunden worden ist mit dem Befehl lsblk

Ihr seht dass der USB Stick als sda1 zu finden ist, und unter /media/mario/stickbezeichnung gemounted wurden ist. Nehmen wir an auf dem USB Stick wäre noch der Ordner umbrel auf dem Ihr die Daten sichern wollt, dann währe der Pfad zum Ordner /media/mario/stickbezeichnung/umbrel/

Dementsprechend passt Ihr den Befehl an mit dem Benutzernamen und der IP Adresse des Linux Rechners:

rsync -avz --info=progress2 --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/ordnername mario@192.168.1.84:/media/mario/7E2D368C6FFFE5CF/umbrel/

Nun müsst Ihr wieder Ordnername mit den 3 Ordner blockchain, indexes und chainstate ersetzen und könnt die Ordner direkt auf eine externe Festplatte sichern.

Auf einer externen Platte mit Windows Betriebssystem sichern

Windows SSH Server ist nicht wirklich zuverlässig, deshalb erledigen wir dass mit einen Rsync Server den wir direkt ansprechen. Wir müssen wie in den Vorbereitungen bereits angesprochen DeltaCopy installieren. Wir erstellen auf DeltaCopy Server ein neues Modul mit dem namen blockchain, und setzen den Pfad auf den externen Datenträger

Dazu müsst Ihr einfach nur Add New Directory auswählen und mit Browse den Pfad angeben. Stellt sicher das der Rsync Server läuft und die Ampel auf grün zeigt. Ausserdem muss auf Eurem Windowsrechner der Rsync TCP Port 873 offen sein.

Danach sprecht Ihr das Ziel nicht mit einem Pfad an, sondern mit dem Modulnamen, in unserem Falle blockchain.

rsync -avz --info=progress2 --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/ordnername 192.168.1.75::blockchain

RaspiBlitz Fullnode Blockchain sichern

Die Befehle sind alle gleich, ausser dass die Blockchain woanders zu finden ist. Der Pfad für die Blockchain auf dem Raspi ist: /mnt/hdd/bitcoin/

Die Ordner heissen hier: blocks, chainstate und indexes.

Die Befehle sind also nur bzgl des Quellpfades anzupassen, z.B für die Sicherung auf die NAS:

rsync -avz --info=progress2 --append-verify /mnt/hdd/bitcoin/blocks  benutzername@172.16.0.54:/volume1/backups/blockchain/raspi/

Bitte Zielordner dann halt ensprechend mit raspi oder so abändern.

Wiederherstellen der Blockchain auf Fullnodes

Habt Ihr Eure Fullnode verkonfiguriert, oder habt eine neue, könnt Ihr nun die Blockchains auf die jeweiligen Geräte ziehen.

Wichtig dabei ist, dass die Geräte nicht syncen währen der Übertragung. Der bitcoind.service muss also kurz angehalten werden.

Unterm Raspi ist das relativ einfach. Ihr richtet das Gerät ein bzw installiert RaspiBlitz, und lasst ihn kurz in Ruhe damit alle nötigen Ordner erstellt werden können. Danach stopt ihr die synchronisation mit:

sudo systemctl stop bitcoind.service

Sobald Ihr alle Daten wieder rüber habt. Könnt Ihr den Service mit

sudo systemctl start bitcoind.service 

wieder starten.

Auf dem Umbrel müsst Ihr kurz den Docker-Container stoppen. Der Container heisst normalerweise lncm/bitcoind:v25.1

Checkt kurz mit docker ps wie der container bei Euch heisst. Ihr erkennt in an der Bitcoin Core Versionsnummer, hier in meinem Falle 25.1

Stoppt den Container mit:

docker stop bitcoin_bitcoind_1

und startet Ihn wieder mit:

docker start bitcoin_bitcoind_1

Sobald die Übertragung aller Ordner fertig ist.

Die Daten von der NAS oder vom Linux Backup ziehen

Ihr müsst Euch nun vom jeweiligen Gerät arbeiten. Also entweder auf der Umbrel oder auf dem Blitz. Der Rsync Befehl ist nun umgekehrt:

rsync -avz --info=progress2 --append-verify benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/blockchain /root/umbrel/app-data/bitcoin/data/bitcoin/blockchain

oder für den Raspi:

rsync -avz --info=progress2 --append-verify benutzername@172.16.0.54:/volume1/backups/blockchain/raspi/blocks /mnt/hdd/bitcoin/blocks

Daten von Windows Rsync Modul ziehen

Beim Windows Rsync Server müssen wir uns einfach auf das Modul beiziehen. Gebt Modulname und Pfad zum Ordner an, also Beispielsweise für die Umbrel:

rsync -avz --info=progress2 --append-verify 192.168.1.75::modulname/umbrel/blockchain /root/umbrel/app-data/bitcoin/data/bitcoin/blockchain

Auf dem Raspi ist der Pfad und der Ordnername blocks entsprechend anzupassen.

Danach könnt Ihr die Services wieder starten und kurz abwarten bis die Node die Daten gecheckt hat. Auf dem Umbrel geht das meisst ganz fix. Der Raspi benötigt allgemein etwas länger. Falls es Probleme auf dem Raspi gibt, checkt die logs mit:

sudo tail -f /mnt/hdd/bitcoin/debug.log

Hat der Raspi die Blockchain korrekt geladen, dürfen keine Blockchain Fehler auftreten und die Syncro muss normal weiter gehen:

Die Sicherungen automatisieren

Wenn Ihr wollt, könnt Ihr das ganze auch automatisieren. Führt Ihr rsync via SSH aus, dann müsst Ihr natürlich ein Passwort eingeben. Das funktioniert natürlich nicht wenn das alles automatisch ablaufen soll. Deshalb kann sich der Quellrechner via SSH-ID beim Zielrechner authentifzieren. Das geht mit ssh-copy-id

Loggt auf auf Eurer Node ein. Führt den folgenden Befehl aus:

ssh-copy-id benutzername@IPdesBackupsServers

und gebt Euer Passwort des Zielrechners ein. Danach liegt der öffentliche Schlüssel der Fullnode auf dem Zielrechner, und dieser muss sich von nun an nicht mehr mit einem Passwort authentifzieren, sondern tut das über SSH Schlüsselpaare. Damit ist die voraussetzung geschaffen um automatische Rsync Befehle über SSH zu ermöglichen.

Cronjob erstellen

Mit crontab -e erstellen wir einen neuen Cronjob. Richtet Ihr das erste mal ein, fragt Euch Crontab mit welchen Editor Ihr arbeiten wollt. Nehmt am besten immer Nano, also die Nummer eins.

Danach tragt Ihr am Ende der Datei folgendes ein:

0 1 1 * * rsync -avz --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/blockchain  benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

0 6 1 * * rsync -avz --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/indexes benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

0 8 1 * * rsync -avz --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/chainstate benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

Damit wird Beispielsweise immer am ersten des Monats um 01:00 der rsync Befehl ausgeführt. Gestartet wird mit dem Ordner blockchain, diesem geben wir 5 Std Zeit, danach indexes und 2 Stunden später chainstate. Passt den Befehl auf Eure Fullnode Betriebssystem und Euren Speicherort entsprechend an.

Damit sollte die Blockchain regelmässig gespeichert werden. Mehr als einmal im Monat ist in der regel nicht notwendig, dass könnt Ihr aber nach Euren Bedürfnissen anpassen.

Weitere wichtige Hinweise

Falls Daten bzw Ordner nicht übertragen werden, checkt Eure Firewall-Einstellungen und achtet darauf dass die jeweiligen Ports geöffnet sind.

Wichtig ist, dass das SSH Fenster, auf dem Ihr die Übertragungen startet, nicht geschlossen werden. Die Blockchain Sicherhung oder Übertragung kann bei ca 700GB je nach Netzwerkgeschwindigkeit mehrere Stunden gehen. In dieser Zeit darf der Rechner, mit dem Ihr Euch verbindet auf die Nodes verbindert, nicht schlafen geht! Schaltet also den Suspend bzw Schlafmodus des Rechners ab! Bricht die SSH Verbindung ab, bricht auch die Übertragung ab!

The post Bitcoin Blockchain mit Rsync sichern auf Umbrel & Raspi appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist RaspiBlitz

RaspiBlitz ist ein vielseitiges und leistungsfähiges Full Node Betriebssystem für Bitcoin-Enthusiasten, das auf dem beliebten und kostengünstigen Raspberry Pi basiert. Es ermöglicht es euch, eure eigene Bitcoin Full Node und Lightning Network Node zu betreiben, was für die Unterstützung der Dezentralisierung des Bitcoin-Netzwerks und die Teilnahme am Lightning Network, einer Skalierungslösung für schnellere und kostengünstigere Bitcoin-Transaktionen, wesentlich ist.

Der Hauptvorteil von RaspiBlitz liegt in seiner Open-Source-Natur. Dies bedeutet, dass der Quellcode für jedermann zugänglich ist, was Transparenz und Vertrauen in das System schafft. Nutzer können den Code einsehen, verstehen und bei Bedarf anpassen, was besonders für diejenigen interessant ist, die tiefere Einblicke in die technischen Aspekte von Bitcoin und dem Lightning Network gewinnen möchten. Die Community rund um RaspiBlitz ist sehr aktiv und unterstützend, was den Austausch von Wissen und Erfahrungen sowie die schnelle Behebung von Problemen fördert.

Vorteile von RaspiBlitz

1. Open-Source und Transparent: Da es sich um ein Open-Source-Projekt handelt, könnt ihr den Code überprüfen und gegenbefalls Änderungen selber vornehmen.
2. Anpassungsfähigkeit: RaspiBlitz bietet viele Konfigurationsoptionen und die Möglichkeit, zusätzliche Funktionen hinzuzufügen. Die Möglichkeiten verschiedenste Backups zu erstellen ist super, es gibt wirklich im Raspi CLI Menü alles man sich so vorstellen kann, grosses Lob!
3. Community-Unterstützung: Eine aktive Community bedeutet, dass Benutzer Hilfe und Ratschläge erhalten können. Für beinahe jedes Problem wird in Zusammenarbeit eine Lösung gefunden.
4. Kostengünstig: Es läuft auf dem auch auf dem 4er Raspberry Pi, welches eine relativ preiswerte Hardware ist.

Nachteile von RaspiBlitz

1. Technisches Know-how erforderlich: Die Einrichtung und Konfiguration können für weniger technisch versierte Benutzer herausfordernd sein.
2. Weniger benutzerfreundliche Schnittstelle: Die Benutzeroberfläche ist nicht so intuitiv wie einige andere Lösungen. Es gibt ein Web-UI und ein Konsolen-Menü für technischere Änderungen und Anpassungen.
3. Hardware-Beschränkungen: Die Leistung ist aufgrund der Beschränkungen des Raspberry Pi begrenzt.
4. nicht 100% Stabil - betrifft hauptsächlich Installationen auf einen Pi4 mit nur 4GB RAM und sobald viele weitere Apps parallel dazu laufen.

Was ist Umbrel

Umbrel ist eine Softwareplattform, die es euch ebenso ermöglicht, einfach euren eigenen Server für Bitcoin- und Lightning-Netzwerk-Dienste zu betreiben. Sie zeichnet sich durch eine benutzerfreundliche Oberfläche aus, die auch für Nicht-Techniker geeignet ist, und ermöglicht es Nutzern, einen Bitcoin Full Node und einen Lightning Network Node zu betreiben, was die Dezentralisierung und Sicherheit des Bitcoin-Netzwerks unterstützt. Umbrel gibt es als ARM Version für den Pi, und als x86 Version für grössere Server.

Die Installation ist zudem relativ einfach, für den Pi flasht man eine SD Karte mit einem entsprechenden Image, für einen Server gibt es einen Einzeiler den man einfach in die Konsole hauen kann.

Es ist jedoch wichtig zu wissen, dass Umbrel nicht vollständig Open-Source ist, was für Open-Source-Puristen ein Nachteil sein könnte. Dies bedeutet, dass nicht der gesamte Quellcode der Plattform für die öffentliche Überprüfung und Modifikation verfügbar ist. Diese Einschränkung kann für Nutzer, die großen Wert auf vollständige Transparenz und die Freiheit zur Anpassung ihrer Software legen, ein entscheidender Faktor sein. Umbrel richtet sich somit eher an Benutzer, die eine einfache und benutzerfreundliche Lösung für den Betrieb eines Bitcoin- und Lightning-Nodes suchen, ohne dabei den Anspruch auf vollständige Open-Source-Software zu haben.

Vorteile von Umbrel

1. Einfachheit und Benutzerfreundlichkeit: Die Einrichtung ist einfach und die Benutzeroberfläche ist intuitiv.
2. Plug-and-Play: Ideal für Benutzer, die eine einfach zu verwendende Lösung suchen.
3. Ästhetisch moderneres Design: Die Schnittstelle ist modern und ansprechend gestaltet.
4. Gute Dokumentation und Support: Umbrel bietet umfangreiche Hilfsmittel und eine aktive Community.
5. nahezu zu 100% stabil und sicher einsetzbar
6. Cross-Plattform kompatibel

Nachteile von Umbrel

1. Weniger Anpassungsmöglichkeiten: Es bietet nicht ansatzweise so viele Konfigurationsoptionen wie RaspiBlitz.
2. Geschlossene Komponenten: Einige Teile des Systems sind nicht Open-Source, was für Puristen ein Nachteil sein könnte.
3. Abhängigkeit vom Umbrel-Ökosystem: Nutzer sind stärker an die von Umbrel bereitgestellte Infrastruktur gebunden.
4. Privatsphäre etwas fragwürdig: Umbrel hat einige komische Angewohnheiten nicht genauer identifzierebare Services zu kontaktieren. Da die Verbindung SSL verschlüsselt ist, kann man nicht sagen was da übertragen wird. Es werden sicherlich keine Seeds oder Privatskeys übermittelt, wohleher handelt es sich dabe um Nutzerstatistiken. Mit tcpdump und enstsprechenden Server- oder Firewalleinstellungen kann man dem aber ein relativ schnelles Ende setzen.
5. Immer noch keine SSL/HTTPS: um Services von aussen über das Clearnet zu erreichen oder auch intern im LAN sicher zu nutzen. Tor funktioniert aber zuverlässig, wenn nicht immer super schnell.

Was ist bei Umbrel zu beachten

Im Kontext von Umbrel und dessen Open-Source-Status gibt es einige Aspekte zu beachten:

• Umbreld: Mit der Version 0.5.4 wurde ein neues Komponente namens umbreld eingeführt, das als Binärdatei verteilt und während der Installation heruntergeladen wird. Die Quellcodes für umbreld befinden sich im server-Unterverzeichnis des Umbrel GitHub-Repositorys. Es wurde angemerkt, dass der Entwicklungsprozess von Umbrel es schwierig macht, die Entwicklung zu verfolgen, da Änderungen in privaten Zweigen erfolgen und erst bei der Veröffentlichung einer neuen Version von Umbrel öffentlich gemacht werden​.
• Umbrel 1.10 ist praktisch nicht mehr anpassbar. Alle Änderungen werden bei Systemupdates komplett überschrieben. Das macht UmbrelOS starr und unflexibel. Eigene Scripte, oder eigene Anpassungen sind damit nur noch schwer möglich.

Diese Praxis hat zu Bedenken geführt, dass es für Außenstehende fast unmöglich ist, an der Entwicklung von Umbrel teilzunehmen oder diese sogar zu verfolgen. Technisch gesehen bleibt das Projekt zwar Open-Source, aber die Art und Weise, wie die Entwicklung gehandhabt wird, macht es schwierig, Einfluss auf die Änderungen zu nehmen oder diese zu kommentieren, bevor sie in den Master-Branch übernommen werden.

• Erweiterte Konfigurationen sind ab 1.10 nur noch sehr eingeschränkt möglich. Umbrel bzw. die Bitcoin Komponenten laufen in eigenen Docker Containern. Das Betriebssystem ist ein eigens entwickelte Plattform auf denen praktisch keine alten Scripte mehr funktionieren. Das wiederum bedeutet das Anpassungen nicht so einfach zu tätigen sind. .

Die unzählige Auswahl an zusätzlichen Programmen bei Umbrel - ein Problem?

Die Integration von Drittanbieter-Apps in ein Full-Node-System wie Umbrel eröffnet eine breite Palette von Möglichkeiten, birgt jedoch auch bestimmte Risiken und wirft Fragen bezüglich des eigentlichen Zwecks einer Full Node auf.

Aus Sicht der Sicherheit: Das Hinzufügen zusätzlicher Apps zu einer Bitcoin Full Node kann die Sicherheit des Systems beeinträchtigen. Jede zusätzliche Software, insbesondere wenn sie von Drittanbietern stammt, kann potenzielle Sicherheitslücken mit sich bringen. Diese Schwachstellen könnten von Angreifern ausgenutzt werden, um Zugang zum Node oder zu sensiblen Informationen zu erlangen. Auch wenn Umbrel darauf abzielt, die Sicherheit der angebotenen Apps zu gewährleisten, erhöht jede zusätzliche App die Angriffsfläche und kann die Integrität des Gesamtsystems gefährden.

Darüber hinaus kann die Installation nicht-essentieller Software die Leistung der Full Node beeinträchtigen. Full Nodes erfordern eine bestimmte Menge an Ressourcen, um effizient zu funktionieren. Zusätzliche Anwendungen können die verfügbaren Ressourcen beanspruchen und dadurch die Hauptfunktionen der Node – die Verifizierung von Transaktionen und die Aufrechterhaltung des Netzwerks – beeinträchtigen.

Aus der Perspektive der Zweckbestimmung: Eine Bitcoin Full Node hat einen spezifischen Zweck: Sie dient der Unterstützung des Bitcoin-Netzwerks durch die Verifizierung von Transaktionen und Blöcken. Indem sie eine Kopie der gesamten Blockchain hält und neue Transaktionen unabhängig validiert, trägt sie zur Dezentralisierung und Sicherheit des Netzwerks bei. Die Installation von zusätzlichen Apps, die nicht direkt mit Bitcoin in Verbindung stehen, kann von diesem primären Ziel ablenken.

Ich argumentiere, dass eine Full Node ausschließlich für Bitcoin-bezogene Aktivitäten genutzt werden sollte, um die Sicherheit und die ununterbrochene Funktionalität des Netzwerks zu gewährleisten. Die Hinzufügung von Nicht-Bitcoin-Software kann als Ablenkung von diesem Ziel angesehen werden und möglicherweise die philosophischen Grundsätze, auf denen die Idee eines dezentralisierten, unabhängigen Netzwerks basiert, untergraben. Eine Nextcloud beispielsweise gehört schlicht und einfach nicht auf eine Bitcoin Fullnode!

Was gilt es bei Raspiblitz zu beachten

Auch bei RaspiBlitz gibt es einiges zu beachten. Das wichtigste vorerst.

Systemstabilität: Die Software läuft nicht zu 100% stabil. Es gibt ab und an mal Abstürze, vor allem wenn viele zusätzliche Komponenten wie Electrum, ein eigener Mempool, oder BTC Pay installiert sind. Auf dem Raspiblitz Telegram Kanal gibt es immer mal wieder User, deren Node hängen geblieben ist, die Laufwerke nicht mehr erkannt werden, oder gar das ganze System wegstirbt. Ich möchte dies einfach der Vorsicht halber erwähnen da dies bei schlechter Vorbereitung zu finanziellem Schaden führen kann, wurde die Node vorher nicht entsprechend gesichert. Ihr geht es vor allem um die Sicherung der Lightning Kanäle. Wer kein Lightning betreibt, muss nur seine Seedphrase sichern, und hat auch nach einer Neu-Installation sofort wieder Zugriff auf seine Funds.

Konfigurierbarkeit: Raspiblitz ist aber, da es nicht in Docker Containern läuft, vollständig und relativ einfach anpassbar. Alle Konfigurationen sind einfach zugänglich und erreichbar. Das bietet sich vor allem für diejenigen an, die gerne die komplette Konfiguration selber vornehmen und anpassen wollen. Jedoch sei hier gesagt, es muss natürlich das technische Verständnis dafür vorhanden sein.

Fazit

Die Wahl zwischen RaspiBlitz und Umbrel hängt also stark von den individuellen Bedürfnissen und technischen Fähigkeiten eurerseits ab. Die Wahl ergibt sich somit aus den eigenen indivduellen Interessen und der eigenen Anforderungen an die Fullnode. RaspiBlitz ist ideal für diejenigen, die eine anpassbare, Open-Source-Lösung mit starker Community-Unterstützung suchen. Umbrel hingegen eignet sich besser für Benutzer, die Wert auf Benutzerfreundlichkeit, einfache Einrichtung und ein modernes Interface legen. Umbrel ist quasi run and forget.

Ein weitere Punkt ist die Zuverlässigkeit. Umbrel ist, dass muss man einfach sagen, zu fast 100% zuverlässig. Die Node läuft jetzt seit über 4 Jahren und hatte bis jetzt, keinen einzigen Ausfall. Lightning Node Betreiber sollten auf dem Raspiblitz zusätzliche Sicherheitsmassnahmen betreiben, um sich gegen einen Ausfall seiner Lightning Kanäle abzusichern.

Beide Systeme werden aber kontinuierlich weiterentwickelt werden, und was heute ein Nachteil sein könnte, kann in Zukunft verbessert werden. Die Raspiblitz Community ist gross und unheimlich hilfsbereit. Die Wahl sollte also auch unter Berücksichtigung der langfristigen Ziele und der Bereitschaft zur Auseinandersetzung mit technischen Herausforderungen getroffen werden.

The post RaspiBlitz VS Umbrel - welches von beiden? appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist ein Watchtower

Ein Watchtower ist im Grunde genommen ein Netzwerkknoten, der dazu dient, das Lightning-Netzwerk zu überwachen und sicherzustellen, dass alle Teilnehmer ehrlich agieren. Da Transaktionen im Lightning-Netzwerk off-chain durchgeführt werden, besteht die Möglichkeit, dass eine der Parteien versucht, eine alte Transaktion zu veröffentlichen, um betrügerisch mehr Bitcoins zu erhalten, als sie sollte. Der Watchtower stellt sicher, dass dies nicht geschieht.

Technische Erklärung

1. Zustandskanäle: Lightning-Netzwerktransaktionen verwenden "Zustandskanäle". Dies bedeutet, dass nur die Eröffnung und Schließung eines Kanals auf der Haupt-Blockchain veröffentlicht werden, während alle anderen Transaktionen off-chain und privat zwischen den beiden Parteien stattfinden.
2. Betrugsszenario: Wenn eine Partei versucht, eine alte Transaktion zu veröffentlichen, um betrügerisch mehr Geld zu erhalten, wird dies als "Betrugsversuch" bezeichnet.
3. Rolle des Watchtowers: Ein Watchtower speichert verschlüsselte Zustandsupdates von Kanälen. Er kennt jedoch den tatsächlichen Inhalt dieser Updates nicht und kann sie daher nicht entschlüsseln. Trotzdem kann er feststellen, wenn eine alte Transaktion auf der Blockchain veröffentlicht wird.
4. Reaktion auf Betrug: Sobald der Watchtower einen Betrugsversuch erkennt, kann er eine Straftransaktion auslösen. Diese Straftransaktion stellt sicher, dass der betrügerische Teilnehmer seine gesamten im Kanal gehaltenen Mittel verliert. Das bedeutet, dass der Betrug nicht nur verhindert wird, sondern die betrügerische Partei auch finanziell bestraft wird.

Nutzen

1. Sicherheit: Watchtowers erhöhen die Sicherheit im Lightning-Netzwerk, indem sie betrügerische Aktionen verhindern.
2. Vertrauen: Mit Watchtowers können Nutzer des Lightning-Netzwerks sicher sein, dass ihre Transaktionen geschützt sind, auch wenn sie nicht ständig online sind.
3. Skalierbarkeit: Da Watchtowers nur dann eingreifen, wenn ein Betrug erkannt wird, reduzieren sie die Notwendigkeit für alle Teilnehmer, ständig alle Transaktionen zu überwachen. Dies erleichtert die Skalierung des Netzwerks.
4. Förderung der Ehrlichkeit: Die Existenz von Watchtowers stellt eine Abschreckung für potenzielle Betrüger dar, da das Risiko, alle Mittel zu verlieren, hoch ist.

Vorausetzungen auf der Umbrel Node

Die Umbrel Node sollte auf dem aktuellsten Stand sein und die Lightning Wallet eingerichtet sein. Es benötigt keine Portweiterleitungen da der Watchtower über das Tor Netzwerk agiert. Es müssen natürlich Kanäle vorhanden sein die der Watchtower überwachen kann, ansonsten nützt das Tool nicht viel.

Einrichtung des Watchtowers auf der Umbrel Node

Öffnet Eure Lightning Node und klickt oben rechts auf die 3 Punkte und öffnet die Advanced Settings. Navigiert zum Eintrag Watchtower und öffnet die Einstellungen in dem Ihr darauf klickt.

Aktiviert den Watchtower Service. Im Unteren Feld findet Ihr die Adresse Eures Watchtowers. Dies ist die Serveradresse falls Ihr auf die Lightning Node aufpassen möchtet. Bitte stellt sicher dass Eure Lightning Node auch immer verfügbar ist, und eine aussreichen hohe Onlinezeit hat damit Ihr Euren Job als Aufpasser auch wahrnehmen könnt.

Weiter unten finden wir den Watchtower Client. Diese funktioniert ermöglich uns, dass wir jemandens Node hinzufügen können, damit diese wie oben beschrieben auf unsere Node aufpasst, sollte diese mal Offline gehen. Damit wird verhindert dass ein Betrüger einen alten Chainstate veröffentlich und Eure Node dagegen nicht Einspruch erheben kann da diese Offline ist.

Wir fügen in das Feld die URI unser gewünschten Partners ein der auf uns aufpassen soll. Bitte stellt sicher dass Ihr wenn möglich die Node von jemanden nehmt, den Ihr kennt und vertraut. Die Auswahl im Internet ist nicht so gross, und nehmt bitte nicht irgendeinen Watchtower den Ihr auf einer dubiosen Seite ausgegraben habt. Gerne dürft Ihr hier den Watchtower von uns eintragen. Die Adresse wäre:

0214365a2cf18a3f84c421c648d03bedb021ff74afb95cc7ea0cbbf23b976d1033@yreb4gbnfi5ewbibvpxm2sjdndcsicvwlua2ncjlad2f6h7vgf7eehid.onion:9911

Fügt die Adresse hinzu und klickt auf ADD. Danach könnt Ihr herunterscrollen und auf Save and Restart Node klicken.

Der Watchtower ist bereits eingerichtet und die von Euch eingetragene Node passt nun auf Eure Kanäle auf

Raspiblitz Watchtower Server und Client einrichten

Die Einrichtung auf dem Blitz ist nicht ganz so einfach wie auf der Umbrel Node, aber trotzdem machbar. Stellt zuerst sicher dass Ihr auf der neusten Version 1.9.0 seid und ebenfalls die neusten Lightning Version 16.4-beta installiert ist.

gebt menu ein und stellt sicher dass die Node auf dem aktuellsten Stand ist:

Loggt Euch per SSH auf Eurem Blitz ein:

ssh admin@interneIP

Watchtower Tor Konfiguration

Wir möchten dass der Watchtower über Tor kommunziert genau wie bei der Umbrel Node. Dazu müssen wir die Ports für den Watchtower in die Tor Konfiguration des Systems eingeben. Öffnet die Datei torrc mit

nano /etc/tor/torrc

Fügt am Ende der Datei die folgenden Zeilen hinzu:

# Hidden Service for incoming LND WatchTower connections
HiddenServiceDir /mnt/hdd/tor/lndWT9911
HiddenServicePort 9911 127.0.0.1:9911

LND Konfiguration anpassen

Öffnet die LND Konfiguration mit

sudo nano /mnt/hdd/lnd/lnd.conf

und fügt den folgenden Inhalt am Ende der Datei ein:

[Watchtower]
watchtower.active=1

[Wtclient]
wtclient.active=1

startet kurz den LND Service neu mit

sudo systemctl restart lnd.service

Watchtower hinzufügen

stellt sicher dass Ihr nicht als Sudo user eingeloggt sein. die Befehle für Lightning Node müssen als admin ausgeführt werden. Mit wtclient add können wir einen Watchtower nun hinzufügen. Das wäre also:

lncli wtclient add 0214365a2cf18a3f84c421c648d03bedb021ff74afb95cc7ea0cbbf23b976d1033@yreb4gbnfi5ewbibvpxm2sjdndcsicvwlua2ncjlad2f6h7vgf7eehid.onion:9911

Ihr könnt hier auch gerne die Adresse meiner Node verwenden. Startet die LND Node erneut neu mit:

sudo systemctl restart lnd.service

Mit dem Befehl lncli wtclient towers könnt Ihr überprüfen ob der Watchtower erfolgreich hinzugefügt worden ist:

Der Watchtower der auf uns aufgpasst wurde erfolgreich hinzugefügt.

Debugging

Mit dem folgenden Befehl könnt Ihr schauen ob der Watchtower erfolgreich kontaktiert wird:

sudo tail -f -n 10000 /mnt/hdd/lnd/logs/bitcoin/mainnet/lnd.log | grep WTCL

Der Watchtower wird kontaktiert. Es gibt aber bei mir nichts zu syncen der der RaspiBlitz bei mir nur zu Testzwecken läuft.

Raspiblitz als Watchtower

Die Grundlegende Einrichtung ist bereits durchgeführt. Damit Ihr die Adresse der RaspiBlitz Node herausfinden könnt, könnt Ihr folgenden Befehle eingeben

sudo cat /mnt/hdd/tor/lndWT9911/hostname = hostname, also die Hostadresse der Node inklusive Port, &
lncli tower info = der pubkey der Node

Zusammen wäre das also die Adresse, die Ihr bei anderen Nodes als Watchtower hinzufügen könnt.

Debugging

Mit folgenden Befehl könnt Ihr schauen ob Euer Watchtower auf andere aufpasst:

sudo tail -f -n 10000 /mnt/hdd/lnd/logs/bitcoin/mainnet/lnd.log | grep WTWR

Weitere Befehle für den RaspiBlitz Watchtower

• lncli wtclient -h - listet alle watchtower Client Befehle auf
  NAME:
  lncli wtclient - Grundbefehl
• Anwendung:
  lncli wtclient Befehl
• Befehle:
  add - neuen Watchtower hinzufügen
  remove - Watchtower entfernen
  towers - zeigt Informationen über alle registrierten Watchtower
  tower - zeigt informationen über einen bestimmten Watchtower
  stats - zeigt die aktuellen Informationen zu dem Watchtower an
  policy - zeigt die Regeln der aktiven Watchtower Verbindung an
• OPTIONS:
  --help, -h (Hilfe Anzeigen)

Beispiel: mit

lncli wtclient remove 0214365a2cf18a3f84c421c648d03bedb021ff74afb95cc7ea0cbbf23b976d1033@yreb4gbnfi5ewbibvpxm2sjdndcsicvwlua2ncjlad2f6h7vgf7eehid.onion:9911

könnt Ihr den hinzugefügten Watchtower wieder entfernen

Liste Öffentliche Watchtower

Öffentliche Watchtower sind aktuell etwas schwer zu finden. Zudem stellt sich die Frage ob man irgend einer fremden Node vertrauen soll, schliesslich soll sie verhindern dass mit Euren Kanälen Unfug angestellt wird. Das ist kaum möglich wenn eine Node ständig offline ist oder irgendwann wieder vom Netz ist. Deswegen ist es auf jedenfall sinnvoll mehrere Watchtower in Eure Node einzutragen. Fällt ein Watchtower aus, verbindet sich die Node nach einiger Zeit mit einer weiteren, die Ihr angegeben habt.

Eine Liste öffentlicher Watchtower gibt es hier in einem GitHub-Thread . Ausserdem könnt Ihr im Blocktrainer Forum sicher auch Leute finden oder Ihr fragt in den Telegram Kanälen von Umbrel oder RaspiBlitz German.

Das wärs auch schon mit dem Artikel Umbrel und RaspiBlitz Lightning Watchtower einrichten. Ich hoffe Ihr konntet Euren Watchtower erfolgreich einrichten, habt Ihr Fragen, schreibt sie in die Kommentare!

The post Umbrel und RaspiBlitz Lightning Watchtower einrichten 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.

Mehr Information zu Sparrow findet ihr hier auf der Mainpage und den Download findet ihr hier.

Wie Ihr die Bitbox App mit Eurer Fullnode verbindet habt Ihr ja bereits in diesem Artikel erfahren. Nun geht es eben um die besagte Sparrow Wallet.

Voraussetzungen um eure Sparrow Wallet mit einer Bitcoin Umbrel Fullnode zu verbinden

Sind im Prinzip die selben, wie im Umbrel Bitbox Tutorial, nur braucht ihr für die Sparrow Wallet nicht den Torbrowser zu öffnen, da Sparrow einen eigenen Tor-Client integriert hat. Das funktioniert also auch ohne öffnen des Browsers.

Ausserdem muss eine Wallet bereits erstellt sein. Demnächst gibt es noch ein Tutorial wie das genau funktioniert.

Anleitung

Hollt euch wie im anderen Artikel erklärt, zuerst mal die Adresse eures Elektrum Servers, wie auch zuvor gilt hier: die Bitcoin Node muss synchronisert sein, und Elektrum muss fertig indexiert sein.

Öffnet dann die Sparrow App und begebt euch oben in der Arbeitsleiste auf File, danach auf Preferences und dann klickt ihr auf Server.

Erledigt die Einstellungen wie folgt: Private Electrum Server, URL ist die Adresse von eurem Elektrum Server, der Port ist 50001, der Proxy muss aktiviert sein, Zugang ist localhost auf Port 9050

Danach könnt ihr die Verbindung testen. Hat alles geklappt, bekommt die Meldung dass ihr mit eurem Elektrum Server verbunden seid. Das wars auch schon!

Nun seid ihr vollständig mit eurer eigenen Fullnode verbunden, und keiner, ausser euch, hat die vollständige Kontrolle und Einsicht über eure Transaktionen, Kontostände und etc. eurer Kontostand wird direkt aus der Blockchain geladen und verifziert, das bekommt kein Mensch mit. Habt ihr noch keine eigene Bitcoin Fullnode? Schaut bei uns im Shop vorbei: Deine eigene Bitcoin Fullnode.

Ich hoffe euch mit dem Tutorial den Umgang mit Bitcoin und Co etwas erleichtert zu haben. Falls ihr Fragen habt, schreibt sie in die Kommentare!

The post Sparrow Wallet mit Umbrel Bitcoin Fullnode verbinden appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorteile die Bitbox02 mit deiner eigenen Umbrel Bitcoin Full zu verbinden

• Privatsphäre: Wenn ihr eure BitBox02 mit einer öffentlichen Node (z.B. der Standard-Einstellung vieler Wallets) verwendet, könnten die Betreiber dieser Node theoretisch sehen, welche Adressen ihr abfragt und daraus Rückschlüsse auf euren Kontostand und eure Transaktionen ziehen. Mit einer eigenen Full Node bleiben diese Informationen privat.
• Sicherheit: Eine eigene Full Node überprüft jede Transaktion und jeden Block gegen die Konsensregeln von Bitcoin. Das bedeutet, ihr müsst euch nicht auf Dritte verlassen, um sicherzustellen, dass eure Transaktionen legitim sind.
• Souveränität: Mit einer eigenen Full Node habt ihr die vollständige Kontrolle über eure Transaktionen. Ihr seid nicht von Drittanbietern abhängig, die den Dienst einschränken, ändern oder beenden könnten.
• Verbesserte Netzwerkgesundheit: Das Betreiben einer eigenen Full Node stärkt das dezentrale Netzwerk von Bitcoin. Je mehr unabhängige Knoten existieren, desto widerstandsfähiger wird das Netzwerk gegenüber Angriffen oder Versuchen der Zensur.
• Geringere Gebühren: Wenn ihr eine Full Node betreibt, könnt ihr besser einschätzen, welche Transaktionsgebühr für eure Transaktion angemessen ist, da Ihr das gesamte Netzwerk überblickt. So könntet Ihr eventuell Gebühren sparen.
• Aktualität: Ihr erhaltet Updates über das Bitcoin-Netzwerk in Echtzeit, ohne euch auf Dritte verlassen zu müssen.
• Unterstützung des Netzwerks: Indem ihr eine eigene Full Node betreibt, tragt Ihr dazu bei, das Bitcoin-Netzwerk sicher und dezentralisiert zu halten.

Wenn ihr euch für den Betrieb einer eigenen Full Node entscheidet, solltet Ihr jedoch auch den zusätzlichen Aufwand und die potenziellen Kosten für Hardware, Strom und Bandbreite berücksichtigen. Es ist auch wichtig sicherzustellen, dass eure Node korrekt konfiguriert ist, um eure Privatsphäre und Sicherheit zu maximieren.

Wir richten den Zugang über das LAN Netzwerk, aber auch über das Tor Netzwerk ein um von einem möglichst hohem Mass an Privatspähre zu profitieren. Das den LAN Zugang nutzt ihr zuhause, und den Tor Zugang wenn ihr unterwegs seid und euch nicht in eurem LAn befindet, in der die Full Node operiert.

Vorausetzungen um eure Bitbox02 mit einer Umbrel Bitcoin Fullnode zu verbinden

Eine voll funktionisfähige und fertig synchroniserte Umbrel Bitcoin Full Node. Um die Bitbox App zu verbinden, muss auch die Electrum App installiert sein, und der Electrum Server muss synchronisiert sein. Nach der Installation von Electrum kann es gut und gerne nochmals einen Tag gehen, bis der Server vollständig synchronisert, und bereit für Verbindungen ist. Falls Ihr noch keinen Electrum Server auf rurer Fullnode habt, installiert Euch Electrum (ElectRS) aus dem App Store.

Tor Konfiguration

Um euch mit dem Tor Netzwerk zu verbinden, müsst ihr Zugang zu Tor haben, das geht am einfachsten mit dem Tor Browser, sobald dieser verbunden ist, habt über den Port 9150 verbindung zum Tor Netzwerk. Startet Ihr die Bitbox App, muss der Tor Browser mit dem Internet verbunden sein. Installiert euch also zuerst den Tor Browser hier.

Danach könnt ihr in der Bitboxapp unter Einstellunge --> erweiterte Einstellungen die Verbindung zu einem Torproxy erlauben:

Gebt hier 127.0.0.1:9150 ein falls ihr den TorBrowser als Proxy verwendet.

Für Das Smartphone benötigt ihr die App Orbot, die euch den TorProxy zur Verfügung stellt.

Beim Smartphone mit Orbot verwendet ihr 127.0.0.1:9050

Für eine Verbindung über das eigene LAN Netzwerk, muss die Proxy Einstellung der Bitbox App deaktiviert sein!

Anleitung für die Verbindung

Im eigenen Netzwerk zuhause

Ruft ihr den Kontostand zuhause ab, empfiehlt es sich, direkt ohne Umwege über Tor mit der Node zu kommunizieren. Die Bitbox App auf dem Desktop sollte bestmöglichst so konfiguriert werden. Die Anfragen für den Kontostand verlassen somit euer Haus nicht.

TorProxy Settings in der Bitbox App sind auf aus. Danach wählt ihr eine eigene Node hinzufügen aus. Gebt hier die lokale IP Adresse der Umbrelnode ein gefolgt vom Port 50001:

Klickt danach auf Überprüfen, und wenn die Verbindung erfolgreich war, danach auf Hinzufügen.

Unterwegs für das Smartphone oder den Laptop über Tor

Loggt euch in das Webinterface eurer Umbrel Node ein. Geht auf euren Electrum Server. Klickt auf Tor und haltet euch die Adresse bereit.

Startet den Tor Browser und öffnet als nächstes die Bitbox App. Geht unten links auf die Einstellungen und klickt hier auf Tor Proxy aktivieren. Gebt die Adresse 127.0.0.1 ein und den Port 9150. Für das Smartphone und Orbot nehmt ihr den Port 9050!
Bestätigt und verlasst das Fenster. Geht als nächstes auf das Feld Eigene Fullnode verbinden

Fügt nun den Adresse vom Electrum Server hier bei host:port ein. Fügt am Ende den Port 50001 hinzu!

Klickt danach auf Überprüfen. Habt Ihr alles korrekt eingegeben, kommt die Meldung dass die Verbindung erfolgreich hergestellt worden ist. Falls nicht, stellt sicher dass der Torbrowser wirklich an ist, und mit dem Tor Netzwerk verbunden ist.

Abschluss

Ihr könnt nun die beiden Shiftcrypto Server entfernen. Die benötigen wir nicht mehr. Sollte etwas nicht klappen, können die Standardeinstellungen jederzeit mit der Option In Werkszustand zurücksetzen wieder hergestellt werden.

Fazit

Nun seid Ihr vollständig mit Eurer eigenen Fullnode verbunden, und keiner, ausser Euch, hat die vollständige Kontrolle über Eure Transaktionen, Kontostände und etc. Habt Ihr noch keine eigene Bitcoin Fullnode oder keine Bitbox02? Schaut bei uns im Shop vorbei: Deine eigene Bitcoin Fullnode & Bitbox02

Ich hoffe Euch mit dem Tutorial den Umgang mit Bitcoin und Co etwas erleichtert zu haben. Falls Ihr Fragen habt, schreibt sie in die Kommentare!

The post Bitbox02 mit Umbrel Bitcoin Fullnode verbinden appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Funktion einer Full Node im Bitcoin Netzwerk

Eine Node, oder Knotenpunkt, ist ein integraler Bestandteil des Bitcoin-Netzwerks. Die Knotenpunkte sind die "Arbeiter" des Netzwerks, die dafür verantwortlich sind, dass Transaktionen korrekt und sicher verlaufen. Es gibt verschiedene Arten von Knotenpunkten, aber im Folgenden konzentrieren wir uns auf die Funktionen einer Full Node im Bitcoin-Netzwerk.

• Validierung von Transaktionen und Blöcken: Eine der Hauptfunktionen einer Full Node besteht darin, alle Transaktionen und Blöcken zu validieren, die durch das Netzwerk laufen. Sie tut dies, indem sie jede Transaktion und jeden Block gegen die Regeln des Bitcoin-Protokolls prüft. Wenn eine Transaktion oder ein Block diesen Regeln nicht entspricht, lehnt die Node sie ab.
• Weiterleitung von Transaktionen und Blöcken: Sobald eine Transaktion oder ein Block validiert wurde, leitet die Node diese Information an andere Nodes im Netzwerk weiter. Dies stellt sicher, dass alle Nodes im Netzwerk immer über den aktuellen Stand der Blockchain informiert sind.
• Erhalt der Blockchain: Jede Full Node hält eine vollständige Kopie der Bitcoin-Blockchain. Dies stellt sicher, dass das Netzwerk nicht von einer zentralen Stelle abhängig ist und trägt zur Dezentralisierung und Sicherheit des Bitcoin-Netzwerks bei.
• Unterstützung des Netzwerks: Indem sie alle oben genannten Aufgaben ausführt, unterstützt jede Full Node das gesamte Bitcoin-Netzwerk. Je mehr Full Nodes es gibt, desto widerstandsfähiger wird das Netzwerk gegen Angriffe und Ausfälle.
• Teilnahme am Konsensprozess: Full Nodes tragen auch zum Konsensprozess bei, indem sie Transaktionen und Blöcke validieren und weiterleiten. Obwohl sie nicht direkt am Mining-Prozess beteiligt sind, tragen sie dennoch zur Einhaltung der Regeln des Bitcoin-Protokolls bei und helfen, das Netzwerk sicher zu halten.

Bitcoin Nodes sind also ein unerlässlicher Bestandteil des Bitcoin-Netzwerks. Sie tragen dazu bei, das Netzwerk sicher, stabil und dezentralisiert zu halten.

Warum eine eigene eine Bitcoin Full Node betreiben

Zu den Vorteilen des Betriebs einer Full Node gehören:

• Erhöhte Sicherheit: Ihr überprüft Transaktionen selbst, anstatt sich auf Dritte zu verlassen.
• Erhöhter Datenschutz: Eure Transaktionen werden direkt über Ihre Node gesendet, so dass niemand sonst diese Informationen sehen kann.
• Unterstützung des Netzwerks: Ihr helft, das Bitcoin-Netzwerk zu dezentralisieren und stärken es gegen Angriffe.
• Finanzielle Freiheit erlangen: ihr seid nicht auf externe Provider oder Dienstleister angewiesen

Benötigte Hardware

Die Anforderungen für den Betrieb einer Bitcoin Full Node sind relativ gering. Ihr benötigt:

• Einen Computer mit einer Internetverbindung: Dies kann ein spezialisierter Einplatinen-Computer wie ein Raspberry Pi, ein alter Laptop oder Desktop-PC sein. Wichtig ist, dass er ständig eingeschaltet und mit dem Internet verbunden sein muss.
• Eine Festplatte mit ausreichend Speicherplatz: Die gesamte Bitcoin-Blockchain nimmt derzeit mehr als 600GB Speicherplatz ein, und sie wächst ständig. Eine Festplatte mit 2TB Speicherplatz ist empfehlenswert. Aktuell empfehle ich Festplatten ab einer grösse von 2TB, die Blockchain ist zwar nur knapp 600GB gross, mit dem Betriebssystem drauf seid Ihr bereits aber über 750-800GB, (ohne eigenen Electrum Server) und bei der aktuellen Lage würde eine 1TB Platte nur noch ein paar Monate Jahre halten Stand 02.01.2025
• Eine stabile Internetverbindung: Eure Node muss in der Lage sein, ständig Transaktionen und Blöcke herunterzuladen und hochzuladen.

Full Node Betriebssysteme

Es gibt mehrere Betriebssysteme, die speziell für das Betreiben einer Bitcoin Full Node entwickelt wurden. Einige der beliebtesten sind:

• Umbrel: Umbrel ist ein einfaches und benutzerfreundliches System, das auf dem Raspberry Pi läuft. Es unterstützt sowohl Bitcoin Full Nodes als auch Lightning Nodes und bietet eine benutzerfreundliche Oberfläche zur Verwaltung eurer Node. Umbrel kann auch auf einem ausgewachsenem Server installiert werden. Raspiblitz ist leider nicht komplett Open Source.
• RaspiBlitz: RaspiBlitz ist eines der bekanntesten und vielseitigsten Open-Source-Projekte, welch es euch ermöglicht, eine Bitcoin und Lightning Node auf einem Raspberry Pi zu betreiben. Es ist etwas komplexer als Umbrel, bietet aber mehr Anpassungsmöglichkeiten. Raspiblitz kann auch auf einem Server betrieben werden.
• Ronin Dojo: Ronin Dojo ist speziell für das Samourai Wallet entwickelt und ermöglicht den Betrieb einer Bitcoin Full Node auf einer Vielzahl von Hardware. Es ist ideal für Benutzer, die ein hohes Maß an Datenschutz und Sicherheit suchen. Auf Ronin Dojo gibt es keine Lightning Node.
• Start9: Start9 ist ein auf Linux basierendes Betriebssystem, das speziell für den Betrieb eines persönlichen Servers entwickelt wurde. Es zielt darauf ab, die Privatsphäre und Datenhoheit zu stärken, indem es Nutzern ermöglicht, Dienste wie Bitcoin-Nodes, Nextcloud oder Matrix mit minimalem technischem Aufwand selbst zu hosten. Die Benutzeroberfläche ist intuitiv und für Nicht-Techniker optimiert, während gleichzeitig fortgeschrittene Konfigurationsmöglichkeiten für erfahrene Anwender zur Verfügung stehen. Es basiert auf Open-Source-Software und unterstützt eine breite Palette von Hardware, von Raspberry Pi bis zu leistungsstärkeren Servern.

Ein Vergleich zwischen Umbrel und Raspiblitz haben wir kürzlich erst hier gepostet: Umbrel VS Raspi

Was und wofür ist eine Lightning Node

Das Bitcoin Lightning Network ist ein sogenanntes "Second-Layer"-Protokoll, das auf der Bitcoin Blockchain aufbaut und dazu dient, Transaktionen schneller und kostengünstiger durchzuführen. Eine Lightning Node ist ein Knotenpunkt in diesem Netzwerk, der die Transaktionen abwickelt.

Anwendung einer Lightning Node

Die Hauptverwendung einer Lightning Node liegt in der Ausführung von Transaktionen. Im Lightning Network werden nicht alle Transaktionen direkt auf der Blockchain durchgeführt. Stattdessen könnt ihr sogenannte "Zahlungskanäle" eröffnen und mehrere Transaktionen durchführen, ohne dass jede einzelne Transaktion in der Blockchain erfasst wird.

Zahlungskanäle sind quasi private Straßen zwischen zwei Lightning Nodes. Wenn zwei Parteien häufig miteinander Transaktionen durchführen, können sie einen Zahlungskanal eröffnen. Innerhalb dieses Kanals können sie so viele Transaktionen durchführen, wie sie möchten, ohne dass Gebühren für jede einzelne Transaktion anfallen. Erst wenn der Kanal geschlossen wird, wird der finale Kontostand auf der Bitcoin Blockchain aktualisiert. Die Anzahlung Zahlungen ist nicht an die Blockzeit des Mainlayers gebunden. Ein Lightning Kanal kann theoretisch bis zu 1 Million Zahlungen pro Sekunde verarbeiten.

Lightning Nodes können auch dazu verwendet werden, Transaktionen für andere Benutzer im Netzwerk weiterzuleiten. In diesem Fall fungiert die Node als eine Art Zwischenstelle, die es ermöglicht, Zahlungen über mehrere Hops von Node zu Node zu senden, ähnlich wie Datenpakete im Internet. Solche Nodes sind auch als Routing Nodes bekannt, da nicht jeder zu jedem einen Kanal haben kann. Ihr verbindet euch also am besten zu einer grösseren Routing Node, welche die Zahlung dann durch ihre breite Verbindung zum Netzwerk an den entsprechenden Zielort weiterleitet.

Funktionsweise einer Lightning Node

Die Funktionsweise einer Lightning Node basiert auf der Idee der "Smart Contracts". Beim Eröffnen eines Zahlungskanals verpflichten sich beide Parteien auf eine bestimmte Menge an Bitcoin, die sie in den Kanal einbringen. Diese Verpflichtung wird auf der Blockchain verzeichnet.

Sobald der Kanal geöffnet ist, können die Parteien so viele Transaktionen durchführen, wie sie möchten, ohne dass diese auf der Blockchain aufgezeichnet werden. Stattdessen werden diese Transaktionen nur zwischen den beiden Parteien im Zahlungskanal aufgezeichnet.

Wenn eine Partei den Kanal schließen möchte, wird eine Abschlusstransaktion auf der Blockchain erstellt, die den endgültigen Kontostand der beiden Parteien widerspiegelt. Beide Parteien unterschreiben diese Transaktion mit ihren privaten Schlüsseln, und der Kanal wird geschlossen.

Die Nutzung des Lightning Networks und der Betrieb einer Lightning Node bieten eine Reihe von Vorteilen, darunter schnellere Transaktionen, geringere Gebühren und eine verbesserte Skalierbarkeit des Bitcoin-Netzwerks. Wer mehr über das Lightning Netzwerk und welche Apps dazu benötigt werden, der findet hier in diesem Artikel zusätzliche Infos.

Lightning für die ganze Familie oder gar einer kleinen Gemeinde

Mit Lightning und LNbits beispielsweise kann man tatsächlich eine ganze Familie oder sogar eine kleine Gemeinde mit individuellen Konten versorgen und somit zur eigenen Bank werden – und das alles mit einer einzigen Fullnode, die beispielsweise auf einem Raspberry Pi 5 betrieben wird, wie dem Raspiblitz.

Wie funktioniert das?

1. Fullnode als Fundament: Die Bitcoin-Fullnode auf dem Raspiblitz synchronisiert die gesamte Blockchain und stellt sicher, dass alle Transaktionen validiert werden. Diese Node dient als vertrauenswürdiges Rückgrat für das Lightning Network.
2. Lightning Network: Über das Lightning Network kann man blitzschnelle und kostengünstige Transaktionen durchführen. Es eröffnet die Möglichkeit, mit Kanälen flexibel Zahlungen zu senden und zu empfangen, ohne die Haupt-Blockchain zu belasten.
3. LNbits als Erweiterung: LNbits ist eine benutzerfreundliche Layer-2-Anwendung, die auf Lightning basiert. Sie ermöglicht es, mehrere Unterkonten zu erstellen – perfekt für Familienmitglieder, Freunde oder Gemeindeprojekte. Jeder Nutzer erhält seinen eigenen Zugang und kann eigenständig Zahlungen senden oder empfangen.

Was macht das so besonders?

• Eigenständige Bank: Anstatt auf Drittanbieter zu vertrauen, kann man selbst die Rolle einer Bank übernehmen. Die Verwaltung liegt vollständig in den eigenen Händen, und niemand kann Guthaben einfrieren oder den Zugang sperren.
• Schnell und günstig: Lightning-Zahlungen sind nahezu sofort und mit minimalen Gebühren möglich. Perfekt für alltägliche Transaktionen wie Einkäufe, Spenden oder das Teilen von Haushaltskosten.
• Privatsphäre und Sicherheit: Durch die Selbsthosted-Lösung bleiben alle sensiblen Daten und Finanzströme lokal und unter voller Kontrolle der Node-Betreibers.
• Zugänglich für alle: LNbits ist einfach zu bedienen und macht Lightning zugänglicher, selbst für technisch weniger versierte Personen. Mit einer intuitiven Benutzeroberfläche können sich die Nutzer eigenständig verwalten.

Raspberry Pi 5 – ausreichend für die Aufgabe

Der Raspiblitz, basierend auf einem Raspberry Pi 5, bietet genug Rechenleistung und Speicher, um eine Fullnode und alle zugehörigen Lightning-Funktionen zu betreiben. Er ist energieeffizient und kostengünstig, was ihn zu einer idealen Lösung für diese Art von Anwendung macht.

Beispiele für die Nutzung:

• Familie: Jeder hat ein eigenes LNbits-Konto für Taschengeld, Einkäufe oder Spenden.
• Gemeinde: Spenden oder lokale Projekte können transparent und kostengünstig verwaltet werden.
• Kleine Geschäfte: Händler können Zahlungen annehmen, ohne auf externe Zahlungsanbieter angewiesen zu sein.

Unvorstellbar? Doch real!

Dass eine so mächtige Infrastruktur auf einem kleinen Gerät wie einem Raspberry Pi laufen kann, zeigt, wie revolutionär Bitcoin und das Lightning Network sind. Es ist die Demokratisierung von Finanzinfrastruktur – für jedermann zugänglich, ohne Mittelsmänner und mit maximaler Freiheit. Ein modernes Beispiel für digitale Souveränität!

Für Was und Wem ist eine Fullnode geeignet

Eine Fullnode eignet sich hervoragend um Bitcoin Transaktionen direkt und ohne Umwege direkt an das Bitcoin Netzwerk zu senden. Eure Fullnode ist quasi euer direkter Zugang zum Netzwerk. Ausserdem könnt ihr viele verschiedene Wallts mit eurer Fullnode verbinden, wenn ihr darauf z.B einen Electrum Server installiert habt. Wallets wie die der Bitbox, Sparrow und auch Peer-to-Peer Programme lassen sich direkt mit der eigenen Fullnode verbinden. Damit sichert ihr euch eure Anonymität im Netzwerk und habt die volle Kontrolle über eure Transaktionen. Ihr könnt eure Familienmitglieder mit eigenen Lightning Wallets versorgen, oder sogar eine Gemeinde Projekt starten, in der eure Node die Schlüssel und Schaltstelle für all eure Zahlungen ist.

Auf der Fullnode könnt ihr ausserdem euren eigenen Mempool bzw. Blockchain Explorer verwenden. Damit sucht Ihr direkt auf der eigenen Node, wie eure Transaktionen abgearbeitet werden. Wer einen Blog fährt, kann auch einen BTCPay Server installieren, über den ihr z.B Spenden erhalten könnt.

Kann ich mit einer Fullnode Geld bzw. Sats verdienen

Ja, es ist möglich, mit einer Fullnode oder einer Lightning Node Geld zu verdienen, aber es ist wichtig, die Realität hinter diesem Vorhaben zu verstehen. Der Betrieb einer profitablen Lightning Node ist keineswegs einfach oder ein garantierter Weg zu schnellem Reichtum. Es erfordert:

1. Zeit und Einsatz: Eine profitable Node aufzubauen und zu betreiben, benötigt viel Zeit. Das Setup, die kontinuierliche Überwachung und Optimierung sind komplex und zeitaufwendig.
2. Erfahrung und Wissen: Ihr müsst ein tiefes Verständnis des Lightning-Netzwerks und der Routing-Mechanismen entwickeln. Ohne dieses Wissen ist es nahezu unmöglich, effektiv am Netzwerk teilzunehmen. Das Lernen und die Praxis sind wesentliche Bestandteile des Erfolgs. Ein paar Kanäle aufmachen und warten dass die Sats reinkommen ist eine falsche Vorstellung.
3. Node-Management-Tools: Der Einsatz von Tools wie lndg, Thunderhub oder ähnlichen kann helfen, aber erfordert ebenfalls Know-how, um diese effektiv zu nutzen. Diese Tools erleichtern das Management der Liquidität, das Rebalancing und die Optimierung der Kanäle.
4. Kapital: Eine erfolgreiche Lightning Node benötigt ausreichend Kapital, um Liquidität bereitzustellen. Ihr müsst sowohl eingehende als auch ausgehende Liquidität bereitstellen, um Routinggebühren zu verdienen. Außerdem erfordern größere und besser vernetzte Nodes oft höhere Investitionen.
5. Kosten: Der Betrieb einer Node bringt auch Kosten mit sich, wie für Hardware, Strom, Hosting (falls auf einem VPS betrieben) und eventuell Gebühren für die Eröffnung und Schließung von Kanälen.
6. Profitabilität: Am Ende schaffen es nur wenige Betreiber, tatsächlich eine profitable Node zu betreiben. Die Konkurrenz im Lightning-Netzwerk ist groß, und der Markt für Routinggebühren ist hart umkämpft. Viele Nodes verdienen nur minimale Beträge, die oft nicht ausreichen, um die Betriebskosten zu decken.

Der Betrieb einer Lightning Node ist eine Herausforderung, die viel Zeit, Wissen und Kapital erfordert. Es ist eher ein langfristiges Projekt für Enthusiasten, die das Netzwerk unterstützen und fördern möchten, anstatt eine einfache Einnahmequelle. Für viele ist es eine Möglichkeit, die Technologie aktiv mitzugestalten, und weniger eine reine Investition mit finanzieller Rendite.

Kann ich als Laie eine Fullnode bedienen

Die kurze Antwort: Ja, aber es kommt darauf an, welche Lösung ihr wählt.

Einsteigerfreundliche Optionen: Umbrel und Start9

Für Laien ohne Linux-Kenntnisse sind Umbrel und Start9 die beste Wahl. Beide Systeme bieten eine grafische Benutzeroberfläche, die intuitiv über den Webbrowser bedient werden kann. Die Ersteinrichtung erfolgt meist über einen einfachen Installationsassistenten, und die meisten Aufgaben lassen sich per Mausklick erledigen. Ihr könnt Apps installieren, Kanäle öffnen und eure Node verwalten, ohne jemals eine Kommandozeile sehen zu müssen.

Der Nachteil: Beide Systeme sind nicht perfekt. Gelegentlich können Probleme auftreten, die dann doch etwas technisches Verständnis erfordern. Die Community-Foren sind jedoch sehr hilfsbereit, und viele Probleme lassen sich mit etwas Geduld und der Suchmaschine lösen.

Für Fortgeschrittene: RaspiBlitz

RaspiBlitz ist deutlich komplexer und richtet sich an Nutzer mit Linux-Erfahrung und Kommandozeilen-Kenntnissen. Die Bedienung erfolgt primär über ein Terminal-basiertes Menü, und für viele Funktionen müsst ihr Befehle eintippen. Dafür bietet RaspiBlitz maximale Kontrolle und Anpassungsmöglichkeiten. Es gibt aber auch eine grafische Weboberfläche die stetig ausgebaut wird, ist aber noch in der Entwicklungsphase.

Wenn ihr noch nie mit Linux gearbeitet habt oder euch beim Gedanken an die Kommandozeile unwohl fühlt, ist RaspiBlitz eher nicht die richtige Wahl für den Einstieg.

Empfehlung für Laien

Startet mit Umbrel oder Start9. Diese Systeme sind darauf ausgelegt, das Betreiben einer Fullnode so einfach wie möglich zu machen. Ihr werdet trotzdem ein gewisses Maß an technischem Interesse und Lernbereitschaft mitbringen müssen – aber Programmierkenntnisse oder tiefes Linux-Wissen sind nicht erforderlich.

Falls ihr später mehr Kontrolle und Funktionen wollt, könnt ihr euch dann immer noch in Richtung RaspiBlitz weiterentwickeln.

Fazit

Das Betreiben einer eigenen Bitcoin Full Node und Lightning Node bietet eine Vielzahl von Vorteilen. Es ermöglicht euch nicht nur, die Kontrolle über eure eigenen Finanzen zu behalten und zur Stärkung des Netzwerks beizutragen, sondern es bietet auch die Möglichkeit, sofortige, kostengünstige Bitcoin-Transaktionen durchzuführen. Es erfordert jedoch etwas technische Kenntnisse und eine anfängliche Investition in Zeit und Hardware, aber die Vorteile, die es bietet, machen es zu einer lohnenden Unternehmung für jeden, der ernsthaft an Bitcoin interessiert ist.

Falls ihr Interesse habt das Bitcoin Netzwerk zu Unterstützen, und volle Finanzielle Freiheit zu erlangen, wir bieten Full Nodes mit Umbrel (nicht vorinstalliert aber mit Script Installer), Raspiblitz und Start9 vorinstalliert und fertig synchronisiert hier in unserem Shop an.

The post Was ist eine Bitcoin Full Node appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.