Hva er skriptspråket Bitcoin?

Bitcoin Script er programmeringsspråket som styrer alle transaksjoner i Bitcoin-nettverket. Det er et enkelt, stakkbasert språk som definerer de nøyaktige betingelsene for når bitcoin kan brukes, og hver fullnode i nettverket kjører det hver gang en transaksjon valideres. Uten det ville Bitcoin vært en regnskapsbok full av tall uten noen mekanisme for å fastslå hvem som eier hva.

De fleste brukere kommer aldri i direkte kontakt med Bitcoin-skriptspråket. Lommebøkene deres håndterer det i det skjulte. Men hver gang du sender eller mottar BTC, kjører to små programmer på tusenvis av datamaskiner samtidig, og sjekker om betingelsene for utbetalingen er oppfylt. Å forstå hvordan dette fungerer forklarer mye om hvorfor Bitcoin er strukturert slik den er, og hva den kan og ikke kan gjøre sammenlignet med plattformer som Ethereum.

Denne artikkelen beskriver hvordan Bitcoin Script fungerer, gir en oversikt over de viktigste transaksjonstypene det muliggjør, forklarer Taproot-oppgraderingen som moderniserte skriptlaget i 2021, og gir en oppdatering på statusen i debatten om «covenant»-opkoden per juni 2026.

Forvalt Bitcoin-beholdningen din på en sikker måte med selvforvaltning Bitcoin.com Wallet-appen.

Hovedpunkter

• Bitcoin Script er et stakkbasert programmeringsspråk som er innebygd i Bitcoin-protokollen, og som definerer vilkårene for når en bitcoin-utgang kan brukes.
• Hver Bitcoin-transaksjon inneholder to skript: et låseskript (ScriptPubKey) som angis av mottakeren, og et opplåsingsskript (ScriptSig) som oppgis av den som utfører transaksjonen. Begge må gjennomføres uten feil for at transaksjonen skal være gyldig.
• Bitcoin Script er bevisst ikke Turing-komplett. Det har ingen løkker, ingen vedvarende tilstand mellom kjøringer og strenge begrensninger på skriptstørrelsen. Dette sikrer at hvert skript garantert avsluttes, noe som er en sikkerhetsfunksjon, ikke en begrensning.
• Skriptspråket har utviklet seg gjennom fem hovedformater: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) og Taproot (P2TR), og hvert av disse utvider mulighetene samtidig som de forblir bakoverkompatible.
• Taproot (november 2021) innførte Schnorr-signaturer, MAST-baserte utgiftsbaner for økt personvern og Tapscript som et oppdatert skriptspråk med en innebygd mekanisme for enklere oppgraderinger i fremtiden.
• Eksempler på praktisk bruk av Bitcoin Script omfatter lommebøker med flersignatur, tidslåste transaksjoner, Hash Time-Locked Contracts (grunnlaget for Lightning), deponeringstjenester og Discreet Log Contracts.
• I motsetning til Ethereums smarte kontrakter er Bitcoin Script tilstandsfritt: hvert skript kjører helt isolert, uten kjennskap til andre transaksjoner. Dette er et bevisst arkitektonisk valg.
• Det mest aktive området innen utviklingen av Bitcoin Script i 2026 er «covenant»-opkoder, særlig OP_CTV (BIP-119) og OP_CAT (BIP-347), som vil gjøre det mulig for skript å legge begrensninger på hvordan en utgiftstransaksjon må se ut. Ingen av disse er aktivert på hovednettet ennå.

Hva er Bitcoin Script?

Bitcoin Script er et stakkbasert, tilstandsfritt skriptspråk som er innebygd i Bitcoin-protokollen. Hver transaksjonsutgang i Bitcoin-nettverket inneholder et låseskript (kalt ScriptPubKey) som angir vilkårene for å bruke midlene. Alle som ønsker å bruke disse midlene, må oppgi et opplåsingsskript (kalt ScriptSig, eller i SegWit- og Taproot-transaksjoner, vitnedataene) som oppfyller disse vilkårene.

