Grundkonfiguration einer Lightning Node & Best Practices

Technik
,
5

So, hier ist die Fortsetzung zum Theme Sicherheit. Diesmal geht es um die Firewall.

Für die Eiligen – TL;DR
Der Raspiblitz ist im Grundzustand gut konfiguriert, aber ich empfehle Thunderhub und RTL auf den Nicht-SSL Ports nicht zuzulassen.

4. Firewall konfigurieren

Zuallererst: Wenn ihr eure Node ohne externe IP-Adresse mit NAT hinter einem Router betreibt, dann sind die meisten Punkte in diesem Post nicht so wichtig. Aber trotzdem könnte ihr durch ein paar Konfigurationen eure Node noch sicherer machen, insbesondere gegen einen Angriff aus dem eigenen Netz. Das könnte z.B. passieren, wenn sich in einem Computer in eurem Netzzwerk ein Trojaner eingeschlichen hat, oder wenn der Angriff auf der Straße in Reichweite eures WLAN-Netzwerks befindet.

Netzwerk-Grundlagen

Eine Firewall schützt euere Node vor ungewollten Netzwerkzugriffen. Linux – und damit auch eure Node – hat standardmäßig eine Firewall mit dabei. Beim Raspiblitz ist diese auch schon vorkonfiguriert und aktiviert. Damit ihr versteht, was ihr da macht, sind ein paar Netzwerkgrundlagen nötig:

  1. Computer können über unterschiedliche Protokolle miteinander sprechen, bei unserer Lightning Node ist das z.B. TCP/IP. Das Internet Protocol (IP) bildet die Grundlage des ganzen Internets.
  2. Euer Computer hat dabei eine IP-Adresse. Üblicherweise wird dies in eurem Heimnetzwerk eine lokale IP-Adresse sein, beispielsweise 192.168.0.23, möglicherweise beginnt sie auch mit 10.x.x.x oder 172.16.x.x. Euer Router wird in den meisten fällen die interne Adresse 192.168.0.1 und zusätzlich eine externe Adresse haben und vermittelt Anfragen in euer Netzwerk.
  3. Ein Programm auf einem Computer, kann aber auch mit einem anderen Programm auf dem selben Computer kommunizieren, in diesem Fall nutzt es die „Loopback“ Adresse 127.0.0.1 oder den hostnamen „localhost“.
  4. Wenn ein Programm eine solche Kommunikation (egal ob von außerhalb des privaten Netzes, von innerhalb oder auf dem selben Computer) anbieten will, dann spricht man meist von einem Dienst, der auf einem sog. Port lauscht. Das ganze ist im Transmission Control Protocol (TCP) definiert. Ein Service lauscht also auf einem Port, as eine bestimmte Nummer hat, die meist einem Standard folgen. HTTP hat üblicherweise den Port 80, HTTPS 443, SSH 22, Bitcoin 8333 und Lightning 9735.
  5. Eine Kommunikation findet nun von einer IP-Adresse zu einer anderen IP-Adresse + Port statt. Beispielsweise greift eine andere Node (mit einer externen IP-Adresse) auf eure Node über den Port 9735 zu. Oder ihr greift selbst von eurem lokalen Netzwerk per SSH auf Port 22 eurer Node zu.

Und genau hier greift eine Firewall ein: Mit der Firewall wird genau definiert, von wo aus ein Dienst auf einen bestimmten Port zugreifen darf.

iptables und ufw

Unter Linux heißt die Firewall „iptables“, die sehr mächtig ist. Bei einem Raspiblitz wird deswegen das Programm „ufw“ (auf deutsch „unkomplizierte Firewall“) zur einfachen Konfiguration eingesetzt.

Um zu prüfen, ob die Firewall läuft nutzt auf dem Terminal den Befehl sudo systemctl status ufw.service das sollte ein paar Zeilen ausgeben inklusive einem Active: active – dann läuft der Dienst.

Wenn ihr nur Tor verwendet ist alles etwas einfacher

