Hvad er Bitcoin-scriptsproget?

Bitcoin Script er det programmeringssprog, der styrer alle transaktioner på Bitcoin-netværket. Det er et enkelt, stakbaseret sprog, der definerer de nøjagtige betingelser, under hvilke bitcoin kan bruges, og hver eneste fuld node på netværket kører det, hver gang en transaktion valideres. Uden det ville Bitcoin blot være en bogføring med tal uden nogen mekanisme til at fastslå, hvem der ejer hvad.

De fleste brugere kommer aldrig i direkte kontakt med Bitcoins scriptsprog. Deres tegnebøger håndterer det i det skjulte. Men hver gang du sender eller modtager BTC, kører to små programmer samtidigt på tusindvis af computere, hvor de kontrollerer, om betingelserne for transaktionen er opfyldt. At forstå, hvordan det fungerer, forklarer i høj grad, hvorfor Bitcoin er opbygget, som den er, og hvad den kan og ikke kan i forhold til platforme som Ethereum.

Denne artikel beskriver, hvordan Bitcoin Script fungerer, gennemgår de vigtigste transaktionstyper, som det muliggør, forklarer Taproot-opgraderingen, der moderniserede scriptlaget i 2021, og redegør for, hvor debatten om »covenant«-opkoden står pr. juni 2026.

Administrer dine Bitcoin sikkert med selvopbevaring Bitcoin.com Wallet-appen.

De vigtigste pointer

• Bitcoin Script er et stakbaseret programmeringssprog, der er indbygget i Bitcoin-protokollen, og som definerer de betingelser, under hvilke en bitcoin-output kan bruges.
• Hver Bitcoin-transaktion indeholder to scripts: et låsescript (ScriptPubKey), der fastsættes af modtageren, og et oplåsningsscript (ScriptSig), der leveres af afsenderen. Begge skal udføres korrekt, for at en transaktion er gyldig.
• Bitcoin Script er bevidst ikke Turing-komplet. Det har ingen sløjfer, ingen vedvarende tilstand mellem kørslerne og strenge begrænsninger på scriptets størrelse. Dette sikrer, at hvert script garanteret afsluttes, hvilket er en sikkerhedsfunktion, ikke en begrænsning.
• Skriptsproget har gennemgået fem større udviklingsfaser: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) og Taproot (P2TR), hvor hver fase har udvidet mulighederne, samtidig med at den har bevaret bagudkompatibiliteten.
• Taproot (november 2021) introducerede Schnorr-signaturer, MAST-baserede udgiftsstier for at sikre privatlivets fred samt Tapscript som et opdateret scriptsprog med en indbygget mekanisme, der muliggør mere smidige opgraderinger i fremtiden.
• Eksempler på anvendelser i praksis, der bygger på Bitcoin Script, omfatter tegnebøger med flersignatur, tidslåste transaktioner, Hash Time-Locked Contracts (grundlaget for Lightning), escrow og Discreet Log Contracts.
• I modsætning til Ethereums smartkontrakter er Bitcoin Script stateless: hvert script kører fuldstændig isoleret uden kendskab til andre transaktioner. Dette er et bevidst arkitektonisk valg.
• Det mest aktive område inden for udviklingen af Bitcoin Script i 2026 er covenant-opkoder, især OP_CTV (BIP-119) og OP_CAT (BIP-347), som vil gøre det muligt for scripts at fastlægge, hvordan en udbetalingstransaktion skal se ud. Ingen af dem er endnu blevet aktiveret på mainnet.

Hvad er Bitcoin Script?

Bitcoin Script er et stakbaseret, stateløst scriptsprog, der er indbygget i Bitcoin-protokollen. Hver transaktionsudgang på Bitcoin-netværket indeholder et låseskript (kaldet ScriptPubKey), der angiver betingelserne for at bruge midlerne. Enhver, der ønsker at bruge disse midler, skal fremlægge et oplåsningsskript (kaldet ScriptSig eller, i SegWit- og Taproot-transaktioner, vidnedataene), der opfylder disse betingelser.

