Lightning Network løser Bitcoins skaleringsproblem, men den løsningen skaper sitt eget hodebry: en ny lommebok har ingen inngående kapasitet, og uten inngående kapasitet kan den ikke motta betalinger. I 2026 er svaret på det problemet standardisert gjennom tre spesifikasjoner kalt LSPS0, LSPS1 og LSPS2. De definerer hvordan en lommebok snakker med en Lightning Service Provider (LSP) for å kjøpe eller automatisk få tildelt kanalkapasitet. Denne artikkelen går gjennom hele prosessen i 12 steg, fra å forstå hva en LSP faktisk gjør til å sette opp og teste en just-in-time-kanal (JIT) med ekte programvare.

Målgruppen er utviklere, nodedriftere og tekniske Bitcoin-brukere i Norden som vil forstå likviditetslaget i Lightning Network, ikke bare bruke en ferdig lommebok-app uten å vite hva som skjer under skallet. Vi bruker Core Lightning (CLN), Lightning Development Kit (LDK) og referanseimplementasjoner av LSPS1 og LSPS2 som gjennomgående eksempler.

Hva er en Lightning Service Provider, og hvorfor trenger du en?

En Lightning Service Provider, forkortet LSP, er en node som selger eller tilbyr betalingskanaler til andre noder. Tanken er enkel: å drifte en egen velbalansert node med god inngående og utgående kapasitet krever kapital, tid og kontinuerlig vedlikehold. De fleste nye brukere har ingen av disse tingene klare på dag én. En LSP løser det ved å stille opp som motpart i en kanal, enten mot forhåndsbetaling eller mot et gebyr som trekkes fra den første innkommende betalingen.

Før LSPS-spesifikasjonene fantes, måtte hver lommebok-app integrere seg mot hver enkelt LSP sitt eget, proprietære API. Det ga vendor lock-in: en lommebok bygget mot ett grensesnitt kunne ikke uten videre bytte til en annen leverandør uten å skrive om integrasjonskoden. LSPS-spesifikasjonene, utviklet gjennom samarbeidet BitcoinAndLightningLayerSpecs, definerer et felles språk som enhver LSP kan implementere og enhver lommebok kan integrere mot én gang, for så å velge fritt mellom leverandører. Ifølge en teknisk oversikt publisert i juli 2026 er LSPS0, LSPS1 og LSPS2 nå aktive spesifikasjoner som flere produksjonsklare noder støtter.

Det finnes to hovedtyper likviditetstjenester i dag. Den første er en forhåndskjøpt, stående kanal: brukeren betaler på forhånd, i bitcoin, for en kanal av en gitt størrelse som åpnes direkte mot deres node. Den andre er en just-in-time-kanal, der kanalen opprettes akkurat i det øyeblikket en betaling kommer inn, og gebyret trekkes fra selve betalingen i stedet for å betales separat i forkant. LSPS1 standardiserer den første modellen. LSPS2, som også er kjent under navnet bLIP-52 i BOLT-prosessen, standardiserer den andre.

Forutsetninger og verktøy du trenger

Denne tutorialen er praktisk rettet og forutsetter at du allerede har en viss fortrolighet med kommandolinjen og Bitcoin-begreper som UTXO, on-chain-transaksjoner og kanalbalanse. Du trenger ikke være Lightning-ekspert, men grunnleggende forståelse av hva en betalingskanal er, gjør resten enklere å følge.

  • En Linux-maskin (Ubuntu 24.04 LTS eller nyere er brukt i eksemplene) med minst 4 GB RAM og 40 GB diskplass for en pruned Bitcoin-node
  • Core Lightning (CLN), siste versjon fra det offisielle repoet til ElementsProject, eller alternativt Lightning Development Kit (LDK) for de som vil bygge inn LSP-klientlogikk direkte i en app
  • Bitcoin Core i pruned eller full node-modus, synkronisert til nettverket (testnet eller signet anbefales for øvelsen før du går til mainnet)
  • Grunnleggende kjennskap til JSON-RPC, siden LSPS1 og LSPS2 kommuniserer via JSON over BOLT 8-krypterte meldinger mellom noder
  • En liten mengde testnet-bitcoin eller signet-coins til å betale for kanaler under testing
  • Terminaltilgang med curl og jq installert for å inspisere RPC-svar

Vi anbefaler sterkt at du gjør hele øvelsen på testnet eller signet først. En feilkonfigurert kanal mot en ukjent LSP på mainnet kan i verste fall bety at midler sitter fast til kanalen lukkes, og det er ikke noe du vil oppleve første gang du tester et nytt verktøy.

Steg 1: Installer og synkroniser en Lightning-node

Start med en fungerende Lightning-node. Core Lightning har native implementasjoner av både LSPS1- og LSPS2-klientsiden, og er derfor et naturlig valg for denne guiden. Installer siste stabile versjon fra det offisielle kildekode-repoet.

