Hva er SegWit (Segregated Witness)? En forklaring på Bitcoins viktigste oppgradering

Hvis du har opprettet en Bitcoin-lommebok og blitt bedt om å velge mellom en «Legacy-», «SegWit-» eller «Native SegWit-»adresse uten noen forklaring på hva dette innebærer, kan dette valget spores tilbake til en enkelt oppgradering som ble gjennomført i 2017.

SegWit, en forkortelse for Segregated Witness, er en oppgradering av Bitcoin-protokollen som ble aktivert i august 2017. Oppgraderingen flytter dataene for digitale signaturer ut av transaksjonens kjernestruktur og over i et eget felt kalt «witness». Den ene arkitektoniske endringen reduserte transaksjonsgebyrene, løste et mangeårig sikkerhetsproblem kalt «transaction malleability» og skapte de tekniske forutsetningene for at Lightning Network og Taproot kunne eksistere.

Denne artikkelen tar for seg hva SegWit egentlig gjør, hvordan systemet for blokkvekt fungerer, hva de ulike adressetypene betyr for gebyrene dine, og den omstridte politiske striden som nesten rev Bitcoin-nettverket i stykker før det i det hele tatt ble aktivert.

Administrer Bitcoin-beholdningen din med Bitcoin.com Wallet-appen.

Hovedpunkter

• SegWit (Segregated Witness) er en oppgradering av Bitcoin-protokollen som ble aktivert 24. august 2017, formelt definert som BIP 141 og foreslått av Pieter Wuille, Eric Lombrozo og Johnson Lau i desember 2015.
• Den skiller dataene for den digitale signaturen («vitnet») fra selve transaksjonsteksten, noe som løser et sikkerhetsproblem kjent som «transaksjonsmalleabilitet» og gjør hver enkelt transaksjon mindre.
• Blokkkapasiteten måles i vektenheter (WU) i stedet for byte. Vitnedata koster 1 WU per byte, mot 4 WU per byte for andre data, noe som gir SegWit-transaksjoner en reduksjon på 75 % i signaturstørrelse.
• Innebygd SegWit (bc1q-adresser) reduserer størrelsen på en standardtransaksjon fra ca. 226 vbytes til ca. 141 vbytes, noe som gir en reduksjon i gebyrene på rundt 38 % sammenlignet med eldre adresser.
• SegWits garanti for fast TXID var den tekniske forutsetningen for Lightning Network. Uten den ville det ikke vært mulig å opprette betalingskanaler på en sikker måte.
• Dets versjonshåndteringssystem for skript gjorde det mulig å implementere Taproot (SegWit V1, aktivert i 2021) og gir et rammeverk for fremtidige oppgraderinger av Bitcoin uten hard forks.
• Fra og med 2026 bruker omtrent 85 % av Bitcoin-transaksjonene SegWit. Det er nettverksstandarden, ikke en ny funksjon.

Hva er SegWit?

SegWit, eller Segregated Witness, er en endring i Bitcoins transaksjonsformat som skiller digitale signaturer – det kryptografiske beviset på at du har rett til å bruke en coin – fra selve transaksjonsdataene, og lagrer dem i en egen struktur kalt «witness». Dette gjør hver transaksjon mindre, gjør at flere transaksjoner får plass i hver blokk, og eliminerer en sårbarhet som hadde gjort det umulig å bygge betalingskanaler på toppen av Bitcoin på en sikker måte.

Navnet kan enkelt forklares slik: «segregated» betyr «adskilt», og «witness» er det kryptografiske begrepet for signaturdataene som bekrefter at en transaksjon er gyldig. «Witness» svarer på spørsmålet «har den rettmessige eieren godkjent dette?», mens resten av transaksjonsdataene svarer på «hvor skal midlene og hvor mye dreier det seg om?»

The official BIP 141 header on GitHub, showing its three co-authors and December 2015 assignment date.

Oppgraderingen ble offisielt definert som Bitcoin Improvement Proposal 141 (BIP 141) og ble foreslått av Bitcoin Core-utviklerne Pieter Wuille, Eric Lombrozo og Johnson Lau på Scaling Bitcoin-konferansen i desember 2015. Den ble aktivert på Bitcoin-hovednettet 24. august 2017, ved blokk 481 824, som en soft fork, noe som betyr at den var bakoverkompatibel. Noder som ikke hadde oppgradert, kunne fortsatt validere de grunnleggende transaksjonsdataene; oppgraderte noder så hele bildet, inkludert vitnet.

