Wat is de programmeertaal Bitcoin Script?

Bitcoin Script is de programmeertaal die elke transactie op het Bitcoin-netwerk regelt. Het is een eenvoudige, op een stack gebaseerde taal die de exacte voorwaarden vastlegt waaronder bitcoins kunnen worden uitgegeven, en elke volledige node op het netwerk voert deze taal uit telkens wanneer een transactie wordt gevalideerd. Zonder deze taal zou Bitcoin slechts een grootboek met getallen zijn, zonder mechanisme om vast te stellen wie wat bezit.

De meeste gebruikers krijgen de Bitcoin-scripttaal nooit rechtstreeks te zien. Hun wallets regelen dit op de achtergrond. Maar elke keer dat je BTC verstuurt of ontvangt, worden er op duizenden computers tegelijkertijd twee kleine programma's uitgevoerd, die controleren of aan de bestedingsvoorwaarden is voldaan. Als je begrijpt hoe dat werkt, wordt veel duidelijk over waarom Bitcoin zo is opgezet en wat het wel en niet kan in vergelijking met platforms zoals Ethereum.

In dit artikel wordt uitgelegd hoe Bitcoin Script werkt, worden de belangrijkste transactietypen die hiermee mogelijk zijn besproken, wordt de Taproot-upgrade toegelicht die de scriptinglaag in 2021 heeft gemoderniseerd, en wordt ingegaan op de stand van zaken rond het debat over de covenant-opcode per juni 2026.

Beheer je Bitcoin veilig met zelfbewaring Bitcoin.com Wallet-app.

Belangrijkste punten

• Bitcoin Script is een op een stack gebaseerde programmeertaal die in het Bitcoin-protocol is ingebouwd en die de voorwaarden vastlegt waaronder een bitcoin-output kan worden uitgegeven.
• Elke Bitcoin-transactie bevat twee scripts: een vergrendelingsscript (ScriptPubKey) dat door de ontvanger wordt ingesteld en een ontgrendelingsscript (ScriptSig) dat door de betaler wordt verstrekt. Beide moeten succesvol worden uitgevoerd om de transactie geldig te maken.
• Bitcoin Script is bewust niet Turing-compleet. Het kent geen lussen, geen blijvende toestand tussen uitvoeringen en er gelden strikte limieten voor de scriptgrootte. Hierdoor wordt gegarandeerd dat elk script wordt beëindigd, wat een beveiligingsfunctie is en geen beperking.
• De scripttaal heeft zich ontwikkeld via vijf belangrijke formaten: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) en Taproot (P2TR), die stuk voor stuk de mogelijkheden hebben uitgebreid en tegelijkertijd achterwaarts compatibel zijn gebleven.
• Taproot (november 2021) introduceerde Schnorr-handtekeningen, op MAST gebaseerde bestedingspaden voor meer privacy en Tapscript als een vernieuwde scripttaal met een ingebouwd mechanisme voor soepelere upgrades in de toekomst.
• Praktijkvoorbeelden die op Bitcoin Script zijn gebaseerd, zijn onder meer wallets met meervoudige handtekeningen, transacties met tijdslot, Hash Time-Locked Contracts (de basis van Lightning), escrow en Discreet Log Contracts.
• In tegenstelling tot de slimme contracten van Ethereum is Bitcoin Script stateloos: elk script draait volledig geïsoleerd, zonder enige kennis van andere transacties. Dit is een bewuste architecturale keuze.
• Het meest actieve gebied binnen de ontwikkeling van Bitcoin Script in 2026 betreft de covenant-opcodes, met name OP_CTV (BIP-119) en OP_CAT (BIP-347), waarmee scripts kunnen bepalen aan welke voorwaarden een uitgavetransactie moet voldoen. Geen van beide is tot nu toe op het mainnet geactiveerd.

Wat is Bitcoin Script?

