Bitcoin Kvantesjekk: Sikre Adressen i 12 Steg [2026]

Rundt 6 millioner bitcoin sitter i dag på adresser der den offentlige nøkkelen allerede er synlig på kjeden, eller vil bli synlig den dagen eieren bruker dem. Det tallet kommer fra flere uavhengige analyser i 2026, blant annet en Glassnode-gjennomgang som lander på 6,04 millioner BTC fordelt på strukturell eksponering (hovedsakelig gamle P2PK-utganger) og operasjonell eksponering gjennom adressegjenbruk. Ingen kvantedatamaskin kan stjele disse pengene i dag. Men “harvest now, decrypt later” er et reelt angrepsmønster: data samles inn nå, og brukes den dagen maskinvaren finnes. Denne guiden viser deg, steg for steg, hvordan du kartlegger din egen eksponering og flytter midlene til tryggere adresser, uten å røre seed-frasen din og uten å stole blindt på en nettside som påstår den kan “kvantesikre” lommeboken din.

Dette er ikke en artikkel om å kjøpe et nytt produkt eller vente på at Bitcoin-protokollen skal endre seg. Det er en praktisk revisjon du kan gjøre med verktøy som allerede finnes: en watch-only-lommebok, en blokkutforsker som mempool.space, og eventuelt din egen Bitcoin Core-node. Du trenger ingen programmeringserfaring, men du må være villig til å lese adresser og scripttyper litt mer nøye enn vanlig. Til slutt sitter du med en dokumentert oversikt over hvilke mynter som er eksponert, og en konkret plan for å flytte dem, uten å gamble med seed-frasen eller falle for useriøse “kvanteoppgraderinger” som allerede dukker opp i markedet.

Hva er kvantetrusselen mot Bitcoin-adresser egentlig?

Bitcoin bruker elliptisk kurve-kryptografi (ECDSA og, for Taproot, Schnorr-signaturer) til å bevise eierskap. Signaturalgoritmene er ikke sårbare fordi de er svake i dag, men fordi en tilstrekkelig stor kvantedatamaskin i teorien kan kjøre Shors algoritme og regne seg baklengs fra en offentlig nøkkel til den tilhørende private nøkkelen. Så lenge ingen slik maskin finnes, er dette et fremtidsscenario. Problemet er at enkelte Bitcoin-utganger allerede viser den offentlige nøkkelen i klartekst på blokkjeden, mens andre skjuler den bak en hash til øyeblikket du bruker pengene. Det skillet avgjør hvor mye tid en fremtidig angriper potensielt får.

NIST har allerede standardisert svaret på dette generelt: FIPS 204 definerer ML-DSA som ny signaturstandard, og FIPS 205 gjør det samme for det hash-baserte alternativet SLH-DSA. Bitcoin-nettverket har derimot ikke aktivert noe tilsvarende. BIP-360, som foreslår en kvanteresistent utgangstype kalt Pay-to-Merkle-Root (P2MR), ble lagt inn i BIPs-repoet i februar 2026, men står fortsatt som et forslag under vurdering, ikke som en aktivert konsensusregel. Et tilhørende forslag, BIP-361, skisserer en faset migrering der nye sårbare utganger til slutt kan nektes, men heller ikke dette er vedtatt protokolladferd per oktober 2026. Behandle derfor alle datoer du ser nevnt i denne sammenhengen som forslag, ikke som frister nettverket faktisk tvinger deg til å følge.

Noe av forvirringen kommer fra at ulike initiativer blandes sammen i mediedekningen. Et G7-relatert dokument og en veikart fra en Cyber Expert Group omtalt i januar 2026 satte generelle mål for overgang til post-kvantum-kryptografi, med et ytre siktemål rundt 2035 og kritiske systemer adressert nærmere 2030–2032. Disse dokumentene nevner ikke Bitcoin, blokkjeder eller digitale eiendeler spesifikt, og bør derfor ikke siteres som en Bitcoin-frist. Samtidig har selskapet BTQ Technologies, ifølge egne uttalelser, kjørt en fungerende implementasjon av et kvanteresistent signaturskjema på et dedikert testnett siden mars 2026, med fem ML-DSA-opkoder og over 100 000 utvunnede blokker. Det viser at teknologien er testbar, men et testnett er ikke det samme som en aktivert endring på Bitcoins hovedkjede.

Det som derimot er konkret og du kan gjøre noe med i dag, er å redusere hvor mye informasjon dine egne mynter eksponerer. Det er formålet med denne gjennomgangen: en praktisk revisjon av egne adresser, ikke en panikkmigrering basert på en påstått deadline. Les mer om hvordan nettverket som helhet diskuterer en eventuell frysing av sårbare utganger i vår egen gjennomgang av BIP-361, og om den bredere sikringsstrategien i artikkelen om post-kvantum-sikring av Bitcoin.

Forutsetninger før du starter

