I april 2026 slo Core Lightning på en funksjon som Lightning-utviklere hadde diskutert i nesten åtte år: kanal-splicing. Med versjon v26.04, utgitt 20. april 2026, ble det mulig å utvide eller krympe en betalingskanal uten å stenge den først. Ingen nedetid, ingen ny kanalforhandling fra bunnen, og ingen dobbel on-chain-kostnad for å lukke og åpne på nytt. Eclair fra ACINQ fulgte etter med endelig, standardisert støtte i versjon 0.14.0 den 21. mai samme år. For norske og nordiske nodeoperatører, som ofte kjører noder hjemme på strøm de allerede betaler for, er dette den største endringen i hvordan man forvalter likviditet siden dual-funded-kanaler ble vanlig.
Denne guiden viser deg nøyaktig hvordan du splicer en kanal i praksis: fra lavnivå-kommandoene splice_init, splice_update og splice_signed, til de nye høynivå-kommandoene splicein og spliceout som gjør prosessen langt enklere. Du får tolv konkrete steg, ferdige kommandoer du kan lime rett inn i terminalen, og en fullstendig gjennomgang av et ekte eksempel der vi utvider en kanal med 500.000 satoshi. Du får også en oversikt over hvor Core Lightning, Eclair og LND faktisk står i 2026, slik at du ikke sløser tid på funksjoner motparten din ikke støtter ennå.
Bitcoin- og Lightning-miljøet i Norge og Norden har lenge vært preget av selvforvaring: folk som kjører egen node hjemme, ofte på en Raspberry Pi eller en liten server ved siden av ruteren, fremfor å stole på en tredjepart for likviditetsstyring. For denne gruppen er splicing spesielt relevant, fordi det fjerner en av de kjedeligste driftsoppgavene med å drive en node: å måtte stenge og gjenåpne kanaler bare for å justere kapasiteten når rutingmønstre endrer seg. Guiden under er skrevet for deg som allerede har en kanal åpen og vil forstå både den manuelle lavnivå-flyten og de nye, enklere kommandoene, uten omveier.
Hva er kanal-splicing, og hvorfor det betyr noe nå
En vanlig Lightning-kanal er låst til en fast kapasitet fra det øyeblikket den åpnes. Vil du legge til mer likviditet, må du historisk sett stenge kanalen, vente på bekreftelser, og åpne en helt ny kanal med en ny on-chain-transaksjon. Det koster gebyrer to ganger, og kanalen er utilgjengelig for ruting i mellomtiden, gjerne i flere timer om mempool er full.
Splicing løser dette ved å la deg legge til midler (splice-in) eller trekke ut midler (splice-out) fra en allerede eksisterende kanal, gjennom én enkelt on-chain-transaksjon som oppdaterer kanalens forpliktelsesstruktur mens kanalen holdes åpen og operativ. Teknisk sett bygges det en ny Partially Signed Bitcoin Transaction (PSBT) som bruker det gamle kanal-utfallet som input og skaper et nytt, oppdatert utfall som output. Begge parter signerer, transaksjonen sendes til nettverket, og når den er bekreftet nok ganger fortsetter kanalen å rute betalinger med sin nye kapasitet.
Ifølge Core Lightning-dokumentasjonen ble de første lavnivå-kommandoene for splicing, splice_init og splice_update, lagt til allerede i versjon 23.08. Det tok likevel nesten tre år før funksjonen gikk fra eksperimentell til produksjonsklar standard. Bitcoin Optech, som følger utviklingen i Bitcoin-protokollen tett, noterer at Core Lightning-pull request #8817 rettet konkrete interoperabilitetsproblemer mot Eclair så sent som 20. mars 2026, bare en måned før splicing ble slått på som standard. Det forteller noe viktig: selv en modnet funksjon som splicing har hatt reelle kompatibilitetsbugger mellom implementasjoner helt fram til nylig, og det er grunnen til at versjonssjekk er steg én i denne guiden, ikke en fotnote.
Splice-in vs. splice-out: to retninger, én kanal
Splice-in betyr at du legger nye midler inn i en eksisterende kanal. Det er nyttig når du ruter mye trafikk gjennom en kanal og stadig går tom for utgående likviditet, uten å måtte åpne en helt ny kanal til samme motpart. Splice-out betyr det motsatte: du trekker midler ut av kanalen til en on-chain-adresse, uten å stenge kanalen. Det er relevant når du vil ta ut overskuddslikviditet, for eksempel etter at en kanal har samlet opp mye innkommende kapasitet fra ruting, uten å miste den etablerte kanalrelasjonen og ryktet den har bygget seg opp i nettverket.
Den mest interessante varianten er det Core Lightning kaller cross-splice: spliceout-kommandoen kan ta imot en andre kanal-ID som mål, slik at likviditet flyttes direkte fra én kanal til en annen i samme node, i én og samme on-chain-transaksjon. Det fjerner behovet for et mellomliggende on-chain-oppgjør, og er i praksis den mest kapitaleffektive måten å rebalansere en nodes kanalportefølje på i 2026.
Derfor sparer splicing penger og driftstid
Den tradisjonelle måten å endre kanalkapasitet på krever to separate on-chain-transaksjoner: én for å stenge den gamle kanalen, og én for å åpne den nye. Begge transaksjonene konkurrerer om plass i samme mempool som alt annet Bitcoin-nettverket behandler akkurat da, og begge må betale en gebyrsats som markedet setter i det øyeblikket. Splicing erstatter dette med én enkelt transaksjon som oppdaterer den eksisterende kanalens forpliktelsesstruktur. Strukturelt ligner en splice-transaksjon på en enkelt kanalåpning: den bruker det eksisterende kanal-utfallet som input og skaper et nytt, oppdatert kanal-utfall som output, i stedet for å avslutte én kjede av transaksjoner og starte en helt ny.
Den andre kostnaden er tid og tilgjengelighet, ikke bare kroner og øre. Når du stenger en kanal tradisjonelt, er den kanalen borte fra rutingtabellen din til den nye er åpnet og har fått nok bekreftelser og kanalannonsering i nettverket. Det kan bety timer eller i verste fall dager uten den ruting-kapasiteten, avhengig av hvor raskt blokker kommer og hvor lenge du venter med å annonsere kanalen på nytt. Med splicing beholder kanalen sin identitet og sitt etablerte rykte i nettverket gjennom hele prosessen. Den fortsetter å rute betalinger normalt mens splice-transaksjonen venter på bekreftelser i bakgrunnen, og går bare kort inn i tilstanden CHANNELD_AWAITING_SPLICE underveis.
For en nodeoperatør som ruter mye trafikk, er dette forskjellen mellom å miste inntekter fra rutinggebyrer i flere timer, og knapt merke at kapasiteten endret seg. For en privatperson som bare vil justere sin egen kanal mot en favorittleverandør eller et vekslingssted, er gevinsten enklere: du sparer én hel on-chain-transaksjon i gebyrer, uansett hvor høy eller lav feeraten er den dagen.
Forutsetninger: programvare, versjoner og maskinvare du trenger
Før du starter må noden din oppfylle noen konkrete krav. Dette er ikke en øvelse du bør gjøre på en kanal med reelle midler før du har testet flyten minst én gang.
- Core Lightning v26.04 eller nyere for stabil, standardpåslått splicing med høynivå-kommandoene
spliceinogspliceout. Nyeste stabile versjon per september 2026 er v26.06.7, utgitt 28. august 2026, som i hovedsak inneholder sikkerhetsrettelser fremfor nye splice-funksjoner. - Bitcoin Core kjørende som full node med oppdatert UTXO-sett. Splicing bygger PSBT-er direkte mot lommeboken din, så en pruned node uten tilstrekkelig indeksering kan gi problemer under
fundpsbt. - En eksisterende, åpen kanal med minst én bekreftelse, og ingen HTLC-er som henger i limbo.
- jq installert for å lese JSON-svar fra
lightning-cliuten å måtte tolke rå tekst manuelt. - En motpart som også støtter splicing på sin side av kanalen. Er motparten på LND, må du regne med begrenset støtte (mer om det lenger ned).
- Nok on-chain-saldo i din Core Lightning-lommebok til å dekke både beløpet du vil splice inn og nettverksgebyret.
Kommandoreferansen under viser hvilke splice-relaterte RPC-kall som finnes, og hvilken versjon de ble introdusert i, hentet direkte fra Core Lightning sin offisielle dokumentasjon.
| Kommando | Formål | Introdusert i | Nivå |
|---|---|---|---|
| listpeerchannels | Lister kanaler og henter kanal-ID | Tidlig versjon | Info |
| fundpsbt | Bygger en PSBT med midler fra lommeboken | Tidlig versjon | Info |
| splice_init | Starter en kanal-splice med kanal-ID og relativt beløp | v23.08 | Lavnivå |
| splice_update | Forhandler PSBT-en fram til begge parter er enige | v23.08 | Lavnivå |
| signpsbt | Signerer den forhandlede PSBT-en lokalt | Tidlig versjon | Info |
| splice_signed | Fullfører splicen og kringkaster transaksjonen | v23.08 | Lavnivå |
| dev-splice (splice) | Høynivå-kommando som kombinerer flere steg, egen PSBT-flyt | v24.11 | Mellomnivå |
| splicein | Legger midler inn i en kanal med én kommando | v26.04 | Høynivå |
| spliceout | Trekker midler ut, støtter cross-splice til annen kanal | v26.04 | Høynivå |
Steg 1–2: Oppdater noden og sjekk kanalstatus
Start med å bekrefte hvilken versjon du faktisk kjører. Mange noder som ble satt opp i 2024 eller tidlig 2025 kjører fortsatt en versjon uten splicein og spliceout, selv om de har de gamle lavnivå-kommandoene tilgjengelig.
lightning-cli --version
# Forventet output (eksempel):
# v26.06.7Er du under v26.04, oppgrader før du fortsetter. Følg standard oppgraderingsprosedyre for din distribusjon (pakkebehandler, Docker-image eller kompilering fra kildekode), og restart lightningd etterpå. Ikke hopp over dette steget: å prøve å kjøre splicein på en eldre versjon gir bare en feilmelding om at kommandoen ikke finnes, og det er den vanligste årsaken til at nye brukere tror splicing er ødelagt.
Finn riktig kanal-ID
Alle splice-kommandoer krever en kanal-ID, ikke et node-ID eller en kort-kanal-ID. Hent den slik:
lightning-cli listpeerchannels | jq '.channels[] | {peer_id, channel_id, short_channel_id, total_msat}'Output-eksempel:
{
"peer_id": "03a1b2c3d4e5f6...",
"channel_id": "8f3e2d1c0b9a...",
"short_channel_id": "902341x1234x0",
"total_msat": 2000000000
}Noter channel_id-verdien. Det er denne du bruker i alle kommandoene under, ikke short_channel_id.
Steg 3–4: Bygg PSBT og start splicen
Skal du splice inn 500.000 satoshi, må du først lage en PSBT som bruker midler fra din on-chain-lommebok. Bruk fundpsbt med et beløp og en gebyrsats du er komfortabel med, gitt mempool-forholdene akkurat da:
lightning-cli fundpsbt satoshi=500000sat feerate=urgent startweight=0 excess_as_change=trueKommandoen returnerer en PSBT-streng du trenger i neste steg. Start så selve splicen med splice_init, som tar kanal-ID, et relativt beløp (positivt for splice-in, negativt for splice-out) og den PSBT-en du nettopp lagde:
lightning-cli splice_init channel_id=8f3e2d1c0b9a... relative_amount=500000 initialpsbt=cHNidP8BA...Ifølge dokumentasjonen tar splice_init også valgfrie parametere for feerate_per_kw og force_feerate, som er nyttige om du vil overstyre gebyrsatsen manuelt fordi mempool endrer seg raskt mens du forhandler.
Steg 5–7: Forhandle og signer PSBT-en
Dette er stedet flest nybegynnere står fast, fordi splice_update ikke er et engangskall. Den må kalles gjentatte ganger til feltet commitments_secured i svaret blir true. Hver runde kan endre inputs og outputs litt, ettersom noden din og motparten forhandler seg fram til en felles transaksjon:
lightning-cli splice_update channel_id=8f3e2d1c0b9a... psbt=cHNidP8BA...
# Gjenta med PSBT-en fra forrige svar helt til:
# "commitments_secured": trueFra og med v24.11 la Core Lightning til feltet signatures_secured i svaret, som forteller deg om motparten allerede har sendt sine signaturer for splicen. Når commitments_secured er true, signerer du PSBT-en lokalt:
lightning-cli signpsbt cHNidP8BA...Kommandoen returnerer en signert PSBT du trenger i det siste steget i lavnivå-flyten.
Steg 8: Fullfør splicen med splice_signed
Siste steg i den klassiske lavnivå-flyten kringkaster transaksjonen til Bitcoin-nettverket:
lightning-cli splice_signed channel_id=8f3e2d1c0b9a... signed_psbt=cHNidP8BA...Etter dette går kanalen inn i en midlertidig tilstand mens transaksjonen venter på bekreftelser. Kanalen fortsetter normalt å rute betalinger med den gamle kapasiteten inntil splicen er bekreftet nok ganger, noe som er hele poenget med funksjonen: ingen nedetid mens du venter på blokker.
Steg 9–10: Høynivå-kommandoene splicein og spliceout
Den seks-trinns lavnivå-flyten over er nyttig å forstå, men fra v26.04 trenger du den sjelden i praksis. De nye høynivå-kommandoene splicein og spliceout pakker sammen fundpsbt, splice_init, forhandlingsløkken, signering og kringkasting i ett enkelt kall. Ifølge Core Lightnings referansedokumentasjon for den underliggende splice-kommandoen kan flere handlinger kombineres i én enkelt on-chain-transaksjon:
# Splice-in: legg til 500 000 sats i en eksisterende kanal
lightning-cli splicein channel_id=8f3e2d1c0b9a... amount=500000sat
# Splice-out: trekk ut 200 000 sats til en on-chain-adresse
lightning-cli spliceout channel_id=8f3e2d1c0b9a... amount=200000sat destination=bc1q...Dette er den anbefalte måten å splice på for de fleste driftsscenarioer i 2026. Du mister litt finkontroll sammenlignet med den manuelle flyten, men vinner betydelig mindre risiko for menneskelige feil i PSBT-håndteringen.
Steg 11: Cross-splice mellom to kanaler
Har du to kanaler der den ene har for mye innkommende kapasitet og den andre for lite utgående, kan du flytte likviditet direkte mellom dem uten et mellomliggende on-chain-steg. spliceout-kommandoen godtar en andre kanal-ID som mål:
lightning-cli spliceout channel_id=8f3e2d1c0b9a... amount=300000sat destination_channel_id=1a2b3c4d5e6f...Dette er trolig den mest kapitaleffektive rebalanseringsteknikken som finnes på Lightning Network per i dag. Vær oppmerksom på at cross-splice mot en Eclair-motpart historisk har hatt interoperabilitetsbugger, rettet i Core Lightning gjennom pull request #8817 i mars 2026, så pass på at begge noder kjører oppdatert programvare før du prøver dette mot en ekstern motpart.
Steg 12: Bekreft splicen på kjeden og i kanalen
Når splicen er sendt, følg den gjennom mempool og til den har nok bekreftelser (de fleste noder krever minst tre til seks, avhengig av beløpets størrelse). Sjekk kanalstatus underveis:
lightning-cli listpeerchannels | jq '.channels[] | select(.channel_id=="8f3e2d1c0b9a...") | {state, total_msat}'
# Forventet mellomtilstand:
# "state": "CHANNELD_AWAITING_SPLICE"
# Etter bekreftelse:
# "state": "CHANNELD_NORMAL", "total_msat": 2500000000Går total_msat opp fra 2.000.000.000 til 2.500.000.000 millisatoshi, har splicingen fungert, og kanalen har nå 2.500.000 satoshi i total kapasitet i stedet for de opprinnelige 2.000.000. Oppdater også din statiske kanal-backup umiddelbart etter en vellykket splice, siden commitment-strukturen har endret seg.
Sikkerhetshensyn før du signerer en splice-PSBT
Splicing flytter selve tillitsmodellen for en kanaloppdatering over på PSBT-formatet, og det gir deg et konkret sted å verifisere hva du faktisk signerer. Før du kaller signpsbt i den manuelle flyten, bør du dekode PSBT-en og sjekke at inputs og outputs stemmer med det du forventer, spesielt beløpet som flyttes og at eventuell endring (change) går til en adresse du kontrollerer. Dette er samme prinsipp som med enhver annen Bitcoin-transaksjon: PSBT-formatet lar deg se nøyaktig hva du signerer før du signerer det, i motsetning til å stole blindt på det underliggende programmet.
Vær også oppmerksom på selve splice_update-løkken. Fordi PSBT-en kan endre seg for hver runde mens partene forhandler, bør et automatisert skript aldri signere blindt på siste PSBT uten en sanity-sjekk av at det forhandlede beløpet fortsatt matcher det du opprinnelig ba om. En motpart som oppfører seg uventet midt i forhandlingen, bør avbrytes fremfor at du presser gjennom en splice for enhver pris. Siden splicing fortsatt er en relativt ung funksjon sammenlignet med resten av Lightning-protokollen, med den nevnte interoperabilitetsrettelsen mellom Core Lightning og Eclair så sent som mars 2026, er det fornuftig å behandle den med samme forsiktighet som du ville brukt på enhver ny protokollfunksjon: test grundig, verifiser output, og ikke splice store beløp før du har gjort mindre operasjoner først.
Til slutt, hold RPC-grensesnittet til lightningd bak et grensesnitt du kontrollerer. Splice-kommandoene flytter reelle midler, og en lightning-cli eksponert uten tilgangskontroll til internett er like farlig som en åpen lommebok-RPC. Bruk Unix-socket lokalt eller en autentisert, kryptert tunnel om du trenger fjerntilgang til noden.
Kompatibilitet i 2026: Core Lightning, LND og Eclair
Splicing er ikke like modent overalt. Om motparten din kjører en annen implementasjon enn deg, må du sjekke hva som faktisk er støttet før du planlegger en splice mot den kanalen. Tabellen under er satt sammen fra offisielle utgivelsesnotater for Core Lightning og utgivelsesnotater for Eclair på GitHub, samt offentlige GitHub-diskusjoner for LND.
| Implementasjon | Versjon | Splicing-status | Dato |
|---|---|---|---|
| Core Lightning | v23.08 | Lavnivå-kommandoer (eksperimentelt) | 2023 |
| Core Lightning | v24.11 | Mellomnivå dev-splice, signatures_secured lagt til | November 2024 |
| Core Lightning | v26.04 | splicein/spliceout, splicing standard påslått | 20. april 2026 |
| Core Lightning | v26.06.7 | Sikkerhetsoppdateringer, splicing uendret | 28. august 2026 |
| Eclair (ACINQ) | v0.14.0 | Endelig, standardisert splicing | 21. mai 2026 |
| Eclair (ACINQ) | v0.14.2 | Siste stabile versjon | 26. august 2026 |
| LND (Lightning Labs) | v0.21.0-beta | Delvis: splice-in støttet ifølge offentlige GitHub-diskusjoner, full splice-out-paritet ikke bekreftet | 2026 |
Hva betyr dette for noder med blandet programvare?
Kjører du Core Lightning mot en Eclair-motpart, kan du forvente full støtte for standardisert splicing så lenge begge sider er på Core Lightning v26.04 eller nyere og Eclair v0.14.0 eller nyere. Er motparten på LND, bør du gå ut fra at splice-out og cross-splice ikke fungerer pålitelig ennå, mens et forsøk på splice-in kan fungere avhengig av nøyaktig LND-versjon. I praksis betyr det at du bør sjekke motpartens node-programvare, for eksempel via node-utforskere som viser implementasjon og versjon, før du planlegger en splice mot en ekstern kanal du ikke selv kontrollerer begge sider av.
LDK, biblioteket bak flere lommebok- og infrastrukturprosjekter som bygger egne Lightning-klienter, oppgis i bransjesammenligninger publisert i 2026 å ha produksjonsstøtte for splicing på linje med Core Lightning og Eclair. Fordi LDK er et bibliotek og ikke en ferdig node-applikasjon i seg selv, avhenger den faktiske splice-opplevelsen av hvordan hver enkelt lommebok eller tjeneste har implementert funksjonen på toppen av biblioteket. Sjekk dokumentasjonen til den spesifikke LDK-baserte klienten du eller motparten din bruker, fremfor å anta at LDK-støtte automatisk betyr at akkurat den appen har eksponert splice-funksjonalitet til sluttbrukeren.
Test splicing risikofritt på testnet eller signet først
Før du kjører noen av kommandoene over mot en kanal med reelle midler, sett opp en testkanal på Bitcoin sitt testnet eller på signet, som er mer stabilt og forutsigbart for utviklingsformål. Verktøy som Polar lar deg spinne opp flere Core Lightning-noder lokalt i containere, koble dem sammen med kanaler, og øve på hele splice-flyten uten at noe koster ekte satoshi. Gå gjennom nøyaktig de samme tolv stegene i denne guiden på testnettet: oppdater versjon, hent kanal-ID, bygg PSBT, kjør splice_init eller splicein, og bekreft at kapasiteten endrer seg som forventet.
Legg spesielt merke til hvordan noden din håndterer en avbrutt splice. Koble fra en av testnodene midt i en splice_update-forhandling, og se hva som skjer med kanaltilstanden. Det gir deg et realistisk bilde av feilmodus før du står i en situasjon med reelle midler og en forhandling som ikke fullfører seg selv. Når du har kjørt gjennom minst tre til fire vellykkede splicer på testnett eller signet, inkludert minst én cross-splice mellom to av dine egne testkanaler, er du i en langt bedre posisjon til å gjøre det samme i produksjon.
Ordliste: sentrale begreper i denne guiden
- PSBT (Partially Signed Bitcoin Transaction): Et standardisert format for å bygge og signere Bitcoin-transaksjoner i flere steg, ofte mellom flere parter eller flere verktøy, før transaksjonen er komplett og klar til kringkasting.
- Kanal-ID (channel_id): En lang, unik identifikator for en spesifikk Lightning-kanal, avledet fra kanalens funding-transaksjon. Ikke å forveksle med det kortere
short_channel_id, som er avledet fra kanalens plassering i blokkjeden. - HTLC (Hashed Timelock Contract): Mekanismen som lar betalinger rute trygt gjennom flere Lightning-kanaler, ved at midler er låst til en hemmelighet og en tidsfrist samtidig.
- Commitment-transaksjon: Den underliggende on-chain-transaksjonen som til enhver tid representerer den nyeste avtalte balansen i en kanal, og som kan kringkastes hvis noe går galt.
- RBF (Replace-By-Fee): En mekanisme som lar deg erstatte en ubekreftet transaksjon med en ny versjon som betaler høyere gebyr, nyttig hvis en splice-transaksjon sitter fast i mempool.
- Cross-splice: En splice-out-operasjon der destinasjonen er en annen av dine egne kanaler i stedet for en on-chain-adresse, slik at likviditet flyttes direkte mellom kanaler.
- Spendable_msat: Feltet i
listpeerchannelssom viser hvor mye utgående kapasitet en kanal faktisk har tilgjengelig akkurat nå, brukt som terskelverdi i vaktskriptet lenger opp i artikkelen. - Submarine swap: En byttetransaksjon mellom on-chain og Lightning-midler gjennom en tredjepart, brukt som alternativ til splicing når du trenger midlertidig mottakskapasitet raskt.
Fem vanlige fallgruver ved kanal-splicing
De fleste splice-relaterte problemer kommer ikke fra selve protokollen, men fra hvordan operatøren bruker den. Her er feilene vi ser oftest når noder tar i bruk splicing for første gang.
- Starte en splice på en kanal med pending HTLC-er. Splicing forutsetter en ren kanaltilstand. Har kanalen betalinger som ikke er ferdig avregnet, bør du vente til de er løst før du kaller splice_init.
- Bruke for lav feerate i en travel mempool. Går gebyrsatsen du valgte under markedsprisen, kan splice-transaksjonen sitte fast ubekreftet i timevis eller dager, og kanalen blir stående i en midlertidig tilstand lenger enn nødvendig.
- Anta at motparten støtter det samme du gjør. Å kalle spliceout med destination_channel_id mot en LND-node som ikke har full støtte, gir bare feilmeldinger og bortkastet tid.
- Glemme at splice_update må kalles gjentatte ganger. Mange nybegynnere kaller den én gang, ser at commitments_secured er false, og tror prosessen har feilet, når løsningen bare er å kalle den på nytt med den returnerte PSBT-en.
- Ikke oppdatere kanal-backupen etter en splice. Fordi commitment-strukturen endres, blir en gammel statisk kanal-backup (SCB) ugyldig for gjenoppretting av den nye tilstanden.
- Blande sammen kanal-ID og short_channel_id. Splice-kommandoene krever den lange kanal-ID-en, ikke det kortere formatet du ser i faktureringsverktøy og block explorers.
- Teste i produksjon uten en testnet-øvelse først. Splicing involverer PSBT-håndtering, og en feil håndtert PSBT kan i verste fall koste deg gebyrer på en mislykket transaksjon.
Splicing sammenlignet med submarine swaps
Splicing er ikke den eneste måten å justere likviditet på i Lightning Network. Submarine swaps, der du bytter en on-chain-betaling mot innkommende Lightning-likviditet gjennom en tredjeparts swap-tjeneste, har lenge vært den vanlige metoden for å skaffe seg mottakskapasitet raskt uten å måtte overtale en motpart til å åpne en kanal mot deg. Forskjellen er strukturell: en submarine swap endrer ikke selve kanalkapasiteten, den flytter bare balansen internt i en eksisterende kanal via en ekstern part, og krever tillit til at swap-tjenesten fullfører sin del av byttet innenfor tidsfristen.
Splice-in gir deg derimot en reell økning i total kanalkapasitet, uten en tredjepart involvert i selve transaksjonen. Det gjør splicing mer egnet når du vil bygge varig, større kapasitet med en motpart du allerede har en etablert kanal med, mens submarine swaps fortsatt har sin plass når du trenger rask, midlertidig mottakskapasitet og ikke vil vente på en on-chain-bekreftelse i det hele tatt. Mange erfarne nodeoperatører bruker begge metodene om hverandre, avhengig av om behovet er kortsiktig balanse eller langsiktig kapasitet.
En tredje vei mange nordiske noder også vurderer er rett og slett å åpne en helt ny, større kanal til samme motpart i tillegg til den eksisterende, fremfor å splice. Det er fortsatt fornuftig i noen tilfeller, for eksempel om du ønsker separate kanaler for ulike ruting-strategier eller vil unngå at all kapasitet mot én motpart ligger i en enkelt kanal som kan bli midlertidig utilgjengelig ved en feil. Splicing utkonkurrerer likevel dette alternativet rent kostnadsmessig i de fleste tilfeller, siden du uansett unngår den doble transaksjonskostnaden en fullstendig stenging og ny åpning ville krevd, selv om du ender opp med å administrere ett tall færre kanaler enn du ellers ville gjort.
Feilsøking: åtte problemer og løsningene
Selv med oppdatert programvare på begge sider av kanalen, dukker det opp konkrete feilmeldinger og fastlåste tilstander i praksis. Tabellen under samler de vanligste problemene nodeoperatører støter på under splicing, med den mest sannsynlige årsaken og hvordan du løser det.
| Problem | Sannsynlig årsak | Løsning |
|---|---|---|
| «unknown command: splicein» | Node kjører eldre versjon enn v26.04 | Oppgrader Core Lightning, restart lightningd |
| splice_update henger uten å nå commitments_secured | Motparten er ikke tilkoblet, eller kjører en gammel versjon | Sjekk peer-tilkobling med listpeers, verifiser versjon hos motparten |
| signpsbt feiler med manglende UTXO | Lommeboken har brukt UTXO-en i mellomtiden | Kjør fundpsbt på nytt for en fersk PSBT |
| Splice-transaksjonen sitter ubekreftet lenge | For lav feerate valgt ved splice_init | Bruk force_feerate for å sette en høyere sats, eller RBF-bump transaksjonen |
| Kanal fastlåst i CHANNELD_AWAITING_SPLICE | Venter fortsatt på nok bekreftelser | Vent, sjekk bitcoind-synkronisering med bitcoin-cli getblockchaininfo |
| Cross-splice feiler mot Eclair-motpart | En av nodene mangler fiksen fra PR #8817 | Oppgrader begge noder til nyeste stabile versjon |
| Ny kapasitet vises ikke etter bekreftelse | Node-cache ikke oppdatert | Kjør listpeerchannels på nytt, vurder restart av lightningd |
| PSBT avvises med «invalid PSBT format» | PSBT-streng er kuttet eller feil kopiert mellom kommandoer | Kopier hele den returnerte PSBT-strengen på nytt, unngå linjeskift |
| «splicing not enabled» på tross av ny versjon | Eksperimentelt flagg fra eldre config-fil overstyrer standard | Fjern gamle experimental-splicing-linjer fra config-filen |
Avanserte tips for produksjonsnoder
Når du har gjort noen splicer manuelt og forstår flyten, er det verdt å bygge inn dette i den daglige driften av noden. Sett opp overvåking av mempool-gebyrer før du planlegger en splice, slik at du ikke starter en operasjon rett før en periode med høy nettverksbelastning. Kombiner splice-in med en fast rutine for likviditetsstyring, for eksempel å splice inn friske midler på kanaler som systematisk går tomme for utgående kapasitet i ruting-statistikken din.
Test alltid nye splice-operasjoner på testnet eller signet før du kjører dem mot en kanal med reelle midler, spesielt om du skal automatisere prosessen med skript. Hold en oppdatert, verifisert kanal-backup etter hver eneste splice, ikke bare de store. Følg også med på utviklingen rundt taproot-kanaler: Eclair støtter allerede oppgradering av eldre kanaler til taproot-format under en splice, mens LND har lagt inn grunnarbeid for nonce-koordinering ved splice-operasjoner i taproot-kanaler gjennom pull request #9982 på GitHub. Det peker mot at splicing og taproot-kanaler kommer til å smelte sammen som standardverktøy for nodeoperatører i løpet av de neste versjonene.
Kjører du et grafisk styringspanel som Ride The Lightning (RTL) eller bruker et RPC-lag som Sparko for fjerntilgang, sjekk at verktøyet faktisk har lagt til støtte for de nye splice-kommandoene før du stoler på grensesnittet fremfor lightning-cli direkte. Flere administrasjonsverktøy hang etter kjernefunksjonaliteten i månedene rett etter at splicing ble standard i v26.04, og viste bare kanalens gamle kapasitet inntil de ble oppdatert. For nordiske nodeoperatører som gjerne kjører noden hjemme på lavt strømforbruk, er splicing også en fin anledning til å konsolidere flere små kanaler til noen få større, mer kapitaleffektive kanaler, i stedet for å sitte med et stort antall små kanaler som hver krever egen vedlikeholdsoppmerksomhet og egen kanal-backup.
Automatiser splicing med et vaktskript
Når du er komfortabel med å splice manuelt, er neste steg gjerne å automatisere rutinemessige justeringer. Et enkelt vaktskript kan sjekke om en kanal har falt under en gitt terskel for utgående kapasitet, og trigge en splicein automatisk fra en on-chain-lommebok som er øremerket til dette formålet. Under er et minimalt eksempel som poller kanalstatus og logger en anbefaling, uten å signere noe automatisk. Bygg gjerne videre selv når du stoler på flyten:
#!/bin/bash
# splice-watch.sh - varsler når en kanal bør splices
CHANNEL_ID="8f3e2d1c0b9a..."
THRESHOLD_MSAT=500000000
CURRENT=$(lightning-cli listpeerchannels | \
jq -r --arg cid "$CHANNEL_ID" \
'.channels[] | select(.channel_id==$cid) | .spendable_msat')
if [ "$CURRENT" -lt "$THRESHOLD_MSAT" ]; then
echo "$(date): Kanal $CHANNEL_ID under terskel ($CURRENT msat). Vurder splicein."
else
echo "$(date): Kanal $CHANNEL_ID OK ($CURRENT msat spendable)."
fiSett dette som en cron-jobb som kjører hver time, og la den varsle deg via e-post eller en enkel webhook fremfor å utføre splicein automatisk med reelle midler. Splicing er fortsatt en operasjon som flytter penger, og selv med den nye høynivå-flyten er det klokt å ha et menneske som trykker på den siste knappen inntil du har kjørt prosessen manuelt mange nok ganger til å stole fullt på den.
Utvider du skriptet senere til faktisk å utføre splicer automatisk, sett en øvre grense på beløp per operasjon og et minimum antall timer mellom hver kjøring. Det hindrer et skript med en logisk feil i å kalle splicein gjentatte ganger og bygge opp unødvendige on-chain-kostnader, eller i verste fall tømme lommeboken din øremerket til splicing raskere enn du hadde planlagt.
Komplett eksempel: utvid en kanal med 500.000 sats fra start til slutt
La oss sette sammen alt i ett scenario. Du har en kanal på 2.000.000 sats som ruter mye trafikk, og du vil legge til 500.000 sats i utgående kapasitet. Noden din kjører Core Lightning v26.06.7, og motparten kjører Eclair v0.14.2, så begge sider støtter standardisert splicing.
# 1. Bekreft versjon
lightning-cli --version
# 2. Finn kanal-ID
lightning-cli listpeerchannels | jq '.channels[] | {channel_id, total_msat, state}'
# 3. Utfør splice-in med høynivå-kommandoen
lightning-cli splicein channel_id=8f3e2d1c0b9a... amount=500000sat
# 4. Følg status underveis
lightning-cli listpeerchannels | jq '.channels[] | select(.channel_id=="8f3e2d1c0b9a...") | {state, total_msat}'Forventet output
Rett etter steg 3 vil kanalen typisk vise "state": "CHANNELD_AWAITING_SPLICE". Etter tre til seks bekreftelser, avhengig av nettverksforholdene, endres tilstanden tilbake til "state": "CHANNELD_NORMAL", og total_msat vil vise 2.500.000.000 millisatoshi, altså 2.500.000 satoshi i total kapasitet. Kanalen har rutet betalinger som normalt gjennom hele prosessen, og du har ikke betalt for å lukke og åpne en ny kanal.
Vil du i stedet trekke ut 200.000 av de nye sats-ene igjen til en kald lagringsadresse, gjentar du bare prinsippet med spliceout i stedet for splicein, med en destination-adresse i parameteren.
Ofte stilte spørsmål
Hva er egentlig forskjellen på splice-in og splice-out?
Splice-in legger nye midler inn i en eksisterende kanal og øker kapasiteten. Splice-out trekker midler ut av kanalen til en on-chain-adresse eller til en annen kanal, og reduserer kapasiteten. Begge skjer uten å stenge kanalen.
Må jeg stenge kanalen for å splice den?
Nei, det er hele poenget med funksjonen. Kanalen forblir åpen og kan rute betalinger under hele prosessen, med unntak av en kort periode der den venter på bekreftelser for splice-transaksjonen.
Hvilken minimumsversjon av Core Lightning trenger jeg for splicing?
De grunnleggende lavnivå-kommandoene finnes fra v23.08, men for stabil, standardpåslått splicing med de enklere kommandoene splicein og spliceout, trenger du v26.04 eller nyere.
Støtter LND splicing i 2026?
Delvis. Ifølge offentlige GitHub-diskusjoner om LND v0.21.0-beta er splice-in støttet i noen grad, men full paritet med Core Lightnings splice-out-flyt er ikke bekreftet. Sjekk alltid motpartens node-versjon før du planlegger en splice mot en ekstern LND-kanal.
Hva skjer hvis motparten min ikke støtter splicing?
Splice-kommandoen feiler med en feilmelding, og ingen midler flyttes. Du må da falle tilbake på den tradisjonelle metoden: stenge kanalen og åpne en ny med ønsket kapasitet.
Koster splicing mer i gebyrer enn å stenge og åpne kanalen på nytt?
Nei, normalt tvert imot. Splicing krever kun én on-chain-transaksjon, mens å stenge og åpne på nytt krever to separate transaksjoner, hver med sitt eget gebyr basert på mempool-forholdene på tidspunktet.
Kan jeg avbryte en splice etter at jeg har startet den?
Før du har kalt splice_signed eller den tilsvarende høynivå-kommandoen, kan forhandlingen i praksis avbrytes ved at du eller motparten kobler fra uten å fullføre. Etter at transaksjonen er signert og kringkastet, må du la den enten bekreftes eller falle ut av mempool før du kan starte på nytt.
Er cross-splice det samme som en vanlig rebalansering?
Nei. Vanlig rebalansering flytter likviditet gjennom Lightning-nettverket via ruting, uten noen on-chain-transaksjon. Cross-splice flytter i stedet midler direkte mellom to av dine egne kanaler gjennom én on-chain-transaksjon, noe som er mer forutsigbart men koster et nettverksgebyr.
Bør jeg drifte noden hjemme eller på en server for å bruke splicing?
Splicing i seg selv stiller ingen ekstra krav til hvor noden kjører. Det som betyr noe er oppetid under selve splice-forhandlingen: mister du tilkoblingen til motparten midt i en splice_update-runde, må forhandlingen startes på nytt. Både en hjemmenode på stabilt bredbånd og en driftet server fungerer fint, så lenge internettforbindelsen ikke faller ut i minuttene operasjonen tar.