Bitcoin Script is een op een stack gebaseerde, stateloze scripttaal die in het Bitcoin-protocol is ingebouwd. Elke transactie-output op het Bitcoin-netwerk bevat een vergrendelingsscript (de zogenaamde ScriptPubKey) waarin de voorwaarden voor het besteden van het geld zijn vastgelegd. Iedereen die dit geld wil besteden, moet een ontgrendelingsscript (de zogenaamde ScriptSig, of bij SegWit- en Taproot-transacties de witness-gegevens) aanleveren dat aan deze voorwaarden voldoet.

De taal ontleent zijn structuur aan Forth, een minimalistische, op een stack gebaseerde programmeertaal die in de jaren zestig is ontwikkeld. Net als Forth wordt Bitcoin Script van links naar rechts gelezen, werkt het met een gegevensstructuur die een stack wordt genoemd, en maakt het gebruik van Reverse-Polish Notation (RPN), waarbij operatoren achter hun operanden staan in plaats van ervoor. Het voert één instructie tegelijk uit, kent geen lussen en bewaart geen gegevens tussen uitvoeringen.

Dat laatste punt is wat de meeste mensen als eerste tegenkomen wanneer ze zich verdiepen in Bitcoin Script op protocolniveau: de taal is bewust niet Turing-compleet. Een Turing-complete taal kan elke berekening uitvoeren, mits er voldoende tijd en middelen beschikbaar zijn. Bitcoin Script kan dat, door zijn ontwerp, niet, en de redenen voor die keuze zijn van groot belang voor de werking van het netwerk.

Hoe Bitcoin Script werkt: het stackmodel

Om te begrijpen hoe Bitcoin Script werkt, moet je weten wat een stack is. Een stack is een gegevensstructuur die werkt volgens het Last-In, First-Out-principe (LIFO). Stel je een stapel borden voor: je kunt alleen iets bovenop leggen of er iets van afhalen. In Bitcoin Script worden gegevens op de stack geplaatst en manipuleren opcodes (operatiecodes) wat er bovenop ligt.

Wanneer een Bitcoin-node een transactie valideert, voert deze achtereenvolgens twee scripts uit:

1. Het ontgrendelingsscript (ScriptSig of witness) die wordt verstrekt door de persoon die de munten uitgeeft. Hierdoor worden gegevens op de stack geplaatst, meestal een digitale handtekening en een openbare sleutel.
2. Het vergrendelingsscript (ScriptPubKey) gekoppeld aan de besteding van de output. Dit bevat opcodes die bewerkingen uitvoeren op de gegevens op de stack en controleren of aan de bestedingsvoorwaarden is voldaan.

Als het script zonder fouten wordt uitgevoerd en aan het einde een waarde anders dan nul (TRUE) op de stack achterlaat, is de transactie geldig. Als het script mislukt of FALSE achterlaat, wordt de transactie door het knooppunt afgewezen en komt deze nooit in een blok terecht.

Deze uitvoering is volledig stateless. Het script heeft geen kennis van eerdere transacties, geen inzicht in de huidige saldi en geen geheugen dat na afloop van de uitvoering behouden blijft. Elk script wordt elke keer opnieuw, volledig geïsoleerd, vanaf nul uitgevoerd.

Stap voor stap: een standaard P2PKH-transactie

Pay-to-Public-Key-Hash (P2PKH) is het oorspronkelijke transactietype van Bitcoin, dat al sinds 2009 in gebruik is. P2PKH-adressen beginnen met "1." Zo zien ScriptPubKey en ScriptSig er in de praktijk uit:

Ontgrendelingsscript (ScriptSig):

<handtekening> <openbare sleutel>

Vergrendelingsscript (ScriptPubKey):

OP_DUP OP_HASH160 <hash van de openbare sleutel> OP_EQUALVERIFY OP_CHECKSIG

Wanneer het knooppunt beide samenvoegt en tegelijkertijd uitvoert, verlopen de stapelbewerkingen stap voor stap:

• De handtekening en de openbare sleutel uit de ScriptSig worden op de stack geplaatst
• OP_DUP kopieert de openbare sleutel bovenaan de stapel
• OP_HASH160 berekent de hash van het duplicaat (SHA-256 gevolgd door RIPEMD-160), wat een hash van 20 bytes oplevert
• De hash van de openbare sleutel uit het vergrendelingsscript wordt op de stack geplaatst
• OP_EQUALVERIFY controleert of de twee hashes met elkaar overeenkomen. Als dat niet het geval is, wordt de uitvoering gestopt en mislukt de transactie.
• OP_CHECKSIG controleert of de handtekening geldig is voor de openbare sleutel