Vermutlich ist eure Node nur im Tor-Netzwerk angebunden. In dem Fall nutzt ihr nicht TCP/IP sondern TCP/Tor. Das heißt die ganzen IP-Adressen für den Zugriff von außen gibt es nicht, sondern das Tor-Netzwerk kümmert sich um alles, inklusiver versteckter Service-Adressen statt IP-Adressen. Erst lokal auf eurer Node wird die Kommunikation übersetzt und an einen TCP-Port gebunden. D.h. für eure Firewall sieht es so aus, als würde ein Programm auf eurer Node (der Tor-Dienst) mit einem anderen Programm (der Lightning-Daemon) sprechen, also von der Adresse 127.0.0.1 (localhost) auf einen Port, bei Lightning eben 9735.

Im Raspiblitz ist ufw automatisch so konfiguriert, dass alle Loopback-Zugriff erlaubt werden.
Wenn ihr das prüfen wollte, sollte sich in der Konfigurationsdatei /etc/ufw/before.rules der folgende Abschnitt befinden:

# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

Der Abschnitt sagt im Grunde, dass alle eingehende und ausgehenden Verbindungen, die über „Loopback“ gehen akzeptiert werden.

Nicht benötigte Services aussperren

Für den laufenden Betrieb eurer Node könnt ihr eigentlich alle anderen Zugriff verbieten, weil alles über Tor läuft.

Allerdings benötigt ihr vermutlich zur Administration Zugriff von außen (außer ihr verwendet an eurer Node nur einen Bildschirm + Tastatur).

Bei einer Lightning-Node wie dem Raspiblitz sind das üblicherweise:

  • SSH (für den Zugriff über die Kommandozeile)
  • RTL (Browser GUI)
  • Thunderhub (Browser-GUI)

Das Ziel der folgenden Anleitung ist nun alle Zugriff von außern zu verbieten, außer für diese 3 Dienste.

Zuerst müsst ihr mal prüfen, wie die Firewall derzeit konfiguriert ist. Das geht mit diesem Befehl sudo ufw status verbose.

Die Ausgabe auf einem unveränderten Raspiblitz sieht ca. so aus:

sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                  
8333                       ALLOW IN    Anywhere                   # bitcoin mainnet
9333                       ALLOW IN    Anywhere                   # litecoin mainnet
19735                      ALLOW IN    Anywhere                   # lightning testnet
9735                       ALLOW IN    Anywhere                   # lightning mainnet
10009                      ALLOW IN    Anywhere                   # lightning gRPC
8080                       ALLOW IN    Anywhere                   # lightning REST API
49200:49250/tcp            ALLOW IN    Anywhere                   # rtorrent
80                         ALLOW IN    Anywhere                   # allow public web HTTP
443                        ALLOW IN    10.0.0.0/8                 # allow local LAN HTTPS
443                        ALLOW IN    172.16.0.0/12              # allow local LAN HTTPS
443                        ALLOW IN    192.168.0.0/16             # allow local LAN HTTPS
Anywhere                   ALLOW IN    10.0.0.0/8 1900/udp        # allow local LAN SSDP for UPnP discovery
Anywhere                   ALLOW IN    172.16.0.0/12 1900/udp     # allow local LAN SSDP for UPnP discovery
Anywhere                   ALLOW IN    192.168.0.0/16 1900/udp    # allow local LAN SSDP for UPnP discovery
3000                       ALLOW IN    Anywhere                   # RTL HTTP
3001                       ALLOW IN    Anywhere                   # RTL HTTPS
3010                       ALLOW IN    Anywhere                   # allow ThunderHub HTTP
3011                       ALLOW IN    Anywhere                   # allow ThunderHub HTTPS
22/tcp (v6)                ALLOW IN    Anywhere (v6)             
18333 (v6)                 ALLOW IN    Anywhere (v6)              # bitcoin testnet
8333 (v6)                  ALLOW IN    Anywhere (v6)              # bitcoin mainnet
9333 (v6)                  ALLOW IN    Anywhere (v6)              # litecoin mainnet
19735 (v6)                 ALLOW IN    Anywhere (v6)              # lightning testnet
9735 (v6)                  ALLOW IN    Anywhere (v6)              # lightning mainnet
10009 (v6)                 ALLOW IN    Anywhere (v6)              # lightning gRPC
8080 (v6)                  ALLOW IN    Anywhere (v6)              # lightning REST API
49200:49250/tcp (v6)       ALLOW IN    Anywhere (v6)              # rtorrent
80 (v6)                    ALLOW IN    Anywhere (v6)              # allow public web HTTP
3000 (v6)                  ALLOW IN    Anywhere (v6)              # RTL HTTP
3001 (v6)                  ALLOW IN    Anywhere (v6)              # RTL HTTPS
3010 (v6)                  ALLOW IN    Anywhere (v6)              # allow ThunderHub HTTP
3011 (v6)                  ALLOW IN    Anywhere (v6)              # allow ThunderHub HTTPS

