To signaturalgoritmer definerer i praksis hvordan penger, kontrakter og identiteter bekreftes digitalt i 2026: ECDSA, arbeidshesten som har signert Bitcoin-transaksjoner, TLS-sertifikater og Ethereum-lommebøker i over et tiår, og Schnorr, algoritmen Bitcoin byttet til i november 2021 gjennom Taproot-oppgraderingen. Forskjellen er ikke bare akademisk. Schnorr-signaturer er fast 64 byte mot ECDSAs variable 70–72 byte, de kan aggregeres til én enkelt signatur for flere deltakere gjennom MuSig2, og de verifiseres om lag 15 % raskere enn ECDSA på tilsvarende maskinvare. For norske og nordiske utviklere som bygger lommebøker, betalingsløsninger eller Lightning-infrastruktur er valget mellom de to ikke lenger teoretisk, det er et spørsmål om gebyrkostnad, personvern og hvilke biblioteker som faktisk støtter hva.

Denne artikkelen går gjennom de tekniske forskjellene, ytelsestall fra tre uavhengige kilder, faktisk Taproot-adopsjon på Bitcoin-nettverket i 2025 og tidlig 2026, og en praktisk migreringsvei for team som fortsatt sitter med rene ECDSA-oppsett. Vi ser også på hvor ECDSA fortsatt er det riktige valget, for eksempel i TLS og Ethereum, og hvor Schnorr gir en reell fordel i kroner og øre.

Sammenligningen er relevant langt utenfor rene Bitcoin-miljøer. Norske betalingsselskaper, banker som eksperimenterer med Bitcoin-relaterte tjenester, og børser som håndterer store uttaksvolumer må alle ta stilling til hvilken signaturstrategi de bygger videre på. Feil valg koster ikke bare i gebyrer, det påvirker også hvor enkelt systemet lar seg utvide med multisig, hvor godt det skalerer når transaksjonsvolumet vokser, og hvor mye personvern kundene faktisk får.

Hva er ECDSA, og hvorfor dominerer den fortsatt?

ECDSA, Elliptic Curve Digital Signature Algorithm, er den elliptiske kurve-varianten av DSA-standarden fra 1990-tallet. Den har vært ryggraden i Bitcoin siden lanseringen i 2009, brukes i TLS/X.509-sertifikater over hele nettet, og driver signeringen bak hver Ethereum-transaksjon i dag. Styrken til ECDSA er utbredelsen: nesten alle kryptografibiblioteker, maskinvarelommebøker og nettlesere støtter den, og standardiseringen går tilbake flere tiår.

Svakheten ligger i detaljene. En ECDSA-signatur kodes med ASN.1 DER-format, som gjør signaturen variabel i lengde, typisk 70–72 byte i en reell Bitcoin-transaksjon, men teoretisk sett kan den bli så kort som 8 byte avhengig av hvordan heltallene r og s koder seg. Denne variasjonen gjør det vanskeligere å beregne nøyaktig transaksjonsstørrelse på forhånd, og den ikke-lineære matematikken bak ECDSA gjør det komplisert å bygge multisignatur-ordninger uten at hver part signerer separat. Tidlige Bitcoin-implementasjoner av ECDSA var dessuten sårbare for signaturmalleabilitet, der en tredjepart kunne endre s-verdien og fortsatt produsere en gyldig signatur, noe som skapte reelle problemer for transaksjons-ID-er før SegWit løste det i 2017.

Hva er Schnorr-signaturer, og hvorfor valgte Bitcoin dem?

Schnorr-signaturer er oppkalt etter matematikeren Claus-Peter Schnorr, som patenterte konstruksjonen allerede i 1989. Patentet gikk ut i 2008, rett før Bitcoin ble lansert, men Satoshi Nakamoto valgte likevel ECDSA fordi det var bedre dokumentert i datidens biblioteker. Det tok Bitcoin-miljøet over et tiår å hente inn forskjellen: BIP340 spesifiserer Schnorr-signaturer over samme secp256k1-kurve som ECDSA bruker, og forslaget ble en del av Taproot-oppgraderingen som ble låst inn av minere i juni 2021 og aktivert på blokk 709 632 i november 2021, ifølge Bitcoin Optechs nyhetsbrev om aktiveringen.

Den store forskjellen fra ECDSA er linearitet. Schnorr-matematikken lar flere offentlige nøkler adderes til én nøkkel, og de tilhørende signaturandelene adderes til én enkelt signatur som verifiserer mot den kombinerte nøkkelen. Det er denne egenskapen som gjør MuSig2-protokollen mulig, og som ligger bak Taproots evne til å skjule om en transaksjon kommer fra én person eller ti. BIP340 beskriver selv målet som “a simple and efficient method that enables multiple collaborating parties to produce a signature that is valid for the sum of their public keys”, som sitert av Bitcoin-utdanningsprosjektet We Are Bitcoin.

secp256k1: kurven begge algoritmene deler

Det er lett å tro at ECDSA og Schnorr er to konkurrerende kurver, men de deler faktisk samme matematiske fundament i Bitcoin: den elliptiske kurven secp256k1. Sikkerhetsnivået mot diskret logaritme-problemet er derfor identisk mellom de to, cirka 128-bit sikkerhet mot kjente klassiske angrep. Forskjellen ligger utelukkende i hvordan signaturen konstrueres oppå kurven, ikke i selve kurvens styrke. Det er en viktig avklaring for team som vurderer overgang, fordi det betyr at Schnorr ikke er et sikrere valg i betydningen “sterkere kryptografi”. Det er et bedre valg i betydningen “enklere matematisk struktur som åpner for funksjonalitet ECDSA aldri kunne tilby uten omveier”.

