Vad är skriptspråket Bitcoin?

Bitcoin Script är det programmeringsspråk som styr varje transaktion i Bitcoin-nätverket. Det är ett enkelt, stackbaserat språk som definierar de exakta villkoren för när bitcoin kan användas, och varje fullnod i nätverket kör det varje gång en transaktion valideras. Utan det skulle Bitcoin vara en bokföring med siffror utan någon mekanism för att säkerställa vem som äger vad.

De flesta användare kommer aldrig i direkt kontakt med Bitcoins skriptspråk. Deras plånböcker sköter det i bakgrunden. Men varje gång du skickar eller tar emot BTC körs två små program samtidigt på tusentals datorer, som kontrollerar om villkoren för transaktionen är uppfyllda. Att förstå hur detta fungerar förklarar i hög grad varför Bitcoin är uppbyggt som det är, och vad det kan och inte kan göra jämfört med plattformar som Ethereum.

Den här artikeln beskriver hur Bitcoin Script fungerar, går igenom de viktigaste transaktionstyperna som det möjliggör, förklarar Taproot-uppgraderingen som moderniserade skriptskiktet år 2021 och redogör för läget i debatten kring opkoden ”covenant” i juni 2026.

Hantera dina Bitcoin på ett säkert sätt med egenförvaring Bitcoin.com Wallet-appen.

Viktiga slutsatser

• Bitcoin Script är ett stackbaserat programmeringsspråk som är inbyggt i Bitcoin-protokollet och som definierar villkoren för när en bitcoin-utgång kan användas.
• Varje Bitcoin-transaktion innehåller två skript: ett låsskript (ScriptPubKey) som anges av mottagaren och ett upplåsningsskript (ScriptSig) som tillhandahålls av avsändaren. Båda måste köras framgångsrikt för att transaktionen ska vara giltig.
• Bitcoin Script är avsiktligt inte Turingkomplett. Det har inga slingor, inget bestående tillstånd mellan körningarna och strikta begränsningar för skriptstorleken. Detta garanterar att varje skript avslutas, vilket är en säkerhetsfunktion, inte en begränsning.
• Skriptspråket har utvecklats genom fem huvudsakliga format: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) och Taproot (P2TR), där vart och ett utökar möjligheterna samtidigt som det förblir bakåtkompatibelt.
• Taproot (november 2021) införde Schnorr-signaturer, MAST-baserade utgiftsvägar för ökad integritet samt Tapscript – ett uppdaterat skriptspråk med en inbyggd mekanism för smidigare framtida uppgraderingar.
• Exempel på praktiska tillämpningar som bygger på Bitcoin Script är plånböcker med flersignatur, tidslåsta transaktioner, Hash Time-Locked Contracts (grunden för Lightning), escrow och Discreet Log Contracts.
• Till skillnad från Ethereums smarta kontrakt är Bitcoin Script tillståndslöst: varje skript körs helt isolerat utan kännedom om någon annan transaktion. Detta är ett medvetet arkitektoniskt val.
• Det mest aktiva området inom utvecklingen av Bitcoin Script år 2026 är opkoder för avtal, särskilt OP_CTV (BIP-119) och OP_CAT (BIP-347), som skulle göra det möjligt för skript att ställa krav på hur en utbetalningstransaktion måste se ut. Ingen av dem har aktiverats på mainnet ännu.

Vad är Bitcoin Script?

Bitcoin Script är ett stackbaserat, tillståndslöst skriptspråk som är inbyggt i Bitcoin-protokollet. Varje transaktionsutgång i Bitcoin-nätverket innehåller ett låsskript (kallat ScriptPubKey) som anger villkoren för att använda medlen. Den som vill använda dessa medel måste tillhandahålla ett upplåsningsskript (kallat ScriptSig, eller i SegWit- och Taproot-transaktioner, vittnesdata) som uppfyller dessa villkor.