Wie ist das ganze zu lesen? Die Zeile
Default: deny (incoming), allow (outgoing), disabled (routed)
bedeutet, dass alle eingehenden Verbindungen nicht erlaubt werden („deny incoming“) und alle ausgehenden Verbindungen erlaubt werden.

Dann folgt die lange Liste an Ports, die trotzdem erlaubt werden und zwar einmal für IPv4 und einmal für IPv6.

Eine andere Ansicht mit Regel-Nummern ermöglicht der Befehl sudo ufw status numbered:

sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere                  
[ 2] 18333                      ALLOW IN    Anywhere                   # bitcoin testnet
[ 3] 8333                       ALLOW IN    Anywhere                   # bitcoin mainnet
[ 4] 9333                       ALLOW IN    Anywhere                   # litecoin mainnet
[ 5] 19735                      ALLOW IN    Anywhere                   # lightning testnet
[ 6] 9735                       ALLOW IN    Anywhere                   # lightning mainnet
[ 7] 10009                      ALLOW IN    Anywhere                   # lightning gRPC
[ 8] 8080                       ALLOW IN    Anywhere                   # lightning REST API
[ 9] 49200:49250/tcp            ALLOW IN    Anywhere                   # rtorrent
[10] 80                         ALLOW IN    Anywhere                   # allow public web HTTP
[11] 443                        ALLOW IN    10.0.0.0/8                 # allow local LAN HTTPS
[12] 443                        ALLOW IN    172.16.0.0/12              # allow local LAN HTTPS
[13] 443                        ALLOW IN    192.168.0.0/16             # allow local LAN HTTPS
[14] Anywhere                   ALLOW IN    10.0.0.0/8 1900/udp        # allow local LAN SSDP for UPnP discovery
[15] Anywhere                   ALLOW IN    172.16.0.0/12 1900/udp     # allow local LAN SSDP for UPnP discovery
[16] Anywhere                   ALLOW IN    192.168.0.0/16 1900/udp    # allow local LAN SSDP for UPnP discovery
[17] 3000                       ALLOW IN    Anywhere                   # RTL HTTP
[18] 3001                       ALLOW IN    Anywhere                   # RTL HTTPS
[19] 3010                       ALLOW IN    Anywhere                   # allow ThunderHub HTTP
[20] 3011                       ALLOW IN    Anywhere                   # allow ThunderHub HTTPS
[21] 22/tcp (v6)                ALLOW IN    Anywhere (v6)             
[22] 18333 (v6)                 ALLOW IN    Anywhere (v6)              # bitcoin testnet
[23] 8333 (v6)                  ALLOW IN    Anywhere (v6)              # bitcoin mainnet
[24] 9333 (v6)                  ALLOW IN    Anywhere (v6)              # litecoin mainnet
[25] 19735 (v6)                 ALLOW IN    Anywhere (v6)              # lightning testnet
[26] 9735 (v6)                  ALLOW IN    Anywhere (v6)              # lightning mainnet
[27] 10009 (v6)                 ALLOW IN    Anywhere (v6)              # lightning gRPC
[28] 8080 (v6)                  ALLOW IN    Anywhere (v6)              # lightning REST API
[29] 49200:49250/tcp (v6)       ALLOW IN    Anywhere (v6)              # rtorrent
[30] 80 (v6)                    ALLOW IN    Anywhere (v6)              # allow public web HTTP
[31] 3000 (v6)                  ALLOW IN    Anywhere (v6)              # RTL HTTP
[32] 3001 (v6)                  ALLOW IN    Anywhere (v6)              # RTL HTTPS
[33] 3010 (v6)                  ALLOW IN    Anywhere (v6)              # allow ThunderHub HTTP
[34] 3011 (v6)                  ALLOW IN    Anywhere (v6)              # allow ThunderHub HTTPS

Wie man sieht, ist in jeder Zeile eine Regel definiert, zum Beispiel:

22/tcp                     ALLOW IN    Anywhere