Teknisk sammenligning: signaturstørrelse, nøkler og format

Tabellen under samler de tekniske forskjellene mellom ECDSA og Schnorr slik de brukes i Bitcoin i dag. Begge algoritmene opererer over samme secp256k1-kurve, så den underliggende sikkerheten mot diskret logaritme-problemet er lik. Forskjellen ligger i konstruksjon, kodingsformat og hvordan signaturene oppfører seg når flere parter er involvert.

EgenskapECDSA (secp256k1)Schnorr (BIP340)
Elliptisk kurvesecp256k1secp256k1
Signaturstørrelse70–72 byte (DER, variabel, teoretisk ned til 8 byte)64 byte (fast lengde)
Offentlig nøkkel (komprimert)33 byte32 byte (x-only)
KodingsformatASN.1 DERFast binærformat
Linearitet / aggregeringNei, ikke-lineær matematikkJa, støtter nøkkel- og signaturaggregering
Batch-verifiseringIngen nevneverdig gevinst i standardformOm lag 2x raskere ved store batcher
Verifiseringshastighet (relativt)ReferansenivåOm lag 15 % raskere på tilsvarende maskinvare
Multisig-håndteringKrever separate signaturer og script per partMuSig2 aggregerer alt til én signatur
SikkerhetsbevisMer komplekst formelt bevisEnkelt bevis under diskret logaritme i standardmodellen
Malleabilitet (historisk)Tidlige implementasjoner sårbare før SegWitDesignet ikke-malbart og deterministisk
Standardisert i Bitcoin fra2009 (fra starten)Blokk 709 632, november 2021
Hovedbruk i dagTLS/X.509, Ethereum, pre-Taproot Bitcoin-adresserBitcoin Taproot (P2TR), Lightning Taproot-kanaler
Adopsjonsandel Bitcoin-tx (tidlig 2026)Om lag 80–85 % av transaksjoneneOm lag 15–20 % av transaksjonene (P2TR)

Legg merke til at ECDSA-signaturen faktisk kan bli kortere enn Schnorr i sjeldne tilfeller, siden DER-kodingen er variabel. I praksis ser man det nesten aldri, og gjennomsnittlig ECDSA-signatur i en reell Bitcoin-transaksjon ligger stabilt på 70–72 byte. Kombinert med at den offentlige nøkkelen også er én byte kortere for Schnorr, blir totalbesparelsen per enkeltsignatur beskjeden isolert sett, men den blir betydelig så snart flere signaturer eller flere parter er involvert.

Hvorfor byte-forskjellen betyr noe i praksis

Åtte til ti byte høres ikke mye ut isolert sett, men i Bitcoin betales gebyret per vbyte, ikke per transaksjon. Lommeboker som bygger transaksjoner med flere innganger, for eksempel en børs som samler mange innskudd til én uttaksbatch, multipliserer forskjellen med antall innganger. En transaksjon med 50 innganger sparer i praksis flere hundre byte bare på signaturvalget, før man i det hele tatt regner med gevinsten fra mindre offentlige nøkler. Den faste lengden på Schnorr gjør det også enklere for lommebokprogramvare å estimere gebyr nøyaktig før en transaksjon sendes, siden utvikleren slipper å bygge inn en sikkerhetsmargin for verste-tilfelle DER-koding slik ECDSA krever.

Ytelsestall: hva sier tre uavhengige benchmarks?

Ytelse er der forskjellen mellom algoritmene blir konkret. Tre separate kilder gir sammenlignbare, men ikke identiske tall, noe som er normalt for mikrobenchmarks på forskjellig maskinvare og med forskjellige biblioteker.

  • Bitcoin Optech Newsletter #379 viser at libsecp256k1, biblioteket Bitcoin Core selv bruker, verifiserer ECDSA-signaturer 2,5 til 5,5 ganger raskere enn en generisk OpenSSL-implementasjon når DER-parsing regnes med. Tallet sier mer om implementasjonskvalitet enn om selve algoritmen, men det viser hvor mye biblioteksvalg påvirker reell ytelse.
  • Spark sin tekniske referanse for Schnorr og MuSig2 rapporterer at Schnorr-verifisering (BIP340) er om lag 15 % raskere enn ECDSA-verifisering på tilsvarende maskinvare over secp256k1, hovedsakelig fordi Schnorr slipper DER-parsing og har enklere aritmetikk. Samme kilde peker på at batch-verifisering av mange Schnorr-signaturer samtidig kan gi omtrent 2x hastighetsgevinst, mens ECDSA i standardform ikke har noen tilsvarende batch-fordel.
  • Et uavhengig benchmark-skriv fra 2024, “Faster Signatures on secp256k1” av utvikleren jtobin, målte en 7,5 ganger forbedring i ECDSA-signering og nesten 2 ganger forbedring i ECDSA-verifisering etter optimalisering, samtidig som Schnorr-signering ble målt til rundt 5,3 millisekund per operasjon på testmaskinvaren som ble brukt.