Språket har hentet sin struktur fra Forth, et minimalistisk, stakkbasert programmeringsspråk utviklet på 1960-tallet. I likhet med Forth leses Bitcoin Script fra venstre til høyre, opererer på en datastruktur kalt en stabel og bruker omvendt polsk notasjon (RPN), der operatorene følger etter operandene i stedet for å gå foran dem. Det utfører én instruksjon om gangen, har ingen løkker og lagrer ikke data mellom utførelser.

Det siste punktet er det de fleste støter på først når de setter seg inn i Bitcoin Script på protokollnivå: språket er bevisst ikke Turing-komplett. Et Turing-komplett språk kan utføre hvilken som helst beregning, gitt nok tid og ressurser. Bitcoin Script kan ikke det, slik det er utformet, og årsakene til dette valget har stor betydning for hvordan nettverket fungerer.

Slik fungerer Bitcoin Script: Stakkmodellen

For å forstå hvordan Bitcoin Script fungerer, må du forstå stakken. En stakk er en datastruktur som fungerer etter prinsippet «sist inn, først ut» (LIFO). Tenk deg en stabel med tallerkener: du kan bare legge til eller ta bort fra toppen. I Bitcoin Script blir data lagt inn i stakken, og opkoder (operasjonskoder) manipulerer det som ligger øverst.

Når en Bitcoin-node validerer en transaksjon, kjører den to skript etter hverandre:

1. Opplåsingsskriptet (ScriptSig eller vitne) oppgitt av den som bruker myntene. Dette legger data inn på stakken, vanligvis en digital signatur og en offentlig nøkkel.
2. Låseskriptet (ScriptPubKey) knyttet til utbetalingen. Denne inneholder operasjonskoder som behandler stakkdataene og kontrollerer om betingelsene for utbetalingen er oppfylt.

Hvis skriptet kjøres uten feil og etterlater en verdi som ikke er null (TRUE) på stakken til slutt, er transaksjonen gyldig. Hvis det mislykkes eller etterlater FALSE, blir transaksjonen avvist av noden og kommer aldri med i en blokk.

Denne utførelsen er fullstendig tilstandsfri. Skriptet har ingen kjennskap til tidligere transaksjoner, ingen oversikt over gjeldende saldoer og ingen informasjon som beholdes etter at skriptet er ferdig med å kjøre. Hvert skript kjører fra bunnen av, isolert, hver gang.

Trinn for trinn: En standard P2PKH-transaksjon

Pay-to-Public-Key-Hash (P2PKH) er den opprinnelige transaksjonstypen i Bitcoin, som har vært i bruk siden 2009. P2PKH-adresser begynner med «1.». Slik ser ScriptPubKey og ScriptSig ut i praksis:

Opplåsingsskript (ScriptSig):

<signatur> <offentlig nøkkel>

Låseskript (ScriptPubKey):

OP_DUP OP_HASH160 <hash av offentlig nøkkel> OP_EQUALVERIFY OP_CHECKSIG

Når noden sammenføyer og utfører begge deler samtidig, foregår stakkoperasjonene trinn for trinn:

• Signaturen og den offentlige nøkkelen fra ScriptSig legges inn i stakken
• OP_DUP kopierer den offentlige nøkkelen øverst i stakken
• OP_HASH160 beregner en hash for duplikatet (SHA-256 etterfulgt av RIPEMD-160), noe som gir en hash på 20 byte
• Hashverdien for den offentlige nøkkelen fra låseskriptet legges inn på stakken
• OP_EQUALVERIFY sjekker om de to hashverdiene stemmer overens. Hvis de ikke gjør det, stoppes utførelsen, og transaksjonen mislykkes.
• OP_CHECKSIG kontrollerer at signaturen er gyldig for den offentlige nøkkelen

Hvis alle trinnene gjennomføres, avsluttes stakken med TRUE, og midlene frigis. Hele prosessen tar millisekunder og gjennomføres på nøyaktig samme måte på hver eneste node i nettverket.

En forklaring på Bitcoin-opkoder

Bitcoin-opkoder er de enkelte kommandoene som utgjør et skript. Hver av dem består av én byte, noe som gir 256 mulige opkodespor. Av disse er omtrent 80 for øyeblikket aktive på hovednettet. Resten er enten reservert, deaktivert eller tildelt OP_SUCCESS-mekanismen for fremtidssikkerhet, som ble introdusert med Tapscript.