Das bedeutet auf den SSH-Dienst mit dem Port 22 dürfen eingehende Verbindungen („IN“) von überall „Anywhere“ angenommen werden. Also von 127.0.0.1, von einer Adresse im lokalen Netz (z.B: 192.168.0.23) oder auch von extern (wenn es nicht der Router mit NAT sowieso nicht ermöglicht).

Wenn wir nur die drei Services SSH, RTL und Thunderhub erlauben wollen, müssen wir alle anderen Services löschen. Das geht am einfachsten mit dem Befehl sudo ufw delete <Nr>.

Ein Beispiel:

sudo ufw delete 9

Deleting:
 allow 8080 comment 'lightning REST API'
Proceed with operation (y|n)?

Das Programm fragt also zur Sicherheit nochmal nach und nach einem „y“ wird die Regel gelöscht. So kann man mit jeder Regel verfahren, die man löschen möchte.

Im übrigen ist es nicht notwendig, den Dienst ufw neu zu starten. Die Änderungen gelten sofort.

Achtung: Die Nummern ändern sich nach jedem Löschvorgang, also am besten mit der höchsten Nummer beginnen oder jedes mal neu die Nummern abfragen.

Zur Erinnerung: Der Zugriff über Tor wird von diesen Regeln nicht erfasst, deswegen können eigentlich fast alle Regeln gelöscht werden. Was auf jeden Fall benötigt wird:

  • Der Port 9735 für Lightning Mainnet
  • Der Port 22 für SSH
  • Der Port 3001 für RTL über SSH
  • Der Port 3011 für Thunderhub über SSH

Wichtig: Ports für RTL und Thunderhub können auf eurem System von meinem Beispiel abweichen.

Einige der Regeln in der UFW-Konfiguration sind eigentlich irrelevant, beispielsweise für den Port 18333 (bitcoin testnet). Vermutlich ist euer System sowieso so konfiguriert, dass der Bitcoin-Dienst gar nicht auf diesem Port lauscht, es kann also sowieso kein Zugriff stattfinden. Ich finde es aber trotzdem besser, wenn auch die entsprechende Firewall-Regel gar nicht existieren.

Welche Services in jedem Fall ausgesperrt gehören

Eigentlich ist die Firewall nicht so wichtig, wenn sich die Node hinter einem Router mit NAT befindet und viele Ports sowieso nicht in Verwendung sind. Es gibt aber einige Services, die mich sehr wohl stören:

  1. Thunderhub über HTTP (ohne SSL)
  2. RTL über HTTP (ohne SSL)

Warum? Ihr könnte diese Dienst ohne Verschlüsselung im internen LAN aufrufen. Dabei wird das RPC-Passwort unverschlüsselt (!) übertragen. Es ist auf jeden Fall empfehlenswert die beiden Dienst nur über HTTPS aufzurufen. Dabei kommt im Normalfall zwar ein selbstsigniertes Zertifikat zur Anwendung, aber wenn ihr den Fingerprint des Zertifikats einmalig manuell prüft, ist das genauso sicher wie in normal signiertes Zertifikat.

Aber wenn ihr einmal unabsichtlich die HTTP-Seite ohne SSL aufruft, übertragt ihr euer Passwort im Klartext in eurem Netz. Ein Angreifer, der sich in Funkreichweite eures WLAN befindet, kann dieses einfach aufzeichnen, sich im WLAN anmelden (auch relativ einfach möglich) und über Thunderhub/RTL eure Node leerräumen.

Also, wenn das oben alles zu viel war, sperrt einfach die folgenden Ports raus:

  • RTL 3000
  • Thunderhub 3010

und zwar swowhl für IPv4 als auch IPv6, also in Summe in meinem Beispiel die Regeln 33, 31, 19 und 17.

Ein paar Sonderfälle für die Profis:

  • Wenn ihr mit der Software von Ledger auf eure Node zugreifen wollt, müsst ihr möglicherweise zusätzliche Ports erlauben, aber das habe ich nicht getestet. Hier geht’s zu einer Anleitung für Bitbox, danke für den Tipp @osito!
  • Wenn ihr eine zweite Bitcoin-Node betreibt und die beiden Nodes die Blockchain untereinander synchronisieren sollen, müsst ihr den Port 8333 erlauben.

Verbindet euch mit meiner (gut abgesicherten) Node!

