Vad är SegWit (Segregated Witness)? En förklaring av Bitcoins viktigaste uppgradering

Om du har öppnat en Bitcoin-plånbok och blivit ombedd att välja mellan en ”Legacy-”, ”SegWit-” eller ”Native SegWit”-adress utan någon förklaring av vad dessa begrepp innebär, så har det valet sin grund i en enda uppgradering som genomfördes 2017.

SegWit, förkortning av Segregerat vittnesmål, är en uppgradering av Bitcoin-protokollet som aktiverades i augusti 2017 och som flyttar data för digitala signaturer från transaktionens kärnstruktur till ett separat fält som kallas ”witness”. Denna enda arkitektoniska förändring sänkte transaktionsavgifterna, åtgärdade en säkerhetsbrist som funnits i flera år – så kallad ”transaction malleability” – och skapade de tekniska förutsättningarna för att Lightning Network och Taproot skulle kunna fungera.

Den här artikeln behandlar vad SegWit egentligen gör, hur systemet med blockvikt fungerar, vad de olika adresstyperna innebär för dina avgifter, samt den omstridda politiska striden som nästan splittrade Bitcoin-nätverket innan SegWit ens hade aktiverats.

Hantera dina Bitcoin med Bitcoin.com Wallet-appen.

Viktiga slutsatser

• SegWit (Segregated Witness) är en uppgradering av Bitcoin-protokollet som aktiverades den 24 augusti 2017, formellt specificerad som BIP 141 och föreslagen av Pieter Wuille, Eric Lombrozo och Johnson Lau i december 2015.
• Den separerar data för den digitala signaturen (”witness”) från transaktionens huvuddel, vilket åtgärdar en säkerhetsbrist som kallas ”transaktionsmalleabilitet” och gör varje transaktion mindre.
• Blockkapaciteten mäts i viktenheter (WU) istället för i byte. Vittnesdata kostar 1 WU per byte, jämfört med 4 WU per byte för övriga data, vilket innebär att SegWit-transaktioner får en rabatt på 75 % på signaturstorleken.
• Inbyggt SegWit (bc1q-adresser) minskar storleken på en standardtransaktion från cirka 226 vbytes till cirka 141 vbytes, vilket sänker avgifterna med ungefär 38 % jämfört med äldre adresser.
• SegWits garanti för ett fast TXID var den tekniska förutsättningen för Lightning Network. Utan den hade det inte gått att upprätta betalningskanaler på ett säkert sätt.
• Dess versionshanteringssystem för skript möjliggjorde Taproot (SegWit V1, aktiverat 2021) och utgör ett ramverk för framtida uppgraderingar av Bitcoin utan hard forks.
• Från och med 2026 använder cirka 85 % av alla Bitcoin-transaktioner SegWit. Det är nätverksstandarden, inte en ny funktion.

Vad är SegWit?

SegWit, eller Segregated Witness, är en förändring av Bitcoins transaktionsformat som separerar digitala signaturer – det kryptografiska beviset på att du har rätt att använda en coin – från själva transaktionsdata och lagrar dem i en separat struktur som kallas ”witness”. Detta gör varje transaktion mindre, gör det möjligt att få plats med fler transaktioner i varje block och eliminerar en sårbarhet som tidigare gjort det omöjligt att på ett säkert sätt bygga betalningskanaler ovanpå Bitcoin.

Namnet kan enkelt förklaras så här: ”segregated” betyder ”separerad”, och ”witness” är den kryptografiska termen för signaturdata som bevisar att en transaktion är giltig. Witness svarar på frågan ”har den rättmätige ägaren godkänt detta?”, medan resten av transaktionsdata svarar på frågan ”vart går pengarna och hur mycket handlar det om?”.

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

Uppgraderingen specificerades formellt som Bitcoin Improvement Proposal 141 (BIP 141) och föreslogs av Bitcoin Core-utvecklarna Pieter Wuille, Eric Lombrozo och Johnson Lau vid konferensen Scaling Bitcoin i december 2015. Den aktiverades på Bitcoins huvudnät den 24 augusti 2017, vid block 481 824, som en soft fork, vilket innebär att den var bakåtkompatibel. Noder som inte hade uppgraderats kunde fortfarande validera de grundläggande transaktionsuppgifterna; uppgraderade noder kunde se hela bilden, inklusive vittnet.

Från och med 2026 använder cirka 85 % av alla Bitcoin-transaktioner SegWit. Det är inte längre en ny funktion utan standarden.