sudo apt update
sudo apt install -y autoconf automake build-essential git libtool \
  libgmp-dev libsqlite3-dev python3 python3-mako net-tools zlib1g-dev \
  libsodium-dev gettext

git clone https://github.com/ElementsProject/lightning.git
cd lightning
pip3 install --user poetry
poetry install
./configure
make -j$(nproc)
sudo make install

Etter installasjon starter du noden mot testnet eller signet med riktig nettverksflagg, og lar den synkronisere mot din lokale Bitcoin Core-instans. Dette kan ta fra noen minutter til flere timer, avhengig av om du kjører en pruned node eller laster ned hele kjeden.

lightningd --network=testnet --daemon \
  --log-file=/var/log/cln/testnet.log \
  --bitcoin-rpcuser=rpcuser \
  --bitcoin-rpcpassword=rpcpassword

lightning-cli getinfo

Svaret fra getinfo skal vise node-ID, blockheight og at noden er fullstendig synkronisert. Hvis blockheight ikke øker, er det et tegn på at Bitcoin Core-tilkoblingen er feilkonfigurert, og du bør løse det før du går videre.

Steg 2: Forstå LSPS0, transportlaget under alt annet

LSPS0 er det underliggende transportlaget som LSPS1 og LSPS2 bygger på. Det definerer hvordan JSON-RPC-meldinger pakkes inn og sendes over BOLT 8-krypterte peer-til-peer-meldinger mellom to Lightning-noder, uten at noen tredjepart ser innholdet. Uten LSPS0 ville hver spesifikasjon måttet definere sin egen transportmekanisme, noe som ville gjort implementasjonsarbeidet dobbelt så komplisert for hver ny LSP.

I praksis betyr dette at klienten (lommeboken din) sender en melding med en bestemt meldingstype til LSP-noden, og mottar et JSON-RPC-svar tilbake i samme format. Du trenger normalt ikke å bygge dette laget selv. Core Lightning og LDK eksponerer høyere-nivå-kommandoer som skjuler LSPS0-detaljene, men det er verdt å vite at de finnes, fordi feilsøking noen ganger krever at du ser på rå meldinger.

# Inspiser rå peer-meldinger for feilsøking
lightning-cli listpeers | jq '.peers[] | {id, connected, features}'

Steg 3: Koble til en LSP og hent informasjon med LSPS1

LSPS1 dekker den klassiske modellen: du kjøper en kanal på forhånd. Flyten starter med at klienten kaller lsps1.get_info for å lære leverandørens grenser, bekreftelseskrav og betalingsmetoder. Flere produksjonsnoder, inkludert Olympus og Alby Hub, har LSPS1-støtte i 2026, så det er realistisk å teste mot en reell leverandør på testnet først hvis de tilbyr det, eller mot en lokal testinstans.

Koble først til LSP-nodens peer-adresse. Deretter sender du en LSPS1-forespørsel om informasjon.

lightning-cli connect LSP_NODE_ID@LSP_HOST:PORT

lightning-cli lsps1-getinfo LSP_NODE_ID

Et typisk svar inneholder minimums- og maksimumsstørrelse for kanaler, hvilke betalingsmetoder leverandøren godtar (on-chain-transaksjon, BOLT 11-faktura eller BOLT 12-tilbud), og hvor mange bekreftelser som kreves før kanalen regnes som gyldig. Noter deg disse grensene, siden de avgjør hvilken kanalstørrelse du faktisk kan bestille i neste steg.

Steg 4: Bestill en kanal med lsps1.create_order

Når du har grensene fra forrige steg, sender du en bestilling med ønsket kanalstørrelse. LSP-noden svarer med en pris og en betalingsmetode.

lightning-cli lsps1-createorder LSP_NODE_ID \
  '{"lsp_balance_sat": "500000", "client_balance_sat": "0",
    "funding_confirms_within_blocks": 6,
    "announce_channel": false}'

Svaret inneholder en ordre-ID, en pris i satoshi, og en betalingsadresse eller faktura. Betal denne fakturaen fra en annen, allerede fungerende kanal, eller send on-chain-betaling hvis det er metoden leverandøren tilbyr. Etter at betalingen er bekreftet, åpner LSP-noden kanalen mot din node automatisk, uten at du selv trenger å sende en fundchannel-kommando.

Dette er den modellen som passer best for en merchant eller en bruker som vet på forhånd at de kommer til å motta regelmessige betalinger, og som ønsker innkommende kapasitet klar før den første betalingen ankommer.

Steg 5: Forstå LSPS2 og just-in-time-kanaler