Als alle stappen succesvol zijn doorlopen, eindigt de stack met TRUE en wordt het geld vrijgegeven. Het hele proces duurt slechts enkele milliseconden en verloopt op elke node in het netwerk op identieke wijze.

Bitcoin-opcodes uitgelegd

Bitcoin-opcodes zijn de afzonderlijke commando’s waaruit een script bestaat. Elk opcode bestaat uit één byte, wat neerkomt op 256 mogelijke opcode-slots. Daarvan zijn er momenteel ongeveer 80 actief op het mainnet. De rest is gereserveerd, uitgeschakeld of toegewezen aan het OP_SUCCESS-mechanisme voor voorwaartse compatibiliteit, dat met Tapscript is geïntroduceerd.

Opcodes kunnen in verschillende categorieën worden ingedeeld:

• Opcodes voor het doorsturen van gegevens waarden zoals openbare sleutels, handtekeningen en hashes op de stack plaatsen
• Rekenkundige opcodes optellen, aftrekken en vergelijken. Vermenigvuldigen en delen zijn echter uitgeschakeld.
• Cryptografische opcodes waaronder OP_SHA256, OP_HASH160 en OP_SHA1 voor hashing, en OP_CHECKSIG voor het verifiëren van handtekeningen
• Opcodes voor stroomregeling voorwaardelijke logica inschakelen: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Opcodes voor het bewerken van de stack waaronder OP_DUP (het bovenste item dupliceren), OP_DROP (het bovenste item verwijderen) en OP_SWAP (de bovenste twee items omwisselen)

In 2010 heeft Satoshi Nakamoto verschillende opcodes uitgeschakeld nadat er kwetsbaarheden waren ontdekt in de oorspronkelijke implementaties ervan. Het gaat onder meer om OP_CAT (twee stackitems samenvoegen), OP_MUL (vermenigvuldigen) en OP_DIV (delen). Het ontbreken ervan heeft blijvende gevolgen gehad voor de mogelijkheden van Bitcoin Script, en bij verschillende van de meest besproken voorstellen voor Bitcoin-upgrades in 2026 gaat het erom of sommige van deze opcodes weer moeten worden ingeschakeld.

Voor de volledige opcode-referentie, inclusief hexadecimale waarden en beschrijvingen, zie de Pagina 'Bitcoin Wiki Script' is de toonaangevende bron.

Waarom het feit dat het niet-Turing-compleet is juist een voordeel is

De gangbare verklaring is dat Bitcoin Script geen lussen kent, waardoor scripts gegarandeerd worden beëindigd en het netwerk dus beschermd is tegen oneindige uitvoering. Dat klopt wel, maar het doet geen recht aan de kern van de zaak.

Het diepere argument betreft het aanvalsoppervlak. Een Turing-complete taal kan willekeurige berekeningen uitdrukken. Die expressiviteit is tegelijkertijd de ruimte waarin bugs zich kunnen nestelen. Solidity van Ethereum heeft enkele van de duurste softwarekwetsbaarheden in de geschiedenis veroorzaakt. Bij de DAO-hack in 2016 werd misbruik gemaakt van een reentrancy-fout in een smart contract, wat leidde tot verliezen van ongeveer 60 miljoen dollar tegen de toenmalige koersen en uiteindelijk resulteerde in een controversiële hard fork van het Ethereum-netwerk. In het bredere DeFi-ecosysteem zijn in de loop van meerdere jaren honderden miljoenen dollars weggevloeid door misbruik van smart contracts.

Bitcoin Script maakt dit soort aanvallen structureel onmogelijk. Je kunt geen Bitcoin-script schrijven dat andere scripts aanroept, in een lus blijft totdat een voorwaarde verandert, of de status tussen transacties opslaat. Elk script is een afgebakend, eindigend en controleerbaar programma. De maximale scriptgrootte is 10.000 bytes. Het maximale aantal niet-push-opcodes per script is 201. Een validator kan altijd de uitvoeringskosten in het ergste geval berekenen voordat het script wordt uitgevoerd.

