Mikä on Bitcoin-skriptikieli?

Bitcoin Script on ohjelmointikieli, joka ohjaa jokaista Bitcoin-verkoston tapahtumaa. Se on yksinkertainen, pinoon perustuva kieli, joka määrittelee tarkat ehdot, joiden mukaisesti bitcoineja voidaan käyttää, ja jokainen verkon täyssolmu suorittaa sitä aina, kun tapahtuma vahvistetaan. Ilman sitä Bitcoin olisi pelkkä numeroiden kirjanpito, jossa ei olisi mekanismia sen varmistamiseksi, kuka mitäkin omistaa.

Useimmat käyttäjät eivät koskaan näe Bitcoin-skriptikieltä suoraan. Heidän lompakkonsa hoitavat sen näkymättömästi. Mutta joka kerta, kun lähetät tai vastaanotat BTC:tä, tuhansilla tietokoneilla suoritetaan samanaikaisesti kaksi pientä ohjelmaa, jotka tarkistavat, täyttyvätkö käyttöehdot. Kun ymmärtää, miten tämä toimii, selviää paljon siitä, miksi Bitcoin on rakennettu juuri tällä tavalla ja mitä se voi ja ei voi tehdä verrattuna esimerkiksi Ethereumin kaltaisiin alustoihin.

Tässä artikkelissa käsitellään Bitcoin Scriptin toimintaa, käydään läpi sen mahdollistamat tärkeimmät transaktiotyypit, selitetään Taproot-päivitys, joka modernisoi skriptikerroksen vuonna 2021, sekä tarkastellaan covenant-opkoodia koskevan keskustelun tilannetta kesäkuussa 2026.

Hallinnoi bitcoinejasi turvallisesti itsehallinnan avulla Bitcoin.com Wallet -sovellus.

Tärkeimmät kohdat

• Bitcoin Script on Bitcoin-protokollaan sisäänrakennettu pino-pohjainen ohjelmointikieli, joka määrittelee ehdot, joiden mukaisesti mikä tahansa bitcoin-lähtö voidaan käyttää.
• Jokaiseen Bitcoin-transaktioon sisältyy kaksi skriptiä: vastaanottajan asettama lukitusskripti (ScriptPubKey) ja maksajan toimittama avausscript (ScriptSig). Molempien on suorituttava onnistuneesti, jotta transaktio olisi pätevä.
• Bitcoin-skripti ei ole tarkoituksella Turing-täydellinen. Siinä ei ole silmukoita, suoritusten välillä ei säilytetä tilaa, ja skriptin koolle on asetettu tiukat rajoitukset. Tämän ansiosta jokainen skripti päättyy taatusti, mikä on turvallisuusominaisuus, ei rajoitus.
• Skriptikieli on kehittynyt viiden päämuodon kautta: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) ja Taproot (P2TR), joista jokainen on laajentanut mahdollisuuksia säilyttäen samalla taaksepäin yhteensopivuuden.
• Taproot-päivityksessä (marraskuu 2021) otettiin käyttöön Schnorr-allekirjoitukset, yksityisyyttä suojaavat MAST-pohjaiset kulutuspolut sekä Tapscript, päivitetty skriptikieli, johon on sisäänrakennettu mekanismi tulevien päivitysten sujuvuuden parantamiseksi.
• Bitcoin Scriptin pohjalta kehitettyjä käytännön sovelluksia ovat muun muassa monen allekirjoituksen lompakot, aikarajoitetut transaktiot, Hash Time-Locked Contracts (Lightning-verkoston perusta), escrow-palvelut sekä Discreet Log Contracts.
• Toisin kuin Ethereumin älykkäät sopimukset, Bitcoin Script on tilaton: jokainen skripti toimii täysin erillään muista, eikä sillä ole tietoa muista transaktioista. Tämä on tietoinen arkkitehtoninen valinta.
• Vuonna 2026 Bitcoin-skriptien kehityksessä aktiivisinta toimintaa on covenant-opkoodien parissa, erityisesti OP_CTV (BIP-119) ja OP_CAT (BIP-347), joiden avulla skripteillä voitaisiin määrittää, millainen rahankäyttötapahtuman on oltava. Kumpikaan niistä ei ole vielä otettu käyttöön pääverkossa.

Mikä on Bitcoin Script?

