Bitcoin Script

Alice menerima 20 000 sat, dua puluh ribu satuan terkecil bitcoin. Jaringan tidak membuka rekening atas namanya. Yang dibuat adalah output transaksi: nilai dana beserta syarat untuk membelanjakannya nanti. Selama belum dibelanjakan, output itu disebut UTXO. Dalam pembayaran biasa, syaratnya meminta tanda tangan dengan kunci yang sesuai. Ketika Alice membayar di kemudian hari, dompetnya memilih output ini, merujuknya melalui input transaksi baru, dan membuat tanda tangan digital. Dompet menggunakan kunci privat tanpa mengirimkannya ke mana pun; pihak lain memverifikasi tanda tangan dengan kunci publik. Mengetahui alamat penerimaan Alice saja tidak cukup. Syarat output awal dicatat dalam kolom scriptPubKey, dan Bitcoin Script menentukan cara memeriksa pemenuhannya. Node bukan petugas yang mengenali Alice, melainkan komputer yang memeriksa aturan. Selain tanda tangan, node harus memeriksa, misalnya, apakah output yang sama sudah dibelanjakan. Transaksi baru valid jika semua aturan yang berlaku dipenuhi. [4] [2]

Untuk pembayaran biasa, dompetlah yang menyusun syarat. Ikuti petunjuk pencadangannya: pemulihan normal dari kata-kata cadangan pada dompet yang kompatibel tidak otomatis mengharuskan Anda menyimpan setiap skrip secara manual. Namun, dalam susunan yang lebih rumit, seperti Multisig yang memerlukan beberapa tanda tangan, kata-kata milik satu peserta mungkin tidak menggambarkan seluruh pengaturan pembelanjaan. Untuk penggunaan sehari-hari, pilih dompet dengan prosedur yang telah teruji alih-alih merakit skrip sendiri dalam notasi heksadesimal. Deskriptor output menjelaskan jenis skrip, kunci, dan cara penurunannya, sehingga membantu menentukan apa yang perlu dicari oleh dompet yang dipulihkan. Kunci privat saja mungkin tidak cukup untuk memulihkan susunan yang lebih rumit. Simpan pula skrip yang diperlukan dan informasi asal kunci, yaitu dari mana serta bagaimana kunci diturunkan, lalu verifikasi jalur pembelanjaan yang memang ingin digunakan. [11]

Bab-bab berikut menjelaskan penulisan syarat di dalam transaksi; Anda tidak harus memahaminya untuk melakukan pembayaran sehari-hari. Kolom scriptSig dan bagian bernama witness menyediakan data verifikasi. Hash adalah sidik jari data, sedangkan penguncian waktu mencegah pembelanjaan sebelum batas tertentu. Bayangkan stack sebagai tumpukan unsur data yang diambil dan ditambahkan dari bagian atas. Script memproses data melalui tumpukan: nilai dimasukkan ke tumpukan, lalu instruksi yang disebut opcode mengambil, membandingkan, atau memprosesnya dengan cara lain. Instruksi tanda tangan memverifikasi tanda tangan; kunci privat maupun pembuatan tanda tangan tidak termasuk dalam verifikasi ini. Bahasa tersebut dapat menggabungkan tanda tangan, syarat hash, dan penguncian waktu. Script tidak memiliki perulangan umum dan bukan Turing-complete: tidak semua perhitungan yang dapat dinyatakan dalam bahasa pemrograman serbaguna dapat dinyatakan di dalamnya. Node harus memakai aturan yang tepat untuk jenis output dan versi skrip yang bersangkutan. [1] [3]

Pada P2PKH (Pay to Public Key Hash), output umumnya berbentuk OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. Input menyediakan tanda tangan dan kunci publik melalui scriptSig. Verifikasi memeriksa apakah hash kunci publik cocok dengan nilai dalam output, lalu memverifikasi tanda tangan. Karena itu, mengetahui alamat atau kunci publik saja tidak cukup untuk membelanjakan output tersebut. Kunci privat digunakan oleh dompet yang menandatangani, bukan oleh node yang memeriksa transaksi. [1]

