Lightning Watchtower: Beskytt Kanaler i 12 Steg [2026]

Lightning-noden din sover ikke, men det gjør du. Hver time noden din er offline, med kanaler åpne, ligger den utsatt for det verste scenariet i Lightning Network: en motpart som sender inn en gammel, ugyldig kanaltilstand og prøver å stjele saldoen din. Løsningen har eksistert i protokollen siden starten, men de fleste nodeoperatører i Norden har aldri satt den opp. Den heter watchtower, og i denne guiden bygger vi en fra bunnen.

Vi går gjennom hele oppsettet med lnd (Lightning Labs sin node-implementasjon), fra å aktivere tårn-serveren til å koble en klient til et eksternt tårn over Tor. Du får kommandoene, konfigurasjonsfilene og feilsøkingen som trengs for å faktisk stole på løsningen når det gjelder. Guiden er skrevet for deg som allerede kjører en Lightning-node, eller som planlegger å sette opp en Lightning-node og vil gjøre det riktig fra dag én.

Hva er en watchtower og hvorfor trenger du en

En Lightning-kanal er i praksis en løpende avtale mellom to parter om hvem som eier hvor mye av en delt saldo. Hver gang dere sender penger frem og tilbake, oppdateres avtalen, og den forrige versjonen blir ugyldig. Problemet oppstår hvis motparten din er uærlig (eller noden deres blir hacket) og de sender inn en gammel, utdatert versjon av kanaltilstanden til Bitcoin-blokkjeden mens du er offline. Har de mer penger i den gamle versjonen enn i den nyeste, kan de stjele differansen, med mindre noen oppdager det og reagerer innen tidsfristen.

Lightning Labs sin dokumentasjon beskriver watchtowers presist: “Watchtowers are other Lightning Network nodes that ideally run on a separate machine and network from the node they are watching over.” Poenget er redundans. Tårnet er alltid våkent, selv når din egen node er avslått for en oppdatering, en strømbrudd eller ferien din. Dokumentasjonen legger til at et tårn “are required to almost always be online and watch every bitcoin block for potential breaches, ideally using their own bitcoin node” (Lightning Labs).

Core Lightning-teamet formulerer det samme poenget fra en litt annen vinkel. Ifølge deres dokumentasjon er “a watchtower is a third-party service that you can hire to defend your node against such breaches, whether malicious or accidental, in the event that your node goes offline” (Core Lightning). Ordet “accidental” er verdt å merke seg. Du trenger ikke en ondsinnet motpart for at dette skal bli et problem. En vanlig krasj, en glemt backup som blir gjenopprettet med feil tilstand, eller en node som mister strøm midt i en oppdatering kan skape akkurat den samme sårbarheten.

Selve mekanismen bak forsvaret kalles en “justice transaction” (straffetransaksjon). Når et tårn oppdager et brudd, reagerer det automatisk. Core Lightning-dokumentasjonen beskriver det slik: tårnet “will watch for breaches on the blockchain and punish the malicious peer by relaying a penalty transaction on your behalf.” Konsekvensen for den som prøver å jukse er brutal: de mister ikke bare sitt eget krav, de mister ofte hele kanalsaldoen til deg som straff. Det er denne asymmetrien, stor gevinst for ærlig oppførsel og stort tap ved forsøk på juks, som gjør Lightning-nettverket økonomisk trygt selv uten sentral tillit.

Slik fungerer straffetransaksjonen teknisk

For å forstå hvorfor et watchtower faktisk kan beskytte deg, hjelper det å se litt under panseret. Hver gang en Lightning-kanal oppdaterer tilstanden sin, genereres det et sett med signerte, men ikke kringkastede transaksjoner. Den viktigste av disse er en revocation key, en hemmelig nøkkel som gjør den forrige kanaltilstanden verdiløs å bruke. Deler du denne nøkkelen med en tredjepart, kan de bygge og sende en straffetransaksjon dersom noen prøver å sende inn en gammel tilstand til blokkjeden.

Det er nøyaktig dette lnd gjør med et watchtower, men uten å avsløre kanalinnholdet. Klienten krypterer en forhåndsbygget straffetransaksjon og laster den opp til tårnet i “blindet” form. Tårnet kan ikke lese hvem partene er eller hvor mye penger som står på spill, det kan bare gjenkjenne når en spesifikk, forventet transaksjon dukker opp i en ny blokk og deretter kringkaste den forhåndssignerte responsen. Denne blinde arkitekturen er selve grunnen til at du kan stole på et watchtower driftet av en fremmed, uten å gi dem innsyn i egen økonomi.