Sproget er opbygget efter Forth, et minimalistisk, stakbaseret programmeringssprog, der blev udviklet i 1960’erne. Ligesom Forth læses Bitcoin Script fra venstre mod højre, opererer på en datastruktur kaldet en stak og bruger omvendt polsk notation (RPN), hvor operatorerne følger efter deres operander i stedet for at gå forud for dem. Det udfører én instruktion ad gangen, har ingen sløjfer og opbevarer ingen data mellem udførelserne.

Det sidste punkt er det, de fleste støder på først, når de sætter sig ind i Bitcoin Script på protokolniveau: Sproget er bevidst ikke Turing-komplet. Et Turing-komplet sprog kan udføre enhver beregning, hvis der er tilstrækkelig tid og ressourcer til rådighed. Bitcoin Script kan, som det er designet, ikke gøre det, og årsagerne til dette valg har stor betydning for, hvordan netværket fungerer.

Sådan fungerer Bitcoin Script: Stakmodellen

For at forstå, hvordan Bitcoin Script fungerer, skal man forstå, hvad en stak er. En stak er en datastruktur, der fungerer efter princippet »sidst ind, først ud« (LIFO). Forestil dig en stak tallerkener: Du kan kun lægge noget på eller tage noget af øverst. I Bitcoin Script skubbes data ind på stakken, og opkoder (operationskoder) manipulerer det, der ligger øverst.

Når en Bitcoin-node validerer en transaktion, kører den to scripts efter hinanden:

1. Låseopskriptet (ScriptSig eller vidne) leveret af den person, der bruger mønterne. Dette placerer data på stakken, typisk en digital signatur og en offentlig nøgle.
2. Låseskriptet (ScriptPubKey) knyttet til den udbetaling, der foretages. Den indeholder opkoder, der behandler stakdataene og kontrollerer, om betingelserne for udbetalingen er opfyldt.

Hvis scriptet kører uden fejl og efterlader en værdi forskellig fra nul (TRUE) på stakken til sidst, er transaktionen gyldig. Hvis det mislykkes eller efterlader FALSE, afvises transaktionen af noden og kommer aldrig med i en blok.

Denne udførelse er fuldstændig stateless. Scriptet har ingen viden om tidligere transaktioner, ingen kendskab til aktuelle saldi og ingen hukommelse, der bevares, når scriptet er færdig med at køre. Hvert script kører fra bunden, isoleret, hver gang.

Trin for trin: En standard P2PKH-transaktion

Pay-to-Public-Key-Hash (P2PKH) er den oprindelige Bitcoin-transaktionstype, der har været i brug siden 2009. P2PKH-adresser begynder med »1.« Sådan ser ScriptPubKey og ScriptSig ud i praksis:

Skript til oplåsning (ScriptSig):

<signatur> <offentlig nøgle>

Låseskript (ScriptPubKey):

OP_DUP OP_HASH160 <hash af offentlig nøgle> OP_EQUALVERIFY OP_CHECKSIG

Når noden sammenkæder og udfører begge dele samtidigt, foregår stakoperationerne trin for trin:

• Signaturen og den offentlige nøgle fra ScriptSig lægges på stakken
• OP_DUP kopierer den offentlige nøgle øverst i stakken
• OP_HASH160 beregner en hash for duplikatet (SHA-256 efterfulgt af RIPEMD-160), hvilket giver en hash på 20 byte
• Hashværdien for den offentlige nøgle fra låseskriptet lægges på stakken
• OP_EQUALVERIFY kontrollerer, om de to hashværdier stemmer overens. Hvis de ikke gør det, afbrydes udførelsen, og transaktionen mislykkes.
• OP_CHECKSIG kontrollerer, at signaturen er gyldig for den offentlige nøgle

Hvis alle trin gennemføres, afsluttes stakken med TRUE, og midlerne frigives. Hele processen tager millisekunder og forløber på nøjagtig samme måde på alle noder i netværket.

Bitcoin-opkoder forklaret

Bitcoin-opkoder er de enkelte kommandoer, der udgør et script. Hver opkode består af en enkelt byte, hvilket giver 256 mulige opkodepladser. Af disse er ca. 80 i øjeblikket aktive på mainnet. Resten er enten reserveret, deaktiveret eller tildelt OP_SUCCESS-mekanismen til fremadkompatibilitet, der blev introduceret med Tapscript.

