SegWit uitgelegd: blokgewicht, kosten en adressen

Segregated Witness, ofwel SegWit, is een soft fork van Bitcoin die witness-data scheidt van de transactieserialisatie die wordt gebruikt voor de transactie-ID (txid). Witness-data blijft onderdeel van de volledige transactie en het blok; het wordt niet buiten de blockchain verplaatst. BIP141 introduceert nieuwe validatie- en blokgewichtregels, terwijl de compatibiliteit met de weergave van een blok door oudere nodes behouden blijft.

SegWit beperkt het blokgewicht tot 4,000,000 gewichtseenheden. Niet-witness bytes tellen vier keer mee en witness bytes één keer. De totale geserialiseerde bytegrootte is daarom afhankelijk van de samenstelling van de transactie en kan oplopen tot bijna 4 MB in blokken met veel witness bytes; 1.8–2.1 MB is geen protocollimiet. Een virtuele byte komt overeen met vier gewichtseenheden, naar boven afgerond voor de virtuele grootte van een transactie. (Bron: BIP141 Segregated Witness )

SegWit verwijdert witness-gegevens uit de txid-berekening, waardoor ongewenste, op witness gebaseerde manipuleerbaarheid van gekwalificeerde transacties wordt aangepakt. Het maakt niet elke transactie-identifier onveranderlijk: het wijzigen van niet-witness-velden, het vervangen van een transactie of het opnemen van manipuleerbare, verouderde inputs kan nog steeds van belang zijn. De verbetering maakt het eenvoudiger om vooraf ondertekende transactieketens te construeren, inclusief die welke door Lightning worden gebruikt.

Oorsprong en geschiedenis

Achtergrond van het onderzoek: SegWit bouwt voort op eerdere discussies over transactiemalleabiliteit, scheiding van getuigen en compatibele protocolupgrades.

December 2015: Pieter Wuille presenteert Segregated Witness tijdens Scaling Bitcoin in Hongkong en legt de voordelen ervan uit op het gebied van flexibiliteit en capaciteit.

Technische specificaties: BIP141 definieert consensuswijzigingen, BIP143 specificeert hashing van handtekeningen voor versie-0 witness-programma's en BIP144 beschrijft wijzigingen in peer-service en serialisatie. Dit zijn afzonderlijke specificaties met verschillende reikwijdtes en auteurs.

Mei 2017: Litecoin activeerde SegWit op zijn netwerk vóór Bitcoin, waarmee het diende als een praktijktestomgeving die de stabiliteit en veiligheid van de upgrade in een productieomgeving aantoonde. De succesvolle activering door Litecoin versterkte het vertrouwen in de implementatie van SegWit op Bitcoin.

Juli-augustus 2017: BIP91, BIP148 en het bestaande activeringsproces spelen verschillende rollen in de omstreden implementatieperiode van SegWit. Bitcoin Cash splitst zich op 1 augustus; SegWit zelf wordt later die maand geactiveerd op Bitcoin.

24 augustus 2017 : SegWit werd officieel geactiveerd op het Bitcoin-mainnet bij blokhoogte 481,824. De activering betekende het einde van een van de meest politiek beladen debatten in de geschiedenis van Bitcoin, vaak aangeduid als de "Blokgrootteoorlog".

Na activering: Wallets en services gebruiken wrapped en native SegWit. Native versie-0 mainnet-adressen beginnen met bc1q; een adres dat begint met 3 is P2SH en is niet per se SegWit.

November 2021: Taproot wordt geactiveerd met witness-versie 1, met Schnorr-handtekeningen en script-tree-commitments.

Huidig ​​gebruik: SegWit blijft onderdeel van de consensusregels van Bitcoin. Adoptiepercentages en de publieke Lightning-capaciteit zijn veranderende meetwaarden die een verouderde dataset en een duidelijke methodologie vereisen.

In eenvoudige bewoordingen