Konsekvensen for en angriper som prøver seg er hard. Fordi straffetransaksjonen normalt lar den ærlige parten hente ut hele kanalsaldoen, ikke bare sin egen andel, blir ethvert forsøk på juks økonomisk selvskadelig for den som prøver. Denne mekanismen, kjent som “penalty” i Lightning-protokollens BOLT-spesifikasjoner, er en av grunnene til at nettverket kan fungere uten noen sentral part som dømmer i tvister.

Forutsetninger før du starter

Sett av 45–60 minutter til selve oppsettet, pluss tid til synkronisering hvis du ikke allerede har en full node kjørende. Du trenger følgende på plass før du går videre:

En kjørende Bitcoin Core-node, gjerne versjon 30.3 (utgitt 8. juli 2026) eller nyere, fullt synkronisert
lnd v0.21.0-beta (utgitt 11. juni 2026 av Lightning Labs) eller nyere, alternativt Core Lightning v26.06.1 hvis du foretrekker den implementasjonen
En Linux-server eller Raspberry Pi med minst 2 GB RAM og stabil strømtilførsel (tårnet må helst kjøre kontinuerlig)
Root- eller sudo-tilgang til maskinen som skal kjøre selve watchtower-tjenesten
Grunnleggende kjennskap til kommandolinjen og redigering av konfigurasjonsfiler
Valgfritt, men anbefalt: en separat fysisk maskin eller VPS for tårnet, atskilt fra hovednoden din
Valgfritt: Tor installert hvis du vil kjøre tårnet som en skjult tjeneste for bedre personvern

Merk deg spesielt punktet om atskilt maskinvare. Hele poenget med en watchtower er at den skal overleve de scenarioene der hovednoden din faller ut. Kjører tårnet på samme fysiske server som noden, mister du den beskyttelsen akkurat når du trenger den mest, altså under et strømbrudd eller en maskinvarefeil som rammer hele serveren.

Steg 1: Sjekk at lnd-installasjonen din er oppdatert

Start med å bekrefte hvilken versjon av lnd du kjører. Watchtower-funksjonaliteten er innebygd i standard lnd-binærfilen, så du trenger ingen tilleggsmoduler, men eldre versjoner kan mangle nyere konfigurasjonsflagg.

lnd --version
lncli --version

# Forventet output ligner på:
# lnd version 0.21.0-beta commit=v0.21.0-beta
# lncli version 0.21.0-beta commit=v0.21.0-beta

Hvis versjonen er eldre enn 0.18, bør du oppgradere før du fortsetter. Last ned siste utgivelse fra det offisielle GitHub-repositoriet til lnd (lnd releases) og følg standard oppgraderingsprosedyre: stopp lnd, bytt ut binærfilen, og start opp igjen med samme datamappe. Ta alltid backup av channel.backup-filen din før en oppgradering, uavhengig av hvor rutinemessig det føles.

Steg 2: Bestem om du vil kjøre server, klient, eller begge

lnd støtter to separate roller, og de fleste nodeoperatører trenger begge etter hvert. Watchtower-server betyr at din egen node tilbyr overvåkingstjenesten til andre, enten offentlig eller privat for eget bruk på en sekundær maskin. Watchtower-klient betyr at din node abonnerer på ett eller flere eksterne tårn for å beskytte dine egne kanaler.

Den vanligste og mest robuste oppsettet for en privatperson er dette: kjør en watchtower-server på en liten, separat maskin (for eksempel en Raspberry Pi hjemme hos en venn, eller en rimelig VPS), og koble hovednoden din til den som klient. Da har du kontroll over hele kjeden uten å stole på en tredjepart. Vil du ha enda mer redundans, kobler du klienten til flere tårn samtidig, inkludert offentlige tårn driftet av andre i miljøet.

Ressursbehovet for selve tårnfunksjonen er beskjedent sammenlignet med å drifte en fullverdig Lightning-node med aktiv ruting. Tårnserveren trenger ikke selv holde styr på kanaler eller betalinger, den lagrer kun krypterte tilstandsoppdateringer fra klientene som er koblet til den. Det gjør en watchtower-server til en av de rimeligste tilleggstjenestene du kan legge til et eksisterende Lightning-oppsett, både i strømforbruk og i lagringsplass.

Steg 3: Aktiver watchtower-serveren i lnd.conf

Åpne konfigurasjonsfilen for lnd (vanligvis ~/.lnd/lnd.conf) på maskinen som skal fungere som tårn, og legg til følgende seksjon:

[watchtower]
watchtower.active=1
watchtower.listen=0.0.0.0:9911
watchtower.externalip=DIN_OFFENTLIGE_IP:9911

Standard lytteport for watchtower-tjenesten i lnd er 9911, ifølge den offisielle dokumentasjonen i lnd-repositoriet (lnd watchtower docs). Feltet watchtower.externalip er det klienter bruker for å finne tårnet ditt utenfra, så sett det til den offentlige IP-en eller domenenavnet til serveren. Har du en dynamisk IP, bør du sette opp DDNS eller kjøre tårnet over Tor i stedet (se steg 8).

Start eller restart lnd etter endringen:

systemctl restart lnd
# eller, hvis du kjører manuelt:
lnd --configfile=~/.lnd/lnd.conf

Steg 4: Hent tårnets URI med lncli tower info

Når serveren er oppe, henter du tårnets identifikator og tilkoblingsadresse med denne kommandoen, som er den offisielle måten å hente tårninformasjon på ifølge Lightning Labs sin dokumentasjon:

lncli tower info

# Eksempel på output:
# pubkey: 03a1b2c3d4e5f6...
# listeners: [0.0.0.0:9911]
# uris: [[email protected]:9911]

Verdien under uris er det du skal gi videre til alle klienter som skal koble seg til dette tårnet, enten det er din egen hovednode eller andre i nettverket. Skriv den ned et trygt sted, den endrer seg ikke med mindre du regenererer nodenøkkelen.

Steg 5: Koble hovednoden din til som watchtower-klient

Gå nå til hovednoden din (den med kanalene du faktisk vil beskytte) og aktiver klientfunksjonen i lnd.conf:

[wtclient]
wtclient.active=1
wtclient.sweep-fee-rate=10

Parameteren wtclient.sweep-fee-rate setter gebyrraten (i sats per byte) som brukes hvis tårnet må sende inn en straffetransaksjon på dine vegne. Dette er dokumentert i Lightning Labs sin offisielle watchtower-guide (docs.lightning.engineering). Sett den for lavt, og transaksjonen kan sitte fast i mempoolen under høy nettverksbelastning nettopp når du trenger rask handling. En verdi mellom 10 og 20 sat/vbyte er et fornuftig utgangspunkt, men juster opp ved perioder med høye avgifter på Bitcoin-nettverket.

Restart noden, og legg deretter til selve tårnet med URI-en du hentet i forrige steg:

systemctl restart lnd

lncli wtclient add [email protected]:9911

# Bekreft at tårnet er registrert:
lncli wtclient towers

Steg 6: Verifiser at klienten faktisk sender oppdateringer

Å legge til et tårn er ikke det samme som å bekrefte at det fungerer. Bruk statistikkommandoen for å se om lnd faktisk sender kanaltilstander til tårnet:

lncli wtclient stats

# Eksempel på output:
# num_backups: 142
# num_pending_backups: 0
# num_failed_backups: 0
# num_sessions_acquired: 1
# num_sessions_active: 1

Er num_pending_backups konstant høy over tid uten å synke, eller num_failed_backups større enn null, har du et problem med tilkoblingen mellom klient og tårn. Gå videre til feilsøkingsdelen lenger ned hvis det er tilfellet.

Steg 7: Test hele kjeden med lncli wtclient tower

For en detaljert titt på ett spesifikt tårn, ikke bare aggregert statistikk, bruker du:

lncli wtclient tower 03a1b2c3d4e5f6...

# Viser blant annet:
# - aktive økter (sessions)
# - antall lagrede kanaltilstander per økt
# - siste vellykkede backup-tidspunkt

Gjør dette til en rutine hver gang du åpner en ny kanal. Nye kanaler krever en ny sikkerhetskopiering til tårnet, og det skjer normalt automatisk, men det er billig å dobbeltsjekke fremfor å oppdage et hull etter at det er for sent.

Steg 8: Kjør tårnet over Tor for bedre personvern

Å eksponere en offentlig IP-adresse for watchtower-serveren avslører hvor noden din fysisk befinner seg og potensielt hvem som eier den. lnd støtter Tor-baserte skjulte tjenester direkte, dokumentert i det offisielle watchtower-dokumentet i lnd-repositoriet:

[tor]
tor.active=1
tor.v3=1

[watchtower]
watchtower.active=1

lnd genererer da automatisk en .onion-adresse for tårnet ditt i stedet for å kreve en åpen offentlig IP. Klienter som skal koble seg til, må selv kjøre med Tor aktivert for å nå adressen, men gevinsten i personvern er betydelig, spesielt hvis du driver et offentlig tårn for andre i miljøet.