Du trenger ikke være node-operatør for å gjennomføre denne revisjonen, men noen verktøy gjør jobben betydelig enklere og tryggere. Sett opp disse før du går videre:

En desktop-lommebok som støtter watch-only-import og PSBT, som Sparrow Wallet (nyeste versjon fra sparrowwallet.com) eller Electrum (nyeste versjon fra electrum.org).
Den eksisterende maskinvarelommeboken din (Trezor, Coldcard, BitBox eller lignende), fulladet og med oppdatert fastvare. Se vår egen gjennomgang av sikkert oppsett av maskinvarelommebok hvis du er usikker på fastvarestatusen.
Tilgang til xpub, zpub eller en fullstendig deskriptor for lommeboken din. Dette finner du i maskinvarelommebokens app, ikke i seed-frasen.
Valgfritt, men anbefalt: en egen Bitcoin Core-node (nyeste stabile versjon, se bitcoincore.org/en/releases) med bitcoin-cli tilgjengelig, slik at du ikke er avhengig av tredjeparts API-er for å sjekke rå transaksjonsdata.
Minst 30–45 minutter uten avbrudd, og en liten testbeløp-strategi før du flytter hovedbeholdningen.

Viktigst av alt: seed-frasen din skal aldri tastes inn i noe annet enn det opprinnelige signeringsmiljøet. Alt vi gjør i denne guiden bruker offentlig informasjon (xpub/deskriptor) frem til selve signeringssteget, der maskinvarelommeboken gjør jobben isolert. Hvis du tidligere har sikkerhetskopiert seed-frasen med SLIP-39 eller en annen Shamir-basert metode, påvirker ikke denne revisjonen den sikkerhetskopien i det hele tatt. Se vår gjennomgang av SLIP-39 Shamir Backup for detaljer om hvordan de to tingene forholder seg til hverandre.

Steg 1–2: Sett opp en watch-only-lommebok uten å eksponere seed-frasen

En watch-only-lommebok inneholder kun offentlig informasjon, typisk en utvidet offentlig nøkkel (xpub/zpub) eller en komplett deskriptor. Den kan utlede mottaksadresser, overvåke saldo og transaksjoner, og bygge usignerte transaksjoner (PSBT), men kan aldri signere noe på egen hånd. Det gjør den ideell for en revisjon: du får full oversikt uten å flytte seed-frasen ut av det trygge signeringsmiljøet.

Mange bruker allerede en watch-only-lommebok uten å tenke over navnet på funksjonen, fordi det ofte er standard oppsett når man kobler en maskinvarelommebok til en koordinator-app for første gang. Poenget i denne guiden er å være bevisst på at nettopp denne separasjonen, offentlig informasjon på datamaskinen og private nøkler kun på den isolerte enheten, er selve grunnen til at revisjonen i det hele tatt er trygg å gjøre på en vanlig internett-tilkoblet datamaskin.

Slik gjør du det i Sparrow Wallet

Åpne Sparrow og velg “New Wallet”.
Velg riktig lommebokpolicy: Native SegWit for en vanlig zpub-lommebok, eller Taproot dersom du allerede bruker bc1p-adresser.
Velg “Watch-only” og koble til maskinvarelommeboken for å importere deskriptoren direkte, eller lim inn xpub/zpub manuelt med korrekt derivation path.
Bekreft at de første mottaksadressene Sparrow viser er identiske med det maskinvarelommeboken din viser på egen skjerm.
Lagre lommebokfilen. Seed-frasen er aldri tastet inn i Sparrow i dette løpet.

Slik gjør du det i Electrum

Opprett en ny lommebok og velg “Import Bitcoin addresses or private keys” eller det tilsvarende watch-only-alternativet for maskinvarelommeboken din.
Lim inn master public key eller xpub, og velg korrekt scripttype (legacy, SegWit eller Taproot).
Fullfør oppsettet uten å taste inn seed-frase eller private nøkler noe sted.
Sammenlign de utledede adressene mot maskinvarelommeboken for å bekrefte at deskriptoren er riktig.

Hvis adressene ikke matcher, stopp. Det betyr enten feil derivation path, feil scripttype, eller en feiltastet nøkkel. Fortsett aldri en revisjon på en watch-only-lommebok der adressene ikke stemmer med originalen.

Steg 3: Forstå adressetypene dine og hva de faktisk eksponerer

Prefikset på en Bitcoin-adresse sier noe om scripttypen, men ikke alt om eksponeringen. Et viktig skille går mellom utganger som viser den offentlige nøkkelen allerede i låseskriptet (lang eksponering), og utganger som først viser nøkkelen når eieren faktisk bruker pengene (kort eksponering). Adressegjenbruk kan flytte en kort-eksponert adresse over i den første kategorien, fordi nøkkelen allerede ligger i en tidligere brukt inputscript på kjeden.