Konklusjonen fra alle tre kildene peker samme vei: forskjellen i rå verifiseringshastighet mellom godt optimalisert ECDSA og Schnorr er moderat, gjerne i området 15–30 % avhengig av implementasjon, men Schnorrs evne til batch-verifisering gir en fordel som skalerer med antall signaturer en node eller børs må sjekke samtidig. For en full node som validerer tusenvis av signaturer per blokk er dette ikke en marginal detalj. Jo flere signaturer et system verifiserer per sekund, desto mer merkbar blir batch-fordelen i praksis, noe som gjør Schnorr spesielt attraktivt for infrastruktur som noder, børser og blokkutforskere fremfor enkeltbrukerlommebøker som bare signerer én transaksjon om gangen.

Taproot-adopsjon: fra null til 20 % av Bitcoin-nettverket

Adopsjonstallene forteller en historie med både vekst og en overraskende topp og nedgang. Taproot-adressen P2TR var praktisk talt fraværende frem til 2023, men vokste raskt da inskripsjons- og Ordinals-relatert aktivitet begynte å bruke Taproot-scriptstier for å lagre data på kjeden. Ifølge on-chain-data sitert via Glassnode nådde Taproot-utganger en topp på rundt 42 % av alle transaksjoner i 2024, drevet nesten utelukkende av denne inskripsjonsbølgen.

Da inskripsjonsaktiviteten falt, falt også Taproot-andelen. Sparks Taproot Adoption Tracker anslår at P2TR-transaksjoner utgjorde om lag 15–20 % av nettverksaktiviteten i 2025, og samme nivå, 15–20 %, holdt seg inn i tidlig 2026. Det viktige poenget her er at dette representerer det Spark omtaler som organisk adopsjon fra lommebøker og protokoller, altså vanlige brukere og applikasjoner som aktivt velger Taproot-adresser, ikke inskripsjonsspekulanter som utnyttet scriptstien midlertidig. For enkeltsignatur-utganger gir P2TR ifølge samme kilde over 40 % lavere gebyr sammenlignet med den eldre P2PKH-adressetypen, en besparelse som kommer direkte av mindre witness-data og mer effektiv scriptstruktur.

Hva betyr dette for nordiske børser og lommebokleverandører?

Norske og nordiske kryptobørser, betalingsselskaper og lommebokleverandører prosesserer store volumer av uttak hver eneste dag, og hver enkelt transaksjon betaler gebyr basert på byte-vekt. Med en Taproot-andel som fortsatt ligger på 15–20 % av nettverket, betyr det at flertallet av bransjen fortsatt sitter igjen med den høyere ECDSA-kostnaden uten å ha tatt steget over. Samtidig gjør EUs reviderte kapitalkravsforordning og økende krav til driftseffektivitet i finanssektoren at selskaper med tynne marginer på transaksjonsgebyrer har et konkret insentiv til å prioritere migrering. Et selskap som håndterer titusenvis av uttak månedlig, og som fortsatt bruker legacy- eller ren SegWit-adresser, betaler i realiteten en løpende signaturpremie som en Taproot-migrering ville fjernet.

MuSig2 og signaturaggregering: der Schnorr virkelig skinner

MuSig2 er protokollen som utnytter Schnorrs linearitet til å la flere deltakere produsere én enkelt signatur som ser identisk ut på kjeden som en vanlig enkeltsignatur. En N-av-N multisig-adresse blir dermed synlig som ett 64-byte signatur og én 32-byte aggregert offentlig nøkkel, uavhengig av hvor mange parter som faktisk deltok. Til sammenligning må en tradisjonell ECDSA n-av-m multisig inkludere flere separate 70–72-byte signaturer pluss scriptlogikken som beskriver terskelen, noe som ifølge Sparks referansemateriale og Bitcoin Optechs Taproot-side gir en reduksjon i witness-størrelse på 40–60 % for typiske oppsett med få deltakere når man går over til MuSig2.

Gevinsten stopper ikke ved gebyr. Fordi en MuSig2-signert transaksjon ser identisk ut som en enkeltsignatur-transaksjon, blir det umulig for en ekstern observatør å se at en Bitcoin-adresse egentlig styres av flere nøkler. Det er en personvernfordel bedrifts-treasuries og DAO-er har begynt å verdsette, i tillegg til kostnadsbesparelsen. Lightning Network har tatt konsekvensen av dette videre: utviklere bak Taproot-kanaler har beskrevet hvordan slike kanaler bruker én enkelt Schnorr-signatur til å bruke finansieringsutgangen i stedet for en tradisjonell 2-av-2 ECDSA-multisig, noe som gir mindre witness-data og billigere kanallukking, et tema som ble fremhevet i flere Bitcoin Optech-gjennomganger gjennom 2025.

For en norsk bedrift som forvalter Bitcoin på vegne av kunder, for eksempel en forvalter av kald lagring eller en Lightning-basert betalingsleverandør, betyr denne personvernegenskapen at man kan operere med interne multisig-kontroller uten å avsløre kontrollstrukturen for konkurrenter eller angripere som analyserer offentlig kjededata. Det gjør MuSig2 til noe mer enn en gebyroptimalisering, det er også et sikkerhetstiltak som reduserer hvor mye informasjon en angriper kan hente ut bare ved å se på blokkjeden.

Sikkerhetsegenskaper: bevisbarhet og malleabilitet