Steg 9: Legg til et andre, uavhengig tårn for redundans

Ett tårn er bedre enn null, men et enkelt feilpunkt er fortsatt et feilpunkt. lnd lar deg legge til flere tårn samtidig, og klienten distribuerer sikkerhetskopiene til alle aktive tårn parallelt:

lncli wtclient add [ANNEN_TÅRN_PUBKEY]@[ANNEN_TÅRN_IP]:9911

# Se alle aktive tårn:
lncli wtclient towers

# Fjern et tårn du ikke lenger stoler på:
lncli wtclient remove [TÅRN_PUBKEY]

Et vanlig oppsett i praksis er ett privat tårn du selv kontrollerer, pluss ett offentlig tårn driftet av en tredjepart i økosystemet, som Lightning Network+ sin community-liste over tilgjengelige tårn (lightningnetwork.plus) gir eksempler på. Kombinasjonen gir deg redundans selv om ditt eget tårn faller ut samtidig som hovednoden.

Steg 10: Bygg inn overvåking og varsling

Et tårn du ikke overvåker er nesten like risikabelt som ikke å ha noe tårn. Sett opp et enkelt sjekk-script som kjører lncli wtclient stats med jevne mellomrom og varsler deg (via e-post, Telegram-bot eller lignende) hvis num_failed_backups øker eller num_sessions_active faller til null. Et grunnleggende cron-eksempel:

#!/bin/bash
STATS=$(lncli wtclient stats)
FAILED=$(echo "$STATS" | grep num_failed_backups | grep -oE '[0-9]+')

if [ "$FAILED" -gt 0 ]; then
  echo "ADVARSEL: $FAILED mislykkede watchtower-backups" | \
    mail -s "Lightning watchtower-feil" [email protected]
fi

Legg dette scriptet i crontab og kjør det hver time. Det tar minutter å sette opp og kan spare deg for en kanal full av bitcoin senere.

Steg 11: Sammenlign watchtower-alternativer for din node-type

Kjører du ikke lnd, finnes tilsvarende funksjonalitet i de andre store implementasjonene. Tabellen under oppsummerer forskjellene mellom de tre mest brukte Lightning-implementasjonene.

Implementasjon	Watchtower-standard	Aktiveringskommando	Versjon brukt i denne guiden
lnd (Lightning Labs)	Egen lnd-protokoll (bakoverkompatibel)	watchtower.active=1 / wtclient.active=1	v0.21.0-beta
Core Lightning	BOLT13-kompatibel	watchtower-plugin (Eye of Satoshi)	v26.06.1
Eclair (ACINQ)	Ingen innebygd watchtower-klient per i dag	Krever tredjepartsløsning	–

Core Lightning bruker en pluginarkitektur og støtter det åpne BOLT13-formatet, som gjør at et Core Lightning-tårn i teorien kan overvåke kanaler fra andre implementasjoner som følger samme standard. Dokumentasjonen deres nevner spesifikt “the watchtower client plugin that works with the Eye of Satoshi tower (or any BOLT13 compliant watchtower)” som et konkret eksempel på denne interoperabiliteten (Core Lightning docs).

Kjører du Eclair fra ACINQ, er situasjonen litt annerledes. Denne implementasjonen mangler i dag en innebygd watchtower-klient tilsvarende det lnd og Core Lightning tilbyr, så du er avhengig av eksterne, community-utviklede løsninger hvis du vil ha samme type beskyttelse. Vurderer du å bytte node-programvare utelukkende for watchtower-støtte, er det verdt å veie det opp mot andre forskjeller mellom implementasjonene, som ruting-algoritmer og administrasjonsverktøy, fremfor å basere hele valget på denne ene funksjonen alene.

Steg 12: Sett opp rutinemessig vedlikehold og rotasjon

Et watchtower-oppsett er ikke noe du konfigurerer én gang og glemmer. Bygg inn faste rutiner:

Sjekk lncli wtclient stats ukentlig, ikke bare rett etter oppsett
Oppgrader lnd og tårnserveren samtidig, aldri bare den ene siden, for å unngå protokollmismatch
Test failover ved å midlertidig stoppe hovednoden og bekrefte at tårnet fortsatt er aktivt og lyttende
Roter eller legg til nye offentlige tårn årlig, siden driftere av tredjepartstårn kan legge ned tjenesten uten varsel
Ta backup av towers.db-filen sammen med resten av lnd-datamappen din

Vanlige fallgruver du bør unngå

Selv et teknisk enkelt oppsett som dette har fallgruver som gjentar seg i praksis. Her er de fem vanligste.