Prefiks	Scripttype	Offentlig nøkkel synlig før bruk?	Risikoprofil
Ingen adresse, kun scriptPubKey	P2PK (Pay-to-Public-Key)	Ja, alltid	Høy – typisk svært gamle Satoshi-tidsalder-utganger
1…	P2PKH	Nei, før første bruk. Ja, hvis adressen er brukt og gjenbrukt	Lav til moderat, avhengig av gjenbruk
3…	P2SH (ofte wrapped SegWit eller multisig)	Nei, før innløsningsskriptet vises ved bruk	Lav, avhenger av underliggende script
bc1q…	P2WPKH / P2WSH (Native SegWit)	Nei, før første bruk	Lav, så lenge adressen ikke er gjenbrukt
bc1p…	P2TR (Taproot)	Nei ved key-path-bruk før forbruk (nøkkelen tweakes)	Lav i dag, men key-path-bruk avslører nøkkelen ved forbruk

Legg merke til at en bc1q- eller bc1p-adresse i seg selv ikke er bevis på noe. Du må inspisere det faktiske scriptet og eventuelle tidligere bruk av samme adresse for å vite hva som egentlig er eksponert.

Det er også verdt å skille mellom teoretisk eksponering og faktisk, nåværende tyveririsiko. En rapport publisert 10. september 2026 og omtalt i starten av oktober 2026 hevder at et forskerteam har redusert det estimerte ressursbehovet for å bryte elliptisk-kurve-kryptografi brukt av Bitcoin og Ethereum med mer enn halvparten, til rundt 1 151 logiske qubits for et teoretisk angrep. Det er fortsatt et forskningsestimat for logiske, feilkorrigerte qubits, ikke en demonstrert praktisk angrepskapasitet, og dagens mest avanserte kvanteprosessorer er fortsatt langt fra dette nivået i stabil, feilkorrigert form. Likevel er trenden i disse estimatene en indikasjon på at marginene kan krympe raskere enn mange forventet for noen år tilbake, noe som gjør en kartlegging av egen eksponering til en fornuftig føre-var-øvelse selv uten en konkret frist.

Steg 4: Identifiser P2PK-adresser og gjenbrukte adresser i egen lommebok

Gå gjennom watch-only-lommeboken din adresse for adresse. I Sparrow og Electrum kan du se transaksjonshistorikken til hver adresse direkte i grensesnittet. Se spesielt etter to ting: adresser som har mottatt og sendt bitcoin flere ganger (gjenbruk), og svært gamle utganger av typen P2PK, som ikke har en vanlig adresse i det hele tatt, men vises som en rå offentlig nøkkel i scriptPubKey.

De fleste moderne lommebøker genererer en ny adresse for hver mottransaksjon som standard, så dette steget handler mest om gamle midler du kanskje har flyttet manuelt eller mottatt til en statisk adresse du har brukt gjentatte ganger, for eksempel en adresse limt inn på en hjemmeside eller brukt til gjentatte lønnsutbetalinger. Merk hver adresse du finner med gjenbruk eller P2PK-opprinnelse. Disse er kandidatene for migrering i de neste stegene.

Hvis du har flyttet midler fra en kald lagringsløsning tidligere, for eksempel gjennom et air-gapped multisig-oppsett, bør du også gå gjennom disse utgangene på samme måte. Et multisig-skript avslører flere offentlige nøkler samtidig når det brukes, ikke bare én, noe som gjør grundigheten i denne gjennomgangen enda viktigere. Vår tidligere gjennomgang av air-gapped multisig for kald lagring beskriver oppsettet i detalj, men dekker ikke denne spesifikke revisjonsprosessen.

Steg 5: Sjekk rå transaksjonsdata på mempool.space

En nettbasert blokkutforsker som mempool.space lar deg se adresseformat, transaksjonshistorikk og enkeltutganger uten å stole blindt på en merkelapp som “legacy” eller “SegWit”. For en grundig sjekk må du se på selve inputscriptet eller witness-dataen til en tidligere forbrukstransaksjon, ikke bare den menneskelesbare etiketten utforskeren viser.

Slik gjør du det: søk opp adressen, åpne den eldste utgående transaksjonen, og se etter en witness- eller scriptSig-verdi som inneholder en lang hex-streng. En offentlig nøkkel i komprimert format er 33 byte (66 hex-tegn) og starter typisk med 02 eller 03. Finner du en slik streng i en tidligere input fra samme adresse, er nøkkelen allerede eksponert på kjeden, uavhengig av om adressen i dag ser “trygg” ut.

For en P2PKH-adresse (1…) ligger den offentlige nøkkelen i scriptSig-feltet til den transaksjonen som bruker utgangen. For en Native SegWit-adresse (bc1q…) ligger den i stedet i witness-feltet, separat fra selve transaksjonsdataen, men fortsatt fullt offentlig og søkbar for alle som ser etter den. For Taproot (bc1p…) er bildet mer nyansert: en key-path-bruk viser den tweakede offentlige nøkkelen og en Schnorr-signatur, mens en script-path-bruk i stedet viser det relevante scriptet og en kontrollblokk. Poenget er samme uansett scripttype: så snart en utgang er brukt, er den tilhørende offentlige nøkkelen eller det tilhørende scriptet synlig for alle, for alltid. Det kan ikke fjernes eller “re-skjules” i etterkant, uansett hvilken programvare du bruker.