1. Stel je voor dat je een brief in een envelop verstuurt. De brief bevat de eigenlijke boodschap (de betalingsgegevens) en het lakzegel is jouw handtekening die de echtheid bewijst. Vóór SegWit moesten zowel de brief als het zegel in één kleine envelop passen. Met SegWit kun je het zegel in een apart, aan de envelop bevestigd zakje bewaren, zodat er meer brieven in de envelop passen, terwijl de zegels ter verificatie toch bij je worden gedragen.
2. Denk aan een verzendregel die verschillende gewichten hanteert voor twee soorten materiaal. SegWit verandert de manier waarop data meetelt voor de capaciteit; alle vereiste validatiedata worden nog steeds in het volledige blok verzonden.
3. Neem bijvoorbeeld een paspoortcontrole op een luchthaven. Vóór SegWit moest elke reiziger zijn of haar complete archiefkast met persoonlijke documenten meenemen door de smalle poort. SegWit is vergelijkbaar met het toestaan ​​dat reizigers met alleen hun paspoort door de poort gaan, terwijl hun volledige documenten via een apart, breder kanaal parallel daaraan worden verwerkt.
4. Stel je een receptkaart voor met een beperkt aantal woorden. Vóór SegWit moesten zowel de kookinstructies als de voetnoten op één kaart passen. SegWit verplaatst de voetnoten naar de achterkant van de kaart en telt ze met minder woorden mee, zodat koks meer daadwerkelijke kookstappen op de voorkant van elke kaart kwijt kunnen.
5. Stel je een tolhuisje op een snelweg voor waar per auto per passagier wordt gerekend. SegWit is vergelijkbaar met het veranderen van die regel, waarbij passagiers op de achterbank een kwart van de prijs betalen. Het tolhuisje verwerkt nog steeds hetzelfde aantal auto's, maar elke auto vervoert in feite meer mensen voor hetzelfde totale tolbedrag.

Belangrijk: Legacy-nodes accepteren de gestripte weergave volgens oudere regels, maar voeren geen SegWit-witnessvalidatie uit. Geüpgrade nodes voeren deze regels wel uit. Wallets hebben compatibele scripts en transactieconstructie nodig om SegWit-uitvoer correct te kunnen besteden. (Bron: BIP144 witness serialization )

Belangrijkste technische kenmerken

Blokgewicht en het nieuwe capaciteitsmodel

• Vervangt de limiet van 1 MB voor de blokgrootte door een limiet van 4,000,000 gewichtseenheden (4 MWU) voor het blokgewicht.
• Niet-getuigendata kost 4 WU per byte; getuigendata kost 1 WU per byte.
• De totale geserialiseerde grootte varieert afhankelijk van de samenstelling van de witness-server en kan oplopen tot 4 MB; het aantal transacties is niet vast.
• Oudere knooppunten ontvangen een compatibele, vereenvoudigde serialisatie; geüpgrade knooppunten valideren ook de witness-verplichtingen en -regels.

Oplossing voor transactiemanipulatie

• Vóór SegWit werd de txid berekend over de gehele transactie, inclusief de handtekeningen.
• Historisch gezien konden toegestane wijzigingen in ontgrendelingsgegevens een txid wijzigen zonder de beoogde betaling te veranderen. Welke wijzigingen geldig zijn, hangt af van de actieve consensus en beleidsregels.
• De txid sluit witness-gegevens uit. Dit voorkomt dat wijzigingen die alleen betrekking hebben op witness-gegevens de txid beïnvloeden, maar niet elke mogelijke wijziging aan de transactie.
• Een aparte witness txid (wtxid) dekt de volledige transactie, inclusief witness-gegevens.

Hoe werkt een SegWit-transactie?

1. De portemonnee van de afzender construeert een transactie met invoergegevens die verwijzen naar eerdere transacties. utxos en geeft uitvoer met specificatie van de adressen van de ontvangers en de bedragen.
2. Native witness-inputs gebruiken een lege scriptSig; P2SH-wrapped witness-inputs bevatten het redeem witness-programma. Andere inputs in een gemengde transactie kunnen nog steeds legacy scriptSigs bevatten. (Bron: Bitcoin Core SegWit wallet ontwikkeling)
3. De transactie wordt geserialiseerd met een markeringsbyte (0x00) en een vlagbyte (0x01) die het SegWit-formaat aangeven.
4. De txid hasht de serialisatie zonder witness, inclusief de daadwerkelijke scriptSig-velden; deze zijn niet universeel leeg.
5. De wtxid wordt berekend door de volledige geserialiseerde transactie, inclusief witness-gegevens, te hashen.
6. Een witness-commitment in de coinbase-transactie verbindt zich aan de witness Merkle-root, naast de gewone transactie Merkle-root-structuur van het blok.
7. Bij het valideren van het blok controleren de knooppunten zowel de standaardtransactievaliditeit als de integriteit van de witness-gegevens.