Bitcoin Script on pinoon perustuva, tilaton skriptikieli, joka on integroitu Bitcoin-protokollaan. Jokaisessa Bitcoin-verkon transaktiolähdössä on lukitusskripti (ns. ScriptPubKey), joka määrittelee varojen käyttämisen ehdot. Jokaisen, joka haluaa käyttää kyseisiä varoja, on toimitettava lukituksen avaava skripti (ns. ScriptSig tai SegWit- ja Taproot-transaktioissa todistajatiedot), joka täyttää nämä ehdot.

Kielen rakenne perustuu Forthiin, 1960-luvulla kehitettyyn minimalistiseen pinoon perustuvaan ohjelmointikieleen. Forthin tavoin Bitcoin Script luetaan vasemmalta oikealle, se toimii pinoksi kutsutun tietorakenteen avulla ja käyttää käänteispoolalaista merkintätapaa (RPN), jossa operaattorit seuraavat operandejaan sen sijaan, että ne edeltäisivät niitä. Se suorittaa yhden käskyn kerrallaan, siinä ei ole silmukoita eikä se säilytä muistia suoritusten välillä.

Juuri tämä viimeinen seikka on se, johon useimmat ihmiset törmäävät ensimmäisenä tutustuessaan Bitcoin-skriptiin protokollatasolla: kieli ei ole tarkoituksella Turing-täydellinen. Turing-täydellinen kieli pystyy suorittamaan minkä tahansa laskennan, kunhan aikaa ja resursseja on riittävästi. Bitcoin-skripti ei voi sitä suunnittelunsa vuoksi tehdä, ja tämän valinnan syillä on suuri merkitys verkon toiminnalle.

Miten Bitcoin-skripti toimii: pino-malli

Jotta voisit ymmärtää, miten Bitcoin Script toimii, sinun on ymmärrettävä pino. Pino on tietorakenne, joka toimii LIFO-periaatteella (Last-In, First-Out). Kuvittele lautaspino: voit lisätä tai poistaa lautasia vain pinon päältä. Bitcoin Scriptissä data työnnetään pinolle, ja opkoodit (operaatiokoodit) käsittelevät sitä, mikä kulloinkin on pinon päällä.

Kun Bitcoin-solmu vahvistaa tapahtuman, se suorittaa peräkkäin kaksi skriptiä:

1. Avaamisskripti (ScriptSig tai todistaja) jonka kolikoita käyttävä henkilö toimittaa. Tämä lisää tiedot pinoon, yleensä digitaalisen allekirjoituksen ja julkisen avaimen.
2. Lukitusskripti (ScriptPubKey) liittyy käytettävään ulostuloon. Se sisältää opkoodeja, jotka käsittelevät pinon tietoja ja tarkistavat, täyttyvätkö käyttöehdot.

Jos skripti suoritetaan ilman virheitä ja jättää lopuksi pinoon nollasta poikkeavan arvon (TRUE), transaktio on kelvollinen. Jos se epäonnistuu tai jättää pinoon arvon FALSE, solmu hylkää transaktion, eikä se pääse koskaan lohkoon.

Tämä suoritus on täysin tilaton. Skripti ei tunne aiempia tapahtumia, ei ole tietoinen nykyisistä saldoista eikä sillä ole muistia, joka säilyisi skriptin suorituksen päätyttyä. Jokainen skripti suoritetaan joka kerta alusta alkaen, erillään muista.

Vaihe vaiheelta: Tavallinen P2PKH-tapahtuma

Pay-to-Public-Key-Hash (P2PKH) on alkuperäinen Bitcoin-tapahtumatyyppi, jota on käytetty vuodesta 2009 lähtien. P2PKH-osoitteet alkavat numerolla ”1”. Tässä on esimerkki siitä, miltä ScriptPubKey ja ScriptSig näyttävät käytännössä:

Skriptin lukituksen avaaminen (ScriptSig):

<allekirjoitus> <julkinen avain>

Salausskripti (ScriptPubKey):

OP_DUP OP_HASH160 <julkisen avaimen hajautusarvo> OP_EQUALVERIFY OP_CHECKSIG

Kun solmu yhdistää nämä kaksi ja suorittaa ne yhdessä, pino-operaatiot etenevät vaihe vaiheelta:

• ScriptSig:n allekirjoitus ja julkinen avain siirretään pinoon
• OP_DUP kopioi pinoon ylimmäksi tulevan julkisen avaimen
• OP_HASH160 laskee päällekkäisen tietueen hajautusarvon (SHA-256 ja sen jälkeen RIPEMD-160), jolloin tuloksena on 20 tavun pituinen hajautusarvo
• Lukitusskriptin julkisen avaimen hajautusarvo lisätään pinoon
• OP_EQUALVERIFY tarkistaa, että nämä kaksi hajautusarvoa ovat samat. Jos ne eivät ole, suoritus keskeytyy ja tapahtuma epäonnistuu.
• OP_CHECKSIG tarkistaa, että allekirjoitus on voimassa kyseiselle julkiselle avaimelle