bitcoin-cli decoderawtransaction "<rawtx_hex>"
# Se etter feltet "scriptSig" eller "txinwitness" i resultatet.
# Eksempel på et felt som avslører en offentlig nøkkel:
#   "txinwitness": [
#     "304402...01",
#     "02f1b1f6e8f1c2a9d7b5e3c4a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1"
#   ]
# Den andre strengen (33 byte, starter med 02/03) ER selve den offentlige nøkkelen.

Steg 6: Skann UTXO-settet med bitcoin-cli for en fullstendig oversikt

Hvis du kjører en egen Bitcoin Core-node, gir listunspent og scantxoutset deg en mer fullstendig og privat oversikt enn å søke manuelt på en tredjeparts nettside. listunspent viser kun utganger lommeboken din allerede kjenner til, mens scantxoutset kan søke gjennom hele det nåværende UTXO-settet etter en gitt deskriptor, uavhengig av om noden har lommeboken lastet.

# List alle kjente usikrede utganger i en lastet lommebok
bitcoin-cli listunspent 0 9999999

# Skann hele UTXO-settet etter en bestemt deskriptor (krever ingen lommebok lastet)
bitcoin-cli scantxoutset start '["wpkh([fingerprint/84h/0h/0h]xpub6.../0/*)"]'

# For en enkelt adresse
bitcoin-cli scantxoutset start '["addr(bc1q...din-adresse...)"]'

Husk at scantxoutset kun ser på dagens UTXO-sett, ikke historiske forbrukte utganger. For å avgjøre om en nøkkel har vært eksponert tidligere, må du fortsatt kombinere dette med en gjennomgang av transaksjonshistorikken, som i forrige steg.

Deskriptorsyntaksen kan se kryptisk ut første gang du møter den, men den følger et konsekvent mønster. wpkh(...) betyr Native SegWit enkeltnøkkel, tr(...) betyr Taproot, og sh(wpkh(...)) betyr en SegWit-adresse pakket inn i en P2SH-adresse (de klassiske 3…-adressene fra overgangsperioden til SegWit). Fingerprint-verdien i hakeparentesen identifiserer hvilken maskinvarelommebok nøkkelen stammer fra, og tallene etter den (for eksempel 84h/0h/0h for Native SegWit eller 86h/0h/0h for Taproot) er BIP-standardiserte derivation paths. Stemmer ikke disse med det maskinvarelommeboken faktisk bruker, vil skanningen ikke finne dine utganger selv om de finnes på kjeden.

Steg 7: Kartlegg hvor stor andel av din formue som faktisk er eksponert

Nå som du har gått gjennom adressene, lag en enkel oversikt: hvor mange BTC ligger på P2PK-utganger, hvor mange ligger på gjenbrukte adresser, og hvor mye ligger på adresser som aldri har vært brukt og derfor fortsatt skjuler nøkkelen bak en hash. De nasjonale estimatene varierer mellom analysene, og det er verdt å kjenne spennet før du trekker egne konklusjoner.

Kilde / analyse (2026)	Estimert eksponert BTC	Hovedforklaring
Glassnode-basert analyse	Ca. 6,04 millioner BTC	Ca. 1,92 mill. strukturell eksponering (P2PK), ca. 4,12 mill. fra adressegjenbruk
Andre 2026-analyser (bransjerapporter)	Ca. 6,2–6,9 millioner BTC	Bredere definisjon av eksponerte og gjenbrukte utganger
Analyse med fokus på eldste mynter	Ca. 6,5–6,9 millioner BTC, inkl. ca. 1,7 mill. i antatt Satoshi-tidsalder-adresser	Inkluderer svært gamle, ubrukte P2PK- og P2PKH-utganger

Tallene er ikke direkte sammenlignbare fordi analysene bruker ulike datasett og definisjoner, men alle peker i samme retning: en betydelig andel av Bitcoins totale forsyning sitter med en offentlig nøkkel som allerede er eller lett kan bli synlig. Din egen andel er sannsynligvis langt mindre dramatisk, men nøyaktig samme logikk gjelder for dine mynter.

Sett opp et enkelt regnestykke for din egen lommebok: summer beløpet på adresser merket som P2PK eller gjenbrukt i steg 4 og 5, og del det på totalsaldoen din. Det gir deg en prosentandel du kan bruke til å prioritere. Er det under fem prosent av formuen, kan migreringen trygt gjøres i eget tempo over noen uker. Er det over halvparten, bør du heller behandle det som et prosjekt du fullfører i løpet av de neste dagene, ikke noe du skyver stadig lenger ut i tid.