De problem som SegWit utvecklades för att lösa

SegWit löste två olika problem som hade begränsat Bitcoin i flera år.

Transaktionsförändringsbarhet

Varje Bitcoin-transaktion har en unik identifierare som kallas TXID, en hash som genereras utifrån transaktionsdata. Före SegWit beräknades den hashen utifrån hela transaktionen, inklusive signaturen.

Här är problemet: en kryptografisk signatur kan inte signera sig själv. Detta skapade en liten lucka där vem som helst som vidarebefordrade din transaktion över nätverket kunde ändra signaturen något, på ett sätt som gjorde att den förblev matematiskt giltig men gav ett annat TXID. Pengarna gick fortfarande till rätt adress och transaktionen genomfördes fortfarande, men identifieraren hade ändrats.

Det låter kanske inte så allvarligt när det gäller en enkel betalning. Men för protokoll som kopplar samman flera obekräftade transaktioner är det ödesdigert. Lightning Network, som fungerar genom att skapa en serie betalningsåtaganden utanför kedjan som refererar till tidigare transaktions-ID:n, kan inte fungera säkert om något av dessa ID:n kan ändras innan de bekräftas. Ett föränderligt TXID innebär att kedjan bryts, och medel kan fastna eller stulas.

Transaktionsmanipulerbarheten orsakade också konkreta skador innan problemet åtgärdades. Börsen Mt. Gox angav detta som en bidragande faktor till sin kollaps 2014, även om historiker diskuterar i vilken utsträckning det var den egentliga orsaken jämfört med en ursäkt för mer djupgående misskötsel.

SegWit löste detta genom att helt ta bort signaturerna från beräkningen av TXID. Identifieraren beräknas nu enbart utifrån transaktionens basfält. En ändring av signaturen påverkar inte längre transaktionens identitet.

Förhindra överbelastning och stigande avgifter

Under 2016 och in på 2017 hanterade Bitcoin ungefär 7 transaktioner per sekund. Under perioder med hög efterfrågan växte transaktionsköerna till tiotusentals, och avgifterna steg till 50 dollar eller mer för en standardöverföring. Problemet var strukturellt: Bitcoins block hade en storleksbegränsning på 1 MB, och signaturerna utgjorde ungefär 65 % av transaktionsstorleken.

Den uppenbara lösningen – att höja gränsen för blockstorleken – krävde en hard fork, vilket innebar att alla noder skulle behöva uppgraderas eller annars hamna på en inkompatibel kedja. Hard forks är förenade med hög risk och är omstridda. SegWit hittade ett sätt att helt kringgå denna begränsning.

Hur SegWit fungerar

Uppdelning av vittnesuppgifter

I en traditionell Bitcoin-transaktion innehåller varje ingång ett ScriptSig-fält med avsändarens signatur och publika nyckel. I en SegWit-transaktion lämnas ScriptSig-fältet tomt för SegWit-ingångar. Signaturen och den publika nyckeln flyttas till ett nytt vittnesfält som läggs till i slutet av transaktionen.

Två ytterligare byte, en markör (0x00) och en flagga (0x01), meddelar SegWit-kompatibla noder att vittnesdata följer. Noder som är äldre än SegWit ser helt enkelt ett tomt ScriptSig och behandlar transaktionen som giltig enligt den äldre tolkningen ”vem som helst kan spendera”, vilket säkerställer bakåtkompatibilitet.

Blockvikt ersätter blockstorlek

SegWit ersatte gränsen på 1 MB för blockstorlek med ett nytt mått: blockvikt, med ett tak på 4 miljoner viktsenheter (WU).

Det avgörande ligger i hur byten räknas:

• Varje byte av transaktionsdata som inte avser vittnen kostar 4 viktenheter
• Varje byte vittnesdata kostar endast 1 vikt-enhet

Eftersom signaturerna är stora och nu finns i vittnesavsnittet tar de upp en fjärdedel så mycket blockkapacitet som tidigare. På så sätt har SegWit i praktiken ökat den effektiva blockstorleken till cirka 1,7–2 MB utan att påverka 1 MB-regeln som gamla noder tillämpar. För ett teoretiskt block som helt består av SegWit-transaktioner är maxstorleken 4 MB, även om detta aldrig inträffar i praktiken eftersom varje block även innehåller data som inte är vittnesdata.