Tårn på samme maskin som noden. Dette er den vanligste feilen blant nybegynnere, og den er forståelig fordi det er teknisk enklere å konfigurere alt på én server. Problemet er at hele poenget med et watchtower er å overleve nettopp de scenarioene der hovednoden faller ut. Kjører begge tjenestene på samme fysiske maskin, forsvinner beskyttelsen i det øyeblikket serveren mister strøm eller nettverkstilkobling, altså akkurat når du trenger den mest.

Feil eller manglende port-forwarding. Port 9911 må være åpen og videresendt i ruteren hvis du kjører tårnet uten Tor. Mange hjemmenettverk blokkerer innkommende trafikk som standard, og uten en eksplisitt regel i ruteren eller brannmuren kan ingen klienter noensinne nå tårnet ditt utenfra, selv om alt ser riktig ut i lnd sin egen konfigurasjon.

Å stole på ett eneste tårn. Ett tårn er fortsatt ett enkelt feilpunkt, uansett hvor pålitelig det virker. Legg alltid til minst to, gjerne driftet av forskjellige aktører på forskjellig infrastruktur, slik at et utfall hos den ene leverandøren ikke fjerner all beskyttelse samtidig.

For lav gebyrrate i wtclient.sweep-fee-rate. Setter du denne verdien for lavt for å spare litt på fremtidige transaksjonsgebyrer, risikerer du at straffetransaksjonen blir sittende fast i mempoolen nettopp under en periode med høy avgiftskonkurranse på Bitcoin-nettverket. Da har tårnet gjort jobben sin ved å oppdage bruddet, men reaksjonen kommer for sent til å være nyttig.

Aldri å teste at det faktisk virker. Mange setter opp et tårn én gang og sjekker aldri statistikken igjen. Uten jevnlig verifisering med lncli wtclient stats vet du ikke om beskyttelsen faktisk er aktiv, om sesjonen har utløpt, eller om tårnet sluttet å svare for flere måneder siden.

Feilsøking: de vanligste problemene og løsningene

Under følger de åtte vanligste problemene nodeoperatører støter på ved oppsett av watchtower med lnd, og hvordan du løser dem.

1. “connection refused” ved lncli wtclient add. Dette er som regel et tegn på at tårnserveren ikke lytter på riktig nettverksgrensesnitt. Bekreft at watchtower.listen=0.0.0.0:9911 faktisk er satt i konfigurasjonsfilen, ikke bare bundet til localhost, og at lnd er restartet etter at endringen ble lagret. Glemmer du restarten, laster ikke lnd inn den nye konfigurasjonen, og feilen vil se identisk ut selv om filen ser riktig ut.

2. num_pending_backups synker aldri. Dette er vanligvis en brannmurblokkering et sted mellom klienten og tårnet, ikke en feil i selve lnd-konfigurasjonen. Test tilkoblingen direkte med nc -zv TÅRN_IP 9911 fra klientmaskinen for å bekrefte at porten faktisk er nåbar over nettverket. Er svaret negativt, sjekk ruterens port-forwarding-regler og eventuelle cloud-brannmurer (security groups) hvis tårnet kjører på en VPS.

3. Tårnet svarer ikke etter en oppgradering. Sjekk at både klient- og servernoden kjører kompatible lnd-versjoner etter oppgraderingen. Store versjonssprang, for eksempel fra en versjon eldre enn 0.15 til nyere enn 0.20, kan i sjeldne tilfeller endre den interne watchtower-protokollen på måter som krever at begge sider oppdateres samtidig.

4. lncli tower info viser tom uris-liste. Feltet watchtower.externalip mangler eller inneholder feil verdi i lnd.conf. Uten en gyldig ekstern adresse kan tårnet ikke annonsere en nåbar tilkoblingssti til klienter, og kommandoen returnerer en tom liste selv om serverdelen kjører helt fint internt.

5. Tor-basert tårn er utilgjengelig med jevne mellomrom. Kortvarige, sporadiske avbrudd er relativt normalt for skjulte Tor-tjenester på grunn av hvordan sirkler bygges opp på nytt. Skjer det ofte og over lengre perioder, sjekk at Tor-daemonen kjører stabilt i bakgrunnen og at systemklokken på serveren er korrekt synkronisert, siden Tor er følsom for klokkeavvik.

6. num_sessions_active faller til null uten advarsel. Et offentlig, gratis tårn kan ha nådd sin lagringsgrense for antall sesjoner den enkelte klienten får bruke. Mange gratis, community-drevne tårn setter et tak per node for å fordele kapasiteten rettferdig mellom brukere. Løsningen er ofte å legge til et nytt tårn i tillegg, ikke å vente på at det gamle frigjør plass.