Begge algoritmene hviler på det samme matematiske problemet, diskret logaritme over elliptiske kurver, og ingen kjent praktisk angrepsvei bryter noen av dem i 2026. Forskjellen ligger i hvor rent sikkerhetsbeviset er. Schnorr-signaturer har et enkelt, velkjent sikkerhetsbevis i standardmodellen under diskret logaritme-antagelsen, mens ECDSAs bevis er mer sammensatt og historisk sett vanskeligere å analysere formelt for kompliserte protokoller, ifølge Sparks tekniske gjennomgang og Bitcoin Optechs Taproot-dokumentasjon. For utviklere som bygger avanserte protokoller oppå signaturskjemaet, som terskelsignaturer eller adaptorsignaturer for atomiske bytter, gjør denne forskjellen Schnorr til et enklere fundament å resonnere formelt rundt.

Malleabilitet er det andre punktet. Tidlige Bitcoin-implementasjoner av ECDSA lot en tredjepart endre s-verdien i en signatur og likevel produsere en gyldig, men annerledes kodet signatur, noe som endret transaksjons-ID-en uten å ugyldiggjøre transaksjonen. Dette skapte reelle problemer for lommebokprogramvare som stolte på uendrede transaksjons-ID-er, og var en medvirkende årsak til SegWit-oppgraderingen i 2017. BIP340 Schnorr ble designet fra grunnen av til å være ikke-malbar og deterministisk, slik at samme melding og nøkkel alltid gir samme signatur, noe som forenkler design av protokoller bygget oppå den, som Lightning og MuSig2.

Bibliotek- og verktøystøtte for utviklere i 2026

Ingen av algoritmene er nyttig for et utviklerteam uten modne biblioteker, noe Bitcoin Optechs Taproot-ressursside dokumenterer grundig for Schnorr-økosystemet spesifikt. ECDSA har et enormt forsprang her rett og slett fordi det har eksistert lengst: OpenSSL, Bouncy Castle, Web Crypto API i nettlesere, og praktisk talt hvert eneste TLS-bibliotek støtter ECDSA ut av boksen. For Bitcoin-spesifikk ECDSA-signering er libsecp256k1, biblioteket vedlikeholdt av Bitcoin Core-utviklere, fortsatt referanseimplementasjonen de fleste lommebøker bygger på.

Det samme biblioteket, libsecp256k1, har siden 2021 også hatt en dedikert Schnorr-modul som implementerer BIP340, og de fleste moderne Bitcoin-verktøy som rust-bitcoin, BitcoinJS og Python-biblioteket buidl har fulgt etter med native støtte. MuSig2-implementasjoner er derimot yngre og mindre standardiserte. Team som vurderer MuSig2 i produksjon bør sjekke om biblioteket følger den ferdigstilte BIP327-spesifikasjonen, ettersom tidlige eksperimentelle MuSig-varianter fra før 2022 ikke er kompatible med den endelige protokollen. Maskinvarelommebøker er der det fortsatt er størst variasjon: nyere fastvareversjoner fra de store produsentene støtter Taproot-signering, men eldre enheter kan kreve en fastvareoppdatering eller mangler støtten helt, noe utviklerteam bør teste eksplisitt før de antar at en integrasjon fungerer på tvers av alt maskinvareutvalg.

For team som jobber i Node.js- eller Python-miljøer, som mange norske fintech-selskaper gjør, finnes det i dag godt vedlikeholdte bindings mot libsecp256k1 for begge språk, slik at man slipper å reimplementere lavnivå elliptisk kurve-matematikk selv. Å skrive egen kryptografisk kode fra bunnen av frarådes uansett i produksjon, uavhengig av hvor enkel Schnorr-konstruksjonen ser ut på papiret, ettersom implementasjonsdetaljer som konstant-tid-utførelse og riktig nonce-generering er lette å gjøre feil og vanskelige å oppdage uten dedikert sikkerhetsgjennomgang.

Kostnadssammenligning: hva koster signaturvalget i praksis?

Siden Bitcoin-gebyrer beregnes ut fra transaksjonens vekt i byte, oversettes hver byte spart i signatur og nøkkel direkte til lavere kostnad per transaksjon. Tabellen under viser gebyrbesparelsen for typiske bruksmønstre, sammenlignet mot ECDSA som referansenivå.

TransaksjonstypeSignaturalgoritmeGebyrbesparelse vs. ECDSA-referanseKilde
Legacy enkeltsignatur (P2PKH)ECDSAReferansenivå (0 %)Bitcoincash.org-spesifikasjon
Taproot enkeltsignatur (P2TR keypath)SchnorrOver 40 % lavere gebyrSpark Taproot Adoption Tracker
Tradisjonell n-av-m multisig (P2SH)ECDSAReferansenivå for multisigBitcoin Optech
MuSig2-aggregert multisig (Taproot)Schnorr40–60 % mindre witness-dataSpark Schnorr & MuSig2-referanse
Lightning-kanal, 2-av-2 multisig (pre-Taproot)ECDSAReferansenivå for kanallukkingBitcoin Optech-gjennomgang
Lightning Taproot-kanal (enkelt Schnorr-signatur)SchnorrMindre witness, billigere lukkingBTCStudy Optech 2025-årsoppsummering