LSPS2, som har gått gjennom BOLT-prosessen under navnet bLIP-52, løser et annet problem: hva gjør en helt ny lommebok som ikke har noen kanal i det hele tatt, og som skal motta sin første betaling? Her kommer “just-in-time”-kanalen inn. I stedet for at brukeren må kjøpe en kanal i forkant, oppdager LSP-noden at en betaling er på vei inn, åpner en kanal der og da, ruter betalingen gjennom den nyopprettede kanalen, og trekker sitt eget gebyr fra beløpet som kommer inn.

Flyten består av fem trinn: lommeboken oppretter en faktura selv om den ikke har en passende innkommende kanal, LSP-noden merker at betalingen ikke kan nå lommeboken på annen måte, LSP-noden åpner en kanal med null bekreftelser (zero-conf), betalingen rutes gjennom den nye kanalen, og til slutt trekker LSP-noden sitt kanalåpningsgebyr fra det innkomne beløpet. Core Lightning og LND har begge produksjonsklare implementasjoner av LSPS2 i 2026, mens LDK sin egen lightning-liquidity-crate i Rust fortsatt var merket som alfa i research fra september samme år.

Steg 6: Sett opp en LSPS2-forespørsel i praksis

Prosessen starter med et kall til lsps2.get_info, der klienten henter leverandørens gjeldende gebyrmodell og minimumsgrenser for JIT-kanaler.

lightning-cli lsps2-getinfo LSP_NODE_ID

# Eksempel på svar (forenklet)
{
  "min_fee_msat": "2000000",
  "proportional": 2500,
  "min_lifetime": 1008,
  "max_client_to_self_delay": 2016
}

Deretter kaller du lsps2.buy for å reservere et kort kanal-ID-alias som skal brukes i fakturaen din. Dette aliaset gjør at betalende part kan rute betalingen til deg selv før den fysiske kanalen eksisterer, fordi LSP-noden later som om kanalen allerede er der og oppretter den reelt i det øyeblikket betalingen ankommer.

lightning-cli lsps2-buy LSP_NODE_ID '{"payment_size_msat": "300000000"}'

# Bruk short channel ID-aliaset fra svaret når du lager fakturaen
lightning-cli invoice 300000000 "forste-betaling" "test av JIT-kanal" \
  --hint-scid=ALIAS_FRA_FORRIGE_SVAR

Send deretter fakturaen til betaleren. Hvis alt er riktig konfigurert, vil du se en ny kanal dukke opp i lightning-cli listpeerchannels i det øyeblikket betalingen ankommer, med status som raskt går fra CHANNELD_AWAITING_LOCKIN til CHANNELD_NORMAL.

Steg 7: Verifiser at kanalen faktisk fungerer

Etter at JIT-kanalen er opprettet, bør du bekrefte at den er brukbar og at beløpet som landet i lommeboken din stemmer med det du forventet minus gebyret.

lightning-cli listpeerchannels | jq '.channels[] |
  {peer_id, state, to_us_msat, total_msat, short_channel_id}'

Sammenlign to_us_msat mot det opprinnelige fakturabeløpet. Differansen skal tilsvare gebyret du fikk oppgitt i lsps2.get_info-svaret i steg 6, altså en fast del pluss en proporsjonal andel av beløpet. Hvis differansen er større enn forventet, har du sannsynligvis misforstått gebyrmodellen, og bør lese leverandørens dokumentasjon på nytt før du gjør dette på mainnet med reelle beløp.

Steg 8: Liquidity ads, alternativet til LSPS-standardene

Ikke alle store aktører har valgt å bygge på LSPS-sporet. ACINQ, selskapet bak Phoenix-lommeboken, har i stedet satset på en kombinasjon av dual funding, splicing og liquidity ads, altså en mekanisme der noder annonserer tilgjengelig likviditet direkte i nettverket og forhandler kanalvilkår uten å gå via LSPS1 eller LSPS2. Dette er verdt å kjenne til fordi det betyr at LSP-økosystemet i praksis er delt i to tilnærminger som løser samme problem på litt forskjellig vis.

Liquidity ads fungerer slik at en node med ledig kapasitet kringkaster et tilbud om å bidra med midler til en kanal, inkludert pris per blokk kanalen skal være åpen. En klient som trenger kapasitet kan søke gjennom disse annonsene og velge den som passer best på pris og vilkår, i stedet for å sende en direkte forespørsel til en navngitt LSP. Dual funding gjør det mulig for begge parter å bidra med midler til samme kanal samtidig, noe som gir mer flexibel balansefordeling fra start enn den tradisjonelle modellen der bare én part finansierer kanalen.

Steg 9: Sammenlign de ulike likviditetsmekanismene

Før du velger hvilken modell du skal bygge mot, er det nyttig å se dem side ved side. Tabellen under oppsummerer forskjellene i når betaling skjer, hva brukeren opplever, og hvilke noder som støtter hva per 2026.