Virtual Bytes (vBytes): Den enhet som visas i plånböckerna

För att avgiftsnivåerna ska vara jämförbara med traditionella transaktioner infördes virtuella byte (vbyte) i SegWit: viktenheter dividerade med 4. För traditionella transaktioner är byte och vbyte identiska. För SegWit-transaktioner är värdet på vbyte lägre eftersom den komprimerade vittnesdata minskar storleken.

Plånboksavgifter anges i satoshi per vbyte (sat/vB). En SegWit-transaktion med färre vbytes medför lägre avgifter vid samma sat/vB-sats. Detta är mekanismen bakom de avgiftsbesparingar du ser när du använder en bc1q-adress istället för en 1...-adress.

SegWit-adresstyper: Vilken ska du använda?

I samband med de tekniska förändringarna införde SegWit nya adressformat. Adresstypen avgör hur din plånbok kodar utbetalningsvillkoren, vilket påverkar dina avgifter, din kompatibilitet med andra plånböcker och hur dina transaktioner ser ut i blockkedjan.

Jämförelse av adresstyper

Uppgifter om transaktionsstorlek: Spark.money – Referens för storleken på Bitcoin-transaktioner, 2026. Avgiftsbesparingarna är ungefärliga och varierar beroende på förhållandena i mempoolen.

Legacy (P2PKH, prefix 1...) är det ursprungliga formatet från 2009. Signaturen förblir i transaktionens huvuddel, där den räknas med full vikt. Inga avgiftsbesparingar. Stöds fortfarande allmänt, vilket är det enda skälet att använda det idag, om du har att göra med mycket gammal programvara som inte kan ta emot något annat.

Nested SegWit (P2SH-P2WPKH, prefix 3...) förpackar ett SegWit-skript inuti ett äldre P2SH-kuvert. När SegWit aktiverades 2017 införde inte alla plånböcker och börser omedelbart stöd för det nya bc1-formatet. Nested SegWit fungerade som en kompatibilitetsbro: du får delvis lägre avgifter, och avsändare som använder äldre programvara kan fortfarande betala dig. År 2026 finns detta format främst kvar som en reservlösning. Den 3... Prefixet är detsamma som för P2SH-adresser som inte använder SegWit, vilket innebär att man inte kan avgöra enbart utifrån adressen om det rör sig om en SegWit-transaktion.

Inbyggd SegWit (P2WPKH, prefix bc1q..., 42 tecken) är det rätta valet för de flesta användare. Den använder Bech32-kodning, som består enbart av gemener, har bättre felupptäckt än Base58 och eliminerar tecken som liknar varandra (inget stort O, noll, stort I eller gemene l). En standardtransaktion av typen P2WPKH med 1 ingång och 2 utgångar kostar cirka 141 vbytes, vilket är ungefär 38 % mindre än motsvarande äldre transaktion. Alla aktiva plånböcker och börser stöder den från och med 2026.

Inbyggd SegWit-multisig (P2WSH, prefix bc1q..., 62 tecken) är varianten med skript-hash, som används för plånböcker med multisignatur och komplexa utbetalningsvillkor. Den längre adressen avspeglar en 32-byte SHA-256-hash istället för den 20-byte-hash som används av P2WPKH. Om du använder en 2-av-3-multisig-konfiguration är P2WSH det SegWit-inbyggda sättet att göra det på.

Taproot (P2TR, prefix bc1p..., 62 tecken) är SegWit version 1, som aktiverades 2021. Den använder Schnorr-signaturer istället för ECDSA, vilket gör det möjligt att slå samman flera signaturer till en enda, vilket gör att multisig-transaktioner inte går att skilja från single-sig-transaktioner på kedjan. Den erbjuder de lägsta avgifterna för single-sig-utbetalningar och bästa möjliga integritet. Använd den när du har bekräftat att dina mottagare och deras plånböcker stöder bc1p-adresser.

Ett snabbt tips

För de flesta: använd inbyggt SegWit (bc1q). Det stöds av i stort sett alla aktiva plånböcker och börser, ger en besparing på cirka 38 % i avgifter jämfört med det gamla systemet och medför ingen kompatibilitetsrisk år 2026 (För utvecklare som integrerar SegWit i plånboksprogramvara, se Utvecklingsguide för Bitcoin Core-plånboken.).

Om din plånbok stöder Taproot (bc1p) och du genomför transaktioner med en enda signatur till mottagare vars plånböcker stöder detta, ger det något lägre avgifter och bättre integritet.

