Agar skrip redeem memenuhi kondisi skrip, apa yang harus ditinggalkannya pada eksekusi pasca tumpukan?
Saya menonton presentasi Andreas Antonopoulos tentang Advanced Bitcoin Scripting.
Tampak dari contoh Andreas bahwa agar skrip penebusan memenuhi kondisi skrip, ia harus meninggalkan TRUE (dan tidak ada yang lain) di tumpukan setelah dijalankan. Ini juga ditanyakan di sini .
Oleh karena itu, ada sufiks VERIFIKASI sehingga beberapa opcode (mis. EQUAL, CHECKSIG, CHECKMULTISIG) memiliki opcode yang bersaing (mis. EQUALVERIFY, CHECKSIGVERIFY, CHECKMULTISIGVERIFY). Alih-alih meninggalkan TRUE di tumpukan, opcode VERIFIKASI ini akan "melanjutkan eksekusi Script jika hasil dari operator bersyarat BENAR" tetapi "tidak akan mendorong TRUE itu kembali ke tumpukan, itu hanya akan melanjutkan eksekusi". Opcode VERIFIKASI ini dapat digunakan untuk memastikan eksekusi skrip penebusan meninggalkan TRUE (dan tidak ada yang lain) di tumpukan daripada mengatakan TRUE TRUE TRUE.
Namun, dalam sesi klub ulasan Bitcoin Core PR ini, Pieter Wuille menyatakan (parafrase):
Untuk CLEANSTACK Anda harus memiliki tumpukan dengan satu elemen di dalamnya yang harus bukan nol. Tanpa CLEANSTACK tumpukan yang tidak kosong dengan beberapa elemen tidak masalah selama elemen teratas bukan nol
Saya punya dua pertanyaan:
Agaknya TRUE setara dengan 1 dan FALSE setara dengan 0?
Setiap opcode yang dievaluasi ke FALSE akan mengakibatkan kegagalan langsung dan penghentian eksekusi? Jadi dengan non-CLEANSTACK Anda tidak akan pernah melihat tumpukan hasil pass TRUE FALSE TRUE karena FALSE akan langsung mengakibatkan kegagalan dan Anda tidak akan menilai TRUE akhir. Namun, Anda bisa melihat tumpukan mengatakan TRUE 3 TRUE 5 dan ini akan lolos dengan non-CLEANSTACK. (Ini akan gagal dengan CLEANSTACK karena CLEANSTACK harus memiliki satu elemen dalam tumpukan yang dihasilkan).
Jawaban
Terima kasih telah berusaha keras menjawab pertanyaan ini di IRC dan sanket1729 untuk pengeditan.
Agaknya TRUE setara dengan 1 dan FALSE setara dengan 0?
TRUE adalah nilai selain nol. Ini sering digunakan dalam skrip yang melibatkan opcode OP_NOPx sebelumnya yang tidak mengeluarkan nilainya dari tumpukan setelah verifikasi, misalnya skrip yang dapat digunakan oleh penambang setelah ketinggian tertentu dapat menggunakan <locktime> OP_CLTV:; jika CLTV gagal, transaksi tidak valid; jika lolos, maka nilai bukan nol yang tersisa di tumpukan memungkinkan skrip untuk lewat.
Setiap opcode yang dievaluasi ke FALSE akan mengakibatkan kegagalan langsung dan penghentian eksekusi? Jadi dengan non-CLEANSTACK Anda tidak akan pernah melihat tumpukan hasil pass TRUE FALSE TRUE karena FALSE akan langsung mengakibatkan kegagalan dan Anda tidak akan menilai TRUE akhir. Namun, Anda bisa melihat tumpukan mengatakan TRUE 3 TRUE 5 dan ini akan lolos dengan non-CLEANSTACK. (Ini akan gagal dengan CLEANSTACK karena CLEANSTACK harus memiliki satu elemen dalam tumpukan yang dihasilkan).
Semua yang penting tanpa CLEANSTACK adalah nilai teratas pada tumpukan di akhir eksekusi. Apa pun yang berada di bawah tumpukan tidak masalah.
CLEANSTACK adalah aturan standar untuk P2SH tetapi ini adalah aturan konsensus untuk Segwit v0 ( spesifikasi BIP141 ) dan Tapscript, SegWit v1 ( spesifikasi BIP342 , aturan 4, ii)
Kata "kegagalan" di sini ambigu. Ada berbagai cara berbeda opcode dapat gagal. Misalnya, jika OP_CHECKSIG gagal, ini hanya mendorong 0 ke tumpukan. Tetapi jika OP_CHECKSIGVERIFY gagal, seluruh skrip gagal. Anda dapat meletakkan TRUE FALSE FALSE pada tumpukan hanya dengan OP_0 OP_0 OP_1.
Beberapa opcode VERIFIKASI misalnya EQUALVERIFY, CHECKSIGVERIFY, CHECKMULTISIGVERIFY segera berakhir jika gagal tetapi padanan non-VERIFY mereka tidak.
Yang terpenting adalah status tumpukan di akhir evaluasi skrip. Misalnya, Anda dapat melakukan OP_CHECKSIG diikuti dengan OP_IF OP_PUSHNUM1 OP_ELSE OP_PUSHNUM2 OP_ENDIF, misalnya jika tanda tangan berhasil, ambil satu cabang; jika gagal, ambil cabang lain (Ini tidak dianggap praktik terbaik dan umumnya tidak boleh dilakukan.)
CLEANSTACK adalah upaya untuk mencegah kelenturan dengan meminta orang menaruh banyak sampah di scriptSig atau data saksi. Karena Anda bisa mendorong sekumpulan data ke tumpukan yang tidak pernah digunakan dan tidak mencegah skrip mengevaluasi dengan benar. (Pre-segwit, ini mempengaruhi kelenturan txid dan diberlakukan sebagai aturan kebijakan standar; dengan segwit, ini tidak lagi mungkin karena ini adalah aturan konsensus)