MekanismeHovedformålNår betales gebyretKjente implementasjoner
LSPS1Forhåndskjøp av kanalFør kanalen åpnesCLN, LND, Olympus, Alby Hub
LSPS2 / bLIP-52Just-in-time-kanal ved første betalingTrukket fra innkommende beløpCLN, LND (produksjon), LDK lightning-liquidity (alfa)
Liquidity adsAnnonsert og forhandlet likviditetVarierer per avtaleACINQ / Phoenix-økosystemet
Dual fundingBegge parter finansierer kanalenIngen separat gebyr nødvendigvisFlere moderne node-implementasjoner
Manuell kanalåpningBrukeren åpner og finansierer selvKun on-chain nettverksgebyrAlle Lightning-noder som standardfunksjon

Legg merke til at LSPS2 er den eneste modellen her som lar en bruker motta sin aller første betaling uten å ha gjort noe som helst i forkant. Det er grunnen til at den regnes som spesielt viktig for lommebok-apper rettet mot nye brukere, der onboarding-friksjon er den største hindringen for adopsjon.

Steg 10: Konfigurer gebyrgrenser og beskyttelse mot overbetaling

En viktig, men ofte oversett del av oppsettet er å sette maksgrenser for hva du er villig til å betale i LSP-gebyrer. Uten en grense kan en kompromittert eller useriøs LSP i teorien forsøke å ta en uforholdsmessig stor andel av en innkommende betaling. De fleste implementasjoner lar deg sette en maksimal proporsjonal sats og en maksimal fast sats før klienten automatisk avviser forespørselen.

# Eksempel: avvis LSPS2-tilbud med gebyr over definerte grenser
lightning-cli lsps2-buy LSP_NODE_ID \
  '{"payment_size_msat": "300000000",
    "max_proportional_fee_ppm": 3000,
    "max_fixed_fee_msat": "3000000"}'

Hvis LSP-noden svarer med et tilbud utenfor disse grensene, bør klienten avvise automatisk heller enn å be brukeren godkjenne manuelt hver gang. Det gir en konsistent beskyttelse mot at gebyrmodeller endres uten varsel mellom hver transaksjon.

Steg 11: Test feilscenarioer før du går til mainnet

Før du flytter dette oppsettet til mainnet med ekte bitcoin, bør du aktivt provosere feil på testnet for å se hvordan klienten din håndterer dem. Dette inkluderer å koble fra LSP-noden midt i en bestilling, sende en betaling som er mindre enn minimumsgrensen, og teste hva som skjer hvis zero-conf-kanalen aldri bekreftes on-chain.

  • Avbryt tilkoblingen til LSP-noden etter lsps1.create_order, men før betaling, og bekreft at ordren utløper slik den skal
  • Send et beløp under min_fee_msat-grensen i en LSPS2-forespørsel og verifiser at klienten gir en forståelig feilmelding, ikke en krasj
  • Simuler at zero-conf-kanalen aldri når nødvendige bekreftelser, og se om noden din markerer kanalen korrekt som usikret i mellomtiden
  • Test med flere parallelle LSPS2-forespørsler samtidig for å se om klienten håndterer race conditions riktig

Steg 12: Sett opp overvåking og logging for produksjon

Når du er klar for mainnet, sett opp logging som fanger alle LSPS1- og LSPS2-forespørsler, svar og eventuelle avviste tilbud. Dette gir deg et revisjonsspor hvis noe går galt, og lar deg sammenligne faktiske gebyrer over tid mot det leverandøren opprinnelig annonserte.

# Følg LSPS-relatert aktivitet i loggen i sanntid
tail -f /var/log/cln/mainnet.log | grep -iE "lsps1|lsps2|jit|zeroconf"

Sett også opp et enkelt varslingsskript som sjekker at balansen mellom innkommende og utgående kapasitet ikke drifter for langt i én retning over tid, siden en node som hovedsakelig mottar JIT-finansierte kanaler, ofte ender opp med mye innkommende og lite utgående kapasitet dersom ingen aktive rebalanseringstiltak gjøres.

Komplett eksempelprosjekt: en enkel LSPS2-klient

Under følger et samlet, forenklet eksempel som binder sammen stegene over i et lite skript. Det forutsetter at Core Lightning allerede kjører lokalt og at du har koblet til en LSP-node på forhånd.

#!/bin/bash
# jit-kanal.sh - hent en just-in-time-kanal via LSPS2 og lag en faktura
set -euo pipefail

LSP_ID="$1"
BELOP_MSAT="$2"
MAKS_PROP_PPM=3000
MAKS_FAST_MSAT=3000000

echo "Henter LSP-info..."
INFO=$(lightning-cli lsps2-getinfo "$LSP_ID")
echo "$INFO" | jq .

echo "Ber om JIT-kanal..."
TILBUD=$(lightning-cli lsps2-buy "$LSP_ID" \
  "{\"payment_size_msat\": \"$BELOP_MSAT\",
    \"max_proportional_fee_ppm\": $MAKS_PROP_PPM,
    \"max_fixed_fee_msat\": \"$MAKS_FAST_MSAT\"}")