Språket har hämtat sin struktur från Forth, ett minimalistiskt, stackbaserat programmeringsspråk som utvecklades på 1960-talet. Precis som Forth läses Bitcoin Script från vänster till höger, arbetar med en datastruktur som kallas en stack och använder omvänd polsk notation (RPN), där operatorerna följer efter sina operander istället för att föregå dem. Det exekverar en instruktion i taget, har inga loopar och lagrar inget minne mellan exekveringarna.

Den sista punkten är det som de flesta stöter på först när de lär sig om Bitcoin Script på protokollnivå: språket är medvetet inte Turingkomplett. Ett Turingkomplett språk kan utföra vilken beräkning som helst, förutsatt att det finns tillräckligt med tid och resurser. Bitcoin Script kan inte göra det, enligt sin utformning, och skälen till det valet har stor betydelse för hur nätverket fungerar.

Hur Bitcoin Script fungerar: Stack-modellen

För att förstå hur Bitcoin Script fungerar måste man förstå vad en stack är. En stack är en datastruktur som fungerar enligt principen ”sist in, först ut” (LIFO). Tänk dig en stapel tallrikar: du kan bara lägga till eller ta bort från toppen. I Bitcoin Script läggs data in i stacken och opkoder (operationskoder) bearbetar det som ligger överst.

När en Bitcoin-nod validerar en transaktion kör den två skript i tur och ordning:

1. Upplåsningsskriptet (ScriptSig eller vittne) som tillhandahålls av den person som använder mynten. Detta lägger data på stacken, vanligtvis en digital signatur och en offentlig nyckel.
2. Låsningsskriptet (ScriptPubKey) kopplad till den utgående transaktionen. Den innehåller opkoder som bearbetar stapeldata och kontrollerar om villkoren för utbetalningen är uppfyllda.

Om skriptet körs utan fel och lämnar ett värde som inte är noll (TRUE) på stacken när det är klart, är transaktionen giltig. Om det misslyckas eller lämnar FALSE, avvisas transaktionen av noden och hamnar aldrig i ett block.

Denna körning är helt tillståndsfri. Skriptet har ingen kännedom om tidigare transaktioner, ingen kännedom om aktuella saldon och inget minne som bevaras efter att skriptet har körts klart. Varje skript körs från grunden, isolerat, varje gång.

Steg för steg: En vanlig P2PKH-transaktion

Pay-to-Public-Key-Hash (P2PKH) är den ursprungliga transaktionstypen i Bitcoin, som har använts sedan 2009. P2PKH-adresser börjar med ”1.” Så här ser ScriptPubKey och ScriptSig ut i praktiken:

Upplåsningsskript (ScriptSig):

<signatur> <offentlig nyckel>

Låsningsskript (ScriptPubKey):

OP_DUP OP_HASH160 <hash av den offentliga nyckeln> OP_EQUALVERIFY OP_CHECKSIG

När noden sammanfogar och kör båda samtidigt fortskrider stapeloperationerna steg för steg:

• Signaturen och den publika nyckeln från ScriptSig läggs in i stacken
• OP_DUP kopierar den publika nyckeln som ligger överst i stapeln
• OP_HASH160 beräknar en hash för dubbletten (SHA-256 följt av RIPEMD-160), vilket ger en hash på 20 byte
• Hashvärdet för den offentliga nyckeln från låsningsskriptet läggs in i stacken
• OP_EQUALVERIFY kontrollerar att de två hashvärdena stämmer överens. Om de inte gör det avbryts körningen och transaktionen misslyckas.
• OP_CHECKSIG kontrollerar att signaturen är giltig för den offentliga nyckeln

Om alla steg godkänns avslutas stacken med TRUE och medlen frigörs. Hela processen tar några millisekunder och genomförs på exakt samma sätt på varje nod i nätverket.

Bitcoin-opkoder förklarade

Bitcoin-opkoder är de enskilda kommandon som utgör ett skript. Varje opkod består av en enda byte, vilket ger 256 möjliga opkodsplatser. Av dessa är ungefär 80 för närvarande aktiva på mainnet. Resten är antingen reserverade, inaktiverade eller tilldelade till OP_SUCCESS-mekanismen för framåtkompatibilitet, som infördes i samband med Tapscript.