Jos kaikki vaiheet sujuvat onnistuneesti, pino päättyy arvoon TRUE ja varat vapautetaan. Koko prosessi kestää millisekunteja ja suoritetaan täsmälleen samalla tavalla verkoston jokaisessa solmussa.

Bitcoin-opkoodien selitys

Bitcoinin opkoodit ovat yksittäisiä komentoja, joista skripti koostuu. Kukin opkoodi on yhden tavun pituinen, joten opkoodipaikkoja on yhteensä 256. Näistä noin 80 on tällä hetkellä käytössä pääverkossa. Loput ovat joko varattuja, pois käytöstä tai osoitettu Tapscriptin myötä käyttöön otettuun OP_SUCCESS-yhteensopivuusmekanismiin.

Opkoodit voidaan jakaa useisiin luokkiin:

• Tietojen lähetyskäsköt lisää arvot, kuten julkiset avaimet, allekirjoitukset ja hajautusarvot, pinoon
• Aritmeettiset opkoodit suorittaa yhteenlasku-, vähennys- ja vertailuoperaatioita. Huomionarvoista on, että kertolasku ja jakolasku eivät ole käytettävissä.
• Salauskoodit niihin kuuluvat OP_SHA256, OP_HASH160 ja OP_SHA1 hajautusta varten sekä OP_CHECKSIG allekirjoituksen todentamista varten
• Virtauksenohjauskoodit ehdollisen logiikan käyttöönotto: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Pinon käsittelyyn liittyvät opkoodit näitä ovat OP_DUP (kopioi ylimmäinen kohde), OP_DROP (poista ylimmäinen kohde) ja OP_SWAP (vaihda kahden ylimmän kohteen paikkaa)

Satoshi Nakamoto poisti useita opkoodeja käytöstä vuonna 2010, kun niiden alkuperäisissä toteutuksissa havaittiin haavoittuvuuksia. Näitä ovat muun muassa OP_CAT (kahden pinokohteen yhdistäminen), OP_MUL (kertolasku) ja OP_DIV (jakolasku). Niiden puuttuminen on vaikuttanut pysyvästi siihen, mitä Bitcoin Scriptilla voidaan ilmaista, ja useissa vuoden 2026 vilkkaimmin keskustelluissa Bitcoin-päivitysehdotuksissa pohditaan, pitäisikö joitakin niistä ottaa uudelleen käyttöön.

Täydellinen opkoodiluettelo, joka sisältää heksadesimaaliarvot ja kuvaukset, löytyy Bitcoin-wikin skriptisivu on luotettava lähde.

Miksi Turingin täydellisyyden puute on etu

Yleinen selitys on, että Bitcoin Scriptissä ei ole silmukoita, joten skriptien päättyminen on taattu ja verkko on siten suojattu loputtomalta suoritukselta. Tämä on totta, mutta se ei kuvaa asiaa riittävän kattavasti.

Syvällisempi perustelu liittyy hyökkäyspintaan. Turing-täydellinen kieli pystyy ilmaisemaan mitä tahansa laskutoimitusta. Juuri tämä ilmaisukyky on myös se tila, jossa virheet piilevät. Ethereumin Solidity-kieli on aiheuttanut joitakin historian kalleimpia ohjelmistohaavoittuvuuksia. Vuoden 2016 DAO-hakkerointi hyödynsi älykkään sopimuksen reentrancy-virhettä ja aiheutti noin 60 miljoonan dollarin tappiot tuolloisten hintojen mukaan, mikä johti lopulta kiistanalaiseen Ethereumin verkon hard forkiin. Laajemmassa DeFi-ekosysteemissä on useiden vuosien aikana menetetty satoja miljoonia dollareita älykkäiden sopimusten haavoittuvuuksien hyödyntämisen seurauksena.

Bitcoin-skripti tekee tämän tyyppiset hyökkäykset rakenteellisesti mahdottomiksi. Ei ole mahdollista kirjoittaa Bitcoin-skriptiä, joka kutsuisi muita skriptejä, toistuisi silmukassa, kunnes ehto muuttuu, tai tallentaisi tilaa transaktioiden välillä. Jokainen skripti on rajattu, päättyvä ja tarkasteltavissa oleva ohjelma. Skriptin enimmäiskoko on 10 000 tavua. Skriptiä kohti sallittujen muiden kuin push-opkoodien enimmäismäärä on 201. Validaattori voi aina laskea pahimman mahdollisen suorituskustannuksen ennen skriptin suorittamista.

