Als je een Bitcoin-portemonnee hebt geopend en gevraagd werd te kiezen tussen een "Legacy"-, "SegWit"- of "Native SegWit"-adres, zonder dat er werd uitgelegd wat dit precies inhoudt, dan is die keuze terug te voeren op één enkele upgrade uit 2017.
SegWit, een afkorting van Segregated Witness, is een upgrade van het Bitcoin-protocol die in augustus 2017 is geactiveerd en waarbij gegevens voor digitale handtekeningen uit de kernstructuur van transacties worden gehaald en naar een apart veld, de zogenaamde ‘witness’, worden verplaatst. Die ene architecturale wijziging zorgde voor lagere transactiekosten, loste een jarenoud beveiligingslek op, ook wel 'transaction malleability' genoemd, en creëerde de technische voorwaarden voor het bestaan van het Lightning Network en Taproot.
In dit artikel wordt uitgelegd wat SegWit precies doet, hoe het systeem van blokgewicht werkt, wat de verschillende soorten adressen betekenen voor je transactiekosten, en welke controversiële 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 protocolupgrade voor Bitcoin 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 dat "transaction malleability" wordt genoemd, wordt verholpen en elke transactie kleiner wordt.
- De blokcapaciteit wordt gemeten in gewichtseenheden (WU) in plaats van in bytes. Getuigengegevens 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 ongeveer 226 vbytes tot ongeveer 141 vbytes, waardoor de kosten met ongeveer 38% dalen in vergelijking met traditionele adressen.
- De garantie van SegWit dat de TXID vastligt, vormde de technische voorwaarde voor het Lightning Network. Zonder deze garantie konden er geen veilige betalingskanalen 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, passen er meer transacties in elk blok en wordt een kwetsbaarheid weggenomen die het onmogelijk had gemaakt om veilig betalingskanalen bovenop Bitcoin 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 beantwoordt de vraag "heeft de rechtmatige eigenaar hier toestemming voor gegeven?", terwijl de rest van de transactiegegevens antwoord geeft op de vraag "waar gaat het geld naartoe en voor welk bedrag?".
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. Nodes die niet waren geüpgraded, konden nog steeds de basis transactiegegevens valideren; geüpgradede nodes zagen het volledige plaatje, inclusief de witness.
Vanaf 2026 maakt ongeveer 85% van alle Bitcoin-transacties gebruik van SegWit. Het is niet langer een nieuwe functie, maar de norm.
De problemen waarvoor SegWit is ontwikkeld
SegWit pakte twee afzonderlijke problemen aan die Bitcoin al jarenlang in zijn ontwikkeling belemmerden.
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 risico dat iemand 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 breekt en dat geld vast kan komen te zitten of gestolen kan worden.
De vervormbaarheid van transacties heeft ook in de praktijk schade aangericht voordat het probleem werd verholpen. De beurs Mt. Gox noemde dit als een van de factoren die hebben bijgedragen aan haar faillissement in 2014, hoewel historici van mening verschillen over de vraag in hoeverre dit de hoofdoorzaak was of slechts een excuus voor ernstiger wanbeleid.
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.
Vermijd files en stijgende kosten
In 2016 en begin 2017 verwerkte Bitcoin ongeveer 7 transacties per seconde. Tijdens pieken in de vraag liepen de achterstanden in transacties op tot tienduizenden en stegen de kosten tot $ 50 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 nodes een upgrade zouden moeten uitvoeren of anders op een incompatibele keten zouden blijven zitten. Hard forks zijn risicovol en 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 getuigedata volgt. Knooppunten die van vóór SegWit dateren, zien alleen een leeg ScriptSig-veld en verwerken de transactie als geldig volgens de oudere interpretatie dat "iedereen het bedrag kan uitgeven", waardoor de achterwaartse compatibiliteit behouden blijft.
Het blokgewicht vervangt de 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 veel ruimte innemen en nu in het witness-gedeelte zijn ondergebracht, nemen ze qua blokcapaciteit nog maar een kwart van de ruimte 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 is het maximum 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 transactiekosten 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 verkleinde getuigedata het aantal naar beneden halen.
Portemonneekosten worden uitgedrukt in satoshi’s per vbyte (sat/vB). Een SegWit-transactie met minder vbytes kost minder aan kosten bij hetzelfde tarief van sat/vB. Dit is het mechanisme achter 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 voorwaarden voor uitgaven codeert, wat van invloed is op je transactiekosten, de compatibiliteit met andere wallets en hoe je transacties op de blockchain worden weergegeven.
Vergelijking van adrestypen
1...3...bc1q... 42 tekensbc1q... 62 tekensbc1p... 62 tekens1...3...bc1q... 42 tekensbc1q... 62 tekensbc1p... 62 tekensGegevens over 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 toestand van de mempool.
Legacy (P2PKH, voorvoegsel 1...) 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 kosten. 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 exchanges meteen ondersteuning voor het nieuwe bc1-formaat. Nested SegWit fungeerde als 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 als een 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.
Ingebouwde 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 verouderde transactie. Alle actieve wallets en exchanges ondersteunen dit vanaf 2026.
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 weerspiegelt een 32-byte SHA-256-hash 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-native manier om dit te doen.
Taproot (P2TR, voorvoegsel bc1p...(62 tekens) is SegWit versie 1, geactiveerd in 2021. 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 tip
Voor de meeste mensen geldt: gebruik native SegWit (bc1q). Dit wordt door vrijwel alle actieve wallets en beurzen ondersteund, bespaart ongeveer 38% aan kosten 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-portemonnee.).
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 kosten 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 strijd om de blokgrootte: waarom SegWit zo omstreden was
De technische argumenten voor SegWit waren duidelijk. Hoe het precies geactiveerd zou worden, was dat niet.
Van 2015 tot 2017 was Bitcoin verwikkeld in een van de meest verdeeldheid zaaiende bestuursconflicten uit zijn geschiedenis. In wezen was de vraag eenvoudig: hoe moet een gedecentraliseerd netwerk zijn eigen regels aanpassen wanneer verschillende groeperingen 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 gebruikte een gepatenteerde techniek genaamd ASICBoost, een optimalisatie die zijn mininghardware een aanzienlijk efficiëntievoordeel opleverde. SegWit was structureel onverenigbaar met verborgen ASICBoost. Het blokkeren van SegWit beschermde dat voordeel.
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 draaien – vanaf 1 augustus 2017 simpelweg elk blok zouden gaan afwijzen dat geen ondersteuning voor SegWit signaleerde.
De logica was simpel: 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 raakten. Het risico was al even duidelijk: als de acceptatie onvoldoende was, zou er een kettingsplitsing ontstaan, waarbij twee incompatibele versies van Bitcoin parallel zouden draaien.
De UASF-campagne was een grassroots-beweging 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 deadline van de UASF kwamen in mei 2017 meer dan 50 grote Bitcoin-bedrijven in New York bijeen en ondertekenden ze wat bekend werd als de New York Agreement. Ze kwamen overeen om SegWit te activeren, maar ook om dit te laten volgen door een hard fork om de blokgrootte te verdubbelen tot 2 MB (dit werd bekend als SegWit2x).
Het compromis stelde geen van beide partijen volledig tevreden. Ontwikkelaars die tegen grotere blokken waren, zagen SegWit2x als een hard fork via een achterdeurtje waar ze niet mee hadden ingestemd. Miners en bedrijven die grotere blokken wilden, kregen nog steeds niet wat ze oorspronkelijk voor ogen hadden.
Op 1 augustus 2017 splitste een groep die alleen een vergroting van de blokgrootte wilde, zonder SegWit, Bitcoin af om Bitcoin Cash (BCH) te creëren, met een bloklimiet van 8 MB. SegWit werd op 24 augustus 2017 op Bitcoin geactiveerd. De SegWit2x-hard fork werd in november 2017 opgegeven nadat de organisatoren tot de conclusie waren gekomen dat er onvoldoende consensus was.
Wat er werd overeengekomen
De uitkomst was van veel groter belang dan alleen de technische details. De UASF had gewerkt: het waren de economische knooppunten, en niet de miners, die 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 beheren 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. In het eerste kwartaal van 2025 waren er al meer dan 100 miljoen transacties verwerkt. Zonder SegWit zou die infrastructuur helemaal niet bestaan.
Hoofdbroncode 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 versie-architectuur die SegWit had gecreëerd.
Ordinale getallen en inscripties
Dankzij dezelfde getuigengegevensstructuur die met SegWit werd geïntroduceerd en door Taproot werd uitgebreid, werd 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 data en ervoor zorgde dat Taproot in 2024 bij ongeveer 42% van de transacties werd gebruikt. Naarmate de inscriptieactiviteit afnam, stabiliseerde het gebruik van Taproot zich tegen het einde van 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
Huidige adoptie
Het gebruik van SegWit nam na de activering gestaag toe en bereikte binnen enkele maanden al 30% van alle transacties; in de twee jaar daarna steeg dit percentage tot boven de 50%, naarmate wallets en beurzen hun software aanpasten.
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 gedreven door de inschrijvingsactiviteit van Ordinals, voordat het tegen het einde van 2025 daalde tot ongeveer 20% naarmate het inschrijvingsvolume afnam.
De acceptatiecurve volgt hetzelfde patroon als bij SegWit zelf: 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
1...bc1q... (inheems) of 3... (genest)1...bc1q... (inheems) of 3... (genest)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 native SegWit (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 demonstratie dat in een gedecentraliseerd netwerk consensus niet iets is dat miners verlenen, maar iets dat gebruikers afdwingen.