ALIAS=$(echo "$TILBUD" | jq -r '.scid_alias')
echo "Fikk alias: $ALIAS"

echo "Lager faktura..."
lightning-cli invoice "$BELOP_MSAT" "jit-test-$(date +%s)" \
  "Just-in-time-kanal via LSPS2" --hint-scid="$ALIAS"

echo "Faktura klar. Vent på betaling og sjekk listpeerchannels for ny kanal."

Kjør skriptet med node-ID og beløp i millisatoshi som argumenter. Resultatet skal være en faktura du kan sende til en betaler, og en ny kanal som dukker opp automatisk når betalingen er mottatt.

Eksempel på forventet output gjennom hele flyten

Her er et typisk hendelsesforløp slik det ser ut i loggene når alt fungerer som det skal, fra første forespørsel til ferdig kanal.

2026-10-02T09:14:03Z lsps2-getinfo: svar mottatt, min_fee_msat=2000000
2026-10-02T09:14:05Z lsps2-buy: tilbud godtatt, scid_alias=103x1x0
2026-10-02T09:14:06Z invoice: faktura opprettet, 300000000 msat
2026-10-02T09:15:21Z peer_connected: LSP-node koblet til for utbetaling
2026-10-02T09:15:22Z channel_opened: zero-conf-kanal 103x1x1 i status AWAITING_LOCKIN
2026-10-02T09:15:23Z payment_received: 300000000 msat mottatt, gebyr trukket: 2750000 msat
2026-10-02T09:15:23Z channel_state: 103x1x1 endret til CHANNELD_NORMAL

Merk at kanalen går rett til CHANNELD_NORMAL uten å vente på on-chain-bekreftelser, nettopp fordi det er en zero-conf-kanal der LSP-noden tar risikoen på seg i det korte tidsvinduet før den underliggende transaksjonen er begravd i en blokk.

Vanlige fallgruver når du setter opp Lightning-likviditet

Gjennom testing dukker noen feil opp igjen og igjen. Her er de vi ser oftest, og hvordan du unngår dem.

  • Å stole blindt på en zero-conf-kanal fra en ukjent LSP. Zero-conf betyr at du mottar og bruker midler før transaksjonen er bekreftet on-chain. Bruk kun denne modellen mot leverandører med dokumentert oppetid og etablert rykte, siden en useriøs motpart i teorien kan dobbeltbruke midlene før bekreftelse.
  • Å ikke sette gebyrgrenser før produksjon. Uten max_proportional_fee_ppm og max_fixed_fee_msat satt eksplisitt, risikerer du å godta vilkår som endres uten varsel mellom hver forespørsel.
  • Å blande sammen LSPS1- og LSPS2-flyten. De løser forskjellige problemer. LSPS1 er for forhåndskjøp, LSPS2 er for betalingsutløst kanaletablering. Å sende en LSPS1-bestilling når du egentlig vil ha en JIT-kanal gir feil resultat og unødig forsinkelse.
  • Å teste direkte på mainnet med store beløp. Testnet og signet finnes nettopp for å fange opp konfigurasjonsfeil uten økonomisk risiko. Hopp aldri over denne fasen for å spare tid.
  • Å ignorere at JIT-kanaler gir skjev balanse over tid. En node som primært mottar kapasitet via LSPS2, ender fort opp med mye innkommende og lite utgående likviditet, noe som gjør det vanskelig å senere sende betalinger uten aktiv rebalansering.
  • Å anta at alle LSP-er støtter samme spesifikasjonsversjon. Spør alltid get_info først, og bygg klientlogikk som håndterer at en leverandør kan mangle støtte for enkelte felt eller parametre.
  • Å overse ACINQ sin alternative modell når du evaluerer økosystemet. Hvis analysen din kun ser på LSPS-adopsjon, overser du en betydelig del av markedet som i stedet bruker liquidity ads og dual funding.

Avanserte tips for drift i produksjon

Når grunnoppsettet fungerer, er det noen videre justeringer som gjør driften mer robust. Sett opp automatisk rotasjon mellom flere LSP-er i stedet for å avhenge av én enkelt leverandør, slik at en nedetid eller prisendring hos én LSP ikke stopper hele betalingsflyten din. Dette er i praksis det samme problemet som LSPS-standardene i utgangspunktet skal løse: unngå å binde deg til ett enkelt API.