Steg 8: Planlegg migreringen til ferske adresser

Når du har identifisert hvilke utganger som bør flyttes, planlegg destinasjonen. En ny, aldri-brukt Taproot-adresse (bc1p…) eller Native SegWit-adresse (bc1q…) skjuler nøkkelen bak en hash helt til du bruker den igjen. Dette er ikke en kvantesikker løsning i seg selv, men det fjerner den eksisterende eksponeringen og flytter problemet til en fremtidig dato der bedre standarder sannsynligvis finnes.

Lag en liste over hvilke UTXO-er som skal flyttes, i hvilken rekkefølge, og til hvilke nye adresser. Flytt ikke alt i én eneste transaksjon hvis du har mange små utganger spredt over flere adresser. Det kan konsolidere mynter på en måte som avslører eierskapssammenhenger du ellers ikke ville vist offentlig, og det gjør testing vanskeligere. Del heller migreringen i flere mindre transaksjoner.

Prioriter etter risiko, ikke etter beløp. En liten sum på en P2PK-adresse fra Bitcoins tidlige år er strengt tatt ikke mer “truet” i dag enn en stor sum på en nylig gjenbrukt adresse, men begge bør flyttes før en eventuell hendelse gjør det til et tidskritisk problem i stedet for en rolig, planlagt øvelse. Sett også av litt ekstra i gebyrbudsjettet enn du tror du trenger. Migrering av flere mindre transaksjoner over tid koster mer i samlede gebyrer enn én stor konsolidering, men den sikkerhetsmessige og personvernmessige fordelen er normalt verdt merkostnaden for beløp av noe størrelse.

Steg 9–10: Bygg transaksjonen som en PSBT og signer med maskinvarelommeboken

En PSBT (Partially Signed Bitcoin Transaction) er et standardisert format for en usignert eller delvis signert transaksjon. Den kan inneholde input- og output-data, tidligere transaksjonsinformasjon, derivation paths, nøkkel-fingerprints og delvise signaturer, uten å inneholde noen privat nøkkel eller seed-frase.

Bygg transaksjonen i watch-only-lommeboken

I Sparrow eller Electrum, velg UTXO-ene du identifiserte i steg 8 som input.
Sett de nye, ferske adressene som mottakere.
Velg en fornuftig gebyrrate basert på nettverksbelastningen, og dobbeltsjekk summen før du fortsetter.
Eksporter den usignerte transaksjonen som en PSBT-fil eller QR-kode.

Signer med maskinvarelommeboken

Importer PSBT-en i maskinvarelommeboken, via USB, SD-kort eller QR-kode avhengig av modell.
Verifiser destinasjonsadressen og beløpet direkte på maskinvarelommebokens egen skjerm, aldri bare på datamaskinens skjerm.
Godkjenn signeringen på enheten.
Importer den signerte PSBT-en tilbake i Sparrow eller Electrum for finalisering.

# Eksempel: finalisere og sende en signert PSBT via bitcoin-cli
bitcoin-cli finalizepsbt "<signed_psbt_base64>"
bitcoin-cli sendrawtransaction "<hex_fra_finalizepsbt>"

Steg 11: Send en testtransaksjon før du flytter hele beholdningen

Før du rører hovedbeløpet, gjennomfør hele kjeden med et lite beløp først, gjerne verdt noen hundre kroner. Bekreft at den nye adressen mottar pengene korrekt, at den vises riktig i watch-only-lommeboken, og at du faktisk kan bruke mynten derfra igjen senere uten problemer. Dette fanger opp feil i deskriptoren, feil derivation path eller feil scripttype før de blir kostbare.

Vent på minst én bekreftelse før du fortsetter med resten av migreringen. En testtransaksjon tar normalt 10–60 minutter å bekrefte, avhengig av gebyr og nettverksbelastning, og er tiden godt verdt sett mot risikoen ved å flytte alt på én gang.

Bruk testtransaksjonen til å øve på hele kontrollrutinen du skal følge for de større beløpene senere: sjekk adressen på maskinvarelommebokens skjerm, bekreft beløpet, bekreft at watch-only-lommeboken viser riktig status etter sending, og bekreft at mottaksadressen stemmer med det du planla i steg 8. Går noe galt her, er kostnaden lav. Går samme feil galt i en transaksjon med hele resten av beholdningen din, er kostnaden potensielt alt du eier.

Steg 12: Verifiser og fullfør hele migreringen

Når testtransaksjonen er bekreftet og alt ser riktig ut, gjennomfør resten av de planlagte overføringene fra steg 8, i de delene du bestemte deg for. Etter hver transaksjon, dobbeltsjekk i watch-only-lommeboken eller på mempool.space at saldoen har flyttet seg som forventet, og at de gamle adressene nå står tomme.