7. Straffetransaksjonen sendes aldri, selv ved reelt brudd. Sjekk at wtclient.sweep-fee-rate ikke er satt så lavt at transaksjonen aldri klarer å nå mempoolen under perioder med høy avgiftskonkurranse. Øk verdien og test gjerne oppsettet i et kontrollert testmiljø (testnet) hvis det er mulig, fremfor å oppdage problemet først når det faktisk gjelder.

8. Ulik oppførsel mellom lnd og Core Lightning-tårn. De to implementasjonene bruker ikke identisk protokoll som standard, selv om begge støtter beslektede konsepter. Blander du implementasjoner i samme oppsett, sørg for at Core Lightning-siden spesifikt kjører et BOLT13-kompatibelt tårn, ikke bare et hvilket som helst tårn bygget for en annen spesifikasjon.

Avanserte tips for produksjonsmiljø

Når grunnoppsettet fungerer, er det noen ekstra grep som skiller et hobbyoppsett fra et som faktisk holder i produksjon over tid.

Sett tårnserveren på en egen VPS i en annen geografisk region enn hovednoden. Det beskytter mot regionale strømbrudd og lokale internettutfall som ellers ville tatt ned begge samtidig. Vurder også å tilby tårntjenesten din offentlig til andre i Lightning-miljøet. Det koster lite ekstra ressurser å la flere klienter koble seg til samme tårn-instans, og du bidrar til et mer desentralisert nettverk av watchtowers totalt sett, i tråd med hele designfilosofien bak Lightning Network.

Til slutt: hold et øye med Bitcoin Core-versjonen tårnet ditt er avhengig av. Bitcoin Core 30.3, utgitt 8. juli 2026, og Bitcoin Core 29.4, utgitt 13. juli 2026, er begge aktivt vedlikeholdte grener ifølge det offisielle utgivelsesarkivet (bitcoin.org). En full node som ikke er oppdatert, kan i verste fall gi tårnet ditt en forsinket eller ufullstendig oversikt over blokkjeden, noe som svekker hele beskyttelsen tårnet er ment å gi.

Tabellen under oppsummerer forskjellen i praktisk risiko mellom en node uten watchtower og en node med et fungerende, overvåket watchtower-oppsett som beskrevet i denne guiden.

Scenario	Uten watchtower	Med overvåket watchtower
Node offline i noen timer (rutinemessig oppdatering)	Ingen beskyttelse mot kanalbrudd i perioden	Kanaltilstander overvåkes kontinuerlig av tårnet
Motpart sender inn utdatert kanaltilstand	Tap kan oppstå hvis du ikke oppdager det i tide selv	Straffetransaksjon kringkastes automatisk av tårnet
Server med noden krasjer helt (maskinvarefeil)	Full eksponering frem til du er tilbake online	Uendret beskyttelse, forutsatt tårnet kjører på egen maskin
Lengre ferie eller reise uten tilgang til noden	Eksponering hele perioden noden er nede	Ingen praktisk endring i risikoprofil

Containerbasert drift med Docker

Skal du drifte watchtower-serveren på en dedikert VPS, er det ofte enklere å administrere den som en container fremfor en manuelt installert binærfil. Under er et minimalt docker-compose-oppsett som starter en lnd-node med watchtower-serveren aktivert. Du må fortsatt sørge for at Bitcoin Core-noden lnd kobler seg til, enten kjører på samme host eller er tilgjengelig over nettverket.

# docker-compose.yml
version: "3.8"
services:
  lnd-watchtower:
    image: lightninglabs/lnd:v0.21.0-beta
    container_name: lnd-watchtower
    restart: unless-stopped
    volumes:
      - ./lnd-data:/root/.lnd
      - ./lnd.conf:/root/.lnd/lnd.conf:ro
    ports:
      - "9911:9911"
    command: ["lnd"]

# Start containeren
docker compose up -d

# Følg loggen mens tårnet starter opp
docker compose logs -f lnd-watchtower

# Kjør lncli-kommandoer inne i containeren
docker exec -it lnd-watchtower lncli tower info

Fordelen med denne tilnærmingen er at oppgraderinger blir en enkel docker compose pull && docker compose up -d i stedet for manuell binærhåndtering, og at hele oppsettet kan versjonskontrolleres i et Git-repository. Ulempen er et tynt ekstra lag med kompleksitet for feilsøking, siden nettverksproblemer nå kan stamme fra enten vertsmaskinens brannmur eller Dockers egen nettverksbro. Test alltid nc -zv fra utsiden av containeren, ikke bare innenfra, for å bekrefte at portvideresendingen faktisk fungerer end-to-end.

