I februar 2026 ble BIP-360 slått sammen i Bitcoins offisielle forslagsarkiv, det første konkrete steget mot en kvantesikker adressetype for nettverket. En måned senere fulgte “Bitcoin Quantum Testnet v0.3.0” fra BTQ Technologies, hvor de nye utgangstypene ble testet med faktiske signaturer fra den post-kvante familien ML-DSA (Dilithium). Samtidig anslår forskning fra Google og selskapet Project Eleven at mellom 6,2 og 6,9 millioner BTC i dag ligger i adresser med en offentlig nøkkel synlig på kjeden, klar til å angripes den dagen en kraftig nok kvantedatamaskin dukker opp.
Denne guiden viser deg hvordan du selv kartlegger hvor eksponert din egen bitcoin-lommebok er, hvilke adressetyper som bør flyttes først, og hvordan du bygger et fungerende Python-verktøy som skanner adressene dine for kvanterisiko. Du trenger ingen forkunnskaper i kryptografi utover det grunnleggende, men du bør vite hvordan du kjører et Python-skript fra terminalen.
Vi går gjennom tolv konkrete steg, fra oppsett av miljø til et ferdig, testet skript du kan kjøre på egne adresser i dag. Underveis bygger vi inn logikk for å skille mellom kritisk eksponerte utganger og de som fortsatt er trygge, slik at du ender opp med en prioritert liste i stedet for en vag følelse av bekymring. Det samme skriptet kan gjenbrukes senere, den dagen lommeboken din faktisk støtter BIP-360-adresser, som en enkel sjekk på at migreringen er fullført.
Hvorfor kvantesikring av bitcoin haster akkurat nå
Bitcoin-utviklere har diskutert kvantetrusselen i over ti år, men 2026 er året da problemet gikk fra teori til konkret protokollarbeid. BIP-360, med tilnavnet Pay-to-Merkle-Root (P2MR), definerer en ny SegWit v2-utgangstype med adresser som starter på “bc1z”. Forslaget fjerner nøkkelstien i Taproot, altså muligheten til å bruke midler direkte med én offentlig nøkkel, og lar i stedet midler kun løses inn via et skript forankret i et Merkle-tre. Det gjør det mulig å bygge inn post-kvante signaturer senere uten en ny hard fork.
Chaincode Labs har i sin 2026-analyse delt migrasjonsarbeidet i tre faser: sikre fortiden, sikre nåtiden og sikre fremtiden. Det er nettopp fortiden som er vanskeligst. Millioner av bitcoin sitter i adresser skapt for over ti år siden, ofte uten at eieren lenger har tilgang eller vet at nøkkelen deres er synlig. Utviklere på bitcoindev-mailinglisten har i 2025 og 2026 aktivt jobbet med P2QRH-designet, blant annet ved å fjerne signaturskjemaet SQIsign fra forslaget til fordel for NIST-godkjente algoritmer som ML-DSA og SLH-DSA.
Poenget med denne artikkelen er ikke å skape panikk. Ingen kjent kvantedatamaskin kan i dag knekke secp256k1-kurven Bitcoin bruker. Poenget er at nøkkelhygiene, altså å unngå å eksponere den offentlige nøkkelen din unødig, er noe du kan gjøre i dag, lenge før noen post-kvante signaturopcode er aktivert på hovednettet.
Diskusjonen er heller ikke ny. Allerede før Taproot ble aktivert på hovednettet i november 2021, pekte flere akademiske artikler på at ECDSA over secp256k1 ville falle for en tilstrekkelig kraftig kvantedatamaskin. Det som er nytt i 2025 og 2026, er at diskusjonen har flyttet seg fra konferansepapirer til faktisk kode: et konkret BIP-nummer, et testnett som kjører, og en åpen dialog mellom kjerneutviklere om hvilke signaturalgoritmer som bør velges. Det gjør temaet langt mer konkret enn det var for bare noen år siden.
Samtidig er Bitcoin et spesielt vanskelig system å oppgradere sammenlignet med for eksempel en nettleser eller en TLS-server. Et sertifikat kan byttes ut på minutter. En bitcoin-adresse som har ligget urørt i ti år, og som eieren kanskje har mistet tilgangen til, kan ikke bare “oppdateres” uten at noen faktisk signerer en transaksjon med den gamle nøkkelen. Det er denne strukturelle tregheten som gjør at utviklere ønsker å starte migreringsarbeidet flere tiår før trusselen er reell, ikke rett før.
Slik fungerer kvantetrusselen mot secp256k1
Bitcoin bruker elliptisk kurve-kryptografi (ECDSA og Schnorr) over kurven secp256k1 for å signere transaksjoner. Sikkerheten hviler på at det er praktisk umulig å regne ut en privat nøkkel fra en offentlig nøkkel med klassiske datamaskiner. Shors algoritme, kjørt på en tilstrekkelig stor og feilfri kvantedatamaskin, kan i teorien løse akkurat dette problemet i polynomisk tid.
Forskere kaller en slik maskin en kryptografisk relevant kvantedatamaskin, forkortet CRQC. Ifølge 2026-rapporter sitert av postquantum.com plasserer de fleste seriøse anslag et CRQC-scenario for secp256k1 et sted i 2030-årene, med noen konservative estimater som strekker seg mot 2040-tallet avhengig av hvor raskt feilkorrigerte qubits skaleres. Det viktige poenget fra Chaincode Labs er at Bitcoins protokollendringer tar lang tid å rulle ut, ofte flere år fra forslag til aktivering, og enda lengre tid før brukerne faktisk flytter midlene sine. Da nytter det ikke å vente til en kvantedatamaskin er rett rundt hjørnet.
Det finnes også en asymmetri i risikoen. Et angrep på en enkelt eksponert offentlig nøkkel krever at angriperen bruker kvantekraften sin før eieren rekker å flytte midlene til en ny adresse. Det gir faktisk et lite tidsvindu selv etter at CRQC-er finnes, men bare for adresser der nøkkelen ikke allerede ligger åpent tilgjengelig på kjeden i en utgang som ikke er brukt.
Det er verdt å skille mellom to helt ulike kvantealgoritmer her, siden de ofte blandes sammen i mediedekning. Shors algoritme angriper den asymmetriske kryptografien, altså signaturene, og er den reelle trusselen mot secp256k1. Grovers algoritme angriper hashfunksjoner som SHA-256, men gir kun en kvadratrot-forbedring i søketid, noe som i praksis betyr at man dobler nøkkellengden for å kompensere. Bitcoins proof-of-work og adressehashing (som i P2PKH og P2WPKH) er dermed langt mer motstandsdyktig mot kvanteangrep enn selve signaturskjemaet. Det er nøyaktig derfor en hash-basert adresse er tryggere enn en adresse med synlig offentlig nøkkel, uavhengig av hvor kraftig datamaskinen som angriper er.
Hvilke bitcoin-adressetyper er sårbare
Ikke alle adressetyper er like utsatt. Det avgjørende spørsmålet er om den offentlige nøkkelen allerede er synlig i en utgang på kjeden, eller om den kun er skjult bak en hash inntil midlene brukes. Tabellen under oppsummerer risikobildet slik det er beskrevet i 2026-analyser fra blant annet Coin Metrics, Google og forskningsselskapet Project Eleven.
| Adressetype | Format | Når eksponeres nøkkelen | Risikonivå |
|---|---|---|---|
| P2PK (legacy) | rå offentlig nøkkel i scriptet | umiddelbart ved mottak | Kritisk |
| P2TR (Taproot) | bc1p… | umiddelbart, x-only-nøkkel ligger åpent i utgangen | Høy |
| P2PKH gjenbrukt | 1… | ved første bruk, deretter eksponert for alltid | Høy |
| P2PKH ubrukt | 1… | kun ved fremtidig bruk | Lav inntil brukt |
| P2WPKH (native SegWit) | bc1q… | kun ved fremtidig bruk, samme regel som P2PKH | Lav inntil brukt |
| P2SH / P2WSH (multisig) | 3… / bc1q (script) | skript skjult bak hash til innløsning | Lavest av dagens typer |
Legg merke til at native SegWit ikke er en magisk løsning. Fordelen forsvinner i det øyeblikket adressen brukes og deretter mottar nye midler på samme adresse. Vanen med å alltid generere en ny mottaksadresse, som de fleste moderne lommebøker gjør automatisk, er dermed langt mer enn en personvernsfunksjon. Den er også det billigste kvantetiltaket du har tilgjengelig i dag.
En adressetype som ofte skaper forvirring, er nestet SegWit (P2SH-P2WPKH), altså adresser som starter på “3” men som pakker inn en SegWit-nøkkel i et P2SH-skript. Disse følger de samme reglene som ren P2SH: skriptet er skjult bak en hash frem til innløsning, og selve nøkkelen inni skriptet eksponeres først når adressen brukes. Forveksler du disse med gamle P2PKH-adresser under en manuell gjennomgang, kan du fort undervurdere eller overvurdere risikoen. Derfor er det tryggere å la et skript som slår opp den faktiske scripttypen på kjeden gjøre jobben, fremfor å gjette basert på adressens første tegn alene.
Hvor mye BTC står faktisk i fare akkurat nå
Tallene varierer noe mellom analysene, men peker i samme retning. Project Eleven kom 17. januar 2025 frem til at 6.262.905 BTC lå i potensielt kvantesårbare utganger. Googles kvanteforskning fra 2026, referert av blant annet Spark og Talos, anslår at rundt 6,9 millioner BTC, tilsvarende omtrent 32 prosent av sirkulerende tilbud, ligger i adresser med synlig offentlig nøkkel. Samme forskning viser at Taproot-transaksjoner utgjorde rundt 21,68 prosent av all bitcoin-aktivitet i 2025.
| Kategori | Anslått BTC i fare | Kilde |
|---|---|---|
| Totalt eksponerte nøkler (alle typer) | 6,2–6,9 mill. BTC | Project Eleven / Google 2026 |
| Legacy P2PK (ofte Satoshi-æra) | ~1,7 mill. BTC | Coin Metrics ATLAS |
| Gjenbrukte P2PKH-adresser | i overkant av 5 mill. BTC i samlet pool | Jared Watkins-analyse 2026 |
| Taproot-transaksjonsandel 2025 | 21,68 % av all aktivitet | Google-forskning, sitert av Spark |
Mye av dette er trolig tapte eller forlatte mynter fra Bitcoins tidligste år, inkludert coinbase-belønninger som aldri har blitt brukt. Men en betydelig andel tilhører aktive brukere som rett og slett ikke vet at lommeboken deres inneholder en gjenbrukt adresse eller en gammel P2PK-utgang. Det er nøyaktig denne gruppen artikkelen retter seg mot.
Skalaen har også en systemisk side, ikke bare en privat. Bitcoins sikkerhetsmodell hviler delvis på at markedet stoler på at eierskap er beskyttet. Dersom en betydelig andel av de 6,9 millioner BTC-ene som i dag ligger eksponert, plutselig ble flyttet av en angriper med tilgang til kvantekraft, ville det ikke bare ramme de individuelle eierne. Det ville også utløse en tillitskrise for nettverket som helhet, ettersom markedet måtte prise inn at “eierskap” av eldre bitcoin ikke lenger var en garantert rettighet. Det er en av grunnene til at BIP-360 diskuteres som et protokollspørsmål og ikke bare som en brukeranbefaling.
Forutsetninger: dette trenger du før du starter
Prosjektet i denne guiden er bygget for å kjøre lokalt på maskinen din, uten at du trenger å laste ned hele blokkjeden. Sørg for at følgende er på plass før du går videre.
- Python 3.11 eller nyere installert (sjekk med
python3 --version) - pip-pakkene
requestsogtabulate(installeres i steg 1) - En liste over dine egne bitcoin-adresser, hentet ut av lommeboken din (Electrum, Sparrow, Ledger Live eller Trezor Suite i nyeste versjon støtter alle adresseeksport)
- Valgfritt: egen Bitcoin Core-node med
txindex=1eller en selvhostet Esplora-instans, dersom du ikke ønsker å sende adressene dine til en tredjeparts API - 15–30 minutter, avhengig av hvor mange adresser lommeboken din har brukt over tid
Merk at hvis du bruker en offentlig blokkjede-API i denne guiden (Esplora fra Blockstream), avslører du hvilke adresser som hører sammen for tjenesteleverandøren. Det er en avveining mellom bekvemmelighet og personvern som vi kommer tilbake til under fallgruver.
Du trenger ikke være utvikler til vanlig for å følge denne guiden, men det hjelper å ha kjørt minst ett Python-skript fra terminalen tidligere. Alt kode du limer inn er kommentert på norsk, og hvert steg bygger direkte videre på det forrige, slik at du kan stoppe opp og teste underveis fremfor å lime inn alt på én gang.
Steg 1–3: Sett opp skannemiljøet
Vi starter med et rent virtuelt miljø slik at avhengighetene ikke rører resten av systemet ditt.
mkdir bitcoin-kvante-skanner
cd bitcoin-kvante-skanner
python3 -m venv venv
source venv/bin/activate
pip install requests tabulateSteg 2 handler om å definere hvilken datakilde skriptet skal bruke. Vi bruker Esplora sitt offentlige API fra Blockstream som standard, fordi det returnerer et felt kalt scriptpubkey_type for hver utgang, noe som gjør klassifiseringen enkel. Ønsker du mer personvern, peker du samme kode mot din egen Esplora-instans ved å bytte ut base-URL-en.
ESPLORA_BASE = "https://blockstream.info/api"
# Bytt til f.eks. "http://localhost:3000" hvis du kjører egen Esplora-nodeSteg 3 er å legge adressene dine i en enkel tekstfil, én adresse per linje, kalt adresser.txt. Ikke lim inn private nøkler eller seed-fraser noe sted i dette prosjektet. Skriptet trenger kun offentlige adresser for å gjøre jobben sin.
Hvor finner du disse adressene? De fleste lommebøker har en “eksporter” eller “vis alle adresser”-funksjon under innstillinger eller avansert visning. Electrum viser alle brukte og ubrukte adresser under fanen “Addresses”. Sparrow Wallet har en tilsvarende visning under “Addresses”-fanen i hver lommebokrad. Bruker du en maskinvarelommebok direkte mot en tredjeparts app som Ledger Live, må du som regel bytte til “avansert modus” for å se hele adresselisten, ikke bare saldoen.
Steg 4–6: Identifiser eksponerte UTXO-er i lommeboken din
Nå bygger vi selve logikken. Steg 4 henter statistikk for hver adresse, inkludert hvor mange ganger den er brukt til å motta og bruke midler. Dette avslører gjenbruk.
import requests
def hent_adressestatistikk(adresse):
r = requests.get(f"{ESPLORA_BASE}/address/{adresse}", timeout=10)
r.raise_for_status()
return r.json()["chain_stats"]
def er_gjenbrukt(stats):
# Adressen er gjenbrukt hvis den har blitt brukt til å sende FRA seg
# samtidig som den fortsatt sitter med ubrukte midler
return stats["spent_txo_count"] > 0 and stats["funded_txo_count"] > stats["spent_txo_count"]Steg 5 henter selve UTXO-listen for adressen, og slår opp scripttypen for hver enkelt utgang via transaksjonsdataene. Dette er kjernen i risikoklassifiseringen.
RISIKO = {
"p2pk": ("KRITISK", "Nøkkelen ligger klartekst i scriptet."),
"v1_p2tr": ("HOY", "Taproot-nøkkelen er synlig i utgangen."),
"p2pkh": ("AVHENGER", "Eksponeres først ved bruk."),
"v0_p2wpkh": ("AVHENGER", "Native SegWit, eksponeres ved bruk."),
"p2sh": ("LAV", "Skjult bak hash til innløsning."),
"v0_p2wsh": ("LAV", "Skjult bak hash til innløsning."),
}
def hent_scripttype(txid, vout_index):
r = requests.get(f"{ESPLORA_BASE}/tx/{txid}", timeout=10)
r.raise_for_status()
vout = r.json()["vout"][vout_index]
return vout.get("scriptpubkey_type", "ukjent")
def hent_utxoer(adresse):
r = requests.get(f"{ESPLORA_BASE}/address/{adresse}/utxo", timeout=10)
r.raise_for_status()
return r.json()Steg 6 samler funnene og justerer risikoen opp dersom en normalt trygg adressetype viser seg å være gjenbrukt. Det er her de fleste overraskelser dukker opp, spesielt for lommebøker som er flere år gamle og har blitt importert mellom ulik programvare underveis.
Et vanlig funn på dette punktet er en adresse som opprinnelig ble opprettet i én lommebok, deretter importert til en annen med en importfunksjon som ikke fulgte samme regel for å alltid generere nye adresser. Resultatet er ofte en håndfull adresser som er brukt om igjen uten at eieren har lagt merke til det, siden saldoen i lommeboken har sett helt normal ut hele veien.
def skann_adresse(adresse):
stats = hent_adressestatistikk(adresse)
gjenbrukt = er_gjenbrukt(stats)
funn = []
for utxo in hent_utxoer(adresse):
script_type = hent_scripttype(utxo["txid"], utxo["vout"])
nivaa, arsak = RISIKO.get(script_type, ("UKJENT", "Ukjent scripttype."))
if script_type in ("p2pkh", "v0_p2wpkh") and gjenbrukt:
nivaa, arsak = "HOY", "Adressen er brukt før, nøkkelen er allerede offentlig."
funn.append({
"adresse": adresse,
"verdi_sats": utxo["value"],
"type": script_type,
"risiko": nivaa,
"arsak": arsak,
})
return funnSteg 7–9: Prioriter og flytt midler trygt
Med en full liste over funn kan du nå sortere etter alvorlighetsgrad. Steg 7 handler om å lage en prioritert flytteliste: alt merket KRITISK flyttes først, deretter HOY, mens AVHENGER og LAV kan vente til du uansett skal bruke midlene neste gang.
Steg 8 er å opprette en ny, aldri tidligere brukt mottaksadresse i lommeboken din. Bruk native SegWit (bc1q) dersom du prioriterer laveste risiko frem til BIP-360 er ferdig utviklet, siden Taproot fortsatt eksponerer nøkkelen med det samme midlene ankommer. Husk regelen fra tidligere: bruk hver adresse kun én gang for mottak, og la lommeboken generere en ny for hver transaksjon. Når BIP-360 aktiveres på hovednettet og lommebok-programvaren støtter bc1z-adresser, gjentar du samme prosess mot den nye adressetypen.
Vær spesielt oppmerksom på om lommeboken din faktisk lar deg velge adressetype for mottak, eller om den har satt et fast standardvalg du ikke ser i det vanlige grensesnittet. Flere eldre lommeboker som ikke har fått oppdateringer på noen år, genererer fortsatt P2PKH-adresser som standard. Sjekk innstillingene, og bytt om nødvendig til en nyere lommebok som Sparrow eller en oppdatert versjon av Electrum før du fortsetter flyttingen.
Steg 9 er selve flyttingen, og her er det verdt å bruke litt tid. Ikke slå sammen alle UTXO-ene dine i én eneste transaksjon. Det knytter adressene dine tydelig sammen for enhver som analyserer kjeden (adresseklynging), noe som til dels motvirker poenget med å flytte bort fra eksponerte nøkler i utgangspunktet. Del i stedet opp flyttingen i flere mindre transaksjoner over noen dager, spesielt for de KRITISK-merkede UTXO-ene.
En praktisk tilnærming er å flytte den enkeltstørste KRITISK-utgangen først, alene, i sin egen transaksjon. Vent til den er bekreftet med flere blokker før du går videre til neste. Dette gir deg også muligheten til å oppdage feil tidlig, for eksempel en feilskrevet mottaksadresse, uten at hele beholdningen din er eksponert i samme transaksjon. Sørg for å betale en fornuftig nettverksavgift for hver flytting, siden en transaksjon som blir hengende ubekreftet lenge, i teorien gir angripere lenger tid på å utnytte en eksponert nøkkel før flyttingen er endelig.
Steg 10–12: Multisig, firmware og overvåkning
Steg 10 legger til et ekstra sikkerhetslag: multisig. En 2-av-3-oppsett, der ingen enkelt nøkkel alene kan flytte midler, reduserer ikke selve kvanterisikoen til den enkelte nøkkelen, men det hever kravet for et vellykket angrep betraktelig siden en angriper må knekke flere uavhengige nøkler samtidig og innenfor samme tidsvindu.
Steg 11 er å holde maskinvarelommeboken din oppdatert. Verken Ledger, Trezor eller Coldcard har i dag post-kvante signaturer i produksjonsfirmware. Alle tre produsentene beskriver i sin 2025–2026-dokumentasjon at de følger NIST-standardiseringen og forbereder støtte for nye scripttyper og større nøkkelstørrelser, men ingen har satt en konkret lanseringsdato for PQ-signering. Oppdater likevel firmware jevnlig, siden støtte for nye adresseformater som P2MR/P2QRH vil komme via ordinære firmware-oppdateringer når BIP-360 modnes.
Steg 12 er å sette opp løpende overvåkning. Kjør skanneskriptet på nytt hver gang du mottar nye midler eller importerer en gammel lommebok, og følg med på utviklingen til BIP-360 direkte via bitcoindev-mailinglisten eller BIP-360-nettsiden. Siden forslaget fortsatt er i aktiv utvikling, kan detaljer i adresseformat og opcode-navn endre seg før en eventuell aktivering.
En enkel måte å holde oversikt på uten å sjekke mailinglisten daglig, er å sette et kalenderpåminnelse hver tredje måned for å kjøre skanneren på nytt og lese status på bip360.org. Fordi soft forks i Bitcoin normalt tar år fra forslag til aktivering, er det ingen grunn til å sjekke oftere enn dette. Det som derimot haster mer, er å faktisk gjennomføre flyttingen av de KRITISK-merkede UTXO-ene dine, siden den jobben er uavhengig av hvor lang tid BIP-360 selv tar.
Det komplette prosjektet: full Python-skanner
Under følger hele skriptet samlet, klart til å lagres som kvante_skanner.py og kjøres direkte. Det leser adresser fra adresser.txt, skanner hver av dem, og skriver ut en sortert risikorapport.
import sys
import time
import requests
from tabulate import tabulate
ESPLORA_BASE = "https://blockstream.info/api"
RISIKO = {
"p2pk": ("KRITISK", "Nøkkelen ligger klartekst i scriptet."),
"v1_p2tr": ("HOY", "Taproot-nøkkelen er synlig i utgangen."),
"p2pkh": ("AVHENGER", "Eksponeres først ved bruk."),
"v0_p2wpkh": ("AVHENGER", "Native SegWit, eksponeres ved bruk."),
"p2sh": ("LAV", "Skjult bak hash til innløsning."),
"v0_p2wsh": ("LAV", "Skjult bak hash til innløsning."),
}
RISIKO_RANG = {"KRITISK": 0, "HOY": 1, "AVHENGER": 2, "LAV": 3, "UKJENT": 4}
def hent_json(url):
r = requests.get(url, timeout=10)
r.raise_for_status()
return r.json()
def hent_adressestatistikk(adresse):
return hent_json(f"{ESPLORA_BASE}/address/{adresse}")["chain_stats"]
def er_gjenbrukt(stats):
return stats["spent_txo_count"] > 0 and stats["funded_txo_count"] > stats["spent_txo_count"]
def hent_scripttype(txid, vout_index):
tx = hent_json(f"{ESPLORA_BASE}/tx/{txid}")
return tx["vout"][vout_index].get("scriptpubkey_type", "ukjent")
def hent_utxoer(adresse):
return hent_json(f"{ESPLORA_BASE}/address/{adresse}/utxo")
def skann_adresse(adresse):
stats = hent_adressestatistikk(adresse)
gjenbrukt = er_gjenbrukt(stats)
funn = []
for utxo in hent_utxoer(adresse):
script_type = hent_scripttype(utxo["txid"], utxo["vout"])
nivaa, arsak = RISIKO.get(script_type, ("UKJENT", "Ukjent scripttype."))
if script_type in ("p2pkh", "v0_p2wpkh") and gjenbrukt:
nivaa, arsak = "HOY", "Adressen er brukt før, nøkkelen er offentlig."
funn.append({
"adresse": adresse,
"verdi_btc": round(utxo["value"] / 1e8, 8),
"type": script_type,
"risiko": nivaa,
"arsak": arsak,
})
time.sleep(0.2) # skån det offentlige API-et
return funn
def main():
with open("adresser.txt") as f:
adresser = [linje.strip() for linje in f if linje.strip()]
alle_funn = []
for adresse in adresser:
try:
alle_funn.extend(skann_adresse(adresse))
except requests.HTTPError as e:
print(f"Advarsel: kunne ikke hente {adresse}: {e}", file=sys.stderr)
alle_funn.sort(key=lambda x: RISIKO_RANG.get(x["risiko"], 9))
tabell = [[f["risiko"], f["adresse"][:12] + "...", f["type"], f["verdi_btc"], f["arsak"]]
for f in alle_funn]
print(tabulate(tabell, headers=["Risiko", "Adresse", "Type", "BTC", "Årsak"]))
total_kritisk = sum(f["verdi_btc"] for f in alle_funn if f["risiko"] in ("KRITISK", "HOY"))
print(f"\nTotalt i KRITISK/HOY risiko: {total_kritisk} BTC")
if __name__ == "__main__":
main()Lagre filen, legg adressene dine i adresser.txt i samme mappe, og kjør skriptet med python3 kvante_skanner.py. Med en lommebok på 10–20 adresser tar en full kjøring vanligvis under et minutt, siden hver adresse krever to eller tre API-kall pluss en liten pause mellom hvert kall. Har du flere hundre adresser, forvent flere minutter, og vurder cache-løsningen beskrevet under avanserte tips lenger ned.
Eksempel på output og hvordan du tolker det
Kjører du skriptet mot en lommebok som har vært i bruk over flere år, ser output typisk slik ut:
Risiko Adresse Type BTC Årsak
-------- ------------- ---------- --------- --------------------------------------------
HOY 1FfmbHfnpaZj... p2pkh 0.02150000 Adressen er brukt før, nøkkelen er offentlig.
HOY bc1p5cyxnuxm... v1_p2tr 0.10000000 Taproot-nøkkelen er synlig i utgangen.
AVHENGER bc1q9d6uu0nl... v0_p2wpkh 0.00340000 Eksponeres først ved bruk.
LAV bc1q...script v0_p2wsh 0.50000000 Skjult bak hash til innløsning.
Totalt i KRITISK/HOY risiko: 0.1215 BTCLegg merke til rekkefølgen: HOY og KRITISK ligger øverst, uavhengig av hvilken kronologisk rekkefølge adressene ble lest inn i. Summen nederst forteller deg konkret hvor mye du bør prioritere å flytte, og gir deg et tall å måle fremgang mot etter hvert som du flytter midler over til nye adresser.
Vanlige fallgruver ved kvantesikring
De fleste feilene i dette prosjektet skjer ikke i koden, men i beslutningene rundt selve flyttingen. Under følger de fallgruvene vi ser oftest når brukere begynner å rydde opp i gamle lommebøker, hentet fra hvordan adresseklynging, gjenbruk og feil prioritering typisk oppstår i praksis.
- Å stole blindt på et offentlig API. Blockstream sitt Esplora-API er praktisk, men hver forespørsel avslører for tjenesteleverandøren hvilke adresser som tilhører samme person. Kjør egen node hvis personvern er viktig for deg.
- Å tro at native SegWit er evig trygt. Fordelen forsvinner i det øyeblikket adressen brukes og deretter mottar nye midler. Bruk alltid en fersk adresse per mottak.
- Å samle alle UTXO-er i én transaksjon. Det knytter adressene dine sammen på kjeden og gjør adresseklynging trivielt for enhver som analyserer transaksjonshistorikken din.
- Å vente på at BIP-360 aktiveres før du gjør noe. Nøkkelhygiene, altså å unngå gjenbruk og flytte bort fra P2PK, er noe du kan og bør gjøre lenge før noen post-kvante opcode er live.
- Å glemme endre-adressen (change). En transaksjon som bruker en gammel P2PKH-utgang, sender ofte vekslepenger tilbake til en ny adresse av samme gamle type hvis lommeboken din ikke er konfigurert til å bruke en nyere standard som standard.
- Å ikke verifisere adresser selv før flytting. Skriptet i denne guiden gir deg et risikobilde, men du bør alltid dobbeltsjekke mottaksadressen på skjermen til maskinvarelommeboken din før du signerer.
- Å behandle BIP-360 som ferdig og aktivert. Forslaget er slått sammen i BIP-repoet og testet på et testnett, men det er fortsatt langt fra en aktivert soft fork på hovednettet. Bygg ikke langsiktige planer rundt bc1z-adresser før lommeboken og nettverket faktisk støtter dem i produksjon.
Feilsøking: 8 vanlige problemer og løsninger
Selv et enkelt skript mot et offentlig API kan snuble på flere måter, spesielt hvis lommeboken din har flere hundre historiske adresser eller du kjører skannerene mot en node med begrenset kapasitet. Her er de vanligste feilmeldingene og hvordan du løser dem.
- HTTP 429 Too Many Requests fra Esplora. Du sender for mange forespørsler for raskt. Øk
time.sleep()-verdien i skriptet, eller kjør mot din egen node. - requests.exceptions.ConnectionError. API-et er nede eller du mangler internettforbindelse. Prøv en alternativ Esplora-instans, eller vent noen minutter og prøv igjen.
- KeyError på ‘scriptpubkey_type’. Enkelte eldre eller uvanlige transaksjoner mangler feltet. Bruk alltid
.get()med en standardverdi, slik skriptet over gjør. - Adressen viser tomme UTXO-er selv om du vet den har midler. Sjekk at du ikke ved en feil har limt inn en testnet-adresse mot et mainnet-API, eller omvendt.
- Skriptet er tregt på lommebøker med hundrevis av adresser. Legg til parallellisering med
concurrent.futures.ThreadPoolExecutor, men hold samtidigheten lav (3–5 samtidige forespørsler er vanligvis trygt) for å ikke bli blokkert av API-et. Kombiner gjerne med SQLite-cachen fra avanserte tips for å unngå å slå opp samme transaksjon flere ganger. - SSL-feil ved tilkobling. Oppdater
certifi-pakken medpip install --upgrade certifi, spesielt på eldre Python-installasjoner. - Feil klassifisering av “gjenbrukt”. Noen lommebøker bruker interne endre-adresser på måter som kan gi falske positiver. Kryssjekk mistenkelige funn manuelt på en blokkjede-utforsker før du konkluderer.
- Multisig-transaksjonen nekter å signere. Dette skyldes som regel at maskinvarelommebøkene i oppsettet bruker ulike derivasjonsstier. Bekreft at alle enhetene er satt opp med samme BIP48- eller BIP87-sti før du prøver på nytt, og at hver enhet faktisk har importert de andre deltakernes offentlige nøkler korrekt.
Avanserte tips og neste steg
Hvis du vil gå lenger enn den grunnleggende skanneren, finnes det flere naturlige utvidelser. Legg til en cache-mekanisme som lagrer allerede oppslåtte transaksjoner lokalt i en SQLite-database, slik at gjentatte kjøringer mot samme lommebok går raskere og belaster API-et mindre. Du kan også koble skriptet til en varslingstjeneste, for eksempel en enkel e-postjobb, som kjører ukentlig og varsler deg dersom en ny KRITISK- eller HOY-adresse dukker opp i lommeboken din.
En minimal cache trenger bare å lagre resultatet av hent_scripttype(), siden en transaksjons scripttype aldri endrer seg etter at den er bekreftet på kjeden:
import sqlite3
def hent_cache():
db = sqlite3.connect("cache.db")
db.execute("CREATE TABLE IF NOT EXISTS scripttyper (txid TEXT, vout INTEGER, type TEXT, PRIMARY KEY (txid, vout))")
return db
def hent_scripttype_cachet(db, txid, vout_index):
rad = db.execute("SELECT type FROM scripttyper WHERE txid=? AND vout=?", (txid, vout_index)).fetchone()
if rad:
return rad[0]
script_type = hent_scripttype(txid, vout_index)
db.execute("INSERT INTO scripttyper VALUES (?, ?, ?)", (txid, vout_index, script_type))
db.commit()
return script_typeBytt ut kallet til hent_scripttype() i hovedskriptet med hent_scripttype_cachet(db, ...), og gjentatte kjøringer mot samme lommebok blir merkbart raskere allerede fra andre gang.
For større beholdninger bør du vurdere PSBT-basert signering (Partially Signed Bitcoin Transactions) kombinert med air-gapped maskinvarelommebøker. Det betyr at den enheten som faktisk signerer, aldri kobles til internett, noe som fjerner en hel klasse angrep uavhengig av kvantetrusselen. Sparrow Wallet og Electrum støtter begge PSBT-arbeidsflyt sammen med de fleste maskinvarelommebøker.
Det er også verdt å kjenne til hvilke signaturalgoritmer som faktisk ligger bak begrepet “post-kvante” i Bitcoin-sammenheng, siden BIP-360-materialet peker mot NIST-familien fremfor eksotiske alternativer som SQIsign, som ble forlatt tidlig i 2025. De to mest aktuelle kandidatene er svært forskjellige i størrelse, noe som har direkte konsekvens for hvor mye plass fremtidige transaksjoner vil ta.
| Algoritme | NIST-status | Egenskap relevant for Bitcoin |
|---|---|---|
| ML-DSA (Dilithium) | Standardisert av NIST | Raskere signering, men vesentlig større signaturer enn ECDSA/Schnorr |
| SLH-DSA (SPHINCS+) | Standardisert av NIST | Hash-basert og svært konservativ sikkerhetsmessig, men tregere og enda større signaturer |
| SQIsign | Forlatt fra BIP-360 tidlig i 2025 | Kompakte signaturer, men vurdert som umodent for produksjon i Bitcoin-sammenheng |
Denne størrelsesforskjellen er en del av grunnen til at BIP-360 er designet som et to-trinns løp: først en ny utgangstype som gir plass til fremtidige signaturer, deretter en egen beslutning om hvilken av disse algoritmene som faktisk skal aktiveres. Følg med på diskusjonen dersom du er interessert i detaljene, men for din egen migrering er det viktigste å ha midlene liggende i en adressetype som er klar til å ta imot den løsningen fellesskapet til slutt lander på.
Følg også med på veikartet for BIP-360 selv, siden detaljene fortsatt kan endre seg før en eventuell aktivering på hovednettet.
| Milepæl | Status | Tidspunkt |
|---|---|---|
| BIP-360 (P2MR/P2QRH) publisert og slått sammen i BIP-repoet | Fullført | Februar 2026 |
| SQIsign fjernet fra forslaget til fordel for NIST-algoritmer | Fullført | Tidlig 2025 |
| Bitcoin Quantum Testnet v0.3.0 med Dilithium-opcoder | Fullført (testnett) | Mars 2026 |
| Maskinvarelommebok-støtte for P2MR/P2QRH-adresser | Under utvikling | Ikke fastsatt |
| Eventuell aktivering av PQ-signaturopcoder på hovednettet | Ikke fastsatt | Avhenger av konsensus og videre forskning |
Husk at rekkefølgen i tabellen ikke er en garanti. Bitcoin-utvikling går gjennom lange perioder med gjennomgang og debatt, og et forslag som er slått sammen i repoet er fortsatt langt fra en aktivert soft fork.
Ofte stilte spørsmål
Her samler vi de spørsmålene som oftest dukker opp når vi diskuterer kvantetrusselen mot Bitcoin med lesere, fra tidsperspektiv til konkrete handlinger du kan ta i dag.
Når kan en kvantedatamaskin faktisk knekke Bitcoin sine nøkler?
Ingen vet et eksakt årstall. De fleste 2026-analyser plasserer en kryptografisk relevant kvantedatamaskin et sted i 2030-årene, med enkelte mer konservative anslag som strekker seg mot 2040-tallet. Ingen eksisterende maskin er i nærheten av å true secp256k1 i dag.
Er lommeboken min i fare akkurat nå?
Ikke fra et kvanteangrep i dag. Risikoen er fremtidig og avhenger av om det finnes en fungerende CRQC. Det som derimot er reelt i dag, er at eksponerte nøkler blir stående lenger jo lenger du venter med å rydde opp i adressehygienen din, og at flytting av store beholdninger uansett tar tid å gjøre riktig uten å skape unødige koblinger mellom adressene dine.
Hva er forskjellen på BIP-360 og en vanlig myk fork?
BIP-360 er teknisk sett også en myk fork, men den beskrives av utviklerne som et “enabling primitive”. Det betyr at den i seg selv ikke innfører post-kvante signaturer, men skaper en ny utgangstype (P2MR/P2QRH) som senere kan utvides med slike signaturer gjennom en egen, separat soft fork.
Bør jeg flytte alle mine bitcoin nå?
Nei, ikke i panikk og ikke i én transaksjon. Prioriter adresser merket KRITISK og HOY i skanneren, flytt dem gradvis i separate transaksjoner, og la resten ligge til du uansett skal bruke dem.
Er maskinvarelommebøker som Ledger og Trezor kvantesikre?
Ikke ennå. Verken Ledger, Trezor eller Coldcard har post-kvante signaturer i produksjonsfirmware per 2026. Alle beskriver at de følger NIST-standardiseringen og planlegger støtte for nye adresseformater etter hvert som Bitcoin-protokollen selv støtter dem. Det betyr i praksis at du ikke kan kjøpe deg ut av problemet ved å bytte maskinvarelommebok i dag. Det du derimot kan gjøre, er å velge en produsent med en åpen, dokumentert oppgraderingsplan og holde firmwaren løpende oppdatert.
Hva skjer med tapte eller inaktive bitcoin i P2PK-adresser?
De rundt 1,7 millioner BTC i legacy P2PK-utganger, mange fra Bitcoins aller tidligste år, kan ikke flyttes av noen siden nøklene antas tapt eller eierne er inaktive. Disse forblir sårbare uansett hva protokollen gjør, med mindre samfunnet på et tidspunkt vedtar en kontroversiell mekanisme for å fryse dem, slik enkelte forslag har diskutert.
Kan jeg bruke skriptet i artikkelen på en lommebok med veldig mange adresser?
Ja, men vurder å legge til parallellisering og en lokal cache som beskrevet under avanserte tips, samt å kjøre mot din egen node fremfor et offentlig API for å unngå både treghet og personvernlekkasje.
Hva bør jeg gjøre helt konkret i dag?
Kjør skanneren mot adressene dine, identifiser alt merket KRITISK og HOY, flytt disse midlene gradvis til ferske adresser, slutt å gjenbruke mottaksadresser, og hold både lommebok-programvare og maskinvarefirmware oppdatert slik at du automatisk får støtte når BIP-360 modnes.