Dokumenter hvilke UTXO-er som er flyttet og til hvilke nye adresser, i en egen notatfil eller et regneark, uten å inkludere xpub eller seed. Dette gjør det enklere å bekrefte fremover at du ikke gjenbruker de nye, “rene” adressene på samme måte som de gamle.

Hva denne revisjonen ikke dekker: børser og Lightning-kanaler

De tolv stegene over gjelder on-chain UTXO-er du har full kontroll over, altså mynter der du selv sitter med den private nøkkelen eller seed-frasen. To store kategorier faller utenfor dette: mynter som ligger på en børs, og mynter som ligger låst i en Lightning-kanal.

Når bitcoin ligger på en børs, er det børsen som kontrollerer de underliggende adressene, ikke deg. Du har ingen mulighet til å sjekke eller migrere disse adressene selv, og børsens egen eksponering er et spørsmål kun leverandøren kan svare på. Det eneste fornuftige du kan gjøre, er å spørre børsen direkte om hvordan de planlegger å håndtere en eventuell fremtidig protokollendring, og eventuelt flytte midler du vil ha full kontroll over til egen watch-only-overvåket lommebok.

Lightning-kanaler har en annen logikk. Midler i en åpen kanal er bundet til en multisig-utgang mellom deg og motparten, og flyttes ikke med en vanlig on-chain-transaksjon mens kanalen er åpen. En eventuell migrering ville kreve at kanalen stenges først, hvoretter de resulterende on-chain-utgangene kan behandles på samme måte som beskrevet i denne guiden. Det er foreløpig ingen etablert standard for å gjøre dette i stor skala, og en forhastet masse-stenging av kanaler utelukkende av kvantehensyn vil sannsynligvis kost mer i gebyrer og tapt likviditet enn den løser i praksis i dag.

Det samme forbeholdet gjelder i stor grad for andre kjeder du måtte eie, som Ethereum. Kontomodellen der er annerledes enn Bitcoins UTXO-modell, signaturalgoritmen er i Ethereums tilfelle ECDSA over samme type elliptisk kurve-matematikk, og en offentlig nøkkel kan under visse omstendigheter være synlig allerede fra selve adressen, avhengig av hvordan lommeboken og eventuelle smartkontrakter er satt opp. Denne guiden er avgrenset til Bitcoins adresseformater og verktøy, men det underliggende prinsippet, nemlig å redusere unødig eksponering av offentlige nøkler før det er strengt nødvendig, er like relevant der.

Vanlige feil du bør unngå

De fleste feilene i en slik revisjon handler ikke om avanserte kryptografiske misforståelser, men om hastverk, feil klikk eller en antagelse som ikke ble dobbeltsjekket. Gå gjennom denne listen før du starter, og igjen rett før du signerer den første reelle migreringstransaksjonen.

Å taste seed-frasen inn i en watch-only-lommebok. Watch-only skal kun ha xpub, zpub eller deskriptor. Trenger programvaren seed-frasen for å “sette opp watch-only”, er det feil funksjon du bruker.
Å gjenbruke den nye “sikre” adressen umiddelbart. Hele poenget med migreringen forsvinner hvis den nye adressen brukes om og om igjen akkurat som den gamle.
Å stole på etiketten i en utforsker uten å sjekke det rå scriptet. “Legacy” eller “SegWit”-merkelapper er en praktisk visning, ikke en autoritativ kilde til scripttype eller eksponeringsstatus.
Å flytte hele beholdningen i én transaksjon uten test. En enkelt feil i derivation path eller deskriptor kan da påvirke alt på én gang.
Å ikke verifisere destinasjonsadressen på maskinvarelommebokens egen skjerm. Skadevare på datamaskinen kan i teorien manipulere det som vises der, men ikke det som vises på en isolert enhet.
Å forveksle et BIP-forslag med en aktivert nettverksregel. BIP-360 og BIP-361 er under vurdering, ikke vedtatt protokolladferd, og det finnes ingen offisiell, bindende Bitcoin-spesifikk frist i dag.
Å glemme mynter på børser eller i Lightning-kanaler. Denne revisjonen dekker on-chain UTXO-er du kontrollerer selv. Børsbeholdning er et spørsmål du må stille leverandøren direkte, og Lightning-kanaler har sin egen sikkerhetskopi- og eksponeringslogikk.

Feilsøking: dette gjør du når noe går galt

Selv med en nøye planlagt revisjon dukker det opp småfeil underveis, særlig i de tekniske stegene som involverer egen node eller kommandolinjeverktøy. Ingen av punktene under er grunn til panikk. De er normale friksjonspunkter, og løsningen er nesten alltid å stoppe opp, verifisere ett steg om gangen, og unngå å presse en kommando som gir feilmelding til å “bare fungere” uten å forstå hvorfor den feilet først.