Opkoder kan inddeles i flere kategorier:

• Opkoder til datapush placere værdier såsom offentlige nøgler, signaturer og hashværdier på stakken
• Aritmetiske opkoder udføre addition, subtraktion og sammenligninger. Det skal dog bemærkes, at multiplikation og division er deaktiveret.
• Kryptografiske opkoder herunder OP_SHA256, OP_HASH160 og OP_SHA1 til hashing samt OP_CHECKSIG til verifikation af signaturer
• Opkoder til strømningsstyring Aktiver betinget logik: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Opkoder til stakmanipulation herunder OP_DUP (duplikerer det øverste element), OP_DROP (fjerner det øverste element) og OP_SWAP (bytter om på de to øverste elementer)

Flere opkoder blev deaktiveret af Satoshi Nakamoto i 2010, efter at der var blevet opdaget sårbarheder i deres oprindelige implementeringer. Heriblandt OP_CAT (sammenkædning af to stakelementer), OP_MUL (multiplikation) og OP_DIV (division). Deres fravær har haft varige konsekvenser for, hvad Bitcoin Script kan udtrykke, og flere af de mest omdiskuterede forslag til opgradering af Bitcoin i 2026 drejer sig om, hvorvidt nogle af dem skal genaktiveres.

For den komplette oversigt over opkoder, herunder hex-værdier og beskrivelser, kan du finde den Siden »Bitcoin Wiki Script« er den autoritative kilde.

Hvorfor det at være ikke-Turing-komplet er en fordel

Den gængse forklaring er, at Bitcoin Script ikke har nogen sløjfer, så scripts garanteret afsluttes, og dermed er netværket beskyttet mod uendelig kørsel. Det er korrekt, men det underdriver pointen.

Det dybere argument handler om angrebsfladen. Et Turing-komplet sprog kan udtrykke vilkårlige beregninger. Netop denne udtrykskraft er også det område, hvor fejl opstår. Ethereums Solidity har været årsag til nogle af de dyreste softwaresårbarheder i historien. DAO-hacket i 2016 udnyttede en reentrancy-fejl i en smart kontrakt og forårsagede tab på omkring 60 millioner dollar til datidens priser, hvilket i sidste ende førte til en kontroversiel hard fork af Ethereum-netværket. Det bredere DeFi-økosystem har over flere år oplevet, at hundredvis af millioner af dollar er blevet drænet gennem udnyttelse af smart kontrakter.

Bitcoin Script gør denne type angreb strukturelt umulig. Man kan ikke skrive et Bitcoin-script, der kalder andre scripts, kører i en løkke, indtil en betingelse ændrer sig, eller gemmer tilstand mellem transaktioner. Hvert script er et afgrænset, afsluttet og inspicerbart program. Den maksimale scriptstørrelse er 10.000 byte. Det maksimale antal ikke-push-opkoder pr. script er 201. En validator kan altid beregne den værst tænkelige udførelsesomkostning, før scriptet køres.

For et netværk med en værdi på flere hundrede milliarder dollars er denne forudsigelighed mere værd end den fleksibilitet, man giver afkald på. Ethereum løser problemet med ubegrænset beregning ved hjælp af gasgrænser, hvor brugerne betaler for hver udført opkode, og hvor scripts, der løber tør for budget, stoppes. Det fungerer, men det medfører sin egen kompleksitet og sine egne fejlmuligheder. Bitcoin omgår problemet fuldstændigt ved sin udformning.

Når det er sagt, betyder »ikke Turing-komplet« ikke, at det »ikke er i stand til at håndtere kompleks logik«. Bitcoin Script understøtter krav om betaling med flere parter, tidsbaserede betingelser, afsløring af hash-præbilleder samt kombinationer af alle disse elementer. Lightning Network, som formidler millioner af betalinger om dagen, er udelukkende bygget på Bitcoin Script-primitiver.

Skripttyper: Udviklingen fra P2PKH til Taproot

Bitcoins scriptlag har udviklet sig betydeligt siden 2009, idet hver opgradering har indført et nyt transaktionsformat, samtidig med at den har været bagudkompatibel med alt, hvad der kom før.

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