Fra og med 2026 bruker omtrent 85 % av alle Bitcoin-transaksjoner SegWit. Det er ikke lenger en ny funksjon, men standarden.

Problemene SegWit ble utviklet for å løse

SegWit løste to separate problemer som hadde begrenset Bitcoin i årevis.

Transaksjonsmanipulerbarhet

Hver Bitcoin-transaksjon har en unik identifikator kalt TXID, en hash som genereres ut fra transaksjonsdataene. Før SegWit ble denne hashen beregnet ut fra hele transaksjonen, inkludert signaturen.

Her er problemet: En kryptografisk signatur kan ikke signere seg selv. Dette åpnet for en liten mulighet for at hvem som helst som videresendte transaksjonen din gjennom nettverket, kunne endre signaturen litt på en måte som holdt den matematisk gyldig, men som ga en annen TXID. Midlene ble fortsatt sendt til riktig adresse, og transaksjonen ble fortsatt gjennomført, men identifikatoren hadde endret seg.

Dette høres ikke ut som noen katastrofe for en enkel betaling. For protokoller som kobler sammen flere ubekreftede transaksjoner, er det imidlertid fatalt. Lightning Network, som fungerer ved å opprette en serie av betalingsforpliktelser utenfor kjeden som refererer til tidligere transaksjons-ID-er, kan ikke fungere sikkert hvis noen av disse ID-ene kan endres før de bekreftes. En endringsbar TXID betyr at kjeden brytes, og midler kan bli strandet eller stjålet.

Transaksjonsmanipulerbarhet førte også til konkrete skader før problemet ble løst. Børsen Mt. Gox pekte på dette som en medvirkende årsak til konkursen i 2014, selv om historikere er uenige om i hvilken grad dette var den egentlige årsaken, eller bare en unnskyldning for mer grunnleggende ledelsesfeil.

SegWit løste dette ved å fjerne signaturer helt fra beregningen av TXID. Identifikatoren beregnes nå utelukkende ut fra transaksjonens grunnleggende felt. Endring av signaturen påvirker ikke lenger transaksjonens identitet.

Unngå overbelastning og stigende gebyrer

I 2016 og inn i 2017 behandlet Bitcoin omtrent 7 transaksjoner i sekundet. Under etterspørselstopper vokste transaksjonskøene til titusenvis, og gebyrene steg til 50 dollar eller mer for en standardoverføring. Problemet var strukturelt: Bitcoins blokker var begrenset til 1 MB, og signaturer utgjorde omtrent 65 % av transaksjonsstørrelsen.

Den åpenbare løsningen, nemlig å øke blokkstørrelsesgrensen, krevde en hard fork, noe som innebar at alle noder måtte oppgradere eller risikere å bli stående igjen på en inkompatibel kjede. Hard forks er risikofylte og omstridte. SegWit fant en måte å omgå denne begrensningen fullstendig på.

Slik fungerer SegWit

Oppdeling av vitnedata

I en tradisjonell Bitcoin-transaksjon inneholder hver inngang et ScriptSig-felt med brukerens signatur og offentlige nøkkel. I en SegWit-transaksjon blir ScriptSig-feltet stående tomt for SegWit-innganger. Signaturen og den offentlige nøkkelen flyttes til et nytt vitnefelt som legges til på slutten av transaksjonen.

To ekstra byte, en markør (0x00) og et flagg (0x01), forteller SegWit-kompatible noder at vitnedata følger. Noder som ble opprettet før SegWit, ser bare et tomt ScriptSig-felt og behandler transaksjonen som gyldig i henhold til den eldre tolkningen «hvem som helst kan bruke», slik at bakoverkompatibiliteten opprettholdes.

Blokkvekt erstatter blokkstørrelse

SegWit erstattet blokkstørrelsesgrensen på 1 MB med en ny måleenhet: blokkvekt, med et tak på 4 millioner vektenheter (WU).

Det avgjørende ligger i hvordan byte telles:

• Hver byte med transaksjonsdata som ikke er vitnedata koster 4 vektenheter
• Hver byte med vitnedata koster bare 1 vektenhet

Siden signaturene er store og nå ligger i vitneseksjonen, opptar de bare en fjerdedel av den blokkkapasiteten de tidligere gjorde. Slik har SegWit i praksis økt den effektive blokkstørrelsen til rundt 1,7 til 2 MB uten å bryte 1 MB-regelen som gamle noder håndhever. For en teoretisk blokk som kun består av SegWit, er maksimumet 4 MB, selv om dette aldri forekommer i praksis fordi hver blokk også inneholder data som ikke er vitnedata.