SegWit-adrestypen

• P2SH-wrapped SegWit: Mainnet-adressen beginnen met 3, maar hetzelfde voorvoegsel vertegenwoordigt ook niet-SegWit P2SH-scripts. BIP49 specificeert een gemeenschappelijke afleidingsconventie voor wrapped wallets.
• Native versie 0 SegWit: Mainnet-adressen beginnen met bc1q en gebruiken Bech32. De besparing op transactiekosten is afhankelijk van het type in- en uitvoer, het aantal transacties en het tarief.
• Taproot: Mainnet versie-1 adressen beginnen met bc1p en gebruiken Bech32m. Andere toekomstige witness-versies gebruiken ook Bech32m, maar hoeven niet met bc1p te beginnen.

Lightning Network-activering

• Het Lightning Network is gebaseerd op vooraf ondertekende transacties die verwijzen naar specifieke txids.
• Vóór SegWit betekende de mogelijkheid tot het wijzigen van transacties dat transactie-ID's na de uitzending konden veranderen, waardoor contracten voor betalingskanalen werden geschonden.
• Het verwijderen van de op witness gebaseerde txid-malleabiliteit ondersteunt een robuuste kanaalconstructie; Lightning kent echter nog steeds zijn eigen liquiditeits-, monitoring- en protocolrisico's.
• Lightning-implementaties maken gebruik van compatibele financierings- en uitgavenformaten; het beheren van een kanaal vereist meer dan alleen het kiezen van een SegWit-adres.

Voordelen nadelen

RISICO BEHEER

Pak het compatibiliteitsrisico aan

• Oudere wallets en sommige exchanges ondersteunen mogelijk geen verzending naar bech32 (bc1) adressen.
• Controleer of de verzendende dienst het exacte adresstype en netwerk van de ontvanger ondersteunt. Wrapped SegWit kan in sommige gevallen compatibiliteit bieden, maar ga er niet vanuit dat elk adres met een 3 als voorvoegsel een SegWit-wallet is.
• Raadpleeg de actuele servicedocumentatie in plaats van uit te gaan van ondersteuning op basis van een oude implementatiedatum.

Risico van gedeeltelijke adoptiekosten

• De verzender betaalt de transactiekosten, die afhankelijk zijn van de verbruikte inputs en de totale transactie. Het ontvangen van een SegWit-output kan de kosten voor het later verbruiken van die output verlagen.
• Gebruik waar nodig compatibele native SegWit-uitgangen en vergelijk de werkelijke virtuele groottes en de geschatte kosten.

Gegevens en gebruik van bronnen door getuigen

• Transacties met veel witness-transacties kunnen grotere geserialiseerde blokken produceren binnen de gewichtslimiet. Het gebruik van de toegestane witness-ruimte is op zich geen protocol-exploit.
• Consensusgewichten en scriptregels beperken de blokken; node-relay- en miningbeleid leggen aanvullende, afzonderlijke limieten op. Beleidslimieten moeten niet worden verward met consensuslimieten.
• De trend van ordinalen en inscripties in 2023 illustreerde deze dynamiek, aangezien grote hoeveelheden bewijsmateriaal werden gebruikt om afbeeldingen en gegevens on-chain te registreren.

Migratierisico voor diensten

• Beurzen en betalingsverwerkers die overstappen van de oude naar de SegWit-adresindeling, moeten de overgang zorgvuldig uitvoeren om verlies van geld of boekhoudkundige fouten te voorkomen.
• Oplossing: laat tijdens de migratie parallelle legacy- en SegWit-systemen draaien; voer grondige tests uit op het testnet voordat het systeem op het mainnet wordt geïmplementeerd.