Ihr könnt euch auch gerne einen Kanal mit meiner Node aufmachen: GLN auf amboss.space . Bitte mind. 2M, kleinere Kanäle ergeben keinen Sinn, da die Open & Close-Kosten sonst in keinem Verhältnis zu den möglichen Gebühreneinnahmen stehen, nur kleine Beträge transferiert werden können und dauernd ein Rebalancing nötig wäre.

Meine Node wird zukünftig einige Online-Shops anbinden und ist mittlerweile auf Platz ~700 auf Terminal Web und hat dort 6/6 Häkchen.

19 „Gefällt mir“
6

Hey @GLN, erstmal danke für die super Einführung! Deine Beiträge sind wirklich immer ausführlich!
Vielleicht kennst du das ja schon aber für Optimierung des Terminal Scores gibt es diesen tollen Service:

1 „Gefällt mir“
7

Vielen Dank für dein immer sehr lehrreichen Content!! :slightly_smiling_face:

Ich bin dabei meine Firewall entsprechend aufzuräumen.
Dabei habe ich mich mit einzelnen Ports beschäftigt. Als Noch-IT-Laie sind mir zum Beispiel bei dem PORT 10006 (v4)/(v6) zusammenhänge mit Watchtower aufgefallen.

Ich möchte gerne meine Node mit Watchtower einrichten - Zwecks Sicherheit.
Auch habe ich die REST API adresse im zusammenhang mit anderen Services gefunden.

Zusammengefasst meine Frage: Wenn man nicht gerade bestimmte Services verwenden möchte, kann man alle bis auf die 4 oben genannten Ports löschen.

Sprich die oben beschriebene konfiguration der Firewall ist für einen Node-Betreiber gedacht, der sich ausschließlich per SSH einlogged und über RTL und Thunderhub wartet/steuert und pflegt, richtig?

8

Hey GLN,

Danke für den ausführlichen Post. Ich werde heute Abend meine USV einrichten und bin über diesen Punkt gestolpert:

E-Mail Notification ist klar, aber wie kann ich dann von einem iPhone von unterwegs auf den Raspiblitz zugreifen um das PW einzugeben?

Grüße
Jan

9

Ja genau, die konkrete Konfiguration hängt von den Services ab, die du nutzen möchtest.

Genau genommen benötigst du für lnd nur den lnd Port 9735, den SSH Port 22 solltest du auch nie blocken, sonst kommst du nicht per SSH rein. Alle anderen Port kann man im Zweifelsfall ja auch später hinzufügen, wenn etwas nicht mehr wie erwartet funktioniert.

Wenn du die folgenden Services von deinem lokalen LAN aus nutzen möchtest, benötigst du die beispielsweise auch noch die folgenden Ports:

  • mempool space: 4081
  • Electrum Rust Server: 50002
  • lnd GRPC: 10009

Das ist nur ein kleine Auswahl, je nachdem welche Services du nutzen möchtest, brauchst du noch mehr Ausnahmen. Aber generell würde ich eben alles verbieten, was du nicht nutzen möchtest.

Der Watchtower lauscht normalerweise auf 9911 – aber nur, wenn du in Clearnet unterwegs bist. Wenn du ausschließlich Tor nutzt, musst du diesen Port nicht freigeben. 10006 sagt mir eigentlich nichts, aber man kann natürlich beliebige Ports nutzen, es gibt zwar übliche Standardwerte, aber jeder kann davon abweichen!

1 „Gefällt mir“
10

Es gibt auch ssh-Terminals für das iPhone! Aber ich habe eigentlich fast immer ein Notebook dabei, zumindest wenn ich länger weg bin…

11

Danke, da mach ich mich mal schlau.
Bin eher selten mal länger weg, höchstens vielleicht der Klassiker Urlaub 1x im Jahr

12

Schau mal hier gibt es eine Anleitung für den Fernzugriff. Über Cmd klappt es bei mir nicht, dafür aber mit dem SSH Client „PuTTY“.

13

Das ist lieb gemeint aber es geht in der Anleitung explizit zum Android, das hilft mir nicht weiter :slight_smile:

14

Ich habe den Hidden Service soweit nach der Anleitung im RaspiBlitz aktiviert.
Wie muss ich nun auf den Windows Client vorgehen um mich von Außerhalb zu Verbinden?

TOR Browser installieren und dann in der Windows Eingabeaufforderung mit
ssh admin@meine URI
anmelden?