Voor een netwerk met een waarde van honderden miljarden dollars is die voorspelbaarheid meer waard dan de flexibiliteit die je opgeeft. Ethereum lost het probleem van onbeperkte rekenkracht op met gaslimieten: gebruikers betalen voor elke uitgevoerde opcode en scripts worden gestopt zodra het budget op is. Dat werkt, maar het brengt zijn eigen complexiteit en storingsmogelijkheden met zich mee. Bitcoin omzeilt het probleem volledig door de manier waarop het is ontworpen.

Dat gezegd hebbende, betekent „niet Turing-compleet” niet dat het „niet in staat is tot complexe logica”. Bitcoin Script ondersteunt vereisten voor uitgaven door meerdere partijen, op tijd gebaseerde voorwaarden, het onthullen van hash-preimages en combinaties van al deze elementen. Het Lightning Network, dat dagelijks miljoenen betalingen verwerkt, is volledig gebouwd op basis van Bitcoin Script-primitieven.

Scripttypen: de ontwikkeling van P2PKH naar Taproot

De scriptlaag van Bitcoin heeft zich sinds 2009 aanzienlijk ontwikkeld; bij elke upgrade werd een nieuw transactieformaat geïntroduceerd, terwijl de achterwaartse compatibiliteit met alle eerdere versies behouden bleef.

P2PK (Pay-to-Public-Key, 2009)

Het oorspronkelijke formaat, dat werd gebruikt bij de eerste Bitcoin-transacties, waaronder de betaling van Satoshi aan Hal Finney in blok 170. Het geld werd rechtstreeks aan een volledige openbare sleutel gekoppeld, in plaats van aan de hash daarvan. Wordt tegenwoordig zelden gebruikt in nieuwe transacties, omdat hierdoor de openbare sleutel al vóór de besteding op de blockchain zichtbaar wordt, wat als een zwakkere beveiliging wordt beschouwd dan wanneer de sleutel eerst wordt gehasht.

P2PKH (Pay-to-Public-Key-Hash, 2009)

Al meer dan tien jaar het standaardformaat. Bij P2PKH worden middelen gekoppeld aan een hash van de openbare sleutel in plaats van aan de sleutel zelf, waardoor de openbare sleutel geheim blijft tot het moment van besteding, wat resulteert in een korter adres van 20 bytes en de basis vormt voor alle adressen die beginnen met „1.“ Volgens on-chain-gegevens van Unchained (april 2026) bevatten P2PKH-adressen momenteel ongeveer 43% van de geminde bitcoinvoorraad.

P2SH (Pay-to-Script-Hash, 2012, BIP 16)

P2SH, dat op 1 april 2012 via een soft fork werd geïntroduceerd, verplaatste de last van complexe bestedingsscripts van de afzender naar de ontvanger. In plaats van een volledig vergrendelingsscript in de output op te nemen, geeft P2SH een verwijzing naar een 20-byte hash van een „redeem script”. Het volledige script wordt pas onthuld wanneer de munten worden uitgegeven. Dit maakte multisig praktisch voor gewone gebruikers: bij een 2-van-3-multisig-configuratie hoefden niet langer alle drie de openbare sleutels zichtbaar te zijn voor de afzender op het moment van betaling. P2SH-adressen beginnen met „3.“

Voor een gedetailleerde uitleg over hoe P2SH-validatie op protocolniveau werkt, De transactiegids van developer.bitcoin.org legt het werkingsmechanisme van het ‘redeem’-script stap voor stap uit.

P2WPKH en P2WSH (Native SegWit, 2017, BIP 141)