Det oprindelige format, der blev brugt i de første Bitcoin-transaktioner, herunder Satoshis betaling til Hal Finney i blok 170. Midlerne blev låst direkte til en fuld offentlig nøgle i stedet for dens hash. Anvendes i dag sjældent i nye transaktioner, da det afslører den offentlige nøgle på blockchainen, før beløbet bruges, hvilket anses for at være en svagere sikkerhedsløsning end først at hashe nøglen.

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

Standardformatet i mere end et årti. P2PKH binder midlerne til en hash af den offentlige nøgle i stedet for selve nøglen, hvilket holder den offentlige nøgle hemmelig indtil det øjeblik, hvor midlerne bruges, hvilket resulterer i en kortere adresse på 20 byte og danner grundlaget for alle adresser, der begynder med »1«. Ifølge on-chain-data fra Unchained (april 2026) rummer P2PKH-adresser i øjeblikket ca. 43 % af den udvundne bitcoin-forsyning.

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

P2SH, der blev indført via en soft fork den 1. april 2012, flyttede byrden ved komplekse udbetalingsscripts fra afsenderen til modtageren. I stedet for at indlejre et fuldt låsescript i outputtet, genererer P2SH-outputtet en 20-byte hash af et »redeem script«. Det fulde script afsløres først, når mønterne bruges. Dette gjorde multisig praktisk for almindelige brugere: En 2-ud-af-3-multisig-opsætning krævede ikke længere, at alle tre offentlige nøgler var synlige for afsenderen på betalingstidspunktet. P2SH-adresser starter med »3.«

For en detaljeret beskrivelse af, hvordan P2SH-validering fungerer på protokolniveau, Vejledning i transaktioner på developer.bitcoin.org gennemgår »redeem script«-mekanismen trin for trin.

P2WPKH og P2WSH (indbygget SegWit, 2017, BIP 141)

Segregated Witness, der blev aktiveret i august 2017 ved blok 481.824, flyttede signaturdataene ud af transaktionens hoveddel og over i en separat »witness«-struktur. »Witness«-dataene får en vægtrabat på 75 %, hvilket gør SegWit-transaktioner betydeligt billigere. En standard P2WPKH-transaktion med én indgang og to udgange vejer ca. 141 virtuelle byte, sammenlignet med 226 vbyte for den tilsvarende P2PKH-transaktion, ifølge Spark's analyse af typer af Bitcoin-adresser fra marts 2026. SegWit løste også problemet med transaktionsmanipulation, hvilket var en forudsætning for Lightning Network. Indbyggede SegWit-adresser begynder med »bc1q.«

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

Taproot blev aktiveret i november 2021 ved blok 709.632 og er den mest betydningsfulde opgradering af Bitcoins scriptlag siden SegWit. Den introducerede Schnorr-signaturer, en ny output-type med MAST-understøttelse samt Tapscript som et opdateret script-sprog. Taproot-adresser starter med "bc1p."

Taproot og Tapscript: Hvordan Bitcoins script-sprog ændrede sig i 2021

Taproot er ikke en enkelt ændring. Det er tre Bitcoin Improvement Proposals, der er udformet i fællesskab og aktiveret samtidigt.

BIP 340: Schnorr-signaturer

Bitcoin anvendte oprindeligt ECDSA (Elliptic Curve Digital Signature Algorithm). Satoshi valgte denne algoritme blandt andet, fordi Schnorr-signaturer på det tidspunkt var patentbeskyttet. Det pågældende patent udløb i 2008, og Taproot indførte endelig Schnorr i protokollen.

Schnorr-signaturer er mindre, nemlig 64 byte, sammenlignet med 71–73 byte for ECDSA. Endnu vigtigere er det, at de understøtter nøgleaggregering via en ordning kaldet MuSig2. Nøgleaggregering gør det muligt for flere underskrivere at kombinere deres individuelle nøgler og signaturer til en enkelt samlet nøgle og signatur, der på blockchainen ikke kan skelnes fra en almindelig betaling med en enkelt signatur. En 2-ud-af-3 multisig-tegnebog, der foretager udbetalinger via Taproots kooperative nøglevej, ser identisk ud med en standardbetaling på blockchainen. Det er en reel forbedring af privatlivets fred for alle, der opbevarer bitcoin i en kompleks depotordning.