Opkoder kan deles inn i flere kategorier:

• Opkoder for datapush legge verdier som offentlige nøkler, signaturer og hashverdier inn på stakken
• Aritmetiske operasjonskoder utføre addisjon, subtraksjon og sammenligningsoperasjoner. Det er verdt å merke seg at multiplikasjon og divisjon er deaktivert.
• Kryptografiske operasjonskoder inkluderer OP_SHA256, OP_HASH160 og OP_SHA1 for hashing, samt OP_CHECKSIG for verifisering av signaturer
• Operasjonskoder for strømningskontroll aktivere betinget logikk: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Operasjonskoder for stakkmanipulering blant annet OP_DUP (dupliser det øverste elementet), OP_DROP (fjern det øverste elementet) og OP_SWAP (bytt om de to øverste elementene)

Flere opkoder ble deaktivert av Satoshi Nakamoto i 2010 etter at det ble oppdaget sårbarheter i de opprinnelige implementeringene. Blant disse er OP_CAT (sammenkobling av to stakkelementer), OP_MUL (multiplikasjon) og OP_DIV (divisjon). Deres fravær har hatt varige konsekvenser for hva Bitcoin Script kan uttrykke, og flere av de mest omdiskuterte forslagene til oppgradering av Bitcoin i 2026 dreier seg om hvorvidt noen av dem skal aktiveres på nytt.

For den fullstendige oversikten over operasjonskoder, inkludert heksadesimale verdier og beskrivelser, se Siden «Bitcoin Wiki Script» er den autoritative kilden.

Hvorfor det å ikke være Turing-komplett er en fordel

Den vanlige forklaringen er at Bitcoin Script ikke har noen løkker, slik at skriptene garantert avsluttes, og at nettverket dermed er beskyttet mot uendelig kjøring. Det er riktig, men det underdriver poenget.

Det underliggende argumentet handler om angrepsflaten. Et Turing-komplett språk kan uttrykke vilkårlige beregninger. Denne uttrykksevnen er også det rommet der feilene oppstår. Ethereums Solidity har ført til noen av de mest kostbare programvaresårbarhetene i historien. DAO-hacket i 2016 utnyttet en reentrancy-feil i en smartkontrakt og forårsaket tap på rundt 60 millioner dollar til datidens priser, noe som til slutt førte til en kontroversiell hard fork av Ethereum-nettverket. Det bredere DeFi-økosystemet har sett hundrevis av millioner dollar forsvinne gjennom utnyttelse av smartkontrakter over flere år.

Bitcoin-skript gjør denne typen angrep strukturelt umulig. Man kan ikke skrive et Bitcoin-skript som kaller andre skript, går i en løkke til en betingelse endres, eller lagrer tilstand mellom transaksjoner. Hvert skript er et avgrenset, avsluttbart og inspiserbart program. Maksimal skriptstørrelse er 10 000 byte. Maksimalt antall ikke-push-opkoder per skript er 201. En validator kan alltid beregne den verste mulige utførelseskostnaden før skriptet kjøres.

For et nettverk med en verdi på hundrevis av milliarder dollar er denne forutsigbarheten mer verdt enn den fleksibiliteten man må gi avkall på. Ethereum løser problemet med ubegrenset databehandling ved hjelp av gassgrenser, der brukerne belastes for hver utførte opkode og skript som går tom for budsjett stoppes. Det fungerer, men det medfører sin egen kompleksitet og egne feilmuligheter. Bitcoin omgår problemet fullstendig gjennom sin utforming.

Når det er sagt, betyr «ikke Turing-komplett» ikke «ikke i stand til å håndtere kompleks logikk». Bitcoin Script støtter krav til utbetalinger med flere parter, tidsbaserte betingelser, avsløring av hash-prebilder og kombinasjoner av alle disse. Lightning Network, som håndterer millioner av betalinger hver dag, er fullstendig bygget på Bitcoin Script-primitiver.

Skripttyper: Utviklingen fra P2PKH til Taproot

Bitcoins skriptlag har utviklet seg betydelig siden 2009, og hver oppgradering har innført et nytt transaksjonsformat samtidig som den har vært bakoverkompatibel med alt som har kommet før.

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