For en børs eller lommebokleverandør som prosesserer titusenvis av uttak i måneden, legger denne typen prosentvise besparelser seg raskt opp til en synlig driftskostnad. En norsk eller nordisk børs som fortsatt sender ut legacy P2PKH- eller vanlig P2WPKH-transaksjoner betaler i praksis en signaturpremie hver eneste dag sammenlignet med konkurrenter som har migrert til Taproot-utganger. Over et år med jevnt uttaksvolum kan denne premien utgjøre en betydelig andel av det totale gebyrbudsjettet, spesielt i perioder med høy nettverksbelastning der sat/vB-prisen stiger og hver spart byte teller mer enn normalt.

Fem virkelige eksempler på ECDSA og Schnorr i produksjon

  1. Bitcoin Core og Taproot-aktiveringen. Taproot, inkludert BIP340 Schnorr, ble låst inn av minere i juni 2021 og aktivert på blokk 709 632 i november 2021, dokumentert i Bitcoin Optechs nyhetsbrev “Locking In Taproot”. Aktiveringen skjedde uten en eneste kjedesplitt, noe som i seg selv regnes som et bevis på at koordinert konsensusendring fortsatt er mulig i et desentralisert nettverk med tusenvis av uavhengige node-operatører.
  2. Lightning Network Taproot-kanaler. Implementasjoner som Eclair, LDK og Core Lightning har i 2025 lagt til støtte for såkalte enkle Taproot-kanaler, der finansieringsutgangen brukes med én Schnorr-signatur i stedet for en 2-av-2 ECDSA-multisig, omtalt i Bitcoin Optechs podcast-oppsummeringer og BTCStudys Optech-årsgjennomgang for 2025. For nodedriftere med mange kanaler betyr dette lavere kostnad hver gang en kanal åpnes eller lukkes på kjeden, noe som legger seg opp over tid ettersom kanaler rutinemessig rebalanseres eller stenges.
  3. Bitcoin Cash sin Schnorr-oppgradering fra 2019. Bitcoin Cash spesifiserte Schnorr-signaturer over secp256k1 allerede i sin 2019-oppgradering, dokumentert i Bitcoincash.org sin egen Schnorr-spesifikasjon, som viste at teknologien var produksjonsklar lenge før Bitcoin selv tok den i bruk. Det gjør Bitcoin Cash til det første store nettverket som beviste at Schnorr fungerte i skarp drift, over to år før Bitcoins egen Taproot-aktivering.
  4. TLS og web-PKI holder fast på ECDSA. X.509-sertifikater som sikrer HTTPS-trafikk over hele verden, inkludert norske banker og offentlige tjenester, bruker fortsatt overveiende ECDSA (typisk over P-256), ettersom Schnorr aldri har blitt standardisert inn i TLS- eller X.509-økosystemet. Dette illustrerer hvor stor forskjell det er mellom Bitcoins raske protokollutvikling og de tregere, mer konservative standardiseringsløpene som styrer internett-PKI.
  5. Ethereum og secp256k1-ECDSA. Hver Ethereum-transaksjon signeres i dag med ECDSA over samme secp256k1-kurve som Bitcoin brukte før Taproot, og økosystemet har ingen brei, native Schnorr-støtte per tidlig 2026, selv om kontoabstraksjon (ERC-4337) åpner for alternative signaturskjemaer på applikasjonsnivå. Det betyr at et team som bygger på tvers av Bitcoin og Ethereum i praksis må vedlikeholde to forskjellige signeringsstrategier samtidig.

Fem bruksområder: når bør du velge ECDSA, og når Schnorr?

Valget avhenger nesten alltid av hvilket system du bygger på, ikke av en generell teknisk preferanse. Her er fem konkrete anbefalinger for nordiske utviklerteam.

  • Bitcoin-lommebok med enkeltsignatur: velg Taproot-adresser (P2TR) med Schnorr som standard. Gebyrbesparelsen på over 40 % sammenlignet med legacy-adresser gjør dette til et enkelt valg for nye lommebokprosjekter i 2026, og de fleste populære lommebokrammeverk støtter det allerede ut av boksen.
  • Bedrifts- eller DAO-treasury med multisig: gå for MuSig2 over Schnorr fremfor tradisjonell P2SH-multisig. Du får både lavere gebyr og bedre personvern, siden en aggregert signatur ikke avslører hvor mange nøkler som faktisk kontrollerer midlene, noe som gjør det vanskeligere for utenforstående å kartlegge treasury-strukturen din fra offentlig kjededata.
  • Lightning-node-operatører: prioriter implementasjoner med støtte for Taproot-kanaler når biblioteket ditt (Eclair, LDK, Core Lightning) tilbyr det, for billigere kanallukking og bedre skalerbarhet ved mange samtidige kanaler. Dette er spesielt relevant for noder som håndterer høyt volum og rutinemessig rebalanserer kanaler.
  • TLS-servere og offentlig PKI: bli værende på ECDSA (typisk P-256 eller P-384) inntil Schnorr eventuelt standardiseres inn i X.509 og TLS-økosystemet. Det finnes i dag ingen bred nettleserstøtte for Schnorr-baserte sertifikater, og å avvike fra standarden vil bryte kompatibilitet med nesten alle klienter.
  • Ethereum- og EVM-baserte applikasjoner: hold deg til ECDSA på protokollnivå, men vurder kontoabstraksjon (ERC-4337) hvis du trenger aggregerte eller alternative signaturskjemaer på applikasjonslaget. Dette gir deg mye av fleksibiliteten Schnorr tilbyr på Bitcoin, uten å måtte vente på en protokollendring i selve Ethereum.