Ordliste: sentrale begreper i watchtower-oppsett

Noen av begrepene i denne guiden er spesifikke for Lightning-protokollen og dukker ikke opp andre steder i kryptoverdenen. Tabellen under samler de viktigste for rask oppslag.

Begrep	Betydning
Watchtower	Tredjeparts- eller egendrevet tjeneste som overvåker blokkjeden for kanalbrudd på dine vegne mens noden din er offline
Justice transaction	Straffetransaksjonen som automatisk kringkastes hvis et brudd oppdages, og som lar den ærlige parten hente ut kanalsaldoen
Revocation key	Hemmelig nøkkel som gjør en gammel kanaltilstand ugyldig å bruke etter en oppdatering
BOLT13	Den delen av Lightning-spesifikasjonen (Basis of Lightning Technology) som definerer watchtower-protokollen på tvers av implementasjoner
wtclient	Modulen i lnd som håndterer klientsiden, altså tilkobling til eksterne tårn
Sweep-fee-rate	Gebyrraten (sat/vbyte) som brukes når tårnet sender inn en straffetransaksjon på dine vegne

Komplett prosjekt: watchtower-server og klient på to maskiner

Under følger hele oppsettet samlet, som du kan bruke som mal for et reelt to-maskins prosjekt: én maskin som tårnserver, én som hovednode med klienten.

# === MASKIN A: Watchtower-server ===
# ~/.lnd/lnd.conf

[Application Options]
alias=mitt-tarn
color=#3399FF

[Bitcoin]
bitcoin.active=1
bitcoin.mainnet=1
bitcoin.node=bitcoind

[tor]
tor.active=1
tor.v3=1

[watchtower]
watchtower.active=1
watchtower.listen=0.0.0.0:9911

# Start noden og hent URI
systemctl restart lnd
lncli tower info


# === MASKIN B: Hovednode (watchtower-klient) ===
# ~/.lnd/lnd.conf

[Application Options]
alias=min-hovednode

[Bitcoin]
bitcoin.active=1
bitcoin.mainnet=1
bitcoin.node=bitcoind

[wtclient]
wtclient.active=1
wtclient.sweep-fee-rate=12

# Start noden, legg til tårnet fra Maskin A
systemctl restart lnd
lncli wtclient add [PUBKEY_FRA_MASKIN_A]@[TOR_ELLER_IP]:9911

# Verifiser
lncli wtclient stats
lncli wtclient towers

Med dette oppsettet kjørende har hovednoden din (Maskin B) kontinuerlig sikkerhetskopiering av kanaltilstandene til en uavhengig server (Maskin A), som overvåker Bitcoin-blokkjeden døgnet rundt selv når hovednoden er avslått. Legg gjerne til et andre, offentlig tårn i tillegg for enda et lag redundans, slik du så i steg 9.

Har du allerede satt opp en Lightning-node fra bunnen, er dette det naturlige neste steget. Og har du opplevd eller lest om angrepsbølgen mot Lightning Network tidligere i år, er et watchtower-oppsett nettopp den typen forsvarsmekanisme som forhindrer at et enkeltstående utfall blir til et økonomisk tap.

Watchtower som del av en helhetlig sikkerhetsstrategi

En watchtower løser ett spesifikt problem: beskyttelse mot kanalbrudd mens noden din er offline. Den erstatter ikke andre grunnleggende sikkerhetstiltak. Du trenger fortsatt trygg oppbevaring av seed-frasen til noden, gjerne med Shamir-basert backup i flere deler hvis du opererer med større summer. Har du bitcoin liggende i kald lagring utenfor Lightning-kanalene, gjelder egne rutiner for det, som beskrevet i vår guide til air-gapped multisig kald lagring. Og bruker du en fysisk enhet som signerings-nøkkel for selve noden, bør oppsettet følge samme prinsipper som i vår gjennomgang av sikker oppsett av hardware-lommebok.

Conner Fromknecht, som jobbet med watchtower-implementasjonen hos Lightning Labs, oppsummerte designfilosofien bak funksjonen slik under en teknisk gjennomgang: “The solution that watchtowers provide is that you are going to delegate a highly available party to detect these breaches and respond to them on your behalf” (btctranscripts.com). Det er kjernen i hele arkitekturen. Du delegerer årvåkenheten, ikke kontrollen over pengene dine. Tårnet kan aldri flytte midler ut av kanalen din på annen måte enn å håndheve en straffetransaksjon mot en motpart som allerede har brutt avtalen.