Opkoder kan delas in i flera kategorier:

• Opkoder för datapush lägga värden som publika nycklar, signaturer och hashvärden på stacken
• Aritmetiska opkoder utföra addition, subtraktion och jämförelser. Det är värt att notera att multiplikation och division är inaktiverade.
• Kryptografiska opkoder bland annat OP_SHA256, OP_HASH160 och OP_SHA1 för hashberäkning samt OP_CHECKSIG för verifiering av signaturer
• Opkoder för flödeskontroll aktivera villkorslogik: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Operationskoder för stapelmanipulation bland annat OP_DUP (duplicera det översta elementet), OP_DROP (ta bort det översta elementet) och OP_SWAP (byta plats på de två översta elementen)

Flera opkoder inaktiverades av Satoshi Nakamoto år 2010 efter att sårbarheter upptäckts i deras ursprungliga implementeringar. Dessa inkluderar OP_CAT (sammanfoga två stackobjekt), OP_MUL (multiplicera) och OP_DIV (dela). Deras frånvaro har haft bestående konsekvenser för vad Bitcoin Script kan uttrycka, och flera av de mest omdiskuterade förslagen till uppgraderingar av Bitcoin under 2026 handlar om huruvida vissa av dem ska återaktiveras.

För en fullständig översikt över opkoder, inklusive hexadecimala värden och beskrivningar, se Sidan ”Bitcoin Wiki Script” är den mest tillförlitliga källan.

Varför det faktum att ett system inte är Turingkomplett är en fördel

Den vanliga förklaringen är att Bitcoin Script saknar slingor, vilket innebär att skripten garanterat avslutas och att nätverket därmed skyddas mot oändlig körning. Det stämmer, men det är en förenkling av saken.

Det mer grundläggande argumentet handlar om attackytan. Ett Turing-komplett språk kan uttrycka godtyckliga beräkningar. Denna uttrycksförmåga är också den miljö där buggar frodas. Ethereums Solidity har gett upphov till några av de dyraste programvarusårbarheterna i historien. Hacket mot DAO 2016 utnyttjade en reentrancy-brist i ett smart kontrakt och orsakade förluster på cirka 60 miljoner dollar i dåvarande priser, vilket i slutändan ledde till en kontroversiell hard fork av Ethereum-nätverket. Det bredare DeFi-ekosystemet har sett hundratals miljoner dollar försvinna genom utnyttjande av smarta kontrakt under flera år.

Bitcoin Script gör den typen av attacker strukturellt omöjliga. Det går inte att skriva ett Bitcoin-skript som anropar andra skript, körs i en loop tills ett villkor ändras eller lagrar tillstånd mellan transaktioner. Varje skript är ett avgränsat, avslutbart och granskningsbart program. Den maximala skriptstorleken är 10 000 byte. Det maximala antalet opkoder som inte är av typen ”push” per skript är 201. En validerare kan alltid beräkna den värsta möjliga exekveringskostnaden innan skriptet körs.

För ett nätverk med ett värde på hundratals miljarder dollar är den förutsägbarheten värd mer än den flexibilitet man avstår från. Ethereum löser problemet med obegränsad beräkningskapacitet genom gasgränser, där användarna debiteras för varje opkod som exekveras och skript som överskrider sin budget stoppas. Det fungerar, men medför sin egen komplexitet och egna felkällor. Bitcoin kringgår problemet helt genom sin konstruktion.

Med detta sagt innebär ”inte Turingkomplett” inte att det ”inte klarar av komplex logik”. Bitcoin Script stöder krav på utbetalningar med flera parter, tidsbaserade villkor, avslöjande av hash-prebilder samt kombinationer av alla dessa. Lightning Network, som hanterar miljontals betalningar per dag, är helt uppbyggt på Bitcoin Scripts grundläggande funktioner.

Skripttyper: Utvecklingen från P2PKH till Taproot

Bitcoins skriptspråkslager har utvecklats avsevärt sedan 2009, och varje uppgradering har infört ett nytt transaktionsformat samtidigt som den har varit bakåtkompatibel med allt som kommit tidigare.

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