BIP 341: Pay-to-Taproot og MAST

P2TR introducerer en ny udgangstype med to udgiftsveje:

• A nøglevej betale ved hjælp af en Schnorr-signatur, som anvendes, når alle parter er enige og ønsker den enkleste og billigste løsning
• A skriptsti anvende MAST (Merkelized Abstract Syntax Tree, som er Taproot-implementeringen af konceptet)

MAST gør det muligt for en enkelt output at blive knyttet til et træ bestående af flere udgiftsskripter via en Merkle-rod. Ved udbetaling afsløres kun den specifikke betingelse, der rent faktisk anvendes, på blockchainen. Alle andre mulige udgiftsveje i træet forbliver permanent skjulte. For en bruger, der har konfigureret en kompleks udgiftspolitik, f.eks. »Jeg kan bruge midlerne normalt, eller to ud af tre forvaltere kan bruge dem efter seks måneder, eller en gendannelsesnøgle kan bruge dem efter to år«, vises kun den vej, der rent faktisk udføres, på blockchainen.

I 2024 var Taproots andel af Bitcoin-transaktionerne steget til omkring 42 %, hvilket ifølge data fra Glassnode, som Spark citerede i marts 2026, i høj grad skyldtes aktiviteten omkring Ordinals og BRC-20-inskriptioner. Andelen har siden svinget i takt med markedsforholdene, men infrastrukturen er nu standard i de største tegnebøger og børser. Bitcoin Optechs temaside om Taproot følger den løbende udvikling af protokollen omkring Taproot.

BIP 342: Tapscript

Tapscript er det opdaterede scriptsprog, der anvendes til script-path-udgifter inden for Taproot. Det deler de fleste opkoder med det gamle Bitcoin Script, men indeholder en række væsentlige ændringer:

• OP_CHECKMULTISIG og OP_CHECKMULTISIGVERIFY er udfaset. Den gamle multisig-opkode havde en særhed, der krævede, at man som en midlertidig løsning skulle skubbe et dummy-element ind på stakken. Tapscript fjerner denne og erstatter den med OP_CHECKSIGADD, som verificerer Schnorr-signaturer én ad gangen og tæller dem sammen. Multisig-ordninger med tærskelværdier bliver enklere og billigere at gennemføre.
• Begrænsningerne på scriptstørrelsen pr. MAST-blad er fjernet. De enkelte scripts inden for en Taproot-gren kan være vilkårligt store.
• OP_SUCCESS-opkoder er den mest fremtidsrettede ændring. I det gamle Script-sprog medfører en udefineret opkode, at scriptet fejler. I Tapscript sikrer opkoder i OP_SUCCESS-intervallet, at scriptet udføres uden betingelser. Fremtidige soft forks kan tildele disse opkoder reelle funktioner ved at indføre begrænsninger for, hvornår de skal lykkes, uden at det kræver en ny scriptversion eller en fuldstændig genimplementeringscyklus på tværs af økosystemet. Nye funktioner kan tilføjes til Bitcoins scriptlag på en mere overskuelig måde end nogensinde før i protokollens historie.

Miniscript

Sideløbende med Tapscript er et beslægtet projekt ved navn Miniscript blevet stadig mere relevant for udviklere. Miniscript er en struktureret måde at skrive en delmængde af Bitcoin Script på, som kan analyseres, sammensættes og underskrives generisk. Hvor rå Script kræver manuel opbygning og er vanskeligt at revidere, kan Miniscript-scripts automatisk verificeres for korrekthed og kombineres til større politikker. Det udvider ikke Scriptets funktionalitet, men gør det, som det allerede kan, betydeligt mere tilgængeligt for udviklere, der bygger tegnebøger og opbevaringsværktøjer.

Hvad Bitcoin Script muliggør: Anvendelseseksempler fra den virkelige verden

Følgende transaktionstyper er i dag aktive på Bitcoins mainnet, og de er alle baseret på Bitcoin Script-primitiver:

Multisignatur-tegnebøger (multisig) kræver M ud af N private nøgler for at godkende en udbetaling. En virksomheds finansafdeling kan kræve 3 ud af 5 godkendelser for enhver udbetaling. Et ægtepar kan bruge 2 ud af 2 til fælles opsparing. Med Taproot og Schnorr-nøgleaggregering kan samarbejdsbaserede multisig-udbetalinger nu på blockchainen ikke skelnes fra standardtransaktioner med en enkelt signatur.

Tidslåste transaktioner Brug OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, eller CLTV) og OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, eller CSV) for at forhindre, at midler overføres før en bestemt blokhøjde eller en bestemt tidsperiode er udløbet. Anvendelsesområderne omfatter arveplanlægning, tidsplaner for medarbejderes optjening af tokens, mekanismer til tvungen opsparing samt transaktioner med strafgebyrer, der anvendes inden for Lightning Network-kanaler.

Hash-baserede tidslåste kontrakter (HTLC’er) kombinerer et krav om hash-præbillede med en tidslås. Betingelsen for udbetaling fungerer således: præbilledet af denne hash skal afsløres inden denne blokhøjde, ellers returneres midlerne til afsenderen. HTLC’er udgør kernen i Lightning Network og muliggør tillidsfri betalingsruting på tværs af kanalkæder mellem parter, der ikke har noget direkte forhold til hinanden.

Depotkonto Disse ordninger låser midlerne i et P2SH- eller Taproot-script, hvor frigivelsen kræver enighed blandt flere parter, typisk med en tredjepartsmægler, der besidder en afgørende nøgle.

Diskrete logkontrakter (DLC’er) Brug af orakelbaserede Schnorr-adapter-signaturer gør det muligt at afregne finansielle kontrakter på baggrund af data fra den virkelige verden, såsom prisdata eller udfald af begivenheder, uden at oraklet behøver at opbevare midler. DLC’er er i drift på Bitcoin-mainnet og anvendes til options- og futures-produkter, der afregnes i Bitcoin.

Bitcoin-script kontra Ethereums smarte kontrakter

Både Bitcoin Script og Ethereums Solidity definerer betingelser for, hvornår midler kan overføres, men de repræsenterer fundamentalt forskellige arkitektoniske valg. Det er værd at foretage en direkte sammenligning, da forskellene forklarer meget om de afvejninger, hvert netværk har accepteret.

Den grundlæggende skillelinje er »statefulness«. Ethereum-kontrakter gemmer og ændrer data, der bevares på tværs af transaktioner, hvilket muliggør udlånsprotokoller, decentraliserede børser, on-chain-styring og tokenstandarder. Bitcoin Script har intet tilsvarende. Hvert script kører i et vakuum uden kendskab til andre transaktioner.

Dette er et bevidst arkitektonisk valg, ikke et hul, der bare venter på at blive udfyldt. Bitcoins scriptlag blev udviklet til én specifik opgave: at håndhæve betingelserne for at bruge bitcoin på en forudsigelig og sikker måde i stor skala. I den sammenhæng er statelessness en styrke. Angrebsfladen er mindre, udførelsen er deterministisk på tværs af millioner af uafhængige validatorer, og der findes ingen kategori af smart contract-udnyttelser på protokolniveau, da der ikke findes stateful kontrakter på dette niveau.

Projekter, der ønsker større programmerbarhed oven på Bitcoin, opbygger det i lag. Lightning Network håndterer betalinger. DLC-protokoller håndterer finansielle kontrakter, der henviser til eksterne data. Layer-2-systemer som Ark og Liquid Network imødekommer forskellige skalerbarhedsprofil. Intet af dette kræver ændringer af scriptmodellen i basislaget.

Debatten om »The Covenant«: Hvad kan der ændre sig i Bitcoin Script?

Udviklingen af Bitcoin Script har altid været langsom og konservativ. Det mest aktive udviklingsområde lige nu er »covenant opcodes«, som er forslag, der vil gøre det muligt for et script ikke blot at begrænse, hvem der kan bruge en output, men også hvordan den resulterende transaktion skal se ud. Dette er en betydelig udvidelse af Scripts udtryksmuligheder.

De vigtigste forslag pr. juni 2026 er:

• OP_CTV (BIP-119, CheckTemplateVerify), skrevet af Jeremy Rubin, tilføjer en enkelt opkode, der binder en UTXO til en bestemt, forudbestemt udgiftsskabelon, herunder transaktionens version, locktime, antal input, sekvenser, antal output og output. Det er ikke-rekursivt af design, betragtes som det mest konservative større forslag og er primært rettet mod vaults, overbelastningskontrol og visse Lightning-forbedringer. Pr. april 2026 er der konkrete implementeringsparametre på bordet for OP_CTV, der specificerer et »Speedy Trial«-signalvindue, men der er endnu ikke opnået den brede konsensus i communityet, der kræves for aktivering, ifølge BlockEdens analyse af lånebetingelserne fra april 2026.
• OP_CAT (BIP-347), foreslået af Ethan Heilman og Armin Sabouri, vil genaktivere en opkode, som Satoshi deaktiverede i 2010. OP_CAT sammenkæder to stakelementer, hvilket er enkelt at beskrive, men har vidtrækkende konsekvenser. Når det kombineres med Schnorr-signaturer, muliggør det en »covenant«-lignende transaktionsanalyse. På Bitcoin-testnetværket Signet havde OP_CAT genereret betydeligt flere udviklertransaktioner end hverken APO eller CTV, ifølge sCrypts on-chain-analyse fra slutningen af 2024. OP_CAT er allerede aktivt på Liquid Network og Fractal Bitcoin uden at der er rapporteret om sikkerhedsbrud i forbindelse med det. BIP-347 har et officielt forslagsnummer og aktiv forskning bag sig, men aktivering på mainnet kræver en konsensus i fællesskabet, som endnu ikke findes.
• LNHANCE kombinerer OP_CTV med OP_CHECKSIGFROMSTACK (CSFS) og OP_INTERNALKEY med henblik på specifikke forbedringer af oprettelsen af kanaler i Lightning Network, herunder ikke-interaktive kanalåbninger og mere effektiv administration af kanaler med flere parter.

Ingen af disse er blevet aktiveret på Bitcoins mainnet pr. juni 2026. De tekniske uenigheder mellem dem kan i vid udstrækning løses. Det sværere problem er selve aktiveringsmekanismen. Bitcoins soft fork-proces kræver bred enighed, og debatten om aftalen er præget af en resterende spænding fra tidligere omstridte opgraderinger. Det fremgår klart af debatten, at Bitcoins scriptlag har betydeligt potentiale for vækst inden for dets konservative rammer. Det spørgsmål, der arbejdes med, er rækkefølgen og enighed i fællesskabet, ikke om scriptsproget har en fremtid.

Konklusion

Bitcoin Script er den usynlige infrastruktur, der ligger til grund for hver eneste transaktion på netværket. De fleste brugere kommer aldrig i direkte kontakt med det. Wallets opretter gyldige scripts, underskriver dem og sender dem ud uden nogensinde at afsløre mekanismen bag. Men hver eneste betaling, hver eneste Lightning-kanal, hver eneste tidslåst plan og hvert eneste multisig-boks kører gennem det samme stakbaserede Bitcoin-scriptsprog, der fulgte med protokollen i 2009.

Scripting-laget er vokset betydeligt siden da, idet P2SH har gjort komplekse transaktioner praktisk gennemførlige, SegWit har sænket gebyrerne og muliggjort Lightning, og Taproot har indført Schnorr-signaturer, MAST-baseret privatlivsbeskyttelse samt Tapscripts fremadkompatible opcode-design. De covenant-forslag, der nu er genstand for aktiv diskussion, udgør det næste potentielle kapitel. Om nogen af dem bliver aktiveret, og hvornår det i så fald vil ske, er stadig helt åbent her i midten af 2026.

Man behøver ikke at være udvikler for at forstå Script. Man skal dog erkende, at Bitcoins konservatisme, de bevidste begrænsninger, det langsomme opgraderingsforløb og den manglende Turing-fuldstændighed ikke er en mangel. De egenskaber, der gør Bitcoin Script forudsigeligt, er de samme egenskaber, der har holdt konsensuslaget rent i seksten år.