Det opprinnelige formatet, som ble brukt i de første Bitcoin-transaksjonene, blant annet Satoshis betaling til Hal Finney i blokk 170. Midlene ble låst direkte til en full offentlig nøkkel i stedet for dens hash. Dette brukes sjelden i nye transaksjoner i dag, fordi det eksponerer den offentlige nøkkelen på blokkjeden før utbetalingen, noe som anses som en svakere sikkerhetsløsning enn å hashe nøkkelen først.

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

Standardformatet i mer enn et tiår. P2PKH låser midlene til en hash av den offentlige nøkkelen i stedet for selve nøkkelen, noe som holder den offentlige nøkkelen privat helt frem til det øyeblikket midlene brukes, gir en kortere adresse på 20 byte og danner grunnlaget for alle adresser som begynner med «1». Ifølge on-chain-data fra Unchained (april 2026) inneholder P2PKH-adresser for tiden omtrent 43 % av den utvunnede bitcoin-beholdningen.

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

P2SH ble innført via en soft fork 1. april 2012 og flyttet byrden ved komplekse utbetalingsskript fra avsenderen til mottakeren. I stedet for å legge inn et fullstendig låseskript i utgangen, sender P2SH-utgangen en forpliktelse til en 20-byte hash av et «innløsningsskript». Det fullstendige skriptet avsløres først når myntene brukes. Dette gjorde multisig praktisk for vanlige brukere: et 2-av-3-multisig-oppsett krevde ikke lenger at alle tre offentlige nøkler var synlige for avsenderen ved betalingstidspunktet. P2SH-adresser begynner med «3».

For en detaljert beskrivelse av hvordan P2SH-validering fungerer på protokollnivå, Veiledning til transaksjoner på developer.bitcoin.org går trinn for trinn gjennom hvordan «redeem script»-mekanismen fungerer.

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

Segregated Witness, som ble aktivert i august 2017 ved blokk 481 824, flyttet signaturdataene ut av selve transaksjonskroppen og inn i en egen «witness»-struktur. Witness-dataene får en vektreduksjon på 75 %, noe som gjør SegWit-transaksjoner betydelig billigere. En standard P2WPKH-transaksjon med én inngang og to utganger veier omtrent 141 virtuelle byte, sammenlignet med 226 vbyte for en tilsvarende P2PKH-transaksjon, ifølge Spark sin analyse av typer Bitcoin-adresser fra mars 2026. SegWit løste også problemet med transaksjoners formbarhet, noe som var en forutsetning for Lightning Network. Innfødte SegWit-adresser begynner med «bc1q.».

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

Taproot ble aktivert i november 2021 ved blokk 709 632 og er den viktigste oppgraderingen av Bitcoins skriptlag siden SegWit. Oppgraderingen innførte Schnorr-signaturer, en ny utdatatype med MAST-støtte og Tapscript som et oppdatert skriptspråk. Taproot-adresser begynner med «bc1p.».

Taproot og Tapscript: Hvordan Bitcoin-skriptspråket endret seg i 2021

Taproot er ikke én enkelt endring. Det er tre Bitcoin Improvement Proposals som er utformet i fellesskap og aktiveres samtidig.

BIP 340: Schnorr-signaturer

Bitcoin brukte opprinnelig ECDSA (Elliptic Curve Digital Signature Algorithm). Satoshi valgte denne algoritmen delvis fordi Schnorr-signaturer var patentbeskyttet på den tiden. Det patentet utløp i 2008, og Taproot innførte endelig Schnorr i protokollen.

Schnorr-signaturer er mindre, med 64 byte, sammenlignet med 71–73 byte for ECDSA. Enda viktigere er det at de støtter nøkkelaggregering gjennom en ordning kalt MuSig2. Nøkkelaggregering gjør det mulig for flere signatører å kombinere sine individuelle nøkler og signaturer til én samlet nøkkel og signatur som på blokkjeden ikke kan skilles fra en vanlig betaling med én signatur. En 2-av-3-multisig-lommebok som bruker Taproots samarbeidsbaserte nøkkelbane, ser identisk ut som en standardbetaling på blokkjeden. Dette er en reell forbedring av personvernet for alle som oppbevarer bitcoin i et komplekst forvaringsarrangement.