15

Der Tor deamon in Windows muss laufen. Das heißt, du musst den Tor Browser auch geöfnet und verbunden haben, damit das geht. Ich habe nicht immer den browser öffnen wollen bevor ich die Bitbox app benutze also hab ich direkt den service installiert. das geht so:[TUT] TOR als Systemdienst installieren [4K | DE] - YouTube

Wie du dann weitermachen musst weiß ich selber auch nicht.

1 „Gefällt mir“
16

Gibt’s eine Art Bestrafungsmechanismus im LND Netzwerk??

Ich habe die letzten Wochen sehr viel geroutet.
Der Kanal wurde immer komplett leer gezogen, ich kam mir dem Rebalancen nichtmal hinterher.

Bis ich meine Gebühren schlagartig auf 25000ppm abgehoben habe. Nun routet niemand mehr über mich, obwohl die Gebühren seit drei Tagen auf komplett null sind. Der Kanal ist gut gebalanced, daran liegt es nicht.

1 „Gefällt mir“
17

Du brauchst einen SSH Client, wie PuTTY.
Wie du das genau einrichtest, wird hier erklärt:

1 „Gefällt mir“
18

Es gibt einen Bestrafung im Lightning wenn man versucht sich Sats in einem Channel anzueignen die einem nicht gehören. Darüber hinaus schneiden Nodes mit wie häufig Zahlungen über eine Partnernode scheitern und priorisieren die dann für künftige Zahlungen runter. Wenn der Channel zu viele Probleme macht wird er auch mal von der Node auf inaktiv gesetzt. Bis auf ersteres würde ich das aber als technische Abwicklung bezeichnen und nicht als „Bestrafung“.

Was man auch im Hinterkopf behalten muss, das Gossip Protokoll ist nichts zeitlich zuverlässiges. Das heißt wenn du z.B. die Fees auf 25k hochhebst können danach im Hintergrund etliche Zahlungen über deine Node fehlschlagen weil die die neue Fee noch nicht kennen.
Das danach dann Flaute ist kann zig verschiedene Gründe haben die ich jetzt nicht alle aufzählen mag :sweat_smile:, ich tippe auf „es hat grad keiner Bock“ oder Channel inaktiv.

19

Kanal ist gut gefüllt. Gebühren sind seit 3 Tagen auf 0 und es gab mittlerweile 1 erfolgreiche Transaktion mit 25K Gebühren

Liegt dann wohl daran, das kein er die 0sat Gebühren kennt.

20

Gilt dies auch für gescheiterte Rebalances, welche LNDg automatisch auszuführen versucht (payment invoice expired)?

22

Der andere Kanal hat keinerlei Reaktion mehr gezeigt.
Habe jetzt ein force Close gestartet. Das ist eine ganz neue Erfahrung.

23

Die, die ein Kanal zu Wallet of Satoshi haben, sollten ihn Mal auf Funktion überprüfen.

Meine erhöhung der Gebühren ist wohl nur zufällig zeitgleich mit einem anderen Problem aufgetreten. Bei vielen funktioniert der Kanal nicht mehr.

Screenshot_20221028-152105
Screenshot_20221028-1521051080×2400 298 KB

24

In der letzten Zeit war WoS gerne mal für ein paar Stunden kanaltechnisch offline. Ich nehme das zur Kenntnis und sitze es entspannt aus. Bis jetzt kam der Kanal immer wieder online und ernsthafte Probleme damit habe ich nicht sehen können.

Aber ich habe da auch keinen zweistellig Millionen-Sat-Kanal zu WoS, mit entsprechendem Kapitalrisiko.

25

Habe das Problem, dass meine Node denkt WOS möchte 1000ppm gebühr von mir. Wirklich sind es nur 100ppm. Wie kann ich das in meiner Node richtigstellen. Das Rebalancung ist so unmöglich.

Der Fehler liegt auf meiner Seite, wie kann ich es korrigieren?

Update / Lösung:
Bei Balance of Satoshi gibt es ein toller Command.
bos advertise

Dieser Command bezahlt 10sat an jede andere Node, die bereit ist die neuen Gebühren im Netzwerk sofort zu verbreiten.

Kleine Anmerkung: der Command braucht mittlerweile 1 Stunde und läuft immer noch. Am Anfang war sehr lange nichts zu sehen.