“Scan already in progress” fra scantxoutset. Noden kjører allerede et skann. Vent til det er fullført, eller start en ny RPC-forbindelse for å sjekke status med samme kommando uten “start”-parameteren der det er støttet.
listunspent viser ingen resultater selv om du har midler. Lommeboken er sannsynligvis ikke lastet, eller den er ikke rescannet etter import av deskriptoren. Kjør en rescan fra blokkhøyden der midlene først ble mottatt.
Sparrow viser “Wallet type mismatch” ved import. Du har valgt feil policy (for eksempel Native SegWit når deskriptoren faktisk er Taproot). Slett wallet-oppføringen og importer på nytt med riktig type.
Watch-only-lommeboken viser andre adresser enn maskinvareenheten. Stopp umiddelbart. Dette betyr feil xpub, feil derivation path eller feil kontoindeks. Importer på nytt fra bunnen.
PSBT-en kan ikke finaliseres, “missing signature”. Ikke alle nødvendige signaturer er lagt til, typisk relevant for multisig. Bekreft at riktig antall nøkler har signert før finalizepsbt kjøres.
Maskinvarelommeboken viser en annen adresse enn koordinatorprogramvaren. Stol på enhetens skjerm, ikke dataskjermen. Avbryt transaksjonen og undersøk om deskriptoren er feil importert.
Transaksjonen sitter ubekreftet lenge. Gebyret var sannsynligvis for lavt for nettverksbelastningen. Bruk RBF (Replace-By-Fee) hvis det ble aktivert ved sending, eller vent det ut dersom beløpet ikke er tidskritisk.
mempool.space svarer med feil eller treg lasting. Tredjeparts API-er kan rate-begrense eller ha driftsproblemer. Bruk en alternativ utforsker eller egen node som backup når du skal bekrefte kritiske detaljer.
“Method not found” på scantxoutset. Kommandoen krever en tilstrekkelig oppdatert Bitcoin Core-versjon med indeksering aktivert. Sjekk versjonen med bitcoin-cli -version og oppgrader noden ved behov.

Avanserte tips for videre sikring

Når grunnarbeidet er gjort, er det noen videre skritt som styrker posisjonen din ytterligere. Vurder en multisig-oppsett for de største beløpene, der ingen enkelt nøkkel kan flytte midlene alene. Dette er samme prinsipp som beskrevet i vår gjennomgang av arv og tidslåste multisig-løsninger, og det reduserer både kvante- og tyveririsiko samtidig, siden en angriper må kompromittere flere nøkler i stedet for én. En multisig-utgang avslører riktignok flere offentlige nøkler ved bruk enn en enkeltnøkkel-adresse, men krever samtidig at angriperen bryter flere nøkler for å kunne flytte pengene, noe som øker kostnaden betydelig.

Sett opp adresseovervåking fremover, slik at du får varsel hvis en adresse du regnet som “brukt én gang” plutselig mottar nye innskudd og dermed risikerer gjenbruk. Kjør egen node med Tor der det er praktisk mulig, slik at balansesjekkene dine ikke lekker hvilke adresser som tilhører samme lommebok til en tredjeparts tjeneste. Og hold et øye med utviklingen i BIP-360 og BIP-361 i BIPs-repoet og hos Bitcoin Optech sitt tema om kvanteresistens, uten å handle før forslagene faktisk aktiveres på nettverket. Markedet for falske “kvanteoppgraderinger” av lommebøker vokser i takt med oppmerksomheten rundt temaet, og ingen legitim oppgradering krever at du taster seed-frasen inn på en ekstern nettside.

Til sist: denne revisjonen er ikke en engangsøvelse. Hver gang du mottar en betydelig sum, eller hver gang du setter opp en ny lommebok, er det verdt å sjekke at vanene dine fortsatt holder, at ingen adresser gjenbrukes av gammel vane, og at descriptorer og watch-only-eksporter er oppdatert. Sikkerhet mot en fremtidig kvantetrussel handler først og fremst om gode, repeterbare rutiner i dag, ikke om å finne én magisk løsning.

Komplett arbeidsflyt: fra revisjon til migrert lommebok

Satt sammen består et komplett prosjekt av: en watch-only-lommebok bygget fra deskriptoren din, en gjennomgang av adressetyper og gjenbruk, en kryssjekk mot rå transaksjonsdata og eventuelt et eget node-skann, en dokumentert liste over eksponerte UTXO-er, en migreringsplan i flere mindre transaksjoner, en testtransaksjon, og til slutt PSBT-signering med maskinvarelommeboken for hver reell overføring. Hele løpet krever ingen endring i Bitcoin-protokollen og ingen ny programvare utover det du allerede har, bare en mer disiplinert bruk av verktøyene som finnes.

Tidsbruken varierer naturlig nok med hvor mange adresser og UTXO-er du har. En lommebok med fem til ti adresser er overkommelig å gå gjennom manuelt på under en halvtime. En lommebok med hundrevis av historiske adresser, bygget opp over flere år med gjentatte kjøp og salg, krever mer systematikk. Her er det verdt å eksportere hele transaksjonshistorikken til en CSV-fil fra Sparrow eller Electrum, og filtrere på adresser med mer enn én utgående transaksjon, i stedet for å klikke gjennom alt manuelt i grensesnittet.