BIP 341: Pay-to-Taproot og MAST

P2TR introduserer en ny utgangstype med to utgiftsveier:

• A nøkkelbane gjennomføre transaksjonen ved hjelp av en Schnorr-signatur, som brukes når alle parter er enige og ønsker den enkleste og billigste løsningen
• A skriptbane bruke MAST (Merkelized Abstract Syntax Tree, som er Taproot-implementeringen av konseptet)

MAST gjør det mulig for en enkelt utbetaling å knyttes til et tre av flere utbetalingsskript via en Merkle-rot. Ved utbetaling er det kun den spesifikke betingelsen som faktisk brukes, som blir synlig på blokkjeden. Alle andre mulige utbetalingsveier i treet forblir permanent skjult. For en bruker som har konfigurert en kompleks utgiftspolicy, for eksempel «Jeg kan bruke midlene normalt, eller to av tre forvaltere kan bruke midlene etter seks måneder, eller en gjenopprettingsnøkkel kan bruke midlene etter to år», vises kun den banen som faktisk utføres på blokkjeden.

I 2024 hadde Taproots andel av Bitcoin-transaksjonene vokst til rundt 42 %, hovedsakelig drevet av Ordinals og BRC-20-innskrivningsaktivitet, ifølge data fra Glassnode som Spark siterte i mars 2026. Andelen har siden da svingt i takt med markedsforholdene, men infrastrukturen er nå standard i de største lommebøkene og børsene. Bitcoin Optechs temaside om Taproot holder oversikt over den pågående protokollutviklingen rundt Taproot.

BIP 342: Tapscript

Tapscript er det oppdaterte skriptspråket som brukes til «script-path»-utgifter i Taproot. Det deler de fleste opkoder med det eldre Bitcoin Script, men inneholder flere vesentlige endringer:

• OP_CHECKMULTISIG og OP_CHECKMULTISIGVERIFY er utfaset. Den gamle multisig-opkoden hadde en særegenhet som krevde at man la et dummy-element på stakken som en midlertidig løsning. Tapscript fjerner dette og erstatter det med OP_CHECKSIGADD, som verifiserer Schnorr-signaturer én om gangen og fører telling. Multisig-ordninger med terskel blir enklere og billigere å gjennomføre.
• Begrensningene på skriptstørrelse per MAST-blad er fjernet. Enkeltstående skript innenfor en Taproot-gren kan være så store man ønsker.
• OP_SUCCESS-opkoder er den mest fremtidsrettede endringen. I det gamle skriptsystemet fører en udefinert opkode til at skriptet mislykkes. I Tapscript fører opkoder i OP_SUCCESS-området til at skriptet lykkes ubetinget. Fremtidige soft forks kan tilordne reell atferd til disse opkodene ved å legge til begrensninger på når de skal lykkes, uten at det kreves en ny skriptversjon eller en fullstendig ny distribusjonssyklus i hele økosystemet. Nye funksjoner kan legges til Bitcoins skriptlag på en mer ryddig måte enn noen gang tidligere i protokollens historie.

Miniskript

I tillegg til Tapscript har et beslektet prosjekt kalt Miniscript blitt stadig mer relevant for utviklere. Miniscript er en strukturert måte å skrive en delmengde av Bitcoin Script på, som kan analyseres, kombineres og signeres generisk. Mens rå Script krever manuell konstruksjon og er vanskelig å revidere, kan Miniscript-skript verifiseres automatisk for korrekthet og kombineres til større retningslinjer. Det utvider ikke hva Script kan gjøre, men gjør det som allerede er mulig betydelig mer tilgjengelig for utviklere som bygger lommebøker og forvaringsverktøy.

Hva Bitcoin Script muliggjør: Praktiske bruksområder

Følgende transaksjonstyper er i dag aktive på Bitcoins hovednett, og alle er basert på Bitcoin Script-primitiver:

Lommebøker med flersignatur (multisig) krever M av N private nøkler for å godkjenne et uttak. En bedriftskasse kan kreve 3 av 5 godkjenninger for ethvert uttak. Et ektepar kan bruke 2 av 2 for felles sparekontoer. Med Taproot og Schnorr-nøkkelaggregering er samarbeidsbaserte multisig-utbetalinger nå på blokkjeden umulige å skille fra standardtransaksjoner med én signatur.

Tidslåste transaksjoner Bruk OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, eller CLTV) og OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, eller CSV) for å hindre at midler flyttes før en bestemt blokkhøyde eller en bestemt tidsperiode har gått. Anvendelsesområdene omfatter arveplanlegging, tidsplaner for opptjening av ansattes tokens, mekanismer for tvungen sparing og straffetransaksjoner som brukes i Lightning Network-kanaler.

Hash-baserte tidslåste kontrakter (HTLC-er) kombinere et krav om forbildet til en hash med en tidslås. Betingelsen for utbetaling fungerer slik: forbildet til denne hashen må avsløres før denne blokkhøyden, ellers går midlene tilbake til avsenderen. HTLC-er er kjernen i Lightning Network og muliggjør tillitsfri betalingsruting gjennom kjeder av kanaler mellom parter som ikke har noen direkte relasjon til hverandre.

Depotkonto Disse ordningene låser midler i et P2SH- eller Taproot-skript, som krever samtykke fra flere parter før midlene frigis, vanligvis med en tredjeparts megler som har en avgjørende nøkkel.

Diskrete loggkontrakter (DLC-er) Bruk orakelbaserte Schnorr-adapter-signaturer for å muliggjøre finansielle kontrakter som gjøres opp ved hjelp av data fra den virkelige verden, for eksempel prisoppdateringer eller utfall av hendelser, uten at orakelet trenger å ha midler i sin forvaring. DLC-er er i drift på Bitcoins hovednett og brukes til opsjoner og futures-produkter som gjøres opp i Bitcoin.

Bitcoin-skript vs. Ethereums smarte kontrakter

Både Bitcoin Script og Ethereums Solidity definerer betingelser for når midler kan overføres, men de representerer fundamentalt forskjellige arkitektoniske valg. Det er verdt å foreta en direkte sammenligning, fordi forskjellene forklarer mye om de avveiningene hvert nettverk har akseptert.

Den grunnleggende skillelinjen er «statefulness». Ethereum-kontrakter lagrer og endrer data som vedvarer på tvers av transaksjoner, noe som muliggjør utlånsprotokoller, desentraliserte børser, styring på kjeden og tokenstandarder. Bitcoin Script har ingen tilsvarende funksjon. Hvert skript kjører isolert, uten kjennskap til andre transaksjoner.

Dette er et bevisst arkitektonisk valg, ikke et tomrom som venter på å bli fylt. Bitcoins skriptlag ble utviklet for én spesifikk oppgave: å håndheve vilkårene for å bruke bitcoin – på en forutsigbar og sikker måte, i stor skala. For denne oppgaven er fraværet av tilstand en styrke. Angrepsflaten er mindre, utførelsen er deterministisk på tvers av millioner av uavhengige validatorer, og det finnes ingen kategori av utnyttelse av smarte kontrakter på protokollnivå, fordi det ikke finnes tilstandsbaserte kontrakter på protokollnivå.

Prosjekter som ønsker større programmerbarhet på toppen av Bitcoin, bygger dette opp i lag. Lightning Network håndterer betalinger. DLC-protokoller håndterer finansielle kontrakter som er knyttet til eksterne data. Lag-2-systemer som Ark og Liquid Network retter seg mot ulike skalerbarhetsprofiler. Ingenting av dette krever endringer i skriptmodellen i grunnlaget.

Debatten om «The Covenant»: Hva kan endres i Bitcoin Script?

Utviklingen av Bitcoin Script har alltid vært langsom og konservativ. Det mest aktive utviklingsområdet akkurat nå er «covenant»-opkoder, som er forslag som vil gjøre det mulig for et skript å begrense ikke bare hvem som kan bruke en utgang, men også hvordan den resulterende transaksjonen må se ut. Dette er en betydelig utvidelse av Scripts uttrykksmuligheter.

De fremste forslagene per juni 2026 er:

• OP_CTV (BIP-119, CheckTemplateVerify), skrevet av Jeremy Rubin, legger til én enkelt opkode som binder en UTXO til en bestemt, forhåndsbestemt utgiftsmal, inkludert transaksjonens versjon, låsetid, antall innganger, sekvenser, antall utganger og utganger. Den er ikke-rekursiv i sin utforming, regnes som det mest konservative av de store forslagene, og retter seg primært mot vaults, overbelastningskontroll og visse forbedringer av Lightning-nettverket. Per april 2026 foreligger det konkrete implementeringsparametere for OP_CTV som spesifiserer et «Speedy Trial»-signalvindu, men forslaget har ikke oppnådd den brede konsensusen i fellesskapet som kreves for aktivering, i henhold til BlockEdens analyse av lånevilkårene fra april 2026.
• OP_CAT (BIP-347), foreslått av Ethan Heilman og Armin Sabouri, vil gjenaktivere en opkode som Satoshi deaktiverte i 2010. OP_CAT sammenkobler to stakkelementer, noe som er enkelt å beskrive, men har vidtrekkende konsekvenser. Når det kombineres med Schnorr-signaturer, muliggjør det «covenant»-lignende transaksjonsintrospeksjon. På Bitcoin-testnettverket Signet hadde OP_CAT generert betydelig flere utviklertransaksjoner enn både APO og CTV, ifølge sCrypts on-chain-analyse fra slutten av 2024. OP_CAT er allerede aktivt på Liquid Network og Fractal Bitcoin uten at det har blitt rapportert om sikkerhetsbrudd knyttet til det. BIP-347 har et offisielt forslagsnummer og aktiv forskning i ryggen, men aktivering i hovednettet krever konsensus i fellesskapet, noe som foreløpig ikke foreligger.
• LNHANCE kombinerer OP_CTV med OP_CHECKSIGFROMSTACK (CSFS) og OP_INTERNALKEY, med sikte på konkrete forbedringer i opprettelsen av kanaler i Lightning Network, blant annet ikke-interaktive kanalåpninger og mer effektiv administrasjon av flerpartskanaler.

Ingen av disse er aktivert på Bitcoins hovednett per juni 2026. De tekniske uenighetene mellom dem kan i stor grad løses. Det vanskeligste problemet er aktiveringsmekanismene. Bitcoins soft fork-prosess krever bred konsensus, og debatten om «covenant» bærer med seg gjenværende spenninger fra tidligere omstridte oppgraderinger. Det som fremgår klart av debatten, er at Bitcoins skriptlag har betydelig rom for vekst innenfor sitt konservative rammeverk. Spørsmålet man jobber med, er rekkefølgen og enighet i fellesskapet, ikke om skriptspråket har en fremtid.

Konklusjon

Bitcoin Script er den usynlige infrastrukturen som ligger til grunn for hver eneste transaksjon i nettverket. De fleste brukere kommer aldri i direkte kontakt med det. Lommebøker konstruerer gyldige skript, signerer dem og sender dem ut uten å avsløre mekanismene bak. Men hver betaling, hver Lightning-kanal, hver tidslåst plan og hvert multisig-hvelv kjører gjennom det samme stakkbaserte Bitcoin-skriptspråket som fulgte med protokollen i 2009.

Skriptlaget har vokst betraktelig siden den gang, med P2SH som har gjort komplekse utbetalinger praktisk gjennomførbare, SegWit som har redusert gebyrene og muliggjort Lightning, og Taproot som har innført Schnorr-signaturer, MAST-basert personvern og Tapscripts fremtidsrettede opkode-design. Covenant-forslagene som nå diskuteres aktivt, representerer det neste potensielle kapittelet. Om noen av dem vil bli aktivert, og når dette vil skje, er fortsatt helt åpent per midten av 2026.

Man trenger ikke å være utvikler for å forstå Script. Det krever imidlertid at man innser at Bitcoins konservatisme, de bevisste begrensningene, den langsomme oppgraderingsfrekvensen og mangelen på Turing-fullstendighet ikke er noen svakhet. De egenskapene som gjør Bitcoin Script forutsigbart, er de samme egenskapene som har holdt konsensuslaget rent i seksten år.