Det ursprungliga formatet, som användes i de första Bitcoin-transaktionerna, däribland Satoshis betalning till Hal Finney i block 170. Medlen låstes direkt till en fullständig offentlig nyckel istället för dess hash. Används sällan i nya transaktioner idag eftersom det exponerar den publika nyckeln på blockkedjan innan utbetalningen, vilket anses vara en sämre säkerhetslösning än att först hasha nyckeln.

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

Standardformatet i mer än ett decennium. P2PKH låser medel till en hash av den publika nyckeln istället för till själva nyckeln, vilket håller den publika nyckeln hemlig fram till det ögonblick då pengarna används, ger en kortare adress på 20 byte och utgör grunden för alla adresser som börjar med ”1”. Enligt on-chain-data från Unchained (april 2026) innehar P2PKH-adresser för närvarande cirka 43 % av det utvunna bitcoin-utbudet.

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

P2SH, som infördes via en soft fork den 1 april 2012, flyttade bördan av komplexa utgiftsskript från avsändaren till mottagaren. Istället för att bädda in ett fullständigt låsskript i utgången, skapar P2SH-utgången en 20-byte-hash av ett ”inlösningsskript”. Det fullständiga skriptet avslöjas först när mynten används. Detta gjorde multisig praktiskt för vanliga användare: en 2-av-3-multisig-konfiguration krävde inte längre att alla tre publika nycklarna var synliga för avsändaren vid betalningstillfället. P2SH-adresser börjar med ”3.”

För en detaljerad beskrivning av hur P2SH-valideringen fungerar på protokollnivå, transaktionsguiden på developer.bitcoin.org går igenom mekanismen bakom Redeme-skriptet steg för steg.

P2WPKH och P2WSH (inbyggt SegWit, 2017, BIP 141)

Segregated Witness, som aktiverades i augusti 2017 vid block 481 824, flyttade signaturdata från transaktionens huvuddel till en separat vittnesstruktur. Vittnesdata får en viktreduktion på 75 %, vilket gör SegWit-transaktioner betydligt billigare. En standardtransaktion av typen P2WPKH med en ingång och två utgångar väger cirka 141 virtuella byte, jämfört med 226 vbyte för motsvarande P2PKH-transaktion, enligt Spark:s analys av olika typer av Bitcoin-adresser från mars 2026. SegWit åtgärdade även problemet med transaktionsmanipulerbarhet, vilket var en förutsättning för Lightning Network. Inbyggda SegWit-adresser börjar med ”bc1q.”

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

Taproot aktiverades i november 2021 vid block 709 632 och är den mest betydande uppgraderingen av Bitcoins skriptspråkslager sedan SegWit. Den införde Schnorr-signaturer, en ny utdatatyp med stöd för MAST samt Tapscript som ett uppdaterat skriptspråk. Taproot-adresser börjar med ”bc1p.”

Taproot och Tapscript: Hur Bitcoins skriptspråk förändrades under 2021

Taproot är inte en enskild förändring. Det handlar om tre Bitcoin Improvement Proposals som har utformats gemensamt och aktiverats samtidigt.

BIP 340: Schnorr-signaturer

Bitcoin använde ursprungligen ECDSA (Elliptic Curve Digital Signature Algorithm). Satoshi valde den delvis därför att Schnorr-signaturer vid den tiden var patentskyddade. Det patentet löpte ut 2008, och Taproot införde slutligen Schnorr i protokollet.

Schnorr-signaturer är mindre, 64 byte jämfört med 71–73 byte för ECDSA. Ännu viktigare är att de stöder nyckelaggregering genom ett system som kallas MuSig2. Nyckelaggregering gör det möjligt för flera signatärer att kombinera sina individuella nycklar och signaturer till en enda aggregerad nyckel och signatur som på blockkedjan inte går att skilja från en vanlig betalning med en enda signatur. En 2-av-3-multisig-plånbok som gör uttag via Taproots kooperativa nyckelväg ser identisk ut som en standardbetalning på blockkedjan. Det är en verklig integritetsvinst för alla som innehar bitcoin i ett komplext förvaringsarrangemang.