Bygg inn en enkel prisovervåker som logger gebyrene flere LSP-er tilbyr for samme kanalstørrelse over tid, slik at du kan rute nye forespørsler til den leverandøren som er billigst akkurat nå i stedet for å hardkode én favoritt. Vurder også å kombinere LSPS1 for forutsigbar, planlagt kapasitet med LSPS2 som sikkerhetsnett for uventede innkommende betalinger, i stedet for å velge kun én modell. Til slutt, hvis du driver en lommebok-app med mange brukere, bør du aggregere JIT-kanalforespørsler der det er mulig, siden mange små, separate kanaler fra samme LSP ofte er dyrere i on-chain-gebyrer samlet sett enn færre, større kanaler delt mellom flere brukere internt.

Feilsøking: de vanligste problemene og løsningene

Her er en liste over problemer du sannsynligvis møter på, og konkrete steg for å løse dem.

  • Peer ikke tilgjengelig ved tilkobling til LSP-node: Bekreft at host og port er korrekte, og at noden din har utgående tilkobling tillatt gjennom brannmuren på riktig port (normalt 9735 for Lightning).
  • lsps1-getinfo returnerer tom respons: LSP-noden støtter sannsynligvis ikke LSPS1 i det hele tatt. Kontroller leverandørens dokumentasjon for hvilke LSPS-versjoner de faktisk implementerer før du fortsetter.
  • Ordren utløper før betaling er sendt: De fleste LSP-er setter en kort frist, ofte under en time, for å betale en LSPS1-ordre. Lag en ny ordre i stedet for å prøve å betale en utløpt faktura.
  • Zero-conf-kanalen vises ikke etter betaling: Kontroller at du faktisk brukte scid_alias fra lsps2.buy-svaret i fakturaen din. Uten dette aliaset kan ikke betaleren rute pengene til den enda ikke-eksisterende kanalen.
  • Gebyret er høyere enn forventet: Dobbeltsjekk at du satte max_proportional_fee_ppm og max_fixed_fee_msat i forespørselen. Uten disse godtar klienten som standard leverandørens opprinnelige tilbud uten forhandling.
  • Kanalen blir hengende i AWAITING_LOCKIN lenge: Dette er normalt for zero-conf i noen minutter, men hvis det varer time etter time, kontroller status på den underliggende on-chain-transaksjonen med en blokk-explorer.
  • LDK sin lightning-liquidity-crate feiler ved kompilering: Siden denne fortsatt er i alfa i 2026, bør du forvente brytende endringer mellom versjoner. Lås til en spesifikk commit i Cargo.toml i stedet for å følge hovedgrenen direkte.
  • Node-ID matcher ikke det som står i LSP-ens dokumentasjon: Noen leverandører roterer node-ID periodisk av driftsmessige grunner. Hent alltid gjeldende node-ID fra deres offisielle kanal før du initierer en betaling.
  • Betaling går gjennom, men ingen kanal opprettes: Dette tyder på at betalingen ble rutet via en eksisterende kanal i stedet for å utløse JIT-opprettelse. Kontroller at du faktisk ikke allerede har tilstrekkelig innkommende kapasitet fra før.

LSPS1 mot LSPS2: hvilken modell passer ditt bruksområde?

Valget mellom de to modellene handler i stor grad om hvor forutsigbar betalingsstrømmen din er. En nettbutikk som vet den skal motta et visst volum betalinger hver dag, har mer å vinne på å kjøpe forutsigbar kapasitet gjennom LSPS1, fordi gebyret er kjent på forhånd og uavhengig av hvor mye som faktisk betales inn. En ny lommebok-bruker som aldri har mottatt en Lightning-betaling før, har derimot ingen eksisterende kanal å bygge videre på, og da er LSPS2 den eneste modellen som fungerer uten at brukeren må gjøre noe teknisk i forkant.

KriteriumLSPS1 passer best nårLSPS2 passer best når
BrukererfaringErfaren bruker, planlegger kapasitet i forkantHelt ny bruker uten eksisterende kanal
BetalingsmønsterJevnt, forutsigbart volumEngangsbetaling eller uforutsigbart første innskudd
GebyrstrukturFast pris betalt i forkantTrukket fra selve innbetalingen
Risiko ved forsinkelseLav, kanalen finnes allerede ved betalingKort tidsvindu med zero-conf-eksponering
Typisk brukerNettbutikk, merchant, aktiv node-drifterLommebok-app for sluttbrukere, onboarding-flyt

I praksis bygger de mest robuste lommebok-appene støtte for begge modellene, og lar systemet selv velge den som passer best for hver enkelt situasjon i stedet for å tvinge brukeren til å forstå forskjellen. Det er også verdt å nevne at ACINQ sin tilnærming med liquidity ads og dual funding dekker deler av samme behov uten å gå via LSPS-rammeverket, noe som betyr at det nordiske Lightning-miljøet i praksis har flere parallelle veier til samme mål.

Hvorfor dette er relevant for nordiske Lightning-brukere nå