Resultatet av arbeidet er ikke en kvantesikker lommebok i absolutt forstand, siden ingen slik løsning finnes som en standard, aktivert funksjon på Bitcoin per oktober 2026. Resultatet er en lommebok med vesentlig redusert eksponering, en dokumentert oversikt over hva som eventuelt står igjen, og en klar plan for hva du gjør den dagen BIP-360, BIP-361 eller et annet forslag faktisk blir en reell, aktivert del av protokollen.

Output fra en vellykket migrering bør se ut som dette i watch-only-lommeboken: den gamle adressen viser 0 BTC og en utgående transaksjon, den nye adressen viser innkommende beløp med minst én bekreftelse, og transaksjons-ID-en matcher det du ser i mempool.space eller egen node. Stemmer alt dette, er migreringen fullført korrekt.

Ofte stilte spørsmål

Er bitcoinen min i fare for å bli stjålet av en kvantedatamaskin akkurat nå?
Nei. Ingen kjent kvantedatamaskin kan i dag bryte ECDSA eller Schnorr-signaturer som brukes i Bitcoin. Risikoen er fremtidig og teoretisk, men eksponeringen av offentlige nøkler i dag kan gi en fremtidig angriper et forsprang gjennom “harvest now, decrypt later”.

Må jeg flytte alle mynter akkurat nå på grunn av BIP-361?
Nei. BIP-361 er et forslag under vurdering, ikke en aktivert nettverksregel, og det finnes ingen bindende, offisiell frist for Bitcoin spesifikt per oktober 2026. Du kan redusere eksponeringen i eget tempo.

Er en Taproot-adresse (bc1p) kvantesikker?
Nei. Taproot reduserer visse typer eksponering og gir andre fordeler, men key-path-bruk avslører fortsatt den offentlige nøkkelen ved forbruk. Det er ikke det samme som en post-kvantum-signaturalgoritme.

Kan jeg gjøre hele denne revisjonen uten å eie en maskinvarelommebok?
Ja, selve revisjonen (steg 1–8) krever bare en watch-only-lommebok. Du trenger imidlertid et trygt signeringsmiljø, enten maskinvare eller en godt sikret offline-datamaskin, for selve migreringen i steg 9–12.

Hva gjør jeg med bitcoin som ligger på en børs?
Denne guiden dekker on-chain-adresser du selv kontrollerer. For børsbeholdning må du spørre leverandøren direkte om hvordan de håndterer kundenes adresser og eventuell fremtidig migrering.

Er noen maskinvarelommebøker allerede “kvantesikre”?
Ingen større maskinvarelommebokprodusent hadde, ifølge tilgjengelige oversikter fra august 2026, lansert støtte for post-kvantum-signaturalgoritmer som ML-DSA eller SLH-DSA. Vær skeptisk til produkter eller tjenester som hevder noe annet.

Hvor lang tid tar hele prosessen?
For en lommebok med et moderat antall adresser tar revisjonen (steg 1–8) typisk 15–20 minutter, mens selve migreringen med testtransaksjon og bekreftelser (steg 9–12) tar rundt 20–25 minutter aktivt arbeid, pluss ventetid på blokkbekreftelser.

Kan jeg bruke samme fremgangsmåte på Ethereum eller andre kjeder?
Prinsippet med å unngå å eksponere offentlige nøkler og bruke watch-only-verktøy er overførbart, men den tekniske gjennomføringen er annerledes fordi Ethereum og andre kjeder har andre adresseformater, kontomodeller og signeringsverktøy enn Bitcoins UTXO-modell.

Hva skjer med en gammel adresse etter at jeg har flyttet midlene ut av den?
Den gamle adressen fortsetter å eksistere på kjeden som en historisk post med saldo 0, og den eksponerte offentlige nøkkelen eller det eksponerte scriptet forsvinner ikke fra blokkjedens historikk. Migreringen fjerner ikke historiske data, den fjerner kun risikoen for at disse midlene kan flyttes av noen andre i fremtiden, fordi pengene nå ligger på en ny utgang med en annen, ennå ubrukt nøkkel.

Bør jeg vente med å migrere til en offisiell post-kvantum-signatur finnes på Bitcoin?
Det kommer an på hvor mye du eier og hvor gammel eksponeringen er. For mynter på P2PK-utganger eller sterkt gjenbrukte adresser gir en migrering til en ny, ubrukt Taproot- eller SegWit-adresse en umiddelbar reduksjon i eksponering, selv uten en ny signaturalgoritme. For mynter som allerede ligger trygt på ubrukte, moderne adresser er det mindre å vinne på å handle akkurat nå, og det kan være like fornuftig å vente på at BIP-360 eller lignende forslag faktisk blir aktivert før du gjør nye endringer.