Migreringsguide: fra ECDSA-adresser til Taproot og Schnorr

For team som fortsatt kjører legacy P2PKH eller vanlig P2WPKH, er veien til Taproot og Schnorr en gradvis prosess, ikke en big-bang-overgang. Under følger en praktisk 12-stegs plan.

  1. Kartlegg hvilke deler av systemet som genererer, lagrer eller verifiserer signaturer i dag.
  2. Oppdater kryptografibibliotek til en versjon med native BIP340-støtte (for eksempel libsecp256k1 med Schnorr-modulen aktivert).
  3. Test nøkkelgenerering for Taproot-adresser i et isolert testmiljø, ikke i produksjon.
  4. Generer x-only offentlige nøkler (32 byte) i stedet for komprimerte ECDSA-nøkler (33 byte).
  5. Implementer BIP341-tweaken der utgangsnøkkelen beregnes fra internnøkkel pluss en Merkle-rot for eventuelle scriptstier.
  6. Bygg og test P2TR-adresser (bech32m-format) parallelt med eksisterende P2WPKH-adresser.
  7. Legg til signeringslogikk for BIP340 Schnorr, og verifiser at signaturene er nøyaktig 64 byte.
  8. Hvis multisig er aktuelt, integrer en MuSig2-implementasjon og test nøkkelaggregering med minst tre forskjellige nøkkelsett.
  9. Kjør parallelldrift: send små testbeløp til og fra Taproot-adresser før du migrerer reell trafikk.
  10. Oppdater gebyrestimering i lommeboken din slik at den reflekterer den lavere vbyte-vekten til Schnorr-signaturer.
  11. Informer brukere eller kunder om overgangen, spesielt hvis eldre programvare på deres side ikke støtter bech32m-adresser.
  12. Overvåk adopsjon og feilrater i minst én full driftssyklus før du faser ut ECDSA-støtte helt.

Vanlige fallgruver ved migrering til Taproot og Schnorr

De fleste migreringsproblemer team støter på handler ikke om selve kryptografien, men om integrasjoner rundt den. Den vanligste fallgruven er å anta at alle eksterne tjenester og motparter støtter bech32m-adresseformatet Taproot bruker. Eldre børs-API-er, betalingsprosessorer og enkelte regnskapssystemer validerer fortsatt adresser mot eldre formatlister, og en Taproot-adresse kan i verste fall bli avvist eller feilbehandlet av et system som aldri ble oppdatert etter 2021.

Den andre fallgruven er å blande signeringslogikk feil under en overgangsperiode. Team som kjører parallell støtte for både ECDSA og Schnorr bør teste eksplisitt at lommeboklogikken velger riktig signeringsvei basert på adressetype, i stedet for å anta at ett felles kodeløp håndterer begge. En tredje fallgruve gjelder MuSig2 spesifikt: fordi protokollen krever flere kommunikasjonsrunder mellom deltakerne før en signatur er ferdig, må team bygge robust håndtering for tilfeller der en deltaker faller fra midt i prosessen, noe en enkel ECDSA-multisig med uavhengige signaturer ikke krever i samme grad. Til sist er det verdt å teste gebyrestimering grundig etter migrering, siden en feil antakelse om vbyte-vekt kan føre til underprisede transaksjoner som blir hengende i mempool lenger enn ønsket.

Et minimalt eksempel på hvordan en Taproot-adresse skiller seg fra en tradisjonell adresse i signeringskoden, med pseudokode for nøkkelaggregering via MuSig2:

// Forenklet eksempel: ECDSA-signering (legacy)
const ecdsaSig = ecdsa.sign(privateKey, txHash); // 70-72 byte DER

// Forenklet eksempel: Schnorr-signering (BIP340/Taproot)
const schnorrSig = schnorr.sign(privateKey, txHash); // fast 64 byte

// Forenklet eksempel: MuSig2-nøkkelaggregering for multisig
const aggregatedPubkey = musig2.aggregateKeys([pubkeyA, pubkeyB, pubkeyC]);
const aggregatedSig = musig2.aggregateSignatures([partialSigA, partialSigB, partialSigC]);
// Resultat: én 64-byte signatur som verifiserer mot aggregatedPubkey

Hvordan teste og revidere signaturimplementasjonen din

Uansett om du bygger på ECDSA, Schnorr eller begge samtidig, bør signaturlogikk aldri gå i produksjon uten strukturert testing. Start med kjente testvektorer fra BIP340-spesifikasjonen for Schnorr og fra offisielle secp256k1-testsuiter for ECDSA. Disse vektorene inneholder forhåndsberegnede nøkler, meldinger og forventede signaturer som lar deg bekrefte at implementasjonen din produserer byte-identiske resultater med referanseimplementasjonen, uten å måtte stole blindt på et tredjepartsbibliotek.

