Als je een Bitcoin-portemonnee hebt geopend en gevraagd bent om te kiezen tussen een „Legacy-”, „SegWit-” of „Native SegWit”-adres, zonder dat er uitgelegd werd wat dit precies inhoudt, dan is die keuze terug te voeren op één enkele upgrade die in 2017 is doorgevoerd.
SegWit, afkorting van Gescheiden getuigenis, is een upgrade van het Bitcoin-protocol die in augustus 2017 in werking is getreden en waarbij gegevens voor digitale handtekeningen uit de kernstructuur van de transactie worden verplaatst naar een apart veld, de zogenaamde ‘witness’. Deze ene architecturale wijziging zorgde voor lagere transactiekosten, loste een jarenlang bestaand beveiligingslek op – de zogenaamde ‘transaction malleability’ – en creëerde de technische voorwaarden voor het ontstaan van het Lightning Network en Taproot.
In dit artikel wordt uitgelegd wat SegWit precies doet, hoe het blokgewichtssysteem werkt, wat de verschillende adrestypen betekenen voor je transactiekosten, en welke omstreden politieke strijd het Bitcoin-netwerk bijna uit elkaar dreef nog voordat SegWit in werking trad.
Beheer je Bitcoin met de Bitcoin.com Wallet-app.
Belangrijkste punten
- SegWit (Segregated Witness) is een upgrade van het Bitcoin-protocol die op 24 augustus 2017 in werking is getreden, formeel vastgelegd als BIP 141 en in december 2015 voorgesteld door Pieter Wuille, Eric Lombrozo en Johnson Lau.
- Het scheidt de gegevens van de digitale handtekening (de „witness“) van de hoofdtekst van de transactie, waardoor een beveiligingslek, de zogenaamde „transaction malleability“, wordt verholpen en elke transactie kleiner wordt.
- De blokcapaciteit wordt gemeten in gewichtseenheden (WU) in plaats van in bytes. Getuigingsgegevens kosten 1 WU per byte, tegenover 4 WU per byte voor andere gegevens, waardoor SegWit-transacties 75% minder ruimte innemen voor de handtekening.
- Native SegWit (bc1q-adressen) verkleint een standaardtransactie van ~226 vbytes tot ~141 vbytes, waardoor de kosten met ongeveer 38% dalen in vergelijking met de oude adressen.
- De garantie van SegWit dat de TXID vastligt, vormde de technische voorwaarde voor het Lightning Network. Zonder deze garantie zouden betalingskanalen niet veilig kunnen worden opgezet.
- Dankzij het versiebeheersysteem voor scripts kon Taproot (SegWit V1, geactiveerd in 2021) worden geïmplementeerd en biedt het een raamwerk voor toekomstige Bitcoin-upgrades zonder hard forks.
- Vanaf 2026 maakt ongeveer 85% van de Bitcoin-transacties gebruik van SegWit. Het is de netwerkstandaard, geen nieuwe functie.
Wat is SegWit?
SegWit, oftewel Segregated Witness, is een aanpassing aan het transactieformaat van Bitcoin waarbij digitale handtekeningen – het cryptografische bewijs dat je het recht hebt om een munt uit te geven – worden gescheiden van de hoofdtransactiegegevens en in een aparte structuur, de zogenaamde ‘witness’, worden opgeslagen. Hierdoor wordt elke transactie kleiner, kunnen er meer transacties in elk blok worden opgenomen en wordt een kwetsbaarheid weggenomen die het onmogelijk maakte om op een veilige manier betalingskanalen bovenop Bitcoin op te bouwen.
De naam is eenvoudig uit te leggen: „segregated” betekent „gescheiden”, en „witness” is de cryptografische term voor de handtekeninggegevens die aantonen dat een transactie geldig is. De „witness” geeft antwoord op de vraag „heeft de rechtmatige eigenaar hier toestemming voor gegeven?”, terwijl de overige transactiegegevens antwoord geven op de vraag „waar gaat het geld naartoe en om welk bedrag gaat het?”.
The official BIP 141 header on GitHub, showing its three co-authors and December 2015 assignment date.De upgrade werd officieel vastgelegd als Bitcoin Improvement Proposal 141 (BIP 141) en voorgesteld door de Bitcoin Core-ontwikkelaars Pieter Wuille, Eric Lombrozo en Johnson Lau tijdens de Scaling Bitcoin-conferentie in december 2015. Het werd op 24 augustus 2017 op het Bitcoin-mainnet geactiveerd bij blok 481.824, als een soft fork, wat betekent dat het achterwaarts compatibel was. Knooppunten die nog niet waren geüpgraded, konden nog steeds de basisgegevens van transacties valideren; geüpgradede knooppunten zagen het volledige plaatje, inclusief de ‘witness’.
Vanaf 2026 maakt ongeveer 85% van alle Bitcoin-transacties gebruik van SegWit. Het is inmiddels geen nieuwe functie meer, maar de norm.
De problemen waarvoor SegWit is ontwikkeld
SegWit pakte twee afzonderlijke problemen aan die Bitcoin al jarenlang in zijn ontwikkeling beperkten.
Transactievervormbaarheid
Elke Bitcoin-transactie heeft een unieke identificatiecode, de zogenaamde TXID, een hash die wordt gegenereerd op basis van de transactiegegevens. Vóór SegWit werd die hash berekend over de gehele transactie, inclusief de handtekening.
Het probleem is het volgende: een cryptografische handtekening kan zichzelf niet ondertekenen. Daardoor ontstond er een klein veiligheidslek waardoor iedereen die jouw transactie via het netwerk doorstuurde, de handtekening enigszins kon aanpassen op een manier waardoor deze wiskundig geldig bleef, maar een andere TXID opleverde. Het geld ging nog steeds naar het juiste adres en de transactie werd nog steeds verwerkt, maar de identificatiecode was veranderd.
Voor een eenvoudige betaling klinkt dit niet rampzalig. Voor protocollen die meerdere onbevestigde transacties aan elkaar koppelen, is het echter fataal. Het Lightning Network, dat werkt door een reeks off-chain betalingsverplichtingen te creëren die verwijzen naar eerdere transactie-ID's, kan niet veilig functioneren als een van die ID's kan veranderen voordat ze zijn bevestigd. Een veranderlijke TXID betekent dat de keten wordt verbroken en dat geld vast kan komen te zitten of gestolen kan worden.
De ‘transaction malleability’ heeft ook in de praktijk schade veroorzaakt voordat het probleem werd verholpen. De beurs Mt. Gox noemde het als een van de factoren die hebben bijgedragen aan haar ondergang in 2014, hoewel historici van mening verschillen over de vraag in hoeverre dit de hoofdoorzaak was of juist een excuus voor ernstiger wanbeheer.
SegWit heeft dit opgelost door handtekeningen volledig uit de berekening van de TXID te verwijderen. De identificatiecode wordt nu uitsluitend berekend op basis van de basisvelden van de transactie. Het wijzigen van de handtekening heeft geen invloed meer op de identiteit van de transactie.
Verminder congestie en stijgende kosten
In 2016 en tot in 2017 verwerkte Bitcoin ongeveer 7 transacties per seconde. Tijdens pieken in de vraag liepen de transactieachterstanden op tot tienduizenden en stegen de kosten tot 50 dollar of meer voor een standaardoverboeking. Het probleem was structureel: de blokken van Bitcoin hadden een limiet van 1 MB en handtekeningen maakten ongeveer 65% van de transactiegrootte uit.
De voor de hand liggende oplossing, namelijk het verhogen van de limiet voor de blokgrootte, vereiste een hard fork, wat betekende dat alle knooppunten een upgrade zouden moeten uitvoeren of anders op een incompatibele keten zouden achterblijven. Hard forks brengen grote risico’s met zich mee en zijn omstreden. SegWit vond een manier om deze beperking volledig te omzeilen.
Hoe SegWit werkt
Getuigengegevens scheiden
Bij een traditionele Bitcoin-transactie bevat elke input een ScriptSig-veld met de handtekening en de openbare sleutel van de betaler. Bij een SegWit-transactie wordt het ScriptSig-veld voor SegWit-inputs leeg gelaten. De handtekening en de openbare sleutel worden verplaatst naar een nieuw ‘witness’-veld dat aan het einde van de transactie wordt toegevoegd.
Twee extra bytes, een markering (0x00) en een vlag (0x01), geven aan SegWit-compatibele knooppunten door dat er witness-gegevens volgen. Knooppunten die van vóór SegWit dateren, zien alleen een leeg ScriptSig-veld en verwerken de transactie als geldig volgens de oudere interpretatie „iedereen kan uitgeven”, waardoor de achterwaartse compatibiliteit behouden blijft.
Blokgewicht vervangt blokgrootte
SegWit heeft de limiet van 1 MB voor de blokgrootte vervangen door een nieuwe maatstaf: het blokgewicht, met een maximum van 4 miljoen gewichtseenheden (WU).
Het cruciale punt zit hem in de manier waarop bytes worden geteld:
- Elke byte aan transactiegegevens die niet van een getuige afkomstig is, kost 4 gewichtseenheden
- Elke byte aan getuigengegevens kost slechts 1 gewichtseenheid
Omdat handtekeningen groot zijn en nu in het ‘witness’-gedeelte staan, nemen ze slechts een kwart van de blokcapaciteit in beslag die ze vroeger innamen. Op deze manier heeft SegWit de effectieve blokgrootte in de praktijk vergroot tot ongeveer 1,7 tot 2 MB, zonder af te wijken van de 1 MB-regel die door oude nodes wordt gehandhaafd. Voor een theoretisch volledig SegWit-blok ligt het maximum op 4 MB, hoewel dit in de praktijk nooit voorkomt omdat elk blok ook niet-witness-gegevens bevat.
Virtuele bytes (vBytes): de eenheid die je in wallets ziet
Om de tarieven vergelijkbaar te houden met die van traditionele transacties, heeft SegWit ‘virtuele bytes’ (vbytes) geïntroduceerd: gewichtseenheden die door 4 zijn gedeeld. Bij traditionele transacties zijn bytes en vbytes identiek. Bij SegWit-transacties zijn vbytes lager omdat de gecomprimeerde witness-gegevens het aantal naar beneden halen.
Portemonneekosten worden uitgedrukt in satoshi per vbyte (sat/vB). Voor een SegWit-transactie met minder vbytes betaal je minder kosten bij hetzelfde tarief in sat/vB. Dit is het mechanisme dat ten grondslag ligt aan de kostenbesparing die je ziet wanneer je een bc1q-adres gebruikt in plaats van een 1...-adres.
Soorten SegWit-adressen: welke moet je gebruiken?
Naast de technische wijzigingen heeft SegWit ook nieuwe adresformaten geïntroduceerd. Het adrestype bepaalt hoe je wallet de uitgavecondities codeert, wat van invloed is op je transactiekosten, je compatibiliteit met andere wallets en hoe je transacties op de blockchain worden weergegeven.
Vergelijking van adrestypen
| Adressoort | Voorvoegsel | Codering | Standaard Tx-grootte (1-in, 2-uit) | Kostenbesparing versus verouderde systemen | Ondersteuning voor portemonnees |
|---|---|---|---|---|---|
| Legacy (P2PKH) | 1... | Base58 | ~226 vbytes | Uitgangssituatie | Universeel |
| Geneste SegWit (P2SH-P2WPKH) | 3... | Base58 | ~167 vbytes | ~26% | Zeer breed |
| Native SegWit (P2WPKH) | bc1q... 42 tekens | Bech32 | ~141 vbytes | ~38% | Alle moderne portemonnees |
| Ingebouwde SegWit-multisig (P2WSH) | bc1q... 62 tekens | Bech32 | Verschilt | ~32%+ | Alle moderne portemonnees |
| Taproot (P2TR) | bc1p... 62 tekens | Bech32m | ~154 vbytes | ~32% | De meeste moderne portemonnees |
Gegevens over de transactieomvang: Spark.money: Overzicht van de grootte van Bitcoin-transacties, 2026. De besparingen op de transactiekosten zijn bij benadering en variëren afhankelijk van de situatie in de mempool.
Legacy (P2PKH, voorvoegsel 1...) Dit is het oorspronkelijke formaat uit 2009. De handtekening blijft in de hoofdtekst van de transactie staan, waar deze volledig meetelt. Er is geen besparing op de transactiekosten. Het wordt nog steeds overal ondersteund, wat de enige reden is om het vandaag de dag nog te gebruiken, namelijk als je te maken hebt met zeer verouderde software die geen andere formaten kan verwerken.
Geneste SegWit (P2SH-P2WPKH, voorvoegsel 3...) verpakt een SegWit-script in een oudere P2SH-envelop. Toen SegWit in 2017 werd geactiveerd, boden niet alle wallets en beurzen meteen ondersteuning voor het nieuwe bc1-formaat. Genest SegWit vormde de compatibiliteitsbrug: je profiteert van een gedeeltelijke besparing op de transactiekosten, en afzenders die oudere software gebruiken, kunnen je nog steeds betalen. Tegen 2026 bestaat dit formaat voornamelijk nog als noodoplossing. De 3... Het voorvoegsel wordt gedeeld met niet-SegWit P2SH-adressen, wat betekent dat je aan het adres alleen niet kunt zien of het om een SegWit-transactie gaat.
Native SegWit (P2WPKH, voorvoegsel bc1q..., 42 tekens) is voor de meeste gebruikers de juiste keuze. Het maakt gebruik van Bech32-codering, die volledig uit kleine letters bestaat, een betere foutdetectie biedt dan Base58 en tekens elimineert die op elkaar lijken (geen hoofdletter O, nul, hoofdletter I of kleine letter l). Een standaard P2WPKH-transactie met 1 invoer en 2 uitvoeren kost ~141 vbytes, ongeveer 38% minder dan de vergelijkbare traditionele transactie. Vanaf 2026 ondersteunen alle actieve wallets en beurzen deze methode.
Ingebouwde SegWit-multisig (P2WSH, voorvoegsel bc1q..., 62 tekens) is de script-hash-variant, die wordt gebruikt voor multisig-wallets en complexe bestedingsvoorwaarden. Het langere adres verwijst naar een SHA-256-hash van 32 bytes in plaats van de 20-byte-hash die door P2WPKH wordt gebruikt. Als u een 2-van-3-multisig-opstelling gebruikt, is P2WSH de SegWit-specifieke manier om dit te doen.
Taproot (P2TR, voorvoegsel bc1p..., 62 tekens) is SegWit versie 1, die in 2021 is geactiveerd. Het maakt gebruik van Schnorr-handtekeningen in plaats van ECDSA, waardoor meerdere handtekeningen kunnen worden samengevoegd tot één, waardoor multisig-transacties op de blockchain niet te onderscheiden zijn van single-sig-transacties. Het biedt de laagste kosten voor single-sig-uitgaven en de beste privacy. Gebruik het wanneer u zeker weet dat uw ontvangers en hun wallets bc1p-adressen ondersteunen.
Snelle aanbeveling
Voor de meeste mensen geldt: gebruik native SegWit (bc1q). Dit wordt door vrijwel alle actieve wallets en beurzen ondersteund, levert een besparing van ongeveer 38% op de transactiekosten op in vergelijking met het oude systeem en brengt geen compatibiliteitsrisico’s met zich mee in 2026 (voor ontwikkelaars die SegWit in walletsoftware willen integreren, zie de Handleiding voor het ontwikkelen van een Bitcoin Core-wallet.).
Als je wallet Taproot (bc1p) ondersteunt en je voert transacties met één handtekening uit naar ontvangers wier wallets dit ook ondersteunen, levert dat iets lagere transactiekosten en meer privacy op.
Nested SegWit (3...) is een compatibiliteitsoplossing. Het is prima, maar er is geen reden meer om dit standaard in te stellen.
De ‘Blocksize War’: waarom SegWit zo omstreden was
De technische argumenten voor SegWit waren duidelijk. Hoe het precies geactiveerd zou worden, was dat echter niet.
Van 2015 tot 2017 was Bitcoin verwikkeld in een van de meest polariserende bestuursconflicten uit zijn geschiedenis. In wezen was de vraag eenvoudig: hoe moet een gedecentraliseerd netwerk zijn eigen regels aanpassen wanneer verschillende facties tegenstrijdige belangen hebben?
De impasse in de mijnbouw
Volgens het standaard BIP9-upgradeproces moest voor een soft fork 95% van de miners binnen een periode van twee weken hun steun kenbaar maken. Begin 2017 was SegWit al maanden klaar om te worden geactiveerd, maar bleef het onder die drempel steken.
De grootste weerstand kwam van grote miningbedrijven, met name Bitmain, dat destijds een aanzienlijk deel van de hashrate van Bitcoin in handen had. De reden daarvoor werd later duidelijk: Bitmain maakte gebruik van een gepatenteerde techniek genaamd ASICBoost, een optimalisatie die zijn mininghardware een aanzienlijk efficiëntievoordeel opleverde. SegWit was structureel onverenigbaar met verborgen ASICBoost. Door SegWit te blokkeren, werd dat voordeel beschermd.
BIP 148 en de UASF
In maart 2017 publiceerde een anonieme ontwikkelaar onder het pseudoniem Shaolinfry BIP 148: een User-Activated Soft Fork (UASF). In plaats van te wachten op signalen van miners, stelde BIP 148 voor dat economische knooppunten – dat wil zeggen beurzen, betalingsverwerkers en bedrijven die Bitcoin-software gebruiken – vanaf 1 augustus 2017 simpelweg elk blok zouden gaan afwijzen dat geen ondersteuning voor SegWit signaleerde.
De logica was eenvoudig: miners produceren blokken, maar die hebben alleen waarde als het netwerk ze accepteert. Als een voldoende groot deel van de economische meerderheid BIP 148-knooppunten zou draaien, zouden miners ofwel SegWit activeren, ofwel toekijken hoe hun blokken verweesd zouden raken. Het risico was al even duidelijk: als de acceptatie onvoldoende zou zijn, zou er een kettingsplitsing ontstaan, waarbij twee incompatibele versies van Bitcoin parallel zouden draaien.
De UASF-campagne was een grassroots-initiatief en ging gepaard met veel rumoer. Er verschenen conferentiebadges. De discussies op Twitter werden steeds heftiger. De uitdrukking „run your own node” kreeg een nieuwe urgentie.
De Overeenkomst van New York en Bitcoin Cash
Met het oog op de UASF-deadline kwamen in mei 2017 meer dan 50 grote Bitcoin-bedrijven in New York bijeen en ondertekenden zij wat bekend kwam te staan als de New York Agreement. Ze kwamen overeen om SegWit te activeren, maar ook om daarna een hard fork door te voeren om de blokgrootte te verdubbelen tot 2 MB (dit werd bekend als SegWit2x).
Het compromis stelde geen van beide kampen volledig tevreden. Ontwikkelaars die tegen grotere blokken waren, zagen SegWit2x als een verkapte hard fork waar ze niet mee hadden ingestemd. Miners en bedrijven die grotere blokken wilden, kregen nog steeds niet wat ze oorspronkelijk hadden gewild.
Op 1 augustus 2017 voerde een factie die alleen een verhoging van de blokgrootte wilde, zonder SegWit, een fork uit van Bitcoin, waardoor Bitcoin Cash (BCH) ontstond, met een bloklimiet van 8 MB. SegWit werd op 24 augustus 2017 op Bitcoin geactiveerd. De SegWit2x-hardfork werd in november 2017 afgeblazen nadat de organisatoren tot de conclusie waren gekomen dat er onvoldoende consensus bestond.
Wat er werd overeengekomen
De uitkomst was van groot belang, ook buiten de technische details om. De UASF had gewerkt: economische knooppunten, en niet de miners, bepaalden welke consensusregels van toepassing waren. Dit wordt nu regelmatig aangehaald als bewijs dat het bestuur van Bitcoin uiteindelijk in handen ligt van degenen die de software draaien en gebruiken, en niet van degenen die blokken produceren. 1 augustus wordt door delen van de gemeenschap aangeduid als Bitcoin Independence Day.
Wat SegWit mogelijk heeft gemaakt
Het Lightning Network
Het Lightning Network werd ontworpen voordat SegWit bestond. De makers wisten dat het pas veilig kon worden geïmplementeerd als de kwetsbaarheid van transacties was verholpen, omdat betalingskanalen afhankelijk zijn van ketens van onbevestigde transacties die via hun TXID naar elkaar verwijzen. De garantie van SegWit dat TXID’s vastliggen, maakte die kanalen veilig.
Het Lightning Network werd begin 2018 op het Bitcoin-mainnet gelanceerd, ongeveer zes maanden nadat SegWit was geactiveerd. Tegen het eerste kwartaal van 2025 had het meer dan 100 miljoen transacties verwerkt. Zonder SegWit zou die infrastructuur helemaal niet bestaan.
Taproot en versiebeheer van scripts
SegWit heeft versiebeheer voor scripts geïntroduceerd in het transactieformaat van Bitcoin. Het witness-programma begint met een versiebyte: SegWit V0 ondersteunt P2WPKH en P2WSH. Elke toekomstige upgrade die een nieuw versienummer definieert, krijgt zijn eigen regels zonder in conflict te komen met bestaande regels, en zonder dat er opnieuw een omstreden upgrade-strijd nodig is.
SegWit V1 is Taproot, dat in november 2021 werd geactiveerd. Het introduceerde Schnorr-handtekeningen, het MAST-raamwerk (Merkelized Abstract Syntax Trees) voor complexe bestedingsvoorwaarden, en privacyverbeteringen waardoor multisig-wallets op de blockchain identiek lijken aan single-sig-transacties. Elke technische mogelijkheid die Taproot introduceerde, was gebaseerd op de versiearchitectuur die SegWit had gecreëerd.
Ordinale getallen en inscripties
Dezelfde getuigengegevensstructuur die met SegWit werd geïntroduceerd en door Taproot werd uitgebreid, maakte het technisch mogelijk om willekeurige gegevens, afbeeldingen, tekst en code rechtstreeks in Bitcoin-transacties in te bedden. Dit is het mechanisme achter het Ordinals-protocol en Bitcoin-inscripties, wat leidde tot een sterke stijging in het gebruik van on-chain-gegevens en ervoor zorgde dat het gebruik van Taproot in 2024 opliep tot ongeveer 42% van de transacties. Naarmate de activiteit rond inscripties afnam, stabiliseerde het gebruik van Taproot zich tegen eind 2025 op ongeveer 20% van de transacties, terwijl SegWit V0 met ongeveer 85% het dominante formaat blijft.
SegWit in context: het tijdschema voor de upgrades van Bitcoin
| Jaar | Evenement |
|---|---|
| 2015 | Pieter Wuille presenteert het SegWit-concept op de Scaling Bitcoin-conferentie |
| 2016 | BIP 141 officieel gepubliceerd; steun onder miners blijft steken onder de drempel van 95% |
| maart 2017 | BIP 148 (UASF), gepubliceerd door Shaolinfry |
| mei 2017 | Overeenkomst van New York ondertekend door meer dan 50 bedrijven |
| 1 augustus 2017 | Bitcoin Cash is een afsplitsing van Bitcoin |
| 24 augustus 2017 | SegWit wordt op Bitcoin geactiveerd bij blok 481.824 |
| november 2017 | Hard fork van SegWit2x afgeblazen |
| januari 2018 | Lightning Network gaat live op het mainnet |
| november 2021 | Taproot wordt geactiveerd, voortbouwend op het versiebeheersysteem van SegWit |
| 2023-2024 | Ordinale getallen en inscripties maken gebruik van de SegWit/Taproot-witnessruimte |
| 2026 | Bij ongeveer 85% van de Bitcoin-transacties wordt gebruikgemaakt van SegWit |
Huidige adoptie
Het gebruik van SegWit nam na de activering gestaag toe en bereikte binnen de eerste paar maanden 30% van de transacties, waarna het in de daaropvolgende twee jaar de grens van 50% overschreed naarmate wallets en beurzen hun software bijwerkten.
Vanaf 2026 maakt ongeveer 85% van de Bitcoin-transacties gebruik van SegWit (bron: Spark.money Bitcoin Network Statistics, CoinGecko). De overige 15% bestaat uit verouderde transacties van wallets en diensten die nog niet zijn geüpgraded. Het gebruik van Taproot (P2TR, SegWit V1) bereikte in 2024 een piek van ongeveer 42% van de transacties, grotendeels aangedreven door het inscripteren van Ordinals, waarna het tegen eind 2025 terugliep tot ongeveer 20% naarmate het aantal inscripties afnam.
De acceptatiecurve weerspiegelt wat er met SegWit zelf is gebeurd: het duurt één tot drie jaar voordat nieuwe adresformaten algemeen worden geaccepteerd, aangezien hardware-wallets, beurzen en betalingsverwerkers hun software moeten bijwerken. De ondersteuning voor Taproot breidt zich steeds verder uit in verschillende wallet-implementaties.
SegWit versus Legacy: overzicht van de verschillen
| Functie | Oude versie (vóór SegWit) | SegWit |
|---|---|---|
| Plaats van ondertekening | Binnen ScriptSig (hoofdgedeelte van de transactie) | Apart veld voor getuigen |
| Maatstaf voor blokgrootte | Grootte in bytes (maximaal 1 MB) | Gewichtseenheden (limiet van 4 miljoen WU) |
| Berekening van de TXID | Bevat handtekeninggegevens | Met uitzondering van getuigengegevens |
| Vervormbaarheid van transacties | Mogelijk | Opgelost |
| Standaard 1-in/2-uit-transmissiegrootte | ~226 vbytes | ~141 vbytes (P2WPKH) |
| Kostenbesparing | Uitgangssituatie | ~38% lager (P2WPKH ten opzichte van P2PKH) |
| Ondersteuning voor het Lightning Network | Onveilig | Vereist; maakt betalingskanalen mogelijk |
| Adresvoorvoegsel | 1... | bc1q... (inheems) of 3... (genest) |
| Codering | Base58 | Bech32 |
Conclusie
SegWit is de protocolupgrade die de handtekeninggegevens van Bitcoin heeft gescheiden van de transactiegegevens, een beveiligingslek heeft verholpen dat al sinds 2009 bestond, de transactiekosten met ongeveer een derde heeft verlaagd en de architecturale basis heeft gelegd voor het Lightning Network, Taproot en alles wat sindsdien daarop is voortgebouwd.
Sinds 2026 is het de transactiestandaard op Bitcoin, waarmee het overgrote deel van de on-chain-activiteit wordt verwerkt. De adresformaten die het heeft geïntroduceerd, met name het native SegWit-adres (bc1q), zijn wat de meeste gebruikers tegenwoordig standaard zouden moeten gebruiken. De politieke strijd rond de activering ervan blijft een van de meest leerzame hoofdstukken in de bestuursgeschiedenis van Bitcoin: een illustratie dat in een gedecentraliseerd netwerk consensus niet iets is dat miners toekennen, maar iets dat gebruikers afdwingen.
