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, forkortelse for Segregert vitne, er en oppgradering av Bitcoin-protokollen som ble aktivert i august 2017, og som flytter dataene for digitale signaturer ut av transaksjonens kjernestruktur og inn i et eget felt kalt «witness». Denne 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 spesifisert 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.
• Blokk kapasitet 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å omtrent 38 % sammenlignet med eldre adresser.
• SegWits garanti for fast TXID var den tekniske forutsetningen for Lightning Network. Uten denne garantien ville det ikke vært mulig å opprette betalingskanaler på en sikker måte.
• Dets versjonshåndteringssystem for skript muliggjorde 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. Dette 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 tidligere hadde gjort det umulig å bygge betalingskanaler på en sikker måte på toppen av Bitcoin.

Navnet kan enkelt forklares slik: «segregated» betyr «adskilt», og «witness» er det kryptografiske begrepet for signaturdataene som beviser 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 hen, 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 formelt 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 vært en begrensning for Bitcoin i mange år.

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 der hvem som helst som videresendte transaksjonen din gjennom nettverket, kunne endre signaturen litt på en måte som gjorde at den forble 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 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 faktor til sammenbruddet 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 signaturene helt fra beregningen av TXID. Identifikatoren beregnes nå utelukkende ut fra transaksjonens grunnleggende felt. Endring av signaturen endrer ikke lenger transaksjonens identitet.

Hindre overbelastning og stigende gebyrer

I 2016 og inn i 2017 behandlet Bitcoin omtrent 7 transaksjoner per sekund. Under perioder med høy etterspørsel vokste transaksjonskøene til titusenvis, og gebyrene steg til 50 dollar eller mer for en standardoverføring. Problemet var strukturelt: Bitcoins blokker hadde en størrelsesbegrensning på 1 MB, og signaturer utgjorde omtrent 65 % av transaksjonsstørrelsen.

Den åpenbare løsningen – å øke grensen for blokkstørrelse – krevde en hard fork, noe som innebar at alle noder måtte oppgradere eller ellers bli stående igjen på en inkompatibel kjede. Hard forks er forbundet med høy risiko og er 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 avsenderens 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 «witness»-felt som legges til på slutten av transaksjonen.

To ekstra byte, en markør (0x00) og et flagg (0x01), forteller SegWit-kompatible noder at det følger med vitnedata. Noder som er fra før SegWit, ser ganske enkelt et tomt ScriptSig 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 grensen på 1 MB for blokkstørrelse 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 knyttet til vitner, 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 utelukkende 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-verdien lavere, fordi de komprimerte vitnedataene reduserer tallet.

Gebyrene i lommeboken 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 utbetalingsbetingelsene, 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 – Referanse for transaksjonsstørrelse i 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, der den teller med full vekt. Ingen besparelser på gebyrer. Støttes fortsatt av alle, og det 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. Den 3... Prefikset er det samme som for P2SH-adresser som ikke bruker SegWit, noe som betyr at man 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 ca. 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 gjenspeiler en 32-byte SHA-256-hash i stedet for den 20-byte-hashen som brukes av P2WPKH. Hvis du bruker et 2-av-3-multisig-oppsett, er P2WSH den SegWit-innfødte 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å blokkjeden. Den tilbyr de laveste gebyrene for single-sig-utbetalinger og best mulig personvern. Bruk den når du har bekreftet at mottakerne og lommebøkene deres støtter bc1p-adresser.

Rask anbefaling

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 skal integrere 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å omstridt

De tekniske fordelene ved SegWit var tydelige. Veien frem mot aktivering 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 oppgradere 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 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 største 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 minere, 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 del av det økonomiske flertallet 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 kjedesplitt, med to inkompatible versjoner av Bitcoin som kjørte parallelt.

UASF-kampanjen var en grasrotbevegelse og svært høylydt. Det dukket opp konferansebadger. Diskusjonene på Twitter tilspisset seg. Uttrykket «kjør din egen node» fikk en ny aktualitet.

New York-avtalen og Bitcoin Cash

I lys av fristen for UASF 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 store blokker, betraktet SegWit2x som en hard fork gjennom en bakdør som de ikke hadde gått med på. 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 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. Hardforken SegWit2x ble forlatt i november 2017 etter at initiativtakerne konkluderte med at de ikke hadde tilstrekkelig konsensus.

Hva saken endte med

Resultatet var av stor betydning, 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 nevnt 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 fellesskapet 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 nettverket 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 omfatter 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 de tekniske funksjonene 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, for deretter å stige 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 bruker 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. Bruken av Taproot (P2TR, SegWit V1) nådde en topp på rundt 42 % av transaksjonene i 2024, hovedsakelig drevet av innskrivningsaktiviteten knyttet til Ordinals, før den stabiliserte seg på rundt 20 % mot slutten av 2025 etter hvert som innskrivningsvolumet gikk ned.

Adopsjonskurven gjenspeiler det som skjedde med SegWit selv: 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 å utvides i 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 har blitt 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 striden rundt aktiveringen er fortsatt et av de mest lærerike kapitlene i Bitcoins styringshistorie: et bevis på at i et desentralisert nettverk er konsensus ikke noe gruvearbeiderne innvilger, men noe brukerne krever.