Verkostolle, jonka arvo on satoja miljardeja dollareita, tämä ennustettavuus on arvokkaampaa kuin se joustavuus, josta joudutaan luopumaan. Ethereum ratkaisee rajattoman laskennan ongelman kaasurajoituksilla: se veloittaa käyttäjiltä jokaisesta suoritetusta opkoodista ja keskeyttää skriptit, joiden budjetti loppuu. Se toimii, mutta tuo mukanaan omat monimutkaisuutensa ja vikamahdollisuutensa. Bitcoin kiertää ongelman kokonaan jo suunnitteluvaiheessa.

Tästä huolimatta ”ei Turing-täydellinen” ei tarkoita, että se ”ei kykene monimutkaiseen logiikkaan”. Bitcoin Script tukee monen osapuolen maksuvaatimuksia, aikaperusteisia ehtoja, hash-kuvan alkuperäkuvan paljastamista sekä näiden kaikkien yhdistelmiä. Lightning Network, joka välittää miljoonia maksuja päivittäin, on rakennettu kokonaan Bitcoin Scriptin peruselementtien varaan.

Skriptityypit: Kehitys P2PKH:sta Taprootiin

Bitcoinin skriptikerros on kehittynyt merkittävästi vuodesta 2009 lähtien, ja jokainen päivitys on tuonut mukanaan uuden transaktiomuodon säilyttäen samalla taaksepäin yhteensopivuuden kaikkien aiempien versioiden kanssa.

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

Alkuperäinen muoto, jota käytettiin ensimmäisissä Bitcoin-transaktioissa, mukaan lukien Satoshin maksu Hal Finneylle lohkossa 170. Varat sidottiin suoraan täydelliseen julkiseen avaimeen sen sijaan, että olisi käytetty sen hajautusarvoa. Nykyään sitä käytetään harvoin uusissa transaktioissa, koska se paljastaa julkisen avaimen lohkoketjussa ennen varojen käyttöä, mitä pidetään heikompana turvallisuuskäytäntönä kuin avaimen esihashaus.

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

Vakiomuoto jo yli vuosikymmenen ajan. P2PKH-järjestelmä sitoo varat julkisen avaimen hajautusarvoon avaimen sijaan, jolloin julkinen avain pysyy salaisena käyttöhetkeen asti. Tämä tuottaa lyhyemmän, 20 tavun pituisen osoitteen ja muodostaa perustan kaikille osoitteille, jotka alkavat numerolla ”1”. Unchainedin ketjutietojen (huhtikuu 2026) mukaan P2PKH-osoitteissa on tällä hetkellä noin 43 % louhitusta bitcoin-tarjonnasta.

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

P2SH otettiin käyttöön soft forkin kautta 1. huhtikuuta 2012, ja se siirsi monimutkaisten käyttöskripttien hallinnan lähettäjältä vastaanottajalle. Sen sijaan, että lähtöön upotettaisiin täydellinen lukitusskripti, P2SH-lähtö sisältää sitoumuksen ”lunastusskriptin” 20 tavun pituiseen hajautusarvoon. Koko skripti paljastuu vasta, kun kolikot käytetään. Tämä teki monen allekirjoituksen järjestelmästä käytännöllisen tavallisille käyttäjille: 2-of-3-monen allekirjoituksen järjestelmässä lähettäjän ei enää tarvinnut nähdä kaikkia kolmea julkista avainta maksuhetkellä. P2SH-osoitteet alkavat numerolla ”3”.

Yksityiskohtainen selvitys siitä, miten P2SH-validointi toimii protokollatasolla, löytyy developer.bitcoin.org:n tapahtumaopas opastaa vaihe vaiheelta Redeem-skriptin toimintaperiaatteen läpi.

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

Segregated Witness, joka otettiin käyttöön elokuussa 2017 lohkossa 481 824, siirsi allekirjoitustiedot päätapahtuman rungon ulkopuolelle erilliseen todistajarakenteeseen. Todistajatietoihin sovelletaan 75 prosentin painoalennusta, mikä tekee SegWit-tapahtumista huomattavasti edullisempia. Tavallinen yhden syötteen ja kahden ulostulon P2WPKH-transaktio painaa noin 141 virtuaalibytettä, kun vastaavan P2PKH-transaktion paino on 226 virtuaalibytettä, mukaan Sparkin analyysi Bitcoin-osoitetyypeistä maaliskuusta 2026 lähtien. SegWit korjasi myös transaktioiden muokattavuusongelman, mikä oli Lightning-verkon käyttöönoton edellytys. Alkuperäiset SegWit-osoitteet alkavat merkkijonolla ”bc1q”.

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