BIP 341: Pay-to-Taproot och MAST

P2TR introducerar en ny utdatatyp med två utgiftsvägar:

• A nyckelväg genomföra transaktionen med hjälp av en Schnorr-signatur, vilket används när alla parter är överens och vill välja den enklaste och billigaste lösningen
• A skriptsökväg använda MAST (Merkelized Abstract Syntax Tree, vilket är Taproots implementering av konceptet)

MAST gör det möjligt för en enskild utgång att kopplas till ett träd med flera utgiftsskript via en Merkle-rot. Vid utbetalning avslöjas endast det specifika villkor som faktiskt används på blockkedjan. Alla andra möjliga utgiftsvägar i trädet förblir permanent dolda. För en användare som har konfigurerat en komplex utgiftspolicy, till exempel ”Jag kan göra utgifter som vanligt, eller så kan två av tre förvaltare göra utgifter efter sex månader, eller så kan en återställningsnyckel göra utgifter efter två år”, är det endast den väg som faktiskt utförs som någonsin visas i blockkedjan.

År 2024 hade Taproots andel av Bitcoin-transaktionerna ökat till cirka 42 %, främst tack vare aktiviteten kring Ordinals och BRC-20-inskriptioner, enligt uppgifter från Glassnode som Spark citerade i mars 2026. Den andelen har sedan dess varierat beroende på marknadsförhållandena, men infrastrukturen är nu standard i de flesta större plånböcker och på de flesta börser. Bitcoin Optechs temasida om Taproot följer den pågående protokollutvecklingen kring Taproot.

BIP 342: Tapscript

Tapscript är det uppdaterade skriptspråket som används för transaktioner via script-path inom Taproot. Det delar de flesta opkoderna med det äldre Bitcoin Script, men innehåller flera väsentliga förändringar:

• OP_CHECKMULTISIG och OP_CHECKMULTISIGVERIFY är föråldrade. Den gamla multisig-opkoden hade en egenhet som krävde att man lade till ett dummy-element i stacken som en tillfällig lösning. Tapscript tar bort den och ersätter den med OP_CHECKSIGADD, som verifierar Schnorr-signaturer en i taget och räknar ihop antalet. Tröskelbaserade multisignatursystem blir enklare och billigare att genomföra.
• Begränsningarna för skriptstorlek per MAST-blad har tagits bort. Enskilda skript inom en Taproot-gren kan vara hur stora som helst.
• OP_SUCCESS-opkoder är den mest framåtblickande förändringen. I det gamla skriptspråket leder ett odefinierat opkod till att skriptet misslyckas. I Tapscript leder opkoder inom OP_SUCCESS-intervallet till att skriptet lyckas villkorslöst. Framtida soft forks kan tilldela dessa opkoder ett konkret beteende genom att lägga till begränsningar för när de ska lyckas, utan att det krävs en ny skriptversion eller en fullständig omdistributionscykel i hela ekosystemet. Nya funktioner kan läggas till i Bitcoins skriptlager på ett renare sätt än någonsin tidigare i protokollets historia.

Miniscript

Vid sidan av Tapscript har ett besläktat projekt vid namn Miniscript blivit allt mer relevant för utvecklare. Miniscript är ett strukturerat sätt att skriva en delmängd av Bitcoin Script som går att analysera, kombinera och signera på ett generiskt sätt. Medan vanligt Script kräver manuell konstruktion och är svårt att granska, kan Miniscript-skript verifieras automatiskt för korrekthet och kombineras till större policyer. Det utökar inte vad Script kan göra, men gör det som det redan kan betydligt mer tillgängligt för utvecklare som bygger plånböcker och förvaringsverktyg.

Vad Bitcoin Script möjliggör: Praktiska användningsfall

Följande transaktionstyper är idag aktiva på Bitcoins huvudnät, och alla bygger på Bitcoin Scripts grundläggande funktioner:

Plånböcker med flera signaturer (multisig) kräver M av N privata nycklar för att godkänna en utbetalning. Ett företags finansavdelning kan kräva 3 av 5 godkännanden för varje uttag. Ett gift par kan använda 2 av 2 för gemensamma besparingar. Med Taproot och Schnorr-nyckelaggregering är gemensamma multisig-utbetalningar nu på blockkedjan omöjliga att skilja från vanliga transaktioner med en enda signatur.

Tidsbegränsade transaktioner Använd OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, eller CLTV) och OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, eller CSV) för att förhindra att medel flyttas före en viss blockhöjd eller efter en viss tid. Användningsområdena omfattar arvplanering, scheman för intjänande av anställdas tokens, mekanismer för tvångssparande samt strafftransaktioner som används inom Lightning Network-kanaler.

Hash Time-Locked Contracts (HTLC) kombinera ett krav på en prebild till en hash med en tidslåsning. Villkoret för utbetalning fungerar så här: prebilden till denna hash måste avslöjas innan denna blockhöjd uppnås, annars återgår medlen till avsändaren. HTLC:er är den centrala grundkomponenten i Lightning Network och möjliggör tillitsfri betalningsdirigering genom kedjor av kanaler mellan parter som inte har någon direkt relation till varandra.

Deponeringskonto Dessa lösningar låser medel i ett P2SH- eller Taproot-skript, vilket innebär att flera parter måste komma överens innan medlen kan frigöras. Vanligtvis har en oberoende tredje part en avgörande nyckel som används vid oavgjorda situationer.

Diskreta loggavtal (DLC) Använda orakelbaserade Schnorr-adaptersignaturer för att möjliggöra finansiella kontrakt som avvecklas utifrån data från den verkliga världen, såsom prisflöden eller händelseutfall, utan att oraklet behöver förvalta några medel. DLC:er är i drift på Bitcoins huvudnät och används för options- och terminsprodukter som avvecklas i Bitcoin.

Bitcoin-skript kontra Ethereums smarta kontrakt

Både Bitcoin Script och Ethereums Solidity definierar villkor för hur medel kan överföras, men de representerar i grunden olika arkitektoniska val. Det är värt att göra en direkt jämförelse, eftersom skillnaderna förklarar mycket om de avvägningar som respektive nätverk har gjort.

Den grundläggande skillnaden ligger i statiskheten. Ethereums kontrakt lagrar och ändrar data som bevaras mellan transaktioner, vilket möjliggör utlåningsprotokoll, decentraliserade börser, styrning på blockkedjan och tokenstandarder. Bitcoin Script har ingen motsvarighet. Varje skript körs isolerat utan kännedom om några andra transaktioner.

Detta är ett medvetet arkitektoniskt val, inte en lucka som väntar på att fyllas. Bitcoins skriptskikt utformades för en specifik uppgift: att säkerställa villkoren för att använda bitcoin – på ett förutsägbart och säkert sätt, i stor skala. För den uppgiften är avsaknaden av tillstånd en styrka. Attackytan är mindre, exekveringen är deterministisk hos miljontals oberoende validerare, och det finns ingen typ av utnyttjande av smarta kontrakt på protokollnivå eftersom det inte finns några tillståndsberoende kontrakt på protokollnivå.

Projekt som eftersträvar ökad programmerbarhet utöver Bitcoin bygger upp sin arkitektur i lager. Lightning Network hanterar betalningar. DLC-protokoll hanterar finansiella kontrakt som är kopplade till extern data. Lager-2-system som Ark och Liquid Network riktar sig mot olika skalbarhetsbehov. Inget av detta kräver att skriptmodellen i baslagret ändras.

Debatten om Covenant: Vad kan komma att förändras i Bitcoin Script

Utvecklingen av Bitcoin Script har alltid varit långsam och försiktig. Det mest aktiva utvecklingsområdet just nu är så kallade ”covenant opcodes”, vilket är förslag som skulle göra det möjligt för ett skript att inte bara begränsa vem som får använda en utgång, utan även hur den resulterande transaktionen måste se ut. Detta innebär en betydande utvidgning av Scripts uttrycksförmåga.

De främsta förslagen per juni 2026 är:

• OP_CTV (BIP-119, CheckTemplateVerify), författat av Jeremy Rubin, lägger till en enda opkod som binder en UTXO till en specifik, förutbestämd utgiftsmall som inkluderar transaktionens version, låstid, antal ingångar, sekvenser, antal utgångar och utgångar. Den är icke-rekursiv till sin utformning, anses vara det mest konservativa större förslaget och riktar sig främst mot valv, överbelastningskontroll och vissa förbättringar av Lightning. Från och med april 2026 finns konkreta driftsparametrar för OP_CTV på bordet som specificerar ett ”Speedy Trial”-signaleringsfönster, men den har ännu inte uppnått den breda konsensus inom gemenskapen som krävs för aktivering, enligt BlockEdens analys av lånevillkoren för april 2026.
• OP_CAT (BIP-347), som föreslagits av Ethan Heilman och Armin Sabouri, skulle återaktivera en opkod som Satoshi inaktiverade 2010. OP_CAT sammanfogar två stackobjekt, vilket är enkelt att beskriva men har omfattande konsekvenser. I kombination med Schnorr-signaturer möjliggör det en transaktionsgranskning liknande den i ”covenant”. På Bitcoins testnätverk Signet hade OP_CAT genererat betydligt fler utvecklartransaktioner än både APO och CTV, enligt sCrypts on-chain-analys från slutet av 2024. OP_CAT är redan aktivt på Liquid Network och Fractal Bitcoin utan att några säkerhetsluckor har kunnat kopplas till det. BIP-347 har ett officiellt förslagsnummer och aktiv forskning bakom sig, men aktivering i mainnet kräver konsensus inom gemenskapen, vilket ännu inte finns.
• LNHANCE kombinerar OP_CTV med OP_CHECKSIGFROMSTACK (CSFS) och OP_INTERNALKEY, med syfte att åstadkomma specifika förbättringar av kanaluppbyggnaden i Lightning Network, däribland icke-interaktiva kanalöppningar och en mer effektiv hantering av flerpartskanaler.

Ingen av dessa har aktiverats på Bitcoins huvudnät i juni 2026. De tekniska meningsskiljaktigheterna mellan dem går i stort sett att lösa. Det svårare problemet är aktiveringsmekanismerna. Bitcoins soft fork-process kräver bred konsensus, och debatten om avtalet präglas av kvarvarande spänningar från tidigare omstridda uppgraderingar. Det som framgår tydligt av debatten är att Bitcoins skriptspråkslager har betydande utrymme att växa inom sitt konservativa ramverk. Den fråga som man arbetar med är sekvensering och samförstånd inom gemenskapen, inte om skriptspråket har en framtid.

Slutsats

Bitcoin Script är den osynliga infrastrukturen som ligger till grund för varje transaktion i nätverket. De flesta användare kommer aldrig i direkt kontakt med det. Plånböcker skapar giltiga skript, signerar dem och sänder ut dem utan att någonsin avslöja hur det fungerar. Men varje betalning, varje Lightning-kanal, varje tidslåst plan och varje multisig-valv körs via samma stackbaserade Bitcoin-skriptspråk som levererades med protokollet 2009.

Skriptlagret har vuxit avsevärt sedan dess, där P2SH har gjort komplexa transaktioner praktiskt genomförbara, SegWit har sänkt avgifterna och möjliggjort Lightning, och Taproot har infört Schnorr-signaturer, MAST-baserad integritet samt Tapscripts framåtkompatibla opkoddesign. De förslag till avtal som nu diskuteras aktivt representerar det nästa potentiella kapitlet. Om några av dem kommer att aktiveras, och enligt vilken tidsplan, är fortfarande helt öppet i mitten av 2026.

Man behöver inte vara utvecklare för att förstå Script. Däremot måste man inse att Bitcoins konservativa utformning – de avsiktliga begränsningarna, den långsamma uppgraderingsrytmen och avsaknaden av Turing-fullständighet – inte är någon brist. De egenskaper som gör Bitcoin Script förutsägbart är samma egenskaper som har hållit konsensuslagret rent i sexton år.