Lightning-adopsjon i Norden har historisk vært drevet av en liten, teknisk kjerne av node-driftere, men standardiseringen gjennom LSPS-spesifikasjonene gjør det enklere for norske og nordiske utviklere å bygge egne betalingsløsninger uten å måtte forhandle individuelle integrasjonsavtaler med hver likviditetsleverandør. Det reduserer også risikoen for å bli stående fast med en enkelt leverandør hvis den leverandøren endrer prisstrategi eller legger ned driften. Gitt at flere norske fintech-aktører har vist interesse for Bitcoin-baserte betalingsrails i 2026, er dette grunnarbeidet som gjør at fremtidige produkter kan bygges raskere og med lavere bindingsgrad til én enkelt LSP.

For nodedriftere som allerede kjører egen infrastruktur, betyr LSPS1 og LSPS2 også en mulighet til selv å tilby likviditetstjenester til andre, i stedet for kun å være konsument av dem. En node med god, aktiv kapital og stabil oppetid kan registrere seg som en LSP og generere inntekt gjennom kanalgebyrer, noe som ikke var praktisk mulig på samme skala før en standardisert protokoll gjorde det enkelt for lommebok-apper å koble seg til nye leverandører automatisk.

Du finner den fullstendige spesifikasjonsteksten i det offisielle repoet fra BitcoinAndLightningLayerSpecs, dokumentasjon for Core Lightning sin implementasjon hos docs.corelightning.org, og LDK sitt rammeverk for egne integrasjoner hos lightningdevkit.org. En god teknisk oppsummering av status per 2026 finnes også hos dev.to og i forskningsnotatet fra Spark Money. Alby Hub, som støtter LSPS1 i produksjon, har egen dokumentasjon tilgjengelig på albyhub.com.

Regneeksempel: hva en kanal faktisk koster i praksis

Tall er lettere å forholde seg til enn abstrakte prosentsatser, så la oss sette opp et konkret eksempel. Si at du ber om en LSPS2 JIT-kanal for en innkommende betaling på 300 000 000 millisatoshi, altså 300 000 satoshi. Leverandøren opererer med en fast sats på 2 000 000 millisatoshi (2 000 satoshi) pluss en proporsjonal sats på 2 500 deler per million (0,25 prosent) av beløpet.

Den proporsjonale delen av gebyret blir da 300 000 satoshi multiplisert med 0,0025, som gir 750 satoshi. Legg til den faste satsen på 2 000 satoshi, og det totale gebyret blir 2 750 satoshi, akkurat som i loggeksempelet i steg 7. Det tilsvarer omtrent 0,92 prosent av det opprinnelige beløpet i dette konkrete eksempelet, men den prosentandelen faller raskt ved større beløp siden den faste satsen forblir konstant uansett hvor stor betalingen er. Ved en betaling ti ganger så stor, 3 000 000 satoshi, ville det samme gebyret utgjort rundt 0,33 prosent i stedet, fordi den faste komponenten da utgjør en mindre andel av totalen.

Denne enkle utregningen er grunnen til at LSPS2 ofte er dyrere i prosent for små, enkeltstående betalinger enn for store. Hvis du bygger en lommebok-app der mange brukere mottar små beløp enkeltvis, er dette et konkret argument for å undersøke aggregerte kanalløsninger eller forhandle en lavere fast sats direkte med leverandøren, i stedet for å la hver enkeltbruker betale full fast sats for sin egen separate kanal.

Personvern og tillit: hva en LSP faktisk kan se

En Lightning-kanal krever at to noder stoler på hverandre for selve kanalbalansen, men det betyr ikke at de ser alt hverandres trafikk. Ruting i Lightning Network skjer gjennom onion-pakker etter samme prinsipp som Tor, slik at en mellomliggende node vanligvis bare ser forrige og neste hopp i en betaling, ikke hele ruten eller det endelige beløpet mottakeren sitter med. Når du bruker en LSP til å åpne en kanal, blir derimot LSP-noden selve mottaksendepunktet eller det første hoppet for den spesifikke betalingen, og da ser den langt mer enn en vanlig mellomliggende node ville gjort.

Konkret betyr dette at en LSP som åpner en JIT-kanal for deg, kjenner beløpet i den første betalingen, tidspunktet den ankom, og node-ID til den som sendte pengene til deg. Over tid kan en LSP som håndterer store deler av trafikken din bygge et ganske detaljert bilde av betalingsmønsteret ditt, selv om de aldri ser hva pengene faktisk brukes til etterpå. Dette er ikke unikt for Lightning, det samme gjelder i varierende grad for enhver tredjepartstjeneste som håndterer finansielle transaksjoner, men det er verdt å ha klart for seg før du velger hvor mye av trafikken din som skal gå gjennom én enkelt leverandør.