Taproot otettiin käyttöön marraskuussa 2021 lohkossa 709 632, ja se on Bitcoinin skriptikerroksen merkittävin päivitys SegWitin jälkeen. Sen myötä otettiin käyttöön Schnorr-allekirjoitukset, uusi MAST-tukea sisältävä ulostulotyyppi sekä päivitetty skriptikieli Tapscript. Taproot-osoitteet alkavat merkkijonolla ”bc1p.”

Taproot ja Tapscript: Miten Bitcoinin skriptikieli muuttui vuonna 2021

Taproot ei ole yksittäinen muutos. Se koostuu kolmesta Bitcoin Improvement Proposals -ehdotuksesta, jotka on suunniteltu yhdessä ja otettu käyttöön samanaikaisesti.

BIP 340: Schnorr-allekirjoitukset

Bitcoinissa käytettiin alun perin ECDSA-algoritmia (Elliptic Curve Digital Signature Algorithm). Satoshi valitsi sen osittain siksi, että Schnorr-allekirjoitukset olivat tuolloin patenttisuojattuja. Kyseinen patentti raukesi vuonna 2008, ja Taproot-päivityksen myötä Schnorr-allekirjoitukset otettiin vihdoin käyttöön protokollassa.

Schnorr-allekirjoitukset ovat kooltaan pienempiä (64 tavua) verrattuna ECDSA:n 71–73 tavuun. Vielä tärkeämpää on, että ne tukevat avainten yhdistämistä MuSig2-nimisen järjestelmän avulla. Avainten yhdistämisen ansiosta useat allekirjoittajat voivat yhdistää omat avaimensa ja allekirjoituksensa yhdeksi yhdistetyksi avaimeksi ja allekirjoitukseksi, jota ei voida erottaa ketjussa tavallisesta yhden allekirjoittajan maksusta. Taprootin yhteistyöavainpolkua käyttävä 2-of-3-monen allekirjoituksen lompakko näyttää lohkoketjussa täysin samalta kuin tavallinen maksu. Tämä on todellinen yksityisyyden parannus kaikille, jotka pitävät bitcoineja monimutkaisessa säilytysjärjestelyssä.

BIP 341: Pay-to-Taproot ja MAST

P2TR ottaa käyttöön uuden lähtötyypin, jossa on kaksi maksureittiä:

• A avainpolku käyttää Schnorr-allekirjoitusta, jota käytetään silloin, kun kaikki osapuolet ovat yhtä mieltä ja haluavat valita yksinkertaisimman ja edullisimman vaihtoehdon
• A skriptin polku käyttää MAST-rakennetta (Merkelized Abstract Syntax Tree, joka on kyseisen konseptin Taproot-toteutus)

MAST-tekniikan avulla yksi ulostulo voidaan liittää useista käyttöskripteistä koostuvaan puuhun Merkle-juuren kautta. Käytön yhteydessä ketjussa paljastetaan vain se ehto, jota tosiasiallisesti käytetään. Kaikki muut puussa mahdolliset käyttöpolut pysyvät pysyvästi piilossa. Käyttäjälle, joka on määrittänyt monimutkaisen käyttökäytännön, esimerkiksi ”Voin käyttää varoja normaalisti, tai kaksi kolmesta valtuutetusta voi käyttää varoja kuuden kuukauden kuluttua, tai palautusavain voi käyttää varoja kahden vuoden kuluttua”, vain se reitti, joka tosiasiallisesti toteutetaan, näkyy koskaan lohkoketjussa.

Vuonna 2024 Taprootin osuus Bitcoin-transaktioista oli kasvanut noin 42 prosenttiin, mikä johtui suurelta osin Ordinals- ja BRC-20-merkintöjen käytöstä, kuten Spark maaliskuussa 2026 siteerasi Glassnoden tietoja. Osuus on sen jälkeen vaihdellut markkinatilanteen mukaan, mutta infrastruktuuri on nyt vakiintunut kaikissa suurimmissa lompakoissa ja pörsseissä. Bitcoin Optechin Taproot-aihesivu seuraa Taprootin ympärillä käynnissä olevaa protokollan kehittämistä.

BIP 342: Tapscript