Deretter bør du teste kantsakene spesifikt: hva skjer med en Schnorr-signatur hvis nonce-verdien er null, hva skjer med en ECDSA-signatur hvis s-verdien er i øvre halvdel av kurveordenen (low-s-regelen Bitcoin håndhever siden 2016), og hvordan håndterer koden din en ugyldig eller manipulert offentlig nøkkel. For MuSig2-oppsett spesifikt bør du simulere at én deltaker forsvinner midt i signeringsprosessen, siden protokollens flerrundenatur gjør denne feilmodusen mer sannsynlig enn i enklere signaturskjemaer. Til sist, hvis produktet håndterer reelle midler, bør en uavhengig sikkerhetsrevisor gå gjennom nøkkelhåndtering og signeringsflyt før lansering. Det er en investering som er langt billigere enn konsekvensene av en feil i kode som flytter faktiske Bitcoin.

Fordeler og ulemper: ECDSA

ECDSA sin styrke er modenhet. Den er implementert i praktisk talt alle kryptografibiblioteker, revidert i flere tiår, og fungerer med eksisterende infrastruktur som ikke har blitt oppdatert til nyere standarder. Denne modenheten gjør ECDSA til et lavrisikovalg for team som prioriterer forutsigbarhet over marginale ytelsesgevinster.

  • Fordel: universell støtte i TLS, X.509, hardware-lommebøker og eldre systemer.
  • Fordel: lang driftshistorikk gir høy tillit blant revisorer og sikkerhetsteam.
  • Fordel: kreves fortsatt for Ethereum og de fleste EVM-kjeder i 2026.
  • Ulempe: variabel signaturstørrelse kompliserer nøyaktig gebyrestimering.
  • Ulempe: ikke-lineær matematikk gjør multisig tyngre og dyrere på kjeden.
  • Ulempe: ingen native batch-verifiseringsgevinst i standardform.

Fordeler og ulemper: Schnorr

Schnorr sin styrke er den rene matematikken bak konstruksjonen, som åpner for aggregering og enklere sikkerhetsbevis. Ulempen er at økosystemstøtten fortsatt er begrenset til Bitcoin og et fåtall andre kjeder, noe som betyr at fordelene i praksis bare realiseres fullt ut for team som bygger direkte på Bitcoin-protokollen.

  • Fordel: fast 64-byte signaturstørrelse gir forutsigbar gebyrestimering.
  • Fordel: støtter MuSig2-aggregering, med 40–60 % mindre witness-data for multisig.
  • Fordel: om lag 2x raskere batch-verifisering ved store volumer.
  • Fordel: bedre personvern siden aggregerte signaturer skjuler antall deltakere.
  • Ulempe: ikke standardisert i TLS, X.509 eller de fleste andre blokkjeder enn Bitcoin og Bitcoin Cash.
  • Ulempe: krever oppdatert programvare og lommebokstøtte, noe eldre maskinvarelommebøker mangler.

Hva sier folk som faktisk jobber med Taproot og Schnorr?

Tekniske spesifikasjoner forteller bare halve historien. Folk som bygger direkte på Taproot og Schnorr til daglig har vært tydelige på hvorfor Bitcoin-prosjektet valgte en så streng overgang, der scriptstien i Taproot ikke lenger gir rom for ECDSA i det hele tatt.

Jameson Lopp, Bitcoin-utdanner og teknisk sjef i Casa, har forklart hvorfor Taproots scriptsti utelukkende bruker Schnorr og ikke ECDSA: “No SegWit version 1 (Taproot) doesn’t support ECDSA signing at all”, skrev han i et svar på Bitcoin Stack Exchange. Han utdyper poenget med at hele designet forutsetter konsistens: “All signatures must be Schnorr to take advantage of the various benefits of Schnorr signatures e.g. batch verification.”

Utdanningsprosjektet We Are Bitcoin beskriver samme mekanisme fra et annet vinkel: “Taproot added a second, Schnorr, which does: several public keys add into one public key, and the matching signature shares add into one signature that verifies against it.” De viser også til selve BIP340-teksten, som forklarer at Schnorr-signaturer “provide a simple and efficient method that enables multiple collaborating parties to produce a signature that is valid for the sum of their public keys.”

Det tekniske undervisningsmaterialet fra Bitcoincoding.dev oppsummerer selve byttet kort og presist: “Taproot replaces ECDSA with BIP340 Schnorr (64 bytes, fixed length) and applies the BIP341 tweak P’ = P + t·G to the output key.” Sitatene peker samlet på det samme: overgangen handler ikke om å erstatte én god algoritme med en annen, den handler om å låse opp aggregering, batch-verifisering og en enklere sikkerhetsmodell som ECDSA aldri var designet for.

Verdikt: hvilken algoritme vinner i 2026?

Det finnes ikke ett svar som passer alle. Ser vi på Bitcoin isolert, peker tallene tydelig mot Schnorr for nye prosjekter: over 40 % lavere gebyr for enkeltsignaturer, 40–60 % mindre witness-data for multisig via MuSig2, og en 2x batch-verifiseringsgevinst som blir stadig viktigere etter hvert som transaksjonsvolumet vokser. Aktiveringen i november 2021 var starten, men den organiske adopsjonen på 15–20 % av nettverkstrafikken i 2025 og inn i 2026 viser at overgangen fortsatt er tidlig, ikke ferdig. Med andre ord: teknologien er moden og produksjonstestet i over fire år, men resten av bransjen har ennå ikke tatt igjen det tekniske forspranget.