Praktiske tiltak for å begrense eksponeringen inkluderer å spre betalinger over flere LSP-er i stedet for å konsentrere all trafikk hos én, å foretrekke leverandører som ikke krever identitetsverifisering for mindre kanalstørrelser, og å supplere JIT-finansierte kanaler med egenfinansierte kanaler når volumet tillater det. Det reduserer avhengigheten av en enkelt leverandørs oversikt over betalingshistorikken din, og gir deg samtidig et reelt alternativ hvis en leverandør plutselig endrer vilkår eller stopper driften.

Planlegging av kanalstørrelse og kapitalbehov

Et spørsmål som ofte kommer opp etter at den tekniske biten er på plass, er hvor stor en kanal faktisk bør være. Svaret avhenger av forventet transaksjonsvolum, ikke av et fast tall som passer alle. En tommelfingerregel er å dimensjonere kanalen til omtrent to til tre ganger det største enkeltbeløpet du forventer å motta i løpet av en typisk uke, slik at du har nok slingringsmonn til at flere betalinger kan komme inn før kanalen må rebalanseres eller utvides.

For en LSPS1-bestilling betyr det at du bør gjøre denne vurderingen før du sender create_order, siden en for liten kanal fort blir en flaskehals, mens en for stor kanal betyr at du har betalt for kapasitet du ikke bruker på en stund. For LSPS2 er situasjonen litt annerledes, siden JIT-kanalen i praksis dimensjoneres etter størrelsen på selve den utløsende betalingen. Det betyr at den første kanalen ofte er mindre enn det du egentlig trenger over tid, og at du bør planlegge for å utvide kapasiteten manuelt eller gjennom en ny LSPS1-bestilling etter at den initielle JIT-kanalen er etablert.

Hold også et øye med on-chain-gebyrnivået når du planlegger kanalstørrelse. Når gebyrene på Bitcoin-nettverket er høye, blir det forholdsmessig dyrere å åpne mange små kanaler enn å åpne færre, større kanaler. Dette er en av grunnene til at flere LSP-er og lommebok-apper har begynt å tilby aggregerte JIT-kanaler for flere brukere samtidig, slik at kostnaden ved selve on-chain-transaksjonen deles mellom flere parter i stedet for å belastes én enkelt bruker fullt ut.

Ofte stilte spørsmål om Lightning-likviditet og LSP

Hva er forskjellen mellom en vanlig kanal og en just-in-time-kanal?
En vanlig kanal åpnes manuelt av noden selv, før noen betaling har skjedd, og krever at brukeren selv finansierer eller forhandler åpningen. En just-in-time-kanal via LSPS2 opprettes automatisk av en LSP i det øyeblikket en innkommende betaling ankommer, uten at brukeren har gjort noe på forhånd.

Er zero-conf-kanaler trygge å bruke?
De er trygge når motparten er en kjent, seriøs LSP med etablert drift, siden leverandøren i praksis tar på seg risikoen for dobbeltbruk i det korte tidsvinduet før on-chain-bekreftelse. Bruk dem ikke mot ukjente eller nylig etablerte noder uten dokumentert historikk.

Må jeg velge mellom LSPS1 og LSPS2, eller kan jeg bruke begge?
Du kan og bør normalt støtte begge. LSPS1 passer for planlagt, forhåndskjøpt kapasitet, mens LSPS2 passer for uforutsette eller første innkommende betalinger. De utelukker ikke hverandre.

Hvorfor bruker ikke ACINQ og Phoenix LSPS-spesifikasjonene?
ACINQ har valgt en alternativ teknisk vei basert på dual funding, splicing og liquidity ads, som løser mye av det samme likviditetsbehovet, men gjennom en annen protokollmekanisme enn LSPS1 og LSPS2.

Hvor mye kan jeg forvente å betale i gebyr for en JIT-kanal?
Gebyret varierer fra leverandør til leverandør og består typisk av en fast sats pluss en proporsjonal andel av beløpet som mottas. Hent alltid gjeldende satser direkte fra leverandørens get_info-svar før du sender en betaling, siden satsene kan endres over tid.

Kan jeg bygge min egen LSP med disse spesifikasjonene?
Ja. Både LSPS1- og LSPS2-spesifikasjonene er åpent dokumentert i det offisielle repoet, og Core Lightning sin kodebase inneholder referanseimplementasjoner som kan brukes som utgangspunkt for å tilby tjenesten til andre noder.

Hva skjer hvis LSP-noden går offline rett etter jeg har betalt for en LSPS1-ordre?
Dette er en reell risiko ved forhåndsbetalte ordrer. Velg leverandører med dokumentert oppetid, og vurder å starte med mindre beløp til du har bygget tillit til en bestemt leverandørs driftsstabilitet.

Trenger jeg en LSP hvis jeg allerede har flere velbalanserte kanaler?
Nei, ikke nødvendigvis. LSP-tjenester er mest nyttige for nye noder uten eksisterende kapasitet, eller for noder som opplever ujevn etterspørsel. En node med allerede god balanse i begge retninger har mindre å vinne på denne typen tjeneste.