Tapscript on päivitetty skriptikieli, jota käytetään Taproot-järjestelmän skriptipolun mukaisissa maksuissa. Se käyttää suurinta osaa vanhan Bitcoin Scriptin opkoodeista, mutta siihen on tehty useita merkittäviä muutoksia:

• OP_CHECKMULTISIG ja OP_CHECKMULTISIGVERIFY ovat vanhentuneita. Vanha multisig-opkoodi sisälsi erikoisuuden, joka vaati väliaikaisena ratkaisuna näennäiselementin lisäämistä pinoon. Tapscript poistaa tämän ja korvaa sen OP_CHECKSIGADD, joka tarkistaa Schnorr-allekirjoitukset yksi kerrallaan ja laskee niiden lukumäärän. Kynnysarvoon perustuvien monen allekirjoituksen järjestelmien toteutus muuttuu selkeämmäksi ja edullisemmaksi.
• MAST-lehden skriptien kokorajoitukset on poistettu. Taproot-haaran yksittäiset skriptit voivat olla minkä tahansa kokoisia.
• OP_SUCCESS-opkoodit ovat kaikkein tulevaisuuteen suuntautuvin muutos. Vanhemmassa Script-kielessä määrittelemättömän opkoodin kohtaaminen aiheuttaa skriptin epäonnistumisen. Tapscript-kielessä OP_SUCCESS-alueen opkoodit saavat skriptin onnistumaan ehdoitta. Tulevissa soft forkeissa näille opkoodeille voidaan määrittää todellinen käyttäytyminen lisäämällä rajoituksia niiden onnistumisen ehtoihin ilman, että tarvitaan uutta skriptiversiota tai koko ekosysteemin kattavaa uudelleenasennusjaksoa. Uusia ominaisuuksia voidaan lisätä Bitcoinin skriptikerrokseen selkeämmin kuin koskaan aiemmin protokollan historiassa.

Miniscript

Tapscriptin ohella myös siihen liittyvä Miniscript-projekti on tullut yhä merkittävämmäksi kehittäjille. Miniscript on jäsennelty tapa kirjoittaa Bitcoin Scriptin osajoukkoa, jota voidaan analysoida, yhdistellä ja allekirjoittaa yleisellä tasolla. Kun raaka Script vaatii manuaalista rakentamista ja on vaikea tarkastaa, Miniscript-skriptien oikeellisuus voidaan tarkistaa automaattisesti ja ne voidaan yhdistää suuremmiksi sääntöjoukoiksi. Se ei laajenna Scriptin toimintamahdollisuuksia, mutta tekee sen nykyisistä ominaisuuksista huomattavasti helpommin hyödynnettävissä lompakoita ja säilytystyökaluja kehittäville kehittäjille.

Mitä Bitcoin Script mahdollistaa: Käytännön sovellukset

Seuraavat transaktiotyypit ovat tällä hetkellä käytössä Bitcoinin pääverkossa, ja ne kaikki perustuvat Bitcoin Scriptin perusrakenteisiin:

Monen allekirjoituksen (multisig) lompakot vaatii M/N yksityisavainta kulutuksen hyväksymiseen. Yrityksen kassanhallinta saattaa vaatia 3/5 hyväksyntää mihin tahansa nostoon. Aviopari saattaa käyttää 2/2-mallia yhteisiin säästöihin. Taprootin ja Schnorr-avaimen yhdistämisen ansiosta yhteistyöhön perustuvat monen allekirjoituksen maksut ovat nyt ketjussa erottamattomia tavallisista yhden allekirjoituksen transaktioista.

Aikasidonnaiset tapahtumat Käytä OP_CHECKLOCKTIMEVERIFY- (CheckLockTimeVerify, eli CLTV) ja OP_CHECKSEQUENCEVERIFY- (CheckSequenceVerify, eli CSV) komentoja estämään varojen siirto ennen tiettyä lohkon korkeutta tai kulunutta aikaa. Sovelluksia ovat esimerkiksi perintösuunnittelu, työntekijöiden tokenien vapautumisaikataulut, pakolliset säästämismekanismit sekä Lightning Network -kanavissa käytettävät rangaistustransaktiot.

Hash-pohjaiset aikasidonnaiset sopimukset (HTLC:t) yhdistää hash-arvon alkuperäkuvan vaatimuksen aikalukkoon. Käyttöehto toimii seuraavasti: tämän hash-arvon alkuperäkuva on paljastettava ennen tämän lohkon korkeutta, tai varat palautuvat lähettäjälle. HTLC:t ovat Lightning-verkon keskeinen peruselementti, joka mahdollistaa luottamuksettoman maksujen reitittämisen kanavaketjujen kautta osapuolten välillä, joilla ei ole suoraa suhdetta toisiinsa.