Culturele relevantie

Het debat over schaalvergroting, bekend als de Block Size War, draaide om concurrerende technische en bestuurlijke benaderingen. Bitcoin Cash splitste op 1 augustus 2017; Bitcoin SegWit werd geactiveerd op 24 augustus op een hoogte van 481,824. Dit waren afzonderlijke gebeurtenissen.

De term "UASF" (User-Activated Soft Fork) werd een strijdkreet onder SegWit-aanhangers die pleitten voor het afdwingen van SegWit-activering door node-operators, ongeacht of miners dit signaleerden. De BIP148 UASF-beweging toonde de macht van economische nodes (beurzen, bedrijven, gebruikers) over miners bij het bepalen van het upgradepad van Bitcoin, en schiep een precedent voor hoe toekomstige protocolwijzigingen zouden worden beoordeeld.

De activering van SegWit markeerde ook een keerpunt in het bestuur van Bitcoin. Het mislukken van de New York Agreement (SegWit2x), die voorstelde om SegWit te activeren gevolgd door een verhoging van de blokgrootte naar 2 MB, bevestigde het principe dat geen enkele overeenkomst achter gesloten deuren tussen spelers in de sector de protocolwijzigingen van Bitcoin kon dicteren zonder bredere consensus binnen de gemeenschap.

In de ontwikkelaarswereld wordt SegWit geprezen als een elegante technische oplossing die meerdere problemen tegelijk oploste – schaalbaarheid, flexibiliteit en upgradebaarheid – door middel van één enkele, achterwaarts compatibele wijziging. Het door SegWit geïntroduceerde versiebeheersysteem is uitgegroeid tot het belangrijkste mechanisme voor het uitrollen van latere upgrades, met Taproot (witness v1) als meest bekende voorbeeld.

De "Block Size War" is uitvoerig beschreven in het boek The Blocksize War (2021) van Jonathan Bier, dat een aanrader is geworden voor iedereen die het bestuursmodel van Bitcoin en de sociale dynamiek van de ontwikkeling van gedecentraliseerde protocollen wil begrijpen.

Voorbeelden uit de echte wereld

1. SegWit en transactiebatching

• Scenario: Een dienstverlener wil de totale on-chain kosten van veel opnames verlagen.
• Mechanisme: SegWit kan het inputgewicht verlagen, terwijl batchverwerking de transactieoverhead verdeelt over meerdere outputs. Dit zijn afzonderlijke optimalisaties.
• Resultaat: SegWit en batchverwerking kunnen beide de kosten verlagen, maar de voordelen hangen af ​​van de transactiestructuur en het tarief. Batchverwerking deelt de overheadkosten; SegWit verandert het gewicht van de in aanmerking komende invoergegevens.

2. Groei van het Lightning Network mogelijk gemaakt door SegWit

• Scenario: Betalingskanaalprotocollen hebben betrouwbare referenties nodig voor financierings- en toezeggingstransacties.
• Implementatie: Lightning-nodes openen betalingskanalen door 2-van-2 multisig SegWit-transacties op de Bitcoin-basislaag te creëren. Daaropvolgende betalingen binnen het kanaal worden off-chain uitgevoerd via bijgewerkte commitment-transacties die verwijzen naar de txid van de oorspronkelijke SegWit-financieringstransactie.
• Resultaat: SegWit ondersteunt het transactieontwerp van Lightning, maar kanaalcapaciteit, routingliquiditeit, aantal knooppunten en betalingssucces zijn afzonderlijke meeteenheden. Het protocol vloeit niet voort uit een vaste capaciteit of dollarwaarde voor 2026.

3. Verlichting van de congestie in Mempool tijdens de bullrun van 2021