Virtuelle byte (vBytes): Enheten du ser i lommebøker

For å sikre at gebyrsatsene er sammenlignbare med tradisjonelle transaksjoner, innførte SegWit virtuelle byte (vbyte): vektenheter delt på 4. For tradisjonelle transaksjoner er byte og vbyte identiske. For SegWit-transaksjoner er vbyte lavere fordi de komprimerte vitnedataene reduserer tallet.

Lommebokgebyrer angis i satoshi per vbyte (sat/vB). En SegWit-transaksjon med færre vbytes koster mindre i gebyrer ved samme sat/vB-sats. Dette er mekanismen bak gebyrbesparelsen du opplever når du bruker en bc1q-adresse i stedet for en 1...-adresse.

SegWit-adressetyper: Hvilken bør du bruke?

I tillegg til de tekniske endringene innførte SegWit nye adresseformater. Adressetypen avgjør hvordan lommeboken din koder utbetalingsbetingelser, noe som påvirker gebyrene dine, kompatibiliteten med andre lommebøker og hvordan transaksjonene dine ser ut på blokkjeden.

Sammenligning av adressetyper

Data om transaksjonsstørrelse: Spark.money – Oversikt over transaksjonsstørrelser for Bitcoin, 2026. Gebyrbesparelsene er omtrentlige og varierer avhengig av forholdene i mempoolen.

Legacy (P2PKH, prefiks 1...) er det opprinnelige formatet fra 2009. Signaturen forblir inne i selve transaksjonsteksten, hvor den teller med full vekt. Ingen besparelser på gebyrer. Støttes fortsatt av alle, noe som er den eneste grunnen til å bruke det i dag, hvis du har å gjøre med svært gammel programvare som ikke kan motta noe annet.

Nested SegWit (P2SH-P2WPKH, prefiks 3...) pakker et SegWit-skript inn i en eldre P2SH-konvolutt. Da SegWit ble aktivert i 2017, var det ikke alle lommebøker og børser som umiddelbart la til støtte for det nye bc1-formatet. Nested SegWit fungerte som en kompatibilitetsbro: du oppnår delvis gebyrbesparelse, og avsendere som bruker eldre programvare kan fortsatt betale deg. I 2026 eksisterer dette formatet hovedsakelig som en reserve. 3... Prefikset deles med P2SH-adresser som ikke bruker SegWit, noe som betyr at du ikke kan se ut fra adressen alene om det dreier seg om en SegWit-transaksjon.