Escrow Järjestelyissä varat lukitaan P2SH- tai Taproot-skriptiin, joka edellyttää useiden osapuolten suostumusta varojen vapauttamiseksi; yleensä ratkaisevan avaimen hallussapitäjänä toimii ulkopuolinen välimies.

Discreet Log -sopimukset (DLC) käyttää Oracle-pohjaisia Schnorr-sovitinallekirjoituksia, jotta rahoitussopimukset voidaan toteuttaa todellisten tietojen, kuten hintatietojen tai tapahtumien tulosten, perusteella ilman, että Oracle joutuu ottamaan varoja hallintaansa. DLC:t ovat käytössä Bitcoinin pääverkossa, ja niitä käytetään Bitcoinilla toteutettaviin optio- ja futuurituotteisiin.

Bitcoin-skripti vs. Ethereumin älykkäät sopimukset

Sekä Bitcoin Script että Ethereumin Solidity määrittelevät ehdot, joiden mukaisesti varoja voidaan siirtää, mutta ne edustavat perustavanlaatuisesti erilaisia arkkitehtonisia valintoja. Vertailu on syytä tehdä suoraan, sillä erot selittävät paljon siitä, millaisia kompromisseja kukin verkko on hyväksynyt.

Keskeinen ero on tilallisuus. Ethereumin sopimukset tallentavat ja muokkaavat tietoja, jotka säilyvät transaktioiden yli, mikä mahdollistaa lainanantoprotokollat, hajautetut pörssit, ketjussa tapahtuvan hallinnon ja token-standardit. Bitcoin Scriptissä ei ole vastaavaa ominaisuutta. Jokainen skripti toimii erillään muista transaktioista ilman tietoa muista transaktioista.

Kyseessä on tietoinen arkkitehtoninen valinta, ei aukko, joka odottaisi täyttämistä. Bitcoinin skriptikerros on suunniteltu yhtä tiettyä tehtävää varten: varmistamaan, että bitcoinin käyttämisen ehdot täyttyvät ennustettavasti ja turvallisesti laajassa mittakaavassa. Tässä tehtävässä tilattomuus on vahvuus. Hyökkäyspinta-ala on pienempi, suoritus on determinististä miljoonien itsenäisten validoijien keskuudessa, eikä protokollatasolla ole minkäänlaista älykkäiden sopimusten hyväksikäyttöä, koska protokollatasolla ei ole tilallisia sopimuksia.

Hankkeet, jotka haluavat lisätä Bitcoinin ohjelmoitavuutta, rakentavat järjestelmänsä kerroksittain. Lightning Network hoitaa maksut. DLC-protokollat käsittelevät ulkoisiin tietoihin viittaavia rahoitussopimuksia. Ark- ja Liquid Network -kaltaiset Layer-2-järjestelmät vastaavat erilaisiin skaalautuvuusvaatimuksiin. Mikään näistä ei vaadi peruskerroksen skriptimallin muuttamista.

Kovenanttikeskustelu: Mitä muutoksia Bitcoin Scriptissä voisi tapahtua

Bitcoin-skriptin kehitys on aina ollut hidasta ja varovaista. Tällä hetkellä aktiivisinta kehitystyötä tehdään niin sanottujen covenant-opkoodien parissa. Nämä ovat ehdotuksia, joiden avulla skripti voisi rajoittaa paitsi sitä, kuka voi käyttää ulostuloa, myös sitä, millainen tuloksena olevan transaktion on oltava. Tämä on merkittävä laajennus skriptin ilmaisumahdollisuuksiin.

Kesäkuussa 2026 johtavina ehdotuksina ovat:

• OP_CTV (BIP-119, CheckTemplateVerify), jonka on laatinut Jeremy Rubin, lisää yhden opkoodin, joka sitouttaa UTXO:n tiettyyn, ennalta määrättyyn käyttömalliin, joka sisältää transaktion version, lukitusajan, syötteiden lukumäärän, sekvenssit, tulosteiden lukumäärän ja tulosteet. Se on suunniteltu ei-rekursiiviseksi, ja sitä pidetään konservatiivisimpana merkittävänä ehdotuksena. Se kohdistuu ensisijaisesti vaulteihin, ruuhkien hallintaan ja tiettyihin Lightning-parannuksiin. Huhtikuussa 2026 OP_CTV:llä on pöydällä konkreettiset käyttöönottoparametrit, joissa määritellään Speedy Trial -signalointi-ikkuna, mutta se ei ole vielä saavuttanut aktivointiin vaadittavaa laajaa yhteisön konsensusta, kuten BlockEdenin huhtikuun 2026 velvoiteanalyysi.
• OP_CAT (BIP-347), jonka ovat ehdottaneet Ethan Heilman ja Armin Sabouri, ottaisi uudelleen käyttöön opkoodin, jonka Satoshi poisti käytöstä vuonna 2010. OP_CAT yhdistää kaksi pinoelementtiä, mikä on yksinkertaista kuvailla, mutta jolla on laaja-alaisia vaikutuksia. Yhdistettynä Schnorr-allekirjoituksiin se mahdollistaa sopimuksen kaltaisen transaktioiden tarkastelun. Bitcoin Signet -testiverkossa OP_CAT oli tuottanut huomattavasti enemmän kehittäjien transaktioita kuin APO tai CTV, sCryptin vuoden 2024 lopun ketjuanalyysin mukaan. OP_CAT on jo käytössä Liquid Networkissä ja Fractal Bitcoinissa, eikä siihen ole liitetty yhtään haavoittuvuutta. BIP-347:llä on virallinen ehdotusnumero ja sen takana on aktiivista tutkimusta, mutta sen aktivointi pääverkossa edellyttää yhteisön konsensusta, jota ei vielä ole saavutettu.
• LNHANCE yhdistää OP_CTV:n OP_CHECKSIGFROMSTACK (CSFS) - ja OP_INTERNALKEY-komentoihin, ja sen tavoitteena on tuoda tiettyjä parannuksia Lightning Networkin kanavien rakentamiseen, mukaan lukien ei-interaktiiviset kanavien avaukset ja tehokkaampi monen osapuolen kanavien hallinta.

Yhtäkään näistä ei ole otettu käyttöön Bitcoinin pääverkossa kesäkuuhun 2026 mennessä. Niiden väliset tekniset erimielisyydet ovat suurelta osin ratkaistavissa. Vaikeampi ongelma on aktivointimekanismi. Bitcoinin soft fork -prosessi vaatii laajaa konsensusta, ja sopimuskeskusteluun liittyy jäänteitä aiemmista kiistanalaisista päivityksistä. Keskustelusta käy selväksi, että Bitcoinin skriptikerroksella on merkittävää kasvunvaraa sen konservatiivisen kehyksen sisällä. Käsiteltävänä oleva kysymys koskee järjestystä ja yhteisön yksimielisyyttä, ei sitä, onko skriptikielellä tulevaisuutta.

Johtopäätös

Bitcoin Script on verkoston jokaisen transaktion taustalla toimiva näkymätön infrastruktuuri. Useimmat käyttäjät eivät koskaan kohtaa sitä suoraan. Lompakot rakentavat kelvollisia skriptejä, allekirjoittavat ne ja lähettävät ne eteenpäin paljastamatta koskaan niiden toimintaa. Mutta jokainen maksu, jokainen Lightning-kanava, jokainen aik lukittu suunnitelma ja jokainen monen allekirjoituksen vaati vaati käyttää samaa pinoon perustuvaa Bitcoin-skriptikieltä, joka toimitettiin protokollan mukana vuonna 2009.

Skriptikerros on kasvanut huomattavasti siitä lähtien: P2SH on mahdollistanut monimutkaisten maksujen käytännön toteutuksen, SegWit on alentanut maksuja ja mahdollistanut Lightning-verkoston, ja Taproot on tuonut mukanaan Schnorr-allekirjoitukset, MAST-pohjaisen tietosuojan sekä Tapscriptin eteenpäin yhteensopivan opkoodisuunnittelun. Tällä hetkellä aktiivisesti keskustelun kohteena olevat covenant-ehdotukset edustavat seuraavaa mahdollista vaihetta. Toteutuvatko ne ja millä aikataululla, on vuoden 2026 puolivälissä vielä täysin auki.

Scriptin ymmärtäminen ei vaadi kehittäjän taitoja. Se vaatii kuitenkin sen ymmärtämistä, että Bitcoinin konservatiivisuus, tarkoitukselliset rajoitukset, hidas päivitystahti ja Turingin täydellisyyden puuttuminen eivät ole puutteita. Ne ominaisuudet, jotka tekevät Bitcoin Scriptistä ennustettavan, ovat samat ominaisuudet, jotka ovat pitäneet konsensuskerroksen puhtaana jo kuusitoista vuotta.