• Scenario: Tijdens de Bitcoin-hausse van 2021 steeg het transactievolume enorm, wat leidde tot aanzienlijke overbelasting van de mempool en hogere transactiekosten.
• Mechanisme: Bij hetzelfde tarief verlaagt een kleinere virtuele grootte de totale kosten. Inclusie blijft afhankelijk van het tarief, de voorouderpakketten, het beleid van de miner en de beschikbare blokruimte.
• Resultaat: SegWit verbetert de efficiëntie van de blokruimte voor de juiste transactietypen. Het garandeert echter geen opname in het volgende blok of een universeel twee- of drievoudig tariefvoordeel.

4. Ordinalen en inscripties met behulp van de getuigenruimte

• Scenario: Begin 2023 lanceerde ontwikkelaar Casey Rodarmor de Ordinaal protocol, dat gebruikmaakt van de witness-dataruimte van SegWit om willekeurige gegevens (afbeeldingen, tekst, HTML) rechtstreeks op de Bitcoin-blockchain te schrijven.
• Mechanisme: Inscriptiegegevens worden meegedragen in de Taproot script-path witness-gegevens en ontvangen een witness-weging. Andere blok- en transactiegegevens verbruiken nog steeds gewicht, waardoor een payload, los van de overhead, niet de volledige 4,000,000 bytes kan innemen.
• Resultaat: De inscripties illustreren een intensief gebruik van de beschikbare ruimte door getuigen en hebben het debat over de toewijzing van middelen nieuw leven ingeblazen. Voor het tellen van aantallen en het vaststellen van adoptiecijfers is een gedateerde dataset nodig.

Vergelijkingstabel

Gerelateerde termen

• Bitcoin Verbeteringsvoorstel (BIP) — Het formele proces voor het voorstellen en documenteren van wijzigingen aan het Bitcoin-protocol; SegWit werd geïmplementeerd via BIP141, BIP143 en BIP144.
• Transactie-malleabiliteit — Wijzigingen die een transactie-identificatiecode aanpassen zonder noodzakelijkerwijs de beoogde betaling te veranderen; SegWit behandelt op getuigen gebaseerde formulieren onder specifieke voorwaarden.
• Bliksem netwerk — Het primaire layer-2 betalingskanaalnetwerk van Bitcoin dat directe transacties met lage kosten mogelijk maakt; direct mogelijk gemaakt door de oplossing voor de malleability van SegWit.
• Soft Fork — Een achterwaarts compatibele protocolupgrade waarbij niet-geüpgradede knooppunten nog steeds blokken accepteren van geüpgradede knooppunten; SegWit werd geïmplementeerd als een soft fork om te voorkomen dat het netwerk zou worden opgesplitst.
• Blokgewicht — De door SegWit geïntroduceerde metriek ter vervanging van de oude blokgroottebeperking, gemeten in gewichtseenheden (WU) met een maximum van 4,000,000 WU per blok.
• Bech32 — Adrescodering gebruikt voor native witness-versie 0; Bech32m wordt gebruikt voor versies 1 en later.
• hoofdwortel — Een Bitcoin-upgrade uit 2021 die voortbouwt op SegWit's witness-versie 1 en Schnorr-handtekeningen, MAST en verbeterde privacy voor complexe transacties introduceert.
• UTXO (niet-bestede transactie-uitvoer) — Het fundamentele boekhoudmodel in Bitcoin; SegWit-transacties wijzigen de manier waarop de bestedingsvoorwaarden van UTXO's worden gestructureerd en geverifieerd.
• Witness Program — Het scriptPubKey-formaat dat door SegWit is geïntroduceerd en dat de witness-versie en programma-hash specificeert, waardoor gescheiden verificatie van bestedingsvoorwaarden mogelijk is.
• Bitcoin Cash — Een hard fork van Bitcoin, gecreëerd op 1 augustus 2017 door voorstanders van grotere blokken die het niet eens waren met de SegWit-schaalmethode.
• De 'Block Size War' is het jarenlange debat binnen de Bitcoin-community over de schaalbaarheid van Bitcoin, dat culmineerde in de activering van SegWit en de Bitcoin Cash-fork, en dat de bestuurscultuur van Bitcoin heeft gevormd.
• Ordinals Protocol — Een protocol voor het vastleggen van willekeurige data op Bitcoin met behulp van de korting op de witness space van SegWit, waardoor NFT-achtige functionaliteit op de Bitcoin-blockchain mogelijk wordt.