Segregated Witness, dat in augustus 2017 bij blok 481.824 werd geactiveerd, verplaatste de handtekeninggegevens buiten de hoofdtekst van de transactie naar een aparte ‘witness’-structuur. Voor ‘witness’-gegevens geldt een gewichtsvermindering van 75%, waardoor SegWit-transacties aanzienlijk goedkoper worden. Een standaard P2WPKH-transactie met één invoer en twee uitvoeren weegt ongeveer 141 virtuele bytes, vergeleken met 226 vbytes voor de equivalente P2PKH-transactie, volgens Analyse van de soorten Bitcoin-adressen door Spark vanaf maart 2026. SegWit heeft ook de transactievervormbaarheid verholpen, wat een voorwaarde was voor het Lightning Network. Native SegWit-adressen beginnen met "bc1q."

P2TR (Pay-to-Taproot, 2021, BIP’s 340/341/342)

Taproot werd in november 2021 bij blok 709.632 geactiveerd en is de belangrijkste upgrade van de scriptlaag van Bitcoin sinds SegWit. Hiermee werden Schnorr-handtekeningen, een nieuw outputtype met MAST-ondersteuning en Tapscript als vernieuwde scripttaal geïntroduceerd. Taproot-adressen beginnen met „bc1p.“

Taproot en Tapscript: hoe de scripttaal van Bitcoin in 2021 is veranderd

Taproot bestaat niet uit één enkele wijziging. Het gaat om drie Bitcoin Improvement Proposals die gezamenlijk zijn ontworpen en gelijktijdig in werking zijn getreden.

BIP 340: Schnorr-handtekeningen

Bitcoin maakte aanvankelijk gebruik van ECDSA (Elliptic Curve Digital Signature Algorithm). Satoshi koos hiervoor mede omdat Schnorr-handtekeningen destijds door een octrooi werden beschermd. Dat octrooi liep in 2008 af, en met Taproot werd Schnorr uiteindelijk in het protocol geïntegreerd.

Schnorr-handtekeningen zijn kleiner: 64 bytes, tegenover 71-73 bytes voor ECDSA. Wat nog belangrijker is: ze ondersteunen sleutelaggregatie via een schema dat MuSig2 heet. Dankzij sleutelaggregatie kunnen meerdere ondertekenaars hun individuele sleutels en handtekeningen combineren tot één geaggregeerde sleutel en handtekening die op de blockchain niet te onderscheiden is van een gewone betaling met één handtekening. Een 2-van-3 multisig-portemonnee die uitgaven verricht via het coöperatieve sleutelpad van Taproot, ziet er identiek uit aan een standaardbetaling op de blockchain. Dat is een echte privacywinst voor iedereen die bitcoin aanhoudt in een complexe bewaarregeling.

BIP 341: Pay-to-Taproot en MAST

P2TR introduceert een nieuw uitgangstype met twee bestedingspaden:

• A sleutelpad betalen met behulp van een Schnorr-handtekening, wat wordt gebruikt wanneer alle partijen het eens zijn en de eenvoudigste en goedkoopste oplossing willen
• A scriptpad uitgeven met behulp van MAST (Merkelized Abstract Syntax Tree, de Taproot-implementatie van dit concept)

Met MAST kan één enkele output via een Merkle-root worden gekoppeld aan een boomstructuur van meerdere bestedingsscripts. Bij het besteden wordt alleen de specifieke voorwaarde die daadwerkelijk wordt gebruikt op de blockchain zichtbaar gemaakt. Alle andere mogelijke bestedingspaden in de boomstructuur blijven permanent verborgen. Voor een gebruiker die een complex bestedingsbeleid heeft geconfigureerd, bijvoorbeeld: „Ik kan normaal besteden, of twee van de drie beheerders kunnen na zes maanden besteden, of een herstelsleutel kan na twee jaar besteden“, verschijnt alleen het pad dat daadwerkelijk wordt uitgevoerd op de blockchain.

Volgens gegevens van Glassnode, die in maart 2026 door Spark werden aangehaald, was het aandeel van Taproot in de Bitcoin-transacties tegen 2024 gestegen tot ongeveer 42%, grotendeels dankzij de activiteit rond Ordinals en BRC-20-inscripties. Dat aandeel heeft sindsdien geschommeld naargelang de marktomstandigheden, maar de infrastructuur is nu standaard in alle grote wallets en op alle grote beurzen. De Taproot-themapagina van Bitcoin Optech houdt de lopende protocolontwikkeling rond Taproot bij.