Nested SegWit (3...) är en reservlösning för kompatibilitet. Det fungerar bra, men det finns ingen anledning att använda det som standard längre.

Striden om blockstorleken: Varför SegWit var så kontroversiellt

De tekniska argumenten för SegWit var tydliga. Däremot var vägen till aktivering inte lika tydlig.

Mellan 2015 och 2017 befann sig Bitcoin mitt i en av de mest splittrande konflikterna om styrningen i sin historia. I grund och botten var frågan enkel: hur ska ett decentraliserat nätverk uppdatera sina egna regler när olika fraktioner har motstridiga intressen?

Dödläget inom gruvindustrin

Enligt den vanliga uppgraderingsprocessen enligt BIP9 krävdes det att 95 % av gruvarbetarna signalerade sitt stöd under en tvåveckorsperiod för att en soft fork skulle kunna genomföras. I början av 2017 hade SegWit varit redo att aktiveras i flera månader, men hade fastnat under den tröskeln.

Det starkaste motståndet kom från stora gruvföretag, framför allt Bitmain, som vid den tiden kontrollerade en betydande andel av Bitcoins hashrate. Anledningen blev senare tydlig: Bitmain använde en patenterad teknik kallad ASICBoost, en optimering som gav företagets gruvhårdvara en betydande effektivitetsfördel. SegWit var strukturellt oförenligt med den dolda ASICBoost-tekniken. Genom att blockera SegWit skyddade man denna fördel.

BIP 148 och UASF

I mars 2017 publicerade en anonym utvecklare under pseudonymen Shaolinfry BIP 148: en användaraktiverad soft fork (UASF). I stället för att vänta på signaler från minare föreslog BIP 148 att ekonomiska noder – det vill säga börser, betalningsförmedlare och företag som använder Bitcoin-programvara – helt enkelt skulle börja avvisa alla block som inte signalerade stöd för SegWit från och med den 1 augusti 2017.

Logiken var enkel: gruvarbetare producerar block, men dessa har bara ett värde om nätverket accepterar dem. Om en tillräckligt stor del av den ekonomiska majoriteten körde BIP 148-noder skulle gruvarbetarna antingen aktivera SegWit eller se sina block bli övergivna. Risken var lika tydlig: om införandet inte var tillräckligt stort skulle det bli en kedjesplit, med två inkompatibla versioner av Bitcoin som kördes parallellt.

UASF-kampanjen var en gräsrotsrörelse och väldigt högljudd. Konferensbrickor dök upp. Diskussionerna på Twitter tilltog. Uttrycket ”kör din egen nod” fick en ny aktualitet.

New York-avtalet och Bitcoin Cash

Inför UASF-deadlinen samlades över 50 stora Bitcoin-företag i New York i maj 2017 och undertecknade det som kom att kallas New York-avtalet. De enades om att aktivera SegWit, men också att därefter genomföra en hard fork för att fördubbla blockstorleken till 2 MB (detta kom att kallas SegWit2x).

Kompromissen tillfredsställde inte något av lägren fullt ut. Utvecklare som motsatte sig stora block betraktade SegWit2x som en ”bakdörrs-hardfork” som de inte hade gått med på. Gruvarbetare och företag som ville ha större block fick fortfarande inte det de ursprungligen hade önskat sig.

Den 1 augusti 2017 genomförde en fraktion som hade eftersträvat en ren ökning av blockstorleken, utan SegWit, en fork av Bitcoin för att skapa Bitcoin Cash (BCH), med en blockgräns på 8 MB från början. SegWit aktiverades på Bitcoin den 24 augusti 2017. Hard forken SegWit2x övergavs i november 2017 efter att dess organisatörer kommit fram till att de inte hade tillräcklig konsensus.

Vad man kom överens om

Resultatet var betydelsefullt även bortom de tekniska detaljerna. UASF hade fungerat: det var de ekonomiska noderna, inte gruvarbetarna, som avgjorde vilka konsensusregler som skulle gälla. Detta åberopas numera ofta som ett bevis på att styrningen av Bitcoin i slutändan ligger hos dem som driver och använder programvaran, inte hos dem som producerar block. Den 1 augusti kallas av delar av gemenskapen för ”Bitcoins självständighetsdag”.

Vad SegWit gjorde möjligt

Lightning Network