P2SH menurut BIP16 menyimpan hash skrip di output. Input yang membelanjakannya menyediakan redeemScript yang sesuai, yaitu skrip yang diungkap saat pembelanjaan, beserta data yang diperlukan. scriptSig hanya boleh memuat instruksi yang memasukkan data. Node terlebih dahulu memeriksa kecocokan hash, lalu mengevaluasi redeemScript menggunakan unsur tumpukan yang tersisa. Hash yang benar saja belum cukup: syarat skrip itu juga harus terpenuhi. [5]

Pada SegWit versi 0, data verifikasi dipindahkan ke bagian transaksi yang disebut witness. Bagian ini adalah daftar unsur data, bukan sebuah skrip dengan sendirinya. P2WPKH menggunakan tanda tangan dan kunci publik; P2WSH juga memuat witnessScript, yang hash SHA256-nya harus cocok dengan output. Pada SegWit native, scriptSig kosong. Jika dibungkus dalam P2SH, scriptSig hanya memuat instruksi untuk memasukkan program witness yang sesuai; data verifikasi sebenarnya tetap berada di witness. [6]

Verifikasi tanda tangan menggunakan pesan yang diturunkan dari transaksi melalui prosedur yang ditentukan. Mode SIGHASH menetapkan bagian transaksi mana yang dilindungi tanda tangan dari perubahan. Jadi, kita tidak dapat serta-merta mengatakan bahwa setiap tanda tangan mencakup seluruh transaksi. BIP143 selalu menyertakan nilai output yang dibelanjakan dalam operasi tanda tangan SegWit versi 0. Dompet harus mengetahui data yang benar dan mode yang dipilih; saat memeriksa, Script tidak menilai maksud manusia yang menandatangani. [7]

Taproot menurut BIP341 memungkinkan output P2TR (Pay to Taproot) dibelanjakan dengan dua cara. Jalur kunci memverifikasi tanda tangan Schnorr terhadap kunci publik output tanpa mengungkap skrip. Sebaliknya, jalur skrip mengungkap skrip yang dipilih beserta blok kontrol, disebut control block, yang membuktikan keterkaitannya dengan output. Skrip lain dalam pohon tidak harus diungkap. Aturan bagi skrip yang diungkap juga bergantung pada versi daun yang bersangkutan. [8]

BIP342 menetapkan Tapscript untuk daun Taproot versi 0xc0. Instruksi tanda tangannya menggunakan tanda tangan Schnorr, dan OP_CHECKSIGADD memungkinkan penyusunan syarat yang memerlukan beberapa tanda tangan. OP_CHECKMULTISIG yang lama dilarang ketika dijalankan. Batas lama panjang skrip sebesar 10 000 byte dan batas 201 opcode yang dihitung menurut aturan terdahulu tidak diberlakukan di sini. Jumlah operasi tanda tangan dibatasi anggaran yang diturunkan dari ukuran witness; batas tumpukan tetap berlaku. Karena itu, batas satu versi tidak boleh dianggap sebagai sifat umum seluruh Script. [9]

Aturan konsensus menentukan apakah pembelanjaan dalam blok valid. Kriteria standar transaksi di sini adalah aturan lokal tambahan pada node untuk menerima transaksi yang belum dikonfirmasi ke Mempool dan meneruskannya, bukan proses standardisasi. Maka, transaksi yang valid menurut konsensus belum tentu diteruskan secara umum. OP_SUCCESSx dalam Tapscript memerlukan perhatian khusus: setelah pemeriksaan sebelumnya berhasil, pengenalannya saat penguraian membuat verifikasi skrip langsung berhasil, sebelum eksekusi biasa dan pemeriksaan tumpukan. Ini menyediakan ruang untuk pengembangan mendatang, bukan syarat pembelanjaan biasa yang aman. [10] [9]