BIP 342: Tapscript

Tapscript is de vernieuwde scripttaal die wordt gebruikt voor uitgaven via het scriptpad binnen Taproot. Het deelt de meeste opcodes met het oude Bitcoin Script, maar bevat een aantal belangrijke wijzigingen:

• OP_CHECKMULTISIG en OP_CHECKMULTISIGVERIFY zijn verouderd. De oude multisig-opcode had een eigenaardigheid waardoor als tijdelijke oplossing een dummy-element op de stack moest worden geplaatst. Tapscript verwijdert dit en vervangt het door OP_CHECKSIGADD, dat Schnorr-handtekeningen één voor één verifieert en daarbij een telling bijhoudt. Multisig-schema’s met drempelwaarden worden overzichtelijker en goedkoper om uit te voeren.
• De limieten voor de scriptgrootte per MAST-blad zijn opgeheven. Afzonderlijke scripts binnen een Taproot-tak mogen willekeurig groot zijn.
• OP_SUCCESS-opcodes vormen de meest vooruitstrevende verandering. In het oude Script leidt het tegenkomen van een ongedefinieerde opcode ertoe dat het script mislukt. In Tapscript zorgen opcodes in het OP_SUCCESS-bereik ervoor dat het script onvoorwaardelijk slaagt. Toekomstige soft forks kunnen aan deze opcodes concreet gedrag toekennen door beperkingen toe te voegen aan de omstandigheden waaronder ze slagen, zonder dat daarvoor een nieuwe scriptversie of een volledige herimplementatiecyclus in het hele ecosysteem nodig is. Nieuwe mogelijkheden kunnen op een overzichtelijkere manier aan de scriptlaag van Bitcoin worden toegevoegd dan ooit tevoren in de geschiedenis van het protocol.

Miniscript

Naast Tapscript is een verwant project, Miniscript genaamd, steeds relevanter geworden voor ontwikkelaars. Miniscript is een gestructureerde manier om een subset van Bitcoin Script te schrijven die analyseerbaar, combineerbaar en generiek ondertekenbaar is. Waar onbewerkt Script handmatig moet worden opgebouwd en moeilijk te controleren is, kunnen Miniscript-scripts automatisch op juistheid worden geverifieerd en worden gecombineerd tot grotere beleidsregels. Het breidt de mogelijkheden van Script niet uit, maar maakt wat het al doet aanzienlijk toegankelijker voor ontwikkelaars die wallets en bewaartools bouwen.

Wat Bitcoin Script mogelijk maakt: praktijkvoorbeelden

De volgende transactietypen zijn momenteel actief op het Bitcoin-mainnet; ze zijn allemaal gebaseerd op Bitcoin Script-primitieven:

Portemonnees met meerdere handtekeningen (multisig) Er zijn M van de N privésleutels nodig om een uitgave te autoriseren. De financiële afdeling van een bedrijf kan bijvoorbeeld 3 van de 5 goedkeuringen vereisen voor elke opname. Een echtpaar kan 2 van de 2 gebruiken voor een gezamenlijke spaarrekening. Dankzij Taproot en Schnorr-sleutelaggregatie zijn gezamenlijke multisig-uitgaven nu op de blockchain niet meer te onderscheiden van standaardtransacties met één handtekening.

Transacties met tijdslot Gebruik OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, of CLTV) en OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, of CSV) om te voorkomen dat middelen worden overgedragen voordat een bepaalde blokhoogte is bereikt of een bepaalde tijd is verstreken. Toepassingen zijn onder meer successieplanning, toekenningsschema’s voor werknemers-tokens, mechanismen voor gedwongen sparen en transacties met boetes die binnen Lightning Network-kanalen worden gebruikt.