Utenfor Bitcoin ser bildet annerledes ut. ECDSA forblir standarden i TLS, X.509 og Ethereum fordi disse økosystemene ikke har standardisert Schnorr inn i sine spesifikasjoner. For et norsk utviklerteam er den praktiske konklusjonen todelt: bygg nye Bitcoin-relaterte produkter, lommebøker og Lightning-integrasjoner på Schnorr og Taproot fra dag én, men fortsett å bruke ECDSA der protokollen du bygger på (TLS-sertifikater, Ethereum-signering) ennå ikke har gitt deg noe valg.

Det er verdt å understreke at dette ikke er en konkurranse med én vinner for alltid. ECDSA forsvinner ikke fra internett med det første, og Schnorr vil trolig aldri erstatte ECDSA i TLS gitt hvor tungt web-PKI-infrastrukturen er investert i eksisterende standarder. Det reelle spørsmålet et team bør stille seg er ikke “hvilken algoritme er best generelt”, men “hvilken algoritme støtter protokollen jeg allerede bygger på, og gir den meg en reell besparelse jeg kan hente ut i 2026”. For Bitcoin-nære produkter er svaret stort sett Schnorr. For alt annet er svaret fortsatt ECDSA, i alle fall inntil økosystemene rundt TLS og Ethereum bestemmer seg for noe annet.

Ofte stilte spørsmål

Er Schnorr-signaturer mer sikre enn ECDSA?
Begge hviler på samme matematiske problem, diskret logaritme over secp256k1, og ingen kjent praktisk svakhet bryter noen av dem i 2026. Schnorr har derimot et enklere og mer velkjent sikkerhetsbevis, og ble designet uten den malleabilitetssvakheten som rammet tidlige ECDSA-implementasjoner i Bitcoin.

Kan jeg bruke Schnorr-signaturer i Ethereum?
Ikke direkte på protokollnivå per tidlig 2026. Ethereum-transaksjoner signeres med ECDSA over secp256k1. Kontoabstraksjon gjennom ERC-4337 åpner derimot for alternative signaturskjemaer på applikasjonslaget for smarte kontraktslommebøker.

Hvor mye lavere blir transaksjonsgebyret med Taproot?
For enkeltsignatur-transaksjoner viser data sitert av Spark Taproot Adoption Tracker over 40 % lavere gebyr for P2TR sammenlignet med den eldre P2PKH-adressetypen. For multisig via MuSig2 er besparelsen i witness-størrelse 40–60 % sammenlignet med tradisjonell ECDSA-multisig.

Når ble Taproot og Schnorr aktivert på Bitcoin?
Taproot, inkludert BIP340 Schnorr, ble låst inn av minere i juni 2021 og aktivert på blokk 709 632 i november 2021, ifølge Bitcoin Optechs dokumentasjon av aktiveringen.

Støtter maskinvarelommebøker Taproot og Schnorr i dag?
De fleste større maskinvarelommebøker har lagt til Taproot-adressestøtte etter aktiveringen i 2021, men støttenivået varierer mellom produsenter og fastvareversjoner. Sjekk alltid produsentens egen dokumentasjon for nøyaktig hvilke adressetyper og signeringsskjemaer som støttes før du migrerer midler.

Hva er MuSig2, og hvorfor krever det Schnorr?
MuSig2 er en protokoll som lar flere parter samarbeide om å produsere én enkelt Schnorr-signatur som verifiserer mot en aggregert offentlig nøkkel. Den utnytter Schnorrs lineære matematikk, en egenskap ECDSA mangler, og resulterer i multisig-transaksjoner som ser identiske ut som enkeltsignatur-transaksjoner på kjeden.

Hvorfor falt Taproot-adopsjonen fra 42 % i 2024 til 15–20 % i 2025?
Toppen i 2024 var i stor grad drevet av inskripsjons- og Ordinals-relatert aktivitet som midlertidig utnyttet Taproots scriptsti til å lagre data på kjeden. Da den aktiviteten falt, falt også andelen, men Spark Taproot Adoption Tracker peker på at nivået som gjenstår, 15–20 %, i større grad representerer organisk bruk fra lommebøker og protokoller.

Bør jeg migrere en eksisterende Bitcoin-lommebok til Taproot nå?
For nye lommebøker og produkter er svaret ja, gitt gebyrbesparelsen og den forbedrede personvernprofilen. For eksisterende systemer med mye integrasjonsarbeid rundt legacy-adresser anbefales en gradvis migrering med parallelldrift, slik den 12-stegs planen tidligere i artikkelen beskriver, fremfor en brå full overgang.

Deler ECDSA og Schnorr samme sikkerhetsnivå?
Ja. Begge bygger på samme secp256k1-kurve i Bitcoin og har derfor identisk motstandskraft mot diskret logaritme-angrep, om lag 128-bit sikkerhet mot klassiske angrep. Schnorr er ikke tryggere fordi tallene er større eller kurven er annerledes, det er tryggere fordi konstruksjonen har et enklere og mer velprøvd sikkerhetsbevis, og fordi den unngår malleabilitetsproblemene som rammet tidlige ECDSA-implementasjoner.

Fungerer MuSig2 med hvilken som helst kombinasjon av lommebøker?
Bare hvis alle deltakerne bruker biblioteker som følger den ferdigstilte BIP327-spesifikasjonen for MuSig2. Tidlige, eksperimentelle MuSig-implementasjoner fra før 2022 er ikke kompatible med den endelige protokollen, så team som setter opp flerpartsoppsett bør bekrefte at alle involverte parter kjører oppdatert, standardisert programvare før midler flyttes.