Innebygd SegWit (P2WPKH, prefiks bc1q...(42 tegn) er det riktige valget for de fleste brukere. Den bruker Bech32-koding, som består utelukkende av små bokstaver, har bedre feiloppdagelse enn Base58 og eliminerer tegn som ligner på hverandre (ingen stor O, null, stor I eller liten l). En standard P2WPKH-transaksjon med 1 inngang og 2 utganger koster ~141 vbytes, omtrent 38 % mindre enn den tilsvarende eldre transaksjonen. Alle aktive lommebøker og børser støtter den fra og med 2026.

Innebygd SegWit-multisig (P2WSH, prefiks bc1q...(62 tegn) er script-hash-varianten, som brukes til multisig-lommebøker og komplekse utbetalingsbetingelser. Den lengre adressen reflekterer en 32-byte SHA-256-hash i stedet for den 20-byte-hashen som brukes av P2WPKH. Hvis du kjører et 2-av-3 multisig-oppsett, er P2WSH den SegWit-native måten å gjøre det på.

Taproot (P2TR, prefiks bc1p...(62 tegn) er SegWit versjon 1, som ble aktivert i 2021. Den bruker Schnorr-signaturer i stedet for ECDSA, noe som gjør det mulig å samle flere signaturer i én, slik at multisig-transaksjoner ikke kan skilles fra single-sig-transaksjoner på kjeden. Den tilbyr de laveste gebyrene for single-sig-utgifter og best personvern. Bruk den når du har bekreftet at mottakerne og lommebøkene deres støtter bc1p-adresser.

Et raskt tips

For de fleste: Bruk innbygget SegWit (bc1q). Det støttes av praktisk talt alle aktive lommebøker og børser, gir en besparelse på ca. 38 % i gebyrer sammenlignet med den gamle standarden, og medfører ingen kompatibilitetsrisiko i 2026 (For utviklere som integrerer SegWit i lommebokprogramvare, se Veiledning for utvikling av Bitcoin Core-lommebok.).

Hvis lommeboken din støtter Taproot (bc1p) og du gjennomfører transaksjoner med én signatur til mottakere som har lommebøker som støtter dette, gir det litt lavere gebyrer og bedre personvern.

Nested SegWit (3...) er en kompatibilitetsløsning. Det er greit, men det er ikke lenger noen grunn til å bruke det som standard.

Krigen om blokkstørrelsen: Hvorfor SegWit var så kontroversielt

De tekniske fordelene ved SegWit var åpenbare. Hvordan det skulle aktiveres, var det derimot ikke.

Fra 2015 til 2017 var Bitcoin involvert i en av de mest splittende styringskonfliktene i sin historie. I bunn og grunn var spørsmålet enkelt: Hvordan skal et desentralisert nettverk oppdatere sine egne regler når ulike fraksjoner har motstridende interesser?

Dødvannet i gruveindustrien

I henhold til den vanlige BIP9-oppgraderingsprosessen krevde en soft fork at 95 % av gruvearbeiderne signaliserte sin støtte i løpet av en to-ukers periode. I begynnelsen av 2017 hadde SegWit vært klar til aktivering i flere måneder, men klarte ikke å nå denne terskelen.

Den sterkeste motstanden kom fra store gruvevirksomheter, særlig Bitmain, som på det tidspunktet kontrollerte en betydelig andel av Bitcoins hashrate. Årsaken ble senere klar: Bitmain brukte en patentert teknikk kalt ASICBoost, en optimalisering som ga selskapets gruveutstyr en betydelig effektivitetsfordel. SegWit var strukturelt uforenlig med skjult ASICBoost. Å blokkere SegWit beskyttet denne fordelen.

BIP 148 og UASF

I mars 2017 publiserte en anonym utvikler under pseudonymet Shaolinfry BIP 148: en brukeraktivert soft fork (UASF). I stedet for å vente på signaler fra gruvearbeidere, foreslo BIP 148 at økonomiske noder, det vil si børser, betalingsbehandlere og bedrifter som kjører Bitcoin-programvare, ganske enkelt skulle begynne å avvise alle blokker som ikke signaliserte støtte for SegWit fra og med 1. august 2017.

Logikken var enkel: gruvearbeidere produserer blokker, men disse har bare verdi hvis nettverket godtar dem. Hvis en tilstrekkelig økonomisk majoritet kjørte BIP 148-noder, ville gruvearbeiderne enten aktivere SegWit eller se på at blokkene deres ble foreldreløse. Risikoen var like klar: hvis oppslutningen var utilstrekkelig, ville det oppstå en kjedesplittelse, med to inkompatible versjoner av Bitcoin som kjørte parallelt.

UASF-kampanjen var en grasrotbevegelse som gjorde seg gjeldende. Det dukket opp konferansebadger. Kranglene på Twitter tiltok. Uttrykket «kjør din egen node» fikk en ny aktualitet.

New York-avtalen og Bitcoin Cash

I forkant av UASF-fristen samlet over 50 store Bitcoin-selskaper seg i New York i mai 2017 og undertegnet det som ble kjent som New York-avtalen. De ble enige om å aktivere SegWit, men også å følge opp med en hard fork for å doble blokkstørrelsen til 2 MB (dette ble kjent som SegWit2x).

Kompromisset tilfredsstilte ingen av sidene fullt ut. Utviklere som var imot større blokker, betraktet SegWit2x som en hard fork gjennom en bakdør som de ikke hadde gitt sitt samtykke til. Gruvearbeidere og selskaper som ønsket større blokker, fikk fremdeles ikke det de opprinnelig hadde ønsket seg.

1. august 2017 gjennomførte en fraksjon som hadde ønsket en ren økning av blokkstørrelsen, uten SegWit, en hard fork av Bitcoin for å opprette Bitcoin Cash (BCH), med en blokkstørrelse på 8 MB fra starten av. SegWit ble aktivert på Bitcoin 24. august 2017. SegWit2x-hardforken ble forlatt i november 2017 etter at arrangørene konkluderte med at de ikke hadde tilstrekkelig konsensus.

Hva saken endte med

Resultatet var av stor betydning, langt utover de tekniske detaljene. UASF hadde fungert: Det var de økonomiske nodene, ikke gruvearbeiderne, som avgjorde hvilke konsensusregler som skulle gjelde. Dette blir nå ofte fremholdt som et bevis på at styringen av Bitcoin i siste instans ligger hos dem som driver og bruker programvaren, ikke hos dem som produserer blokker. 1. august blir av deler av miljøet omtalt som «Bitcoins uavhengighetsdag».

Hva SegWit gjorde mulig

Lightning-nettverket

Lightning Network ble utviklet før SegWit eksisterte. Utviklerne visste at det ikke kunne tas i bruk på en sikker måte før problemet med transaksjonsmanipulering var løst, fordi betalingskanaler er avhengige av kjeder av ubekreftede transaksjoner som refererer til hverandre via TXID. SegWits garanti for faste TXID-er gjorde disse kanalene sikre.

Lightning Network ble lansert på Bitcoins hovednettverk tidlig i 2018, omtrent seks måneder etter at SegWit ble aktivert. Innen første kvartal 2025 hadde det behandlet over 100 millioner transaksjoner. Uten SegWit ville ingen av disse infrastrukturene ha eksistert.

Taproot og versjonshåndtering av skript

SegWit innførte versjonshåndtering for skript i Bitcoins transaksjonsformat. Witness-programmet starter med en versjonsbyte: SegWit V0 støtter P2WPKH og P2WSH. Enhver fremtidig oppgradering som definerer et nytt versjonsnummer, får sine egne regler uten å komme i konflikt med eksisterende regler, og uten at det kreves en ny omstridt oppgraderingskamp.

SegWit V1 er Taproot, som ble aktivert i november 2021. Det innførte Schnorr-signaturer, MAST-rammeverket (Merkelized Abstract Syntax Trees) for komplekse utbetalingsbetingelser, samt personvernforbedringer som gjør at multisig-lommebøker fremstår som identiske med single-sig-transaksjoner på blokkjeden. Alle tekniske funksjoner som Taproot introduserte, var avhengige av versjonsarkitekturen som SegWit skapte.

Ordinaler og inskripsjoner

Den samme vitnedatastrukturen som SegWit innførte, og som Taproot utvidet, gjorde det teknisk mulig å legge inn vilkårlige data, bilder, tekst og kode direkte i Bitcoin-transaksjoner. Dette er mekanismen bak Ordinals-protokollen og Bitcoin-inskripsjoner, som førte til en kraftig økning i bruken av data på kjeden og økte Taproot-adopsjonen til omtrent 42 % av transaksjonene i 2024. Etter hvert som inskripsjonsaktiviteten avtok, stabiliserte Taproot-bruken seg på rundt 20 % av transaksjonene mot slutten av 2025, mens SegWit V0 fortsatt er det dominerende formatet med rundt 85 %.

SegWit i sammenheng: Tidslinjen for oppgraderinger av Bitcoin

Gjeldende adopsjon

Bruken av SegWit økte jevnt etter aktiveringen, og nådde 30 % av transaksjonene i løpet av de første månedene, før den klatret over 50 %-merket i løpet av de to påfølgende årene etter hvert som lommebøker og børser oppgraderte programvaren sin.

Per 2026 benytter omtrent 85 % av Bitcoin-transaksjonene SegWit (kilde: Spark.money Bitcoin Network Statistics, CoinGecko). De resterende 15 % er eldre transaksjoner fra lommebøker og tjenester som ikke har oppgradert. Taproot (P2TR, SegWit V1)-adopsjonen nådde en topp på omtrent 42 % av transaksjonene i 2024, hovedsakelig drevet av Ordinals-innskripsjonsaktivitet, før den stabiliserte seg på rundt 20 % mot slutten av 2025 da innskripsjonsvolumet gikk ned.

Adopsjonskurven gjenspeiler det som skjedde med SegWit: Det tar ett til tre år før nye adresseformater blir allment akseptert, ettersom hardware-lommebøker, børser og betalingsleverandører oppdaterer programvaren sin. Støtten for Taproot fortsetter å øke blant ulike lommebokimplementeringer.

SegWit vs. Legacy: Oversikt over forskjellene

Konklusjon

SegWit er protokolloppgraderingen som skilte Bitcoins signaturdata fra transaksjonsdataene, løste en sikkerhetsfeil som hadde eksistert siden 2009, reduserte transaksjonsgebyrene med omtrent en tredjedel og la det arkitektoniske grunnlaget for Lightning Network, Taproot og alt som siden er bygget på disse.

Fra og med 2026 er dette transaksjonsstandarden på Bitcoin, og den håndterer det aller meste av aktiviteten på kjeden. Adressformatene den innførte, særlig det innebygde SegWit-formatet (bc1q), er det de fleste brukere bør benytte som standard i dag. Den politiske kampen som omringet aktiveringen av den, er fortsatt et av de mest lærerike kapitlene i Bitcoins styringshistorie: en demonstrasjon av at i et desentralisert nettverk er konsensus ikke noe gruvearbeidere gir, men noe brukerne hevder.