Hash Time-Locked Contracts (HTLC's) een vereiste voor het prebeeld van een hash combineren met een tijdslot. De uitgiftevoorwaarde werkt als volgt: het prebeeld van deze hash moet vóór deze blokhoogte worden onthuld, anders gaan de middelen terug naar de afzender. HTLC’s vormen de kern van het Lightning Network en maken het mogelijk om op een vertrouwensloze manier betalingen te routeren via ketens van kanalen tussen partijen die geen directe relatie met elkaar hebben.

Escrow Bij dergelijke regelingen worden middelen vastgezet in een P2SH- of Taproot-script, waarbij de vrijgave pas plaatsvindt na instemming van meerdere partijen; doorgaans beschikt een externe bemiddelaar over een beslissende sleutel.

Discrete Log-contracten (DLC’s) Gebruik op oracles gebaseerde Schnorr-adapterhandtekeningen om financiële contracten mogelijk te maken die worden afgewikkeld op basis van realtime gegevens, zoals prijsfeeds of uitkomsten van gebeurtenissen, zonder dat het oracle geld in bewaring hoeft te nemen. DLC’s zijn live op het Bitcoin-mainnet en worden gebruikt voor op Bitcoin afgewikkelde opties en termijncontracten.

Bitcoin-script versus Ethereum-smart contracts

Zowel Bitcoin Script als Solidity van Ethereum leggen voorwaarden vast waaronder geld kan worden overgedragen, maar ze vertegenwoordigen fundamenteel verschillende architecturale keuzes. Het loont de moeite om deze vergelijking direct te maken, omdat de verschillen veel verklaren over de afwegingen die elk netwerk heeft gemaakt.

De fundamentele scheidslijn is de aanwezigheid van statefulness. Ethereum-contracten slaan gegevens op en wijzigen deze, waarbij deze gegevens tussen transacties door behouden blijven. Dit maakt kredietprotocollen, gedecentraliseerde beurzen, on-chain governance en tokenstandaarden mogelijk. Bitcoin Script kent hier geen equivalent voor. Elk script draait in een vacuüm, zonder kennis van enige andere transactie.

Dit is een bewuste architecturale keuze, geen leemte die nog moet worden opgevuld. De scriptinglaag van Bitcoin is ontworpen voor één specifieke taak: het op voorspelbare en veilige wijze, op grote schaal, afdwingen van de voorwaarden voor het uitgeven van bitcoin. Voor die taak is het ontbreken van een status een sterkte. Het aanvalsoppervlak is kleiner, de uitvoering is deterministisch bij miljoenen onafhankelijke validators, en er bestaat geen categorie van smart contract-exploits op protocolniveau, omdat er op protocolniveau geen statusgebonden contracten zijn.

Projecten die meer programmeerbaarheid bovenop Bitcoin willen, bouwen dit in lagen op. Het Lightning Network verwerkt betalingen. DLC-protocollen verwerken financiële contracten die verwijzen naar externe gegevens. Layer-2-systemen zoals Ark en het Liquid Network richten zich op verschillende schaalbaarheidsprofielen. Hiervoor hoeft het scriptmodel van de basislaag niet te worden aangepast.

Het debat over het convenant: wat zou er kunnen veranderen in Bitcoin Script

De ontwikkeling van Bitcoin Script is altijd traag en conservatief verlopen. Het meest actieve ontwikkelingsgebied op dit moment betreft de zogenaamde ‘covenant’-opcodes: dit zijn voorstellen waarmee een script niet alleen kan bepalen wie een output mag besteden, maar ook hoe de daaruit voortvloeiende transactie eruit moet zien. Dit betekent een aanzienlijke uitbreiding van de expressieve mogelijkheden van Script.

De belangrijkste voorstellen per juni 2026 zijn:

• OP_CTV (BIP-119, CheckTemplateVerify), geschreven door Jeremy Rubin, voegt één enkele opcode toe die een UTXO vastlegt in een specifiek, vooraf bepaald bestedingssjabloon, inclusief de versie van de transactie, de locktime, het aantal inputs, de sequenties, het aantal outputs en de outputs. Het is per ontwerp niet-recursief, wordt beschouwd als het meest conservatieve grote voorstel en richt zich voornamelijk op vaults, congestiebeheersing en bepaalde Lightning-verbeteringen. Vanaf april 2026 liggen er concrete implementatieparameters voor OP_CTV op tafel waarin een ‘Speedy Trial’-signaleringsvenster wordt gespecificeerd, maar de brede consensus binnen de gemeenschap die nodig is voor activering is nog niet bereikt, volgens Analyse van de convenanten van BlockEden voor april 2026.
• OP_CAT (BIP-347), voorgesteld door Ethan Heilman en Armin Sabouri, zou een opcode opnieuw inschakelen die Satoshi in 2010 had uitgeschakeld. OP_CAT voegt twee stack-items samen, wat eenvoudig klinkt maar verstrekkende gevolgen heeft. In combinatie met Schnorr-handtekeningen maakt het een ‘covenant’-achtige transactie-introspectie mogelijk. Op het Bitcoin Signet-testnetwerk had OP_CAT aanzienlijk meer transacties van ontwikkelaars gegenereerd dan zowel APO als CTV, volgens de on-chain-analyse van sCrypt uit eind 2024. OP_CAT is al actief op het Liquid Network en Fractal Bitcoin, zonder dat er misbruik aan is toegeschreven. BIP-347 heeft een officieel voorstelnummer en er wordt actief onderzoek naar gedaan, maar voor activering op het mainnet is consensus binnen de gemeenschap nodig, die nog niet bestaat.
• LNHANCE combineert OP_CTV met OP_CHECKSIGFROMSTACK (CSFS) en OP_INTERNALKEY, met het oog op specifieke verbeteringen in de opbouw van Lightning Network-kanalen, waaronder het openen van niet-interactieve kanalen en een efficiënter beheer van kanalen met meerdere partijen.

In juni 2026 was nog geen van deze functies op het Bitcoin-mainnet geactiveerd. De technische meningsverschillen tussen beide partijen zijn grotendeels oplosbaar. Het moeilijkere probleem betreft de activeringsmechanismen. Het soft fork-proces van Bitcoin vereist brede consensus, en het debat over het convenant draagt nog steeds de spanning met zich mee van eerdere omstreden upgrades. Wat uit het debat duidelijk naar voren komt, is dat de scriptinglaag van Bitcoin binnen zijn conservatieve kader aanzienlijke ruimte heeft om te groeien. De vraag waar momenteel aan wordt gewerkt, betreft de volgorde van de stappen en de overeenstemming binnen de gemeenschap, niet of de scripttaal een toekomst heeft.

Conclusie

Bitcoin Script is de onzichtbare infrastructuur die ten grondslag ligt aan elke transactie op het netwerk. De meeste gebruikers komen er nooit rechtstreeks mee in aanraking. Wallets stellen geldige scripts samen, ondertekenen ze en verzenden ze zonder dat de onderliggende werking ooit zichtbaar wordt. Maar elke betaling, elk Lightning-kanaal, elk tijdgebonden plan en elke multisig-kluis maakt gebruik van dezelfde op een stack gebaseerde Bitcoin-scripttaal die in 2009 bij het protocol werd geleverd.

De scriptinglaag is sindsdien aanzienlijk gegroeid: P2SH heeft complexe uitgaven praktisch haalbaar gemaakt, SegWit heeft de transactiekosten verlaagd en Lightning mogelijk gemaakt, en Taproot heeft Schnorr-handtekeningen, op MAST gebaseerde privacy en het toekomstbestendige opcode-ontwerp van Tapscript geïntroduceerd. De covenant-voorstellen die momenteel actief worden besproken, vormen het volgende potentiële hoofdstuk. Of deze daadwerkelijk in werking zullen treden, en binnen welk tijdsbestek, is medio 2026 nog volstrekt onzeker.

Om Script te begrijpen hoef je geen ontwikkelaar te zijn. Je moet wel inzien dat het conservatisme van Bitcoin, de opzettelijke beperkingen, het trage tempo van upgrades en het feit dat het niet Turing-volledig is, geen tekortkomingen zijn. De eigenschappen die Bitcoin Script voorspelbaar maken, zijn precies dezelfde eigenschappen die de consensuslaag al zestien jaar lang zuiver hebben gehouden.