Det er verdt å understreke denne avgrensningen én gang til, fordi den er lett å misforstå: et watchtower har aldri tilgang til å initiere en betaling, åpne eller lukke en kanal på egne premisser, eller flytte penger ut av deg til seg selv. Den eneste handlingen tårnet kan utføre er å kringkaste en forhåndssignert transaksjon som du selv har generert og godkjent på forhånd, og bare når betingelsene for et faktisk brudd er oppfylt på blokkjeden. Denne begrensede fullmakten er selve grunnen til at modellen fungerer selv med tårn driftet av folk du aldri har møtt.

Personvern og desentralisering ved offentlige tårn

Å koble seg til et offentlig, tredjepartsdrevet tårn er bekvemt, men det er ikke helt uten avveininger. Selv om tårnet ikke kan lese detaljene i kanaltilstanden din, kan driften av tårnet se hvilken IP-adresse klienten kobler seg fra, med mindre du ruter tilkoblingen gjennom Tor slik vi viste i steg 8. Over tid kan et mønster av tilkoblinger fra samme adresse gi antydninger om hvilke noder som tilhører samme eier, spesielt hvis du bruker det samme tårnet for flere noder uten Tor.

Det er også et desentraliseringsargument for å drifte eget tårn fremfor å kun stole på store, populære offentlige alternativer. Konsentrerer for mange nodeoperatører seg om noen få dominerende tårn, oppstår en viss grad av sentralisering i en ellers desentralisert protokoll, selv om selve tårnfunksjonen i seg selv aldri kan flytte penger uten et faktisk brudd å reagere på. Å drifte ditt eget tårn, i tillegg til å koble til ett eller to offentlige, er derfor både en personlig sikkerhetsgevinst og et lite bidrag til nettverkets generelle robusthet.

Vurder også hvilken jurisdiksjon en eventuell tredjeparts tårn-tjeneste opererer fra, spesielt hvis du planlegger å bruke Lightning-noden din til betydelige summer over tid. Dette er ikke fordi tårnet har tilgang til midlene dine, men fordi tilgjengelighet og oppetid kan variere med lokale forhold som strømstabilitet og internettinfrastruktur der tjenesten er plassert.

Ofte stilte spørsmål om Lightning-watchtowers

Må jeg betale for å bruke en watchtower?
Nei, protokollen i lnd er i dag gratis å bruke, både for å drifte og for å koble seg til et tårn. Enkelte kommersielle tjenester kan komme til å ta betalt for premium-tårn med garantert oppetid i fremtiden, men grunnfunksjonaliteten krever ingen betaling.

Kan et watchtower stjele pengene mine?
Nei. Tårnet mottar kun krypterte, forseglede data om kanaltilstandene dine. Det kan ikke lese detaljene og kan bare handle ved å sende inn en forhåndssignert straffetransaksjon hvis et faktisk brudd oppdages på blokkjeden.

Hvor mange tårn bør jeg bruke samtidig?
To til tre er et fornuftig utgangspunkt for de fleste. Ett du selv kontrollerer, og ett til to offentlige eller driftet av noen du stoler på i miljøet.

Fungerer watchtowers med alle typer Lightning-kanaler?
Ja, funksjonaliteten er kanaltype-uavhengig i lnd og dekker både eldre og nyere kanalformater, så lenge både server- og klientsiden kjører kompatible versjoner.

Trenger jeg en watchtower hvis noden min alltid er online?
Anbefalingen er ja likevel. “Alltid online” er sjelden bokstavelig sant over tid, og et watchtower-oppsett koster minimalt i ressurser sammenlignet med risikoen ved et enkelt uforutsett utfall.

Kan jeg bruke samme tårn for flere noder?
Ja, ett tårn kan overvåke kanaler for flere uavhengige klientnoder samtidig, så lenge tårnet har nok lagringskapasitet og båndbredde til trafikken.

Hva skjer hvis tårnet mitt går offline permanent?
Fjern det med lncli wtclient remove og legg til et nytt. Har du fulgt anbefalingen om minst to tårn, er du fortsatt beskyttet av det gjenværende tårnet i mellomtiden.

Er watchtower-oppsett relevant for Lightning-noder i Norge og Norden spesifikt?
Ja, prinsippene er identiske uansett geografi. Det eneste lokale hensynet er å velge en VPS-leverandør eller sekundær maskinplassering med stabil strømforsyning og god internettoppetid, noe som uansett gjelder generelt for noder driftet fra Norden.