Lightning Network utformades innan SegWit fanns. Dess skapare insåg att det inte kunde driftsättas på ett säkert sätt förrän problemet med transaktionsmanipulerbarhet hade åtgärdats, eftersom betalningskanaler bygger på kedjor av obekräftade transaktioner som hänvisar till varandra via TXID. SegWits garanti om fasta TXID:er gjorde dessa kanaler säkra.

Lightning Network lanserades på Bitcoins huvudnät i början av 2018, ungefär sex månader efter att SegWit aktiverades. Vid slutet av första kvartalet 2025 hade nätverket hanterat över 100 miljoner transaktioner. Utan SegWit skulle ingen av dessa infrastrukturer existera.

Taproot och versionshantering av skript

SegWit införde versionshantering för skript i Bitcoins transaktionsformat. Witness-programmet inleds med en versionsbyte: SegWit V0 omfattar P2WPKH och P2WSH. Varje framtida uppgradering som definierar ett nytt versionsnummer får sina egna regler utan att komma i konflikt med befintliga regler och utan att det krävs ytterligare en kontroversiell uppgraderingsstrid.

SegWit V1 är Taproot, som aktiverades i november 2021. Det införde Schnorr-signaturer, MAST-ramverket (Merkelized Abstract Syntax Trees) för komplexa utbetalningsvillkor samt integritetsförbättringar som gör att multisig-plånböcker ser identiska ut som single-sig-transaktioner på blockkedjan. Varje teknisk funktion som Taproot introducerade byggde på den versionsarkitektur som SegWit skapade.

Ordinaler och inskriptioner

Samma datastruktur för vittnesdata som infördes med SegWit och som utvidgades med Taproot gjorde det tekniskt möjligt att bädda in godtyckliga data, bilder, text och kod direkt i Bitcoin-transaktioner. Detta är mekanismen bakom Ordinals-protokollet och Bitcoin-inskriptioner, vilket ledde till en kraftig ökning av användningen av data på kedjan och fick andelen transaktioner som använder Taproot att stiga till cirka 42 % år 2024. I takt med att inskriptionsaktiviteten avtog stabiliserades Taproot-användningen på cirka 20 % av transaktionerna i slutet av 2025, medan SegWit V0 förblir det dominerande formatet med cirka 85 %.

SegWit i sitt sammanhang: Tidslinjen för Bitcoins uppgraderingar

Aktuell adoption

Användningen av SegWit ökade stadigt efter aktiveringen och nådde 30 % av transaktionerna redan under de första månaderna, för att sedan stiga över 50-procentsgränsen under de följande två åren i takt med att plånböcker och börser uppgraderade sin programvara.

Från och med 2026 använder cirka 85 % av Bitcoin-transaktionerna SegWit (källa: Spark.money Bitcoin Network Statistics, CoinGecko). De återstående 15 % utgörs av äldre transaktioner från plånböcker och tjänster som inte har uppgraderats. Användningen av Taproot (P2TR, SegWit V1) nådde sin topp på cirka 42 % av transaktionerna år 2024, främst drivet av inskrivningsaktiviteten för Ordinals, innan den stabiliserades på omkring 20 % i slutet av 2025 i takt med att inskrivningsvolymen minskade.

Införandekurvan speglar utvecklingen för SegWit: det tar ett till tre år innan nya adressformat blir allmänt accepterade, eftersom hårdvaruplånböcker, börser och betalningsleverantörer måste uppdatera sin programvara. Stödet för Taproot fortsätter att öka i olika plånboksimplementeringar.

SegWit kontra Legacy: Sammanfattning av skillnaderna

Slutsats

SegWit är den protokolluppgradering som separerade Bitcoins signaturdata från transaktionsdata, åtgärdade en säkerhetsbrist som funnits sedan 2009, sänkte transaktionsavgifterna med ungefär en tredjedel och lade den arkitektoniska grunden för Lightning Network, Taproot och allt som sedan dess har byggts vidare på dessa.

Från och med 2026 är det transaktionsstandarden på Bitcoin och hanterar den överväldigande majoriteten av aktiviteten på kedjan. De adressformat som infördes i samband med detta, särskilt det inbyggda SegWit-formatet (bc1q), är de som de flesta användare bör använda som standard idag. Den politiska striden kring dess aktivering förblir ett av de mest lärorika kapitlen i Bitcoins styrningshistoria: ett bevis på att i ett decentraliserat nätverk är konsensus inte något som minare beviljar, utan något som användarna hävdar.