FAQ

V: Wat betekent "Gescheiden getuige" nu eigenlijk in begrijpelijke taal?

"Gescheiden" betekent apart, en "Witness" verwijst naar de cryptografische handtekeningen die bewijzen dat een transactie geautoriseerd is. "Gescheiden Witness" betekent dus letterlijk het scheiden van de handtekeningen van de hoofdtransactiegegevens. De handtekeningen zijn nog steeds opgenomen in het blok voor verificatiedoeleinden, maar ze worden in een aparte structuur geplaatst die met een korting wordt meegerekend bij het berekenen van de blokcapaciteit.

V: Hoeveel besparen SegWit-transacties op transactiekosten in vergelijking met traditionele transacties?

Besparingen zijn afhankelijk van het type script, het aantal in- en uitgangen en het transactietarief. Bij een vast sat/vB-tarief kost een kleinere virtuele hoeveelheid minder. Vergelijk de geschatte kosten voor de daadwerkelijke transactie in plaats van uit te gaan van een universele korting.

V: Is de invoering van SegWit verplicht voor Bitcoin-gebruikers?

Gebruikers kunnen nog steeds oudere outputs ontvangen en uitgeven, maar oude nodes passen niet alle nieuwere consensusregels toe. SegWit-compatibele software is nodig voor een correcte validatie van de witness en ondersteunde bestedingsformaten. Er is geen huidig ​​adoptiepercentage vereist om het te gebruiken.

V: Hoe heeft SegWit het Lightning Network mogelijk gemaakt?

Lightning is afhankelijk van vooraf ondertekende transacties die verwijzen naar financieringsuitgangen. SegWit verwijdert onder de vereiste voorwaarden op getuigen gebaseerde wijzigingen in de txid, waardoor die verwijzingen betrouwbaarder worden. Het elimineert echter niet alle beveiligings- of beschikbaarheidsrisico's van Lightning.

V: Wat is het verschil tussen bech32- en bech32m-adressen?

Op het Bitcoin mainnet beginnen witness-adressen van versie 0 met bc1q en gebruiken ze Bech32. Taproot-adressen van versie 1 beginnen met bc1p en gebruiken Bech32m. Bech32m is van toepassing op versies 1 tot en met 16; hogere versies hebben andere voorvoegsels en vertegenwoordigen niet automatisch Taproot. (Bron: BIP350 Bech32m adrescodering )

V: Heeft SegWit het schaalbaarheidsprobleem van Bitcoin opgelost?

SegWit verbetert de efficiëntie qua gewicht en ondersteunt ontwerpen voor betaalkanalen, maar biedt geen onbeperkte doorvoer. Capaciteitswinsten zijn afhankelijk van de samenstelling van de transacties, en gelaagde systemen brengen hun eigen operationele afwegingen met zich mee.

V: Waarom bekritiseren sommige mensen SegWit?

Critici hebben verschillende bezwaren geuit. Sommigen betoogden dat een directe vergroting van de blokgrootte eenvoudiger en effectiever zou zijn geweest. Anderen stelden dat het soft fork-implementatiemechanisme (waarbij de truc met "iedereen kan uitgeven" wordt gebruikt voor achterwaartse compatibiliteit) een onelegante workaround was. De controverse rond Ordinals heeft het debat opnieuw aangewakkerd over de vraag of de korting op witness-data niet-monetair gebruik van blokruimte stimuleert dat oorspronkelijk niet door de ontwerpers van SegWit was bedoeld.

Conclusie

SegWit verbetert het transactieontwerp van Bitcoin door middel van scheiding van getuigen en blokgewichtberekening. Gebruik compatibele software en adresformaten en bereken de kosten op basis van de daadwerkelijke transactie in plaats van uit te gaan van vaste besparingen of onbeperkte capaciteit.

Bronnen

BIP141 Afgezonderde getuige

Bitcoin Core SegWit wallet ontwikkeling

BIP350 Bech32m adrescodering

BIP144 getuigenserialisatie

Rangorde-inscriptiegegevens

Bitcoin Cash adaptieve bloklimiet mei 2024