Hvis du har oprettet en Bitcoin-tegnebog og er blevet bedt om at vælge mellem en »Legacy«-, »SegWit«- eller »Native SegWit«-adresse uden nogen forklaring på, hvad disse betegnelser betyder, så kan dette valg spores tilbage til en enkelt opgradering, der blev gennemført i 2017.
SegWit, en forkortelse for Adskilt vidne, er en opgradering af Bitcoin-protokollen, der blev aktiveret i august 2017, og som flytter dataene for den digitale signatur ud af transaktionens kernestruktur og over i et separat felt kaldet »witness«. Denne ene arkitektoniske ændring medførte lavere transaktionsgebyrer, løste et årelangt sikkerhedsproblem kaldet »transaction malleability« og skabte de tekniske forudsætninger for, at Lightning Network og Taproot kunne opstå.
Denne artikel beskriver, hvad SegWit egentlig gør, hvordan blokvægtssystemet fungerer, hvad de forskellige adressetyper betyder for dine gebyrer, samt den omstridte politiske kamp, der næsten rev Bitcoin-netværket fra hinanden, inden det overhovedet blev aktiveret.
Administrer dine Bitcoin med Bitcoin.com Wallet-appen.
De vigtigste pointer
- SegWit (Segregated Witness) er en opgradering af Bitcoin-protokollen, der blev aktiveret den 24. august 2017. Den er formelt defineret som BIP 141 og blev foreslået af Pieter Wuille, Eric Lombrozo og Johnson Lau i december 2015.
- Det adskiller dataene for den digitale signatur (»vidnet«) fra selve transaktionsteksten, hvilket løser et sikkerhedsproblem kaldet »transaktionsmalleabilitet« og gør hver enkelt transaktion mindre.
- Blokkapaciteten måles i vægtenheder (WU) i stedet for i byte. Vidnedata koster 1 WU pr. byte mod 4 WU pr. byte for andre data, hvilket giver SegWit-transaktioner en besparelse på 75 % på signaturstørrelsen.
- Native SegWit (bc1q-adresser) reducerer størrelsen på en standardtransaktion fra ca. 226 vbytes til ca. 141 vbytes, hvilket sænker gebyrerne med ca. 38 % sammenlignet med de gamle adresser.
- SegWits garanti for et fast TXID var den tekniske forudsætning for Lightning Network. Uden den ville det ikke have været muligt at oprette betalingskanaler på en sikker måde.
- Dets versionsstyringssystem for scripts muliggjorde Taproot (SegWit V1, aktiveret i 2021) og danner rammen for fremtidige Bitcoin-opgraderinger uden hard forks.
- Fra og med 2026 anvender ca. 85 % af Bitcoin-transaktionerne SegWit. Det er netværksstandarden, ikke en ny funktion.
Hvad er SegWit?
SegWit, eller Segregated Witness, er en ændring af Bitcoins transaktionsformat, der adskiller digitale signaturer – det kryptografiske bevis på, at man har ret til at bruge en coin – fra de primære transaktionsdata og gemmer dem i en separat struktur kaldet »witness«. Dette gør hver transaktion mindre, giver plads til flere transaktioner i hver blok og fjerner en sårbarhed, der tidligere havde gjort det umuligt at oprette sikre betalingskanaler oven på Bitcoin.
Navnet kan let forklares: »segregated« betyder »adskilt«, og »witness« er det kryptografiske udtryk for de signaturdata, der beviser, at en transaktion er gyldig. »Witness« besvarer spørgsmålet »har den retmæssige ejer godkendt dette?«, mens resten af transaktionsdataene besvarer spørgsmålet »hvor skal midlerne hen, og hvor meget drejer det sig om?«
The official BIP 141 header on GitHub, showing its three co-authors and December 2015 assignment date.Opgraderingen blev formelt defineret som Bitcoin Improvement Proposal 141 (BIP 141) og blev foreslået af Bitcoin Core-udviklerne Pieter Wuille, Eric Lombrozo og Johnson Lau på Scaling Bitcoin-konferencen i december 2015. Den blev aktiveret på Bitcoins mainnet den 24. august 2017 ved blok 481.824 som en soft fork, hvilket betyder, at den var bagudkompatibel. Noder, der ikke var blevet opgraderet, kunne stadig validere de grundlæggende transaktionsdata; opgraderede noder kunne se det fulde billede, herunder vidnet.
Fra og med 2026 anvender ca. 85 % af alle Bitcoin-transaktioner SegWit. Det er ikke længere en ny funktion, men standarden.
De problemer, som SegWit blev udviklet til at løse
SegWit løste to separate problemer, der i årevis havde begrænset Bitcoin.
Transaktionsmanipulerbarhed
Hver Bitcoin-transaktion har en unik identifikator, der kaldes TXID, en hash, der genereres ud fra transaktionsdataene. Før SegWit blev denne hash beregnet på baggrund af hele transaktionen, inklusive signaturen.
Her er problemet: En kryptografisk signatur kan ikke underskrive sig selv. Det efterlod et lille vindue, hvor enhver, der videresendte din transaktion gennem netværket, kunne ændre signaturen en smule på en måde, der bevarede dens matematiske gyldighed, men som resulterede i et andet TXID. Midlerne blev stadig sendt til den rigtige adresse, og transaktionen blev stadig gennemført, men identifikatoren var ændret.
Det lyder måske ikke så katastrofalt for en simpel betaling. Men for protokoller, der sammenkæder flere ubekræftede transaktioner, er det fatalt. Lightning Network, som fungerer ved at oprette en række off-chain-betalingsforpligtelser, der henviser til tidligere transaktions-ID'er, kan ikke fungere sikkert, hvis nogen af disse ID'er kan ændres, før de bekræftes. Et ændrbart TXID betyder, at kæden brydes, og midlerne kan blive strandet eller stjålet.
Transaktionsmanipulerbarhed forårsagede også konkrete skader, inden problemet blev løst. Mt. Gox-børsen nævnte det som en medvirkende årsag til sin kollaps i 2014, selvom historikere er uenige om, i hvilket omfang det var den egentlige årsag, eller om det blot var en undskyldning for mere grundlæggende ledelsesfejl.
SegWit løste dette problem ved helt at fjerne signaturer fra beregningen af TXID. Identifikatoren beregnes nu udelukkende ud fra transaktionens grundlæggende felter. En ændring af signaturen ændrer ikke længere transaktionens identitet.
Undgå overbelastning og stigende gebyrer
I 2016 og ind i 2017 behandlede Bitcoin omkring 7 transaktioner pr. sekund. Under spidsbelastninger voksede transaktionskøen til titusinder, og gebyrerne steg til 50 dollar eller mere for en standardoverførsel. Problemet var strukturelt: Bitcoins blokke var begrænset til 1 MB, og signaturer udgjorde cirka 65 % af transaktionsstørrelsen.
Den oplagte løsning – at hæve grænsen for blokstørrelsen – krævede en hard fork, hvilket betød, at alle noder skulle opgraderes eller ellers blive efterladt på en inkompatibel kæde. Hard forks er forbundet med stor risiko og er omstridte. SegWit fandt en måde at omgå denne begrænsning fuldstændigt.
Sådan fungerer SegWit
Opdeling af vidnedata
I en traditionel Bitcoin-transaktion indeholder hver indgang et ScriptSig-felt med afsenderens signatur og offentlige nøgle. I en SegWit-transaktion efterlades ScriptSig-feltet tomt for SegWit-indgange. Signaturen og den offentlige nøgle flyttes til et nyt »witness«-felt, der tilføjes i slutningen af transaktionen.
To ekstra bytes – en markør (0x00) og et flag (0x01) – fortæller SegWit-kompatible noder, at der følger witness-data. Noder, der er fra før SegWit, ser blot et tomt ScriptSig og behandler transaktionen som gyldig i henhold til den ældre fortolkning, hvor »enhver kan bruge midlerne«, hvilket sikrer bagudkompatibilitet.
Blokvægt erstatter blokstørrelse
SegWit erstattede grænsen på 1 MB for blokstørrelse med en ny måleenhed: blokvægt, der er begrænset til 4 millioner vægtenheder (WU).
Det afgørende ligger i, hvordan bytes tælles:
- Hver byte af transaktionsdata, der ikke stammer fra vidner, koster 4 vægtenheder
- Hver byte vidnedata koster kun 1 vægtenhed
Da signaturerne er store og nu er placeret i »witness«-sektionen, optager de kun en fjerdedel af den blokkapacitet, de tidligere gjorde. På denne måde har SegWit i praksis øget den effektive blokstørrelse til omkring 1,7 til 2 MB uden at røre ved 1 MB-reglen, som gamle noder håndhæver. For en teoretisk blok, der udelukkende består af SegWit-data, er det maksimale 4 MB, selvom dette aldrig forekommer i praksis, da hver blok også indeholder data, der ikke er vidne-data.
Virtuelle bytes (vBytes): Den enhed, du ser i dine tegnebøger
For at sikre, at gebyrsatserne kan sammenlignes med de gamle transaktioner, indførte SegWit virtuelle bytes (vbytes): vægtenheder divideret med 4. For de gamle transaktioner er bytes og vbytes identiske. For SegWit-transaktioner er vbytes lavere, fordi de komprimerede vidnedata trækker tallet ned.
Gebyret for en wallet angives i satoshis pr. vbyte (sat/vB). En SegWit-transaktion med færre vbytes koster mindre i gebyr ved samme sat/vB-sats. Det er denne mekanisme, der ligger bag de gebyrbesparelser, du oplever, når du bruger en bc1q-adresse i stedet for en 1...-adresse.
SegWit-adressetyper: Hvilken skal du vælge?
Sammen med de tekniske ændringer indførte SegWit nye adresseformater. Adressetypen bestemmer, hvordan din wallet koder betingelserne for udbetalinger, hvilket har indflydelse på dine gebyrer, din kompatibilitet med andre wallets og hvordan dine transaktioner ser ud på blockchainen.
Sammenligning af adressetyper
| Adressetype | Præfiks | Kodning | Typisk Tx-størrelse (1 indgang, 2 udgange) | Gebyrbesparelser kontra gamle systemer | Understøttelse af tegnebøger |
|---|---|---|---|---|---|
| Legacy (P2PKH) | 1... | Base58 | ~226 vbyte | Udgangspunkt | Universal |
| Indlejret SegWit (P2SH-P2WPKH) | 3... | Base58 | ~167 vbyte | ~26 % | Meget bredt |
| Indbygget SegWit (P2WPKH) | bc1q... 42 tegn | Bech32 | ~141 vbyte | ~38 % | Alle moderne tegnebøger |
| Indbygget SegWit-multisig (P2WSH) | bc1q... 62 tegn | Bech32 | Varierer | ~32 %+ | Alle moderne tegnebøger |
| Taproot (P2TR) | bc1p... 62 tegn | Bech32m | ~154 vbyte | ~32 % | De fleste moderne tegnebøger |
Data om transaktionsstørrelse: Spark.money – Oversigt over Bitcoin-transaktionsstørrelser, 2026. Besparelserne på gebyrer er omtrentlige og afhænger af forholdene i mempoolen.
Legacy (P2PKH, præfiks 1...) er det oprindelige format fra 2009. Signaturen forbliver inde i transaktionens hoveddel, hvor den tæller med fuld vægt. Der er ingen besparelser på gebyrer. Formatet understøttes stadig af alle, hvilket er den eneste grund til at bruge det i dag, hvis man har at gøre med meget gammel software, der ikke kan modtage andre formater.
Indlejret SegWit (P2SH-P2WPKH, præfiks 3...) indkapsler et SegWit-script i en ældre P2SH-konvolut. Da SegWit blev aktiveret i 2017, tilføjede ikke alle tegnebøger og børser straks understøttelse af det nye bc1-format. Nested SegWit fungerede som en kompatibilitetsbro: Man opnår en delvis besparelse på gebyret, og afsendere, der bruger ældre software, kan stadig betale dig. I 2026 eksisterer dette format hovedsageligt som en nødløsning. Den 3... Præfikset deles med P2SH-adresser, der ikke er SegWit-adresser, hvilket betyder, at man ikke ud fra adressen alene kan se, om der er tale om en SegWit-transaktion.
Indbygget SegWit (P2WPKH, præfiks bc1q..., 42 tegn) er det rigtige valg for de fleste brugere. Den anvender Bech32-kodning, som udelukkende består af små bogstaver, har bedre fejldetektion end Base58 og udelukker tegn, der ligner hinanden (ingen stort O, nul, stort I eller lille l). En standard P2WPKH-transaktion med 1 indgang og 2 udgange koster ca. 141 vbytes, hvilket er ca. 38 % mindre end den tilsvarende ældre transaktion. Alle aktive tegnebøger og børser understøtter den fra og med 2026.
Indbygget SegWit-multisig (P2WSH, præfiks bc1q..., 62 tegn) er script-hash-varianten, der anvendes til multisig-tegnebøger og komplekse udbetalingsbetingelser. Den længere adresse afspejler en 32-byte SHA-256-hash i stedet for den 20-byte hash, der bruges af P2WPKH. Hvis du kører en 2-ud-af-3-multisig-opsætning, er P2WSH den SegWit-native måde at gøre det på.
Taproot (P2TR, præfiks bc1p..., 62 tegn) er SegWit version 1, der blev aktiveret i 2021. Den bruger Schnorr-signaturer i stedet for ECDSA, hvilket gør det muligt at samle flere signaturer til én, så multisig-transaktioner ikke kan skelnes fra single-sig-transaktioner på blockchainen. Den tilbyder de laveste gebyrer for single-sig-udgifter og den bedste privatlivsbeskyttelse. Brug den, når du har bekræftet, at dine modtagere og deres tegnebøger understøtter bc1p-adresser.
Hurtigt tip
For de fleste: Brug native SegWit (bc1q). Det understøttes af stort set alle aktive tegnebøger og børser, sparer ca. 38 % i gebyrer sammenlignet med den gamle standard og medfører ingen kompatibilitetsrisiko i 2026 (Udviklere, der integrerer SegWit i tegnebogssoftware, kan læse mere i Vejledning i udvikling af Bitcoin Core-tegnebøger.).
Hvis din tegnebog understøtter Taproot (bc1p), og du foretager transaktioner med én underskrift til modtagere, hvis tegnebøger understøtter dette, giver det lidt lavere gebyrer og øget privatlivsbeskyttelse.
Nested SegWit (3...) er en kompatibilitetsløsning. Det er fint nok, men der er ikke længere nogen grund til at bruge det som standard.
Krigen om blokstørrelsen: Hvorfor SegWit var så kontroversielt
De tekniske argumenter for SegWit var klare. Vejen til aktivering var det derimod ikke.
Fra 2015 til 2017 var Bitcoin indblandet i en af de mest splittende stridigheder om styringen i sin historie. I bund og grund var spørgsmålet simpelt: Hvordan skal et decentraliseret netværk opdatere sine egne regler, når forskellige fraktioner har modstridende interesser?
Dødvandet i mineindustrien
I henhold til den standardiserede BIP9-opgraderingsproces krævede en soft fork, at 95 % af minerne signalerede deres støtte inden for en periode på to uger. I begyndelsen af 2017 havde SegWit været klar til aktivering i flere måneder, men lå stadig under denne tærskel.
Den største modstand kom fra store minedriftsvirksomheder, især Bitmain, som på det tidspunkt kontrollerede en betydelig andel af Bitcoins hashrate. Årsagen blev senere klar: Bitmain anvendte en patenteret teknik kaldet ASICBoost, en optimering, der gav virksomhedens minedrift-hardware en betydelig effektivitetsfordel. SegWit var strukturelt uforenelig med den skjulte ASICBoost-teknik. Ved at blokere SegWit beskyttede man denne fordel.
BIP 148 og UASF
I marts 2017 offentliggjorde en anonym udvikler under pseudonymet Shaolinfry BIP 148: en brugeraktiveret soft fork (UASF). I stedet for at vente på signaler fra minere foreslog BIP 148, at økonomiske noder – det vil sige børser, betalingsformidlere og virksomheder, der kører Bitcoin-software – simpelthen skulle begynde at afvise alle blokke, der ikke signalerede støtte til SegWit, fra den 1. august 2017 og frem.
Logikken var enkel: Minere producerer blokke, men disse har kun værdi, hvis netværket accepterer dem. Hvis en tilstrækkelig del af det økonomiske flertal kørte BIP 148-noder, ville minerne enten aktivere SegWit eller se deres blokke blive forældreløse. Risikoen var lige så klar: hvis tilslutningen var utilstrækkelig, ville der opstå en kædesplit, hvor to inkompatible versioner af Bitcoin kørte parallelt.
UASF-kampagnen var en græsrodskampagne, der vakte stor opmærksomhed. Der dukkede konferencebadges op. Debatterne på Twitter blev mere intense. Udtrykket »kør din egen node« fik en helt ny aktualitet.
New York-aftalen og Bitcoin Cash
I lyset af UASF-fristen mødtes over 50 store Bitcoin-virksomheder i New York i maj 2017 og underskrev det, der blev kendt som New York-aftalen. De blev enige om at aktivere SegWit, men også om at følge op på det med en hard fork for at fordoble blokstørrelsen til 2 MB (dette blev kendt som SegWit2x).
Kompromiset tilfredsstillede ingen af parterne fuldt ud. Udviklere, der var imod store blokke, betragtede SegWit2x som en skjult hard fork, som de ikke havde givet deres samtykke til. Minere og virksomheder, der ønskede større blokke, fik stadig ikke det, de oprindeligt havde ønsket sig.
Den 1. august 2017 foretog en fraktion, der havde ønsket en ren forøgelse af blokstørrelsen uden SegWit, en fork af Bitcoin for at skabe Bitcoin Cash (BCH) med en blokgrænse på 8 MB fra starten. SegWit blev aktiveret på Bitcoin den 24. august 2017. SegWit2x-hardforken blev opgivet i november 2017, efter at dens arrangører konkluderede, at de ikke havde tilstrækkelig konsensus.
Hvad der blev aftalt
Resultatet havde en betydning, der gik ud over de tekniske detaljer. UASF havde virket: Det var de økonomiske noder, ikke minerne, der afgorde, hvilke konsensusregler der skulle gælde. Dette fremhæves nu ofte som et bevis på, at styringen af Bitcoin i sidste ende ligger hos dem, der driver og bruger softwaren, og ikke hos dem, der producerer blokke. Den 1. august omtales af dele af fællesskabet som »Bitcoins uafhængighedsdag«.
Hvad SegWit har gjort muligt
Lightning-netværket
Lightning Network blev udviklet, før SegWit eksisterede. Dets skabere vidste, at det ikke kunne implementeres sikkert, før problemet med transaktionsmanipulerbarhed var løst, da betalingskanaler er afhængige af kæder af ubekræftede transaktioner, der henviser til hinanden via TXID. SegWits garanti for faste TXID’er gjorde disse kanaler sikre.
Lightning Network blev lanceret på Bitcoins mainnet i begyndelsen af 2018, cirka seks måneder efter at SegWit blev aktiveret. I første kvartal af 2025 havde det behandlet over 100 millioner transaktioner. Uden SegWit ville denne infrastruktur slet ikke eksistere.
Taproot og versionsstyring af scripts
SegWit indførte versionsstyring af script i Bitcoins transaktionsformat. Witness-programmet indledes med en versionsbyte: SegWit V0 dækker P2WPKH og P2WSH. Enhver fremtidig opgradering, der definerer et nyt versionsnummer, får sine egne regler uden at komme i konflikt med de eksisterende og uden at kræve endnu en omstridt opgraderingskamp.
SegWit V1 er Taproot, som blev aktiveret i november 2021. Det indførte Schnorr-signaturer, MAST-rammeværket (Merkelized Abstract Syntax Trees) til komplekse udbetalingsbetingelser samt forbedringer af privatlivsbeskyttelsen, der gør, at multisig-tegnebøger fremstår identiske med single-sig-transaktioner på blockchainen. Alle de tekniske muligheder, som Taproot introducerede, byggede på den versionsarkitektur, som SegWit skabte.
Ordinaler og inskriptioner
Den samme vidnedatastruktur, som SegWit indførte, og som Taproot udvidede, gjorde det teknisk muligt at indlejre vilkårlige data, billeder, tekst og kode direkte i Bitcoin-transaktioner. Dette er mekanismen bag Ordinals-protokollen og Bitcoin-inskriptioner, hvilket førte til en kraftig stigning i brugen af on-chain-data og fik Taproot-anvendelsen til at nå op på ca. 42 % af transaktionerne i 2024. Efterhånden som aktiviteten omkring inskriptioner aftog, stabiliserede brugen af Taproot sig på omkring 20 % af transaktionerne ved udgangen af 2025, mens SegWit V0 fortsat er det dominerende format med omkring 85 %.
SegWit i sammenhæng: Tidslinjen for Bitcoins opgraderinger
| År | Begivenhed |
|---|---|
| 2015 | Pieter Wuille præsenterer SegWit-konceptet på Scaling Bitcoin-konferencen |
| 2016 | BIP 141 er nu officielt offentliggjort; minernes tilslutning ligger under 95 %-tærsklen |
| marts 2017 | BIP 148 (UASF) offentliggjort af Shaolinfry |
| Maj 2017 | New York-aftalen er underskrevet af over 50 virksomheder |
| 1. august 2017 | Bitcoin Cash er en fork af Bitcoin |
| 24. august 2017 | SegWit aktiveres på Bitcoin ved blok 481.824 |
| november 2017 | SegWit2x-hardforken er blevet opgivet |
| Januar 2018 | Lightning Network lanceres på mainnet |
| november 2021 | Taproot aktiveres og bygger videre på SegWits versionssystem |
| 2023–2024 | Ordinaler og indskrifter udnytter SegWit/Taproot-vidneområdet |
| 2026 | Cirka 85 % af Bitcoin-transaktionerne bruger SegWit |
Nuværende adoption
Anvendelsen af SegWit steg støt efter aktiveringen og nåede op på 30 % af transaktionerne inden for de første par måneder, hvorefter den i løbet af de følgende to år steg til over 50 %, i takt med at tegnebøger og børser opgraderede deres software.
I 2026 anvender ca. 85 % af Bitcoin-transaktionerne SegWit (kilde: Spark.money Bitcoin Network Statistics, CoinGecko). De resterende 15 % er ældre transaktioner fra tegnebøger og tjenester, der ikke er blevet opgraderet. Anvendelsen af Taproot (P2TR, SegWit V1) nåede et højdepunkt på ca. 42 % af transaktionerne i 2024, hovedsageligt drevet af indskrivningsaktiviteten af Ordinals, før den faldt til omkring 20 % i slutningen af 2025, da indskrivningsvolumenet faldt.
Udbredelseskurven afspejler det, der skete med selve SegWit: Det tager mellem et og tre år, før nye adresseformater bliver almindeligt udbredt, i takt med at hardware-wallets, børser og betalingsudbydere opdaterer deres software. Understøttelsen af Taproot udbredes fortsat på tværs af forskellige wallet-implementeringer.
SegWit vs. Legacy: Oversigt over forskellene
| Funktion | Ældre version (før SegWit) | SegWit |
|---|---|---|
| Sted for underskrift | Inde i ScriptSig (hovedteksten i transaktionen) | Separat vidnefelt |
| Måleenhed for blokstørrelse | Størrelse i byte (maks. 1 MB) | Vægtenheder (grænse på 4 mio. WU) |
| Beregning af TXID | Indeholder signaturdata | Undtagen vidnedata |
| Transaktionsformbarhed | Muligt | Rettet |
| Typisk størrelse på 1-ind/2-ud-transmitter | ~226 vbyte | ~141 vbytes (P2WPKH) |
| Besparelse på gebyrer | Udgangspunkt | ~38 % lavere (P2WPKH sammenlignet med P2PKH) |
| Understøttelse af Lightning Network | Usikkert | Påkrævet; aktiverer betalingskanaler |
| Adresseprefiks | 1... | bc1q... (indfødt) eller 3... (indlejret) |
| Kodning | Base58 | Bech32 |
Konklusion
SegWit er den protokolopgradering, der adskilte Bitcoins signaturdata fra transaktionsdataene, udbedrede en sikkerhedsfejl, der havde eksisteret siden 2009, reducerede transaktionsgebyrerne med cirka en tredjedel og skabte det arkitektoniske grundlag for Lightning Network, Taproot og alt, hvad der siden er bygget oven på disse.
Fra og med 2026 er det transaktionsstandarden på Bitcoin, der håndterer langt størstedelen af aktiviteten på blockchainen. De adresseformater, den indførte – især det indbyggede SegWit (bc1q) – er dem, som de fleste brugere i dag bør anvende som standard. Den politiske kamp, der omgav aktiveringen, er stadig et af de mest lærerige kapitler i Bitcoins styringshistorie: et bevis på, at konsensus i et decentraliseret netværk ikke er noget, som minere giver, men noget, som brugerne gennemtvinger.






