"Covenants" Bitcoin adalah mekanisme yang menetapkan kondisi untuk transaksi Bitcoin di masa depan. Artikel ini menjelaskan konsep dasar, skenario aplikasi, dan metode implementasi teknis dari klausa pembatasan, dan membahas prinsip desain di baliknya. Proposal teknis seperti OP_CAT, OP_CTV, dan APO diperkenalkan, dan bagaimana mereka meningkatkan programmabilitas dan fungsi kontrak pintar Bitcoin. Pada saat yang sama, artikel juga membahas aplikasi klausa pembatasan dalam jaringan Bitcoin, seperti pengendalian kemacetan, vault, saluran status, dll., dan mendiskusikan gagasan desain untuk mengimplementasikan klausa pembatasan dan sengketa komunitas potensial.

Ditulis bersama olehJeffrey HudanHarper Li

Belakangan ini telah terjadi gelombang diskusi di komunitas Bitcoin tentang pengaktifan ulang opcode seperti OP_CAT, dan Taproot Wizard telah menarik banyak perhatian dengan meluncurkan NFT Quantum Cats, yang mengklaim telah ditugaskan BIP-420. Para pendukung mengklaim bahwa mengaktifkan OP_CAT akan mewujudkan “covenants”, dan dengan demikian membawa kontrak pintar atau programmabilitas di Bitcoin.

Jika Anda memperhatikan kata 'perjanjian' dan melakukan sedikit penelusuran, Anda akan melihat bahwa ini adalah lubang kelinci besar lainnya. Pengembang telah berbicara selama bertahun-tahun tentang teknologi yang mengimplementasikan perjanjian, seperti OP_CTV, APO, OP_VAULT, dan lainnya, selain OP_CAT.

Lebih tepatnya, skrip Bitcoin saat ini juga memiliki beberapa jenis perjanjian, seperti kunci waktu berbasis opcode, yang diimplementasikan dengan mengintrospeksi bidang nLock atau nSequence transaksi untuk membatasi jumlah waktu sebelum transaksi dapat dihabiskan, tetapi masih terbatas pada pembatasan waktu.

Jadi apa sebenarnya "covenants" Bitcoin? Mengapa telah menarik begitu banyak perhatian dan diskusi dari para pengembang selama bertahun-tahun? Apa yang dapat dicapai dari programmabilitas Bitcoin? Apa prinsip desain di baliknya? Artikel ini berusaha memberikan gambaran dan diskusi.

Apa itu 'Perjanjian'?

Perjanjian adalah mekanisme yang dapat menetapkan kondisi pada transaksi Bitcoin di masa depan.

Sebenarnya skrip Bitcoin saat ini mengandung pembatasan, seperti harus memasukkan tanda tangan yang sah, mengirimkan skrip yang sesuai saat menghabiskannya. Selama pengguna dapat membukanya, ia dapat menghabiskan UTXO tersebut di mana pun ia inginkan.

Perjanjian adalah untuk membuat lebih banyak pembatasan di atas pembatasan ini tentang cara membuka kunci, seperti membatasi pengeluaran UTXO setelah dihabiskan, yang bertujuan mencapai efek yang mirip dengan yang ditandai, atau kondisi input lain yang dimasukkan ke dalam transaksi, dll.

Jadi mengapa para pengembang dan peneliti merancang pemeriksaan pembatasan ini? Itu karena covenants bukan hanya pembatasan tanpa alasan, tetapi lebih pada menetapkan aturan untuk pelaksanaan perdagangan. Dengan cara ini, pengguna hanya dapat melakukan transaksi sesuai dengan aturan yang telah ditetapkan sebelumnya, sehingga menyelesaikan proses bisnis yang dimaksud.

Jadi, agak kontra-intuitif, ini membawa lebih banyak skenario aplikasi.

Aplikasi Skenario

Memastikan Hukuman Staking

Salah satu contoh yang paling intuitif dari perjanjian adalah transaksi pemangkasan kota Babel dalam proses staking Bitcoin.

Proses staking Bitcoin Babylon melibatkan pengguna mengirimkan BTC mereka ke skrip khusus pada rantai utama dengan dua kondisi pengeluaran:

• Akhir yang bahagia: setelah sejumlah waktu tertentu, pengguna dapat membuka kunci dengan tanda tangan mereka sendiri, yang berarti proses pembukaan staking sudah selesai.
• Akhir yang buruk: Jika pengguna mengalami serangan double-spend pada rantai PoS, pengguna dapat membuka kunci aset dengan tanda tangan pribadinya melalui EOTS (tanda tangan sekali pakai yang dapat diekstrak), dan sebagian aset dapat dipaksa untuk dikirim ke alamat pembakaran oleh aktor yang menjalankan di jaringan.

Sumber: Bitcoin Staking: Membuka 21 Juta Bitcoin untuk Menjamin Ekonomi Proof-of-Stake

Perhatikan kata 'dipaksa', yang berarti bahwa bahkan jika UTXO dapat dibuka kunci, aset tidak dapat dikirim ke tempat lain, hanya bisa dibakar. Ini memastikan bahwa pengguna jahat tidak dapat mengirim aset kembali ke dirinya sendiri dengan tanda tangan yang diketahui.

Fitur ini, setelah menerapkan perjanjian seperti OP_CTV, dapat diimplementasikan dengan menambahkan opcode ke “akhir buruk” dari skrip staking.

Sebelum OP_CTV diaktifkan, Babel akan memerlukan solusi sementara untuk meniru efek penerapan perjanjian dengan cara membuat pengguna + komite bekerja sama.

Kontrol Kemacetan/Skala

Secara umum, kepadatan terjadi ketika biaya tinggi pada Bitcoin dengan jumlah transaksi yang cukup besar yang terakumulasi di kolam transaksi menunggu untuk dikemas, jadi jika seorang pengguna ingin mengonfirmasi transaksi dengan cepat, dia atau dia perlu meningkatkan biaya.

Pada titik tersebut, jika seorang pengguna harus mengirimkan beberapa transaksi ke beberapa alamat, mereka harus menaikkan biaya dan menanggung biaya yang lebih tinggi. Akibatnya, ini akan lebih meningkatkan biaya transaksi dari seluruh jaringan.

Jika ada perjanjian, maka ada solusi: satu transaksi yang berkomitmen dengan beberapa output. Komitmen ini dapat meyakinkan semua penerima bahwa transaksi akhir akan terjadi dan semua orang dapat menunggu sampai biaya rendah sebelum mengirimkan transaksi spesifik tersebut.

Seperti yang ditunjukkan di bawah ini, ketika permintaan ruang blok tinggi, biaya transaksi menjadi sangat mahal. Dengan menggunakan OP_CHECKTEMPLATEVERIFY, prosesor pembayaran berkapasitas besar dapat menggabungkan semua pembayarannya ke dalam satu transaksi O(1) untuk konfirmasi. Kemudian, setelah jangka waktu tertentu, ketika permintaan ruang blok menurun, pembayaran dapat diperluas dari UTXO tersebut

Sumber: https://utxos.org/penggunaan/skala/

Skenario ini adalah salah satu kasus penggunaan yang lebih khas yang disajikan oleh pembatasan OP_CTV ini. Banyak kasus penggunaan lain dapat ditemukan di https://utxos.org/uses.Selain kontrol kemacetan yang disebutkan di atas, halaman tersebut mencantumkan Soft Fork Bets, opsi Terdesentralisasi, Drivechains, Batch Channels, Non-Interactive Channels, Trustless Coordination-Free Mining Pools, Vaults, Safer Hashed Time Locked Contracts (HTLCS) Limits, dan lainnya.

Lemari besi

Vault adalah salah satu kasus penggunaan Bitcoin yang lebih banyak dibahas, terutama dalam ranah perjanjian. Karena operasi sehari-hari tidak terhindarkan melibatkan keseimbangan antara kebutuhan untuk menjaga dana tetap aman dengan kebutuhan untuk menggunakannya, seseorang ingin memiliki vault yang dapat menjaga dana tetap aman, atau bahkan membatasi penggunaannya ketika akun diretas (misalnya, mengompromikan kunci pribadi).

Berdasarkan teknik yang digunakan untuk menerapkan klausa pembatasan, jenis brankas penitipan ini dapat dibangun dengan relatif mudah.

Ambil skema desain OP_VAULT sebagai contoh: ketika mengeluarkan dana di vault, transaksi perlu dikirimkan ke rantai terlebih dahulu. Transaksi ini menunjukkan niat untuk mengeluarkan vault, yang merupakan "pemicu", dan kondisi ditetapkan di dalamnya:

• Jika semuanya baik, maka transaksi kedua akhirnya akan menarik dana. Setelah menunggu selama N blok, dana dapat dihabiskan lebih lanjut di mana saja.
• Jika ternyata transaksi tersebut dicuri (atau dipaksa dalam serangan “pemicu”), aset dapat segera dikirim ke alamat aman lainnya (lebih aman bagi pengguna) segera sebelum transaksi penarikan dikirim setelah N blok.

Proses OP_VAULT, sumber: BIP-345

Perlu diingat bahwa juga memungkinkan untuk membangun brankas tanpa perjanjian, dan cara yang mungkin dilakukan adalah menggunakan kunci pribadi untuk menyiapkan tanda tangan untuk pengeluaran nanti, lalu menghancurkan kunci pribadi ini. Namun, masih ada lebih banyak batasan, seperti perlunya memastikan bahwa kunci pribadi telah dihancurkan (serupa dengan proses setup yang terpercaya dalam bukti zero pengetahuan), dan kurangnya fleksibilitas dalam menentukan jumlah dan biaya di muka (karena pra-penandatanganan).

Vault yang telah dihitung sebelumnya dan OP_VAULT，sumber: BIP-345

Saluran negara yang lebih kuat dan fleksibel

Secara umum dapat diasumsikan bahwa saluran negara, termasuk Jaringan Petir, memiliki keamanan yang hampir sama dengan rantai utama (dalam hal memastikan bahwa node dapat mengamati status terbaru dan dapat dengan benar memposting status terbaru ke rantai). Namun, dengan klausul, beberapa desain saluran negara baru dapat dibuat di atas Jaringan Petir dengan lebih kokoh atau fleksibel. Beberapa yang lebih dikenal termasuk Eltoo, Ark.

Eltoo (juga dikenal sebagai LN-Symmetry) adalah contoh khas. Mengambil akronim “L2”, teknologi ini mengusulkan lapisan pelaksanaan untuk Jaringan Lightning yang memungkinkan setiap keadaan saluran kemudian untuk menggantikan keadaan sebelumnya tanpa mekanisme hukuman, sehingga menghindari kebutuhan bagi simpul Jaringan Lightning untuk menyimpan beberapa keadaan sebelumnya untuk mencegah lawan mereka melakukan tindakan jahat. Untuk mencapai efek tersebut, Eltoo mengusulkan tanda tangan SIGHASH_NOINPUT, APO (BIP-118).

Ark bertujuan untuk mengurangi kesulitan likuiditas masuk dan manajemen saluran jaringan petir. Ini adalah sebuah protokol dalam bentuk joinpool, di mana beberapa pengguna dapat menerima penyedia layanan sebagai pihak lawan untuk jangka waktu tertentu, dan melakukan perdagangan virtual UTXO (vUTXO) off-chain, tetapi berbagi UTXO on-chain untuk mengurangi biaya. Serupa dengan vaults, Ark dapat diimplementasikan pada jaringan Bitcoin saat ini; namun, dengan pengenalan covenants, Ark dapat mengurangi jumlah interaksi yang diperlukan berdasarkan templat transaksi, memungkinkan keluar yang lebih tidak terpercaya satu sisi.

Ikhtisar Perjanjian

Seperti yang dapat dilihat dari aplikasi di atas, perjanjian lebih seperti sebuah efek daripada teknologi tertentu, dan sebagai hasilnya ada banyak cara teknis untuk menerapkannya. Mereka dapat dikategorikan sebagai:

• Jenis: umum, membatasi
• Implementasi: berbasis opcode, berbasis tanda tangan
• Rekursi: rekursif, non-rekursif

Di sini rekursif berarti: ada beberapa implementasi perjanjian yang juga dapat membatasi output dari transaksi berikutnya dengan membatasi output dari transaksi ini, yang berarti setiap transaksi dalam rantai transaksi dibatasi oleh transaksi sebelumnya.

Beberapa desain perjanjian populer termasuk:

Desain Perjanjian

Seperti yang dapat dilihat dari pengantar sebelumnya, skrip Bitcoin saat ini terutama membatasi kondisi untuk membuka kunci dan tidak membatasi bagaimana UTXO tersebut dapat dihabiskan lebih lanjut. Untuk menerapkan perjanjian, kita perlu memikirkan sebaliknya: mengapa skrip Bitcoin saat ini tidak dapat melaksanakan perjanjian?

Alasan utamanya adalah skrip Bitcoin saat ini tidak dapat membaca transaksi itu sendiri, yang berarti introspeksi transaksi.

Jika kita bisa menerapkan introspeksi — memeriksa segala sesuatu dalam transaksi (termasuk output) — maka kita bisa menerapkan perjanjian.

Jadi desain perjanjian juga berpusat pada bagaimana menerapkan introspeksi.

Berdasarkan Opcode vs Berdasarkan Tanda Tangan

Ide yang paling sederhana dan kasar adalah menambahkan satu atau lebih opcode (satu opcode + beberapa parameter, atau beberapa opcode dengan fungsi yang berbeda) dan membaca konten transaksi secara langsung. Ini juga dikenal sebagai ide berbasis opcode.

Cara lain berpikir adalah daripada membaca dan memeriksa konten transaksi itu sendiri langsung dalam skrip, hash dari konten transaksi dapat digunakan, yang berarti jika hash ini telah ditandatangani, maka dengan mentransformasi opcode seperti OP_CHECKSIG dalam skrip untuk memeriksa tanda tangan ini, dimungkinkan untuk secara tidak langsung menerapkan introspeksi transaksi dan perjanjian. Ide ini didasarkan pada pendekatan desain tanda tangan. Ini terutama mencakup APO dan OP_CSFS.

APO

SIGHASH_ANYPREVOUT (APO) adalah proposal untuk tanda tangan hash. Cara termudah untuk menandatangani adalah dengan mengikatkan diri baik pada input maupun output transaksi, tetapi ada cara yang lebih fleksibel bagi Bitcoin untuk secara selektif mengikatkan diri pada input atau output transaksi, yang dikenal sebagai SIGHASH.

Rentang saat ini dari SIGHASH dan kombinasinya dari tanda tangan untuk input dan output transaksi (sumber: Mastering Bitcoin, 2nd)

Seperti yang ditunjukkan di atas, selain ALL, yang berlaku untuk semua data, NONE ditandatangani sedemikian rupa sehingga berlaku hanya untuk semua masukan dan bukan keluaran, dan SINGLE membangun atas ini dengan menerapkannya hanya untuk keluaran dengan nomor indeks masukan yang sama. Selain itu, SIGHASH dapat dikombinasikan, dengan modifikasi ANYONECANPAY disusun, untuk diterapkan hanya pada satu masukan.

SIGHASH APO, di sisi lain, hanya menandatangani output, bukan masukan. Ini berarti bahwa transaksi yang ditandatangani dengan APO dapat dilampirkan nanti ke setiap UTXO yang memenuhi syarat.

Fleksibilitas ini adalah alasan di balik implementasi kovenan APO:

• Satu atau lebih transaksi dapat dibuat lebih awal
• Informasi dari transaksi-transaksi ini digunakan untuk membuat kunci publik yang hanya tanda tangan pengeluaran bisa dihasilkan/diperiksa dari
• sehingga setiap aset yang dikirim ke alamat kunci publik ini hanya dapat dihabiskan melalui transaksi yang telah dibuat sebelumnya.

Perlu dicatat bahwa karena kunci publik ini tidak memiliki kunci pribadi yang sesuai, hal ini memastikan bahwa aset-aset ini hanya dapat dihabiskan melalui transaksi yang telah dibuat sebelumnya. Selanjutnya, kita dapat menerapkan perjanjian dengan menentukan kemana aset-aset tersebut akan dikirimkan dalam transaksi yang telah dibuat sebelumnya.

Hal ini dapat lebih dipahami dengan membandingkannya dengan kontrak pintar Ethereum: apa yang dapat kita capai dengan kontrak pintar adalah kita hanya dapat menarik uang dari alamat yang dikontrak jika beberapa kondisi terpenuhi, bukan menghabiskannya sembarangan dengan tanda tangan EOA. Dari sudut pandang ini, Bitcoin dapat mencapai efek ini melalui peningkatan dalam mekanisme tanda tangan.

Masalah dengan proses di atas, namun, adalah bahwa ada dev@lists.linuxfoundation.org/msg08075.html">ketergantungan lingkaran dalam perhitungan, karena seseorang perlu mengetahui masukan untuk pra-tanda tangan dan membuat transaksi.

Signifikansi dari implementasi APO dan SIGHASH_NOINPUT dari metode tanda tangan ini adalah bahwa hal itu memecahkan masalah ketergantungan lingkaran ini hanya perlu mengetahui (menentukan) output lengkap dari transaksi pada saat perhitungan.

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), atau BIP-119, menggunakan peningkatan ke Opcode. Itu mengambil hash komitmen sebagai argumen dan memerlukan bahwa setiap transaksi yang menjalankan opcode berisi serangkaian output yang sesuai dengan komitmen tersebut. Dengan CTV, pengguna Bitcoin dapat membatasi cara mereka menggunakan Bitcoin.

Awalnya diperkenalkan sebagai OP_CHECKOUTPUTSHASHVERIFY (COSHV) dan dengan fokus awal pada kemampuan untuk membuat transaksi kontrol kemacetan, kritik terhadap proposal ini juga berpusat pada kenyataan bahwa proposal tersebut tidak cukup generik dan terlalu spesifik untuk kasus penggunaan kontrol kemacetan.

Dalam kasus penggunaan kontrol kemacetan yang disebutkan di atas, Alice, si pengirim, dapat membuat 10 output dan menghash 10 output tersebut, dan menggunakan hasil digest untuk membuat skrip tapleaf yang berisi COSHV. Alice juga dapat menggunakan kunci publik dari para peserta untuk membentuk kunci internal Taproot yang memungkinkan mereka berkolaborasi dalam pengeluaran uang tanpa mengungkap jalur skrip Taproot.

Kemudian Alice memberikan setiap penerima salinan dari semua 10 output sehingga masing-masing dari mereka dapat memverifikasi transaksi pengaturan Alice. Ketika mereka ingin menghabiskan pembayaran nanti, salah satu dari mereka dapat membuat transaksi dengan output yang terkomitmen.

Sepanjang proses tersebut, saat Alice membuat dan mengirim transaksi setup, Alice dapat mengirim 10 salinan output ini melalui metode komunikasi asinkron yang sudah ada, seperti email atau cloud drive. Ini berarti penerima tidak perlu online atau berinteraksi satu sama lain.

Sumber: https://bitcoinops.org/id/newsletters/2019/05/29/#proposed-transaction-output-commitments

Mirip dengan APOs, alamat dapat dibangun berdasarkan kondisi pengeluaran, dan “kunci” dapat dibuat dengan berbagai cara, termasuk kunci tambahan, timelocks relatif atau tetap, dan logika lain untuk menggabungkannya.

Sumber:https://twitter.com/OwenKemeys/status/1741575353716326835

Berdasarkan hal ini, CTV mengusulkan untuk memeriksa apakah transaksi yang dihabiskan setelah hash cocok dengan yang telah ditentukan, yang berarti data transaksi digunakan sebagai kunci untuk membuka “kunci”.

Kita dapat memperluas contoh di atas dari 10 penerima, di mana seorang penerima dapat lebih lanjut membuat kuncinya menjadi transaksi yang ditandatangani tetapi tidak disiarkan yang mengirim ke kelompok penerima berikutnya, dan seterusnya, membentuk struktur pohon seperti yang ditunjukkan pada gambar di bawah ini. Alice dapat membuat perubahan dalam saldo rekening melibatkan beberapa pengguna di rantai hanya menggunakan 1 UTXO dari ruang blok.

Sumber: https://twitter.com/OwenKemeys/status/1741575353716326835

Dan bagaimana jika salah satu daunnya adalah saluran petir, atau penyimpanan dingin, atau jalur pembayaran lainnya? Maka pohon akan diperluas dari pohon pembayaran multi-lapisan satu dimensi menjadi pohon pembayaran multi-dimensi multi-lapisan, dan skenario yang dapat didukung akan lebih kaya dan fleksibel.

Sumber: https://twitter.com/OwenKemeys/status/1744181234417140076

Sejak usulnya diajukan, CTV telah mengalami perubahan nama dari COSHV pada tahun 2019, diberi BIP-119 pada tahun 2020, dan munculnya Sapio, bahasa pemrograman yang digunakan untuk membuat kontrak untuk mendukung CTV, dan telah menerima banyak diskusi komunitas, pembaruan, dan perdebatan tentang pilihan aktivasi di tahun 2022 dan 2023, dan masih menjadi salah satu proposal upgrade soft fork yang paling banyak dibahas dalam komunitas.

OP_CAT

OP_CAT, seperti yang dijelaskan dalam paragraf pembuka, juga merupakan proposal upgrade yang saat ini sedang mendapat banyak perhatian, dan mengimplementasikan fungsi yang menggabungkan dua elemen atau dua set data dari tumpukan. Meskipun terlihat sederhana, OP_CAT sangat fleksibel dan dapat diimplementasikan dalam skrip dengan banyak cara.

Contoh paling langsung adalah operasi Pohon Merkle, yang dapat diinterpretasikan sebagai dua elemen yang digabungkan dan kemudian di-hash. Saat ini, ada OP_SHA256 dan opcode hash lainnya dalam skrip Bitcoin, jadi jika Anda dapat menggabungkan dua elemen menggunakan OP_CAT, Anda dapat menerapkan fungsi verifikasi Pohon Merkle dalam skrip, yang juga memberikan kemampuan verifikasi klien ringan sampai batas tertentu.

Basis lain untuk implementasi adalah peningkatan tanda tangan Schnorr: Anda dapat mengatur kondisi tanda tangan pengeluaran skrip untuk menjadi konkatenasi kunci publik pengguna dan nonce publik; maka jika penandatangan ingin menandatangani transaksi lain untuk menghabiskan dana di tempat lain, ia harus menggunakan nonce yang sama, yang dapat bocor kunci pribadi. Yaitu, OP_CAT mencapai komitmen ke nonce dan dengan demikian memastikan validitas transaksi yang ditandatangani.

Aplikasi lain dari OP_CAT termasuk Bistream,tanda tangan pohon, tanda tangan Lamport tahan quantum, vaults, dan lainnya.

OP_CAT sendiri bukan fitur baru, karena sudah ada dalam versi-versi awal Bitcoin, tetapidinonaktifkanpada tahun 2010 karena potensinya dapat dieksploitasi oleh penyerang. Sebagai contoh, penggunaan berulang OP_DUP dan OP_CAT bisa dengan mudah menyebabkan tumpukan node penuh meledak saat memproses skrip seperti itu, seperti yang terlihat dalam ini demo.

Namun, apakah masalah ledakan tumpukan yang disebutkan di atas akan terjadi saat ini setelah OP_CAT diaktifkan kembali? Karena proposal OP_CAT saat ini hanya melibatkan mengaktifkannya di tapscript, yang memiliki batas 520 byte per elemen tumpukan, itu tidak akan menyebabkan masalah ledakan tumpukan sebelumnya. Ada juga beberapa pengembang yang berpikir bahwa Satoshi Nakamoto mungkin terlalu keras dengan menonaktifkan OP_CAT secara langsung. Namun, karena fleksibilitas OP_CAT, mungkin benar bahwa beberapa skenario aplikasi yang dapat menyebabkan kerentanan akan ada.

Oleh karena itu, dengan menggabungkan skenario aplikasi dan risiko potensial, OP_CAT baru-baru ini mendapat banyak perhatian, dan juga telah memiliki ulasan PRdan saat ini merupakan salah satu proposal upgrade paling populer.

Kesimpulan

“Regulasi Diri Membawa Kebebasan”, seperti yang dapat dilihat dari pengantar di atas, perjanjian dapat diimplementasikan langsung ke dalam skrip Bitcoin untuk memenuhi pengeluaran lebih lanjut pada transaksi, sehingga memungkinkan aturan transaksi yang mirip dengan efek kontrak pintar. Pendekatan pemrograman ini dapat diverifikasi secara lebih alami pada Bitcoin daripada pendekatan off-chain seperti BitVM, dan juga dapat meningkatkan aplikasi pada rantai utama (pengendalian kemacetan), aplikasi off-chain (saluran keadaan), dan arah aplikasi baru lainnya (penyitaan pengepungan, dll.).

Teknik implementasi dari perjanjian, jika digabungkan dengan beberapa upgrade lainnya, bisa lebih membuka potensi dari keprogramabilitasan. Sebagai contoh, proposal terbaru untuk aritmatika 64-bit

di ulasandapat lebih digabungkan dengan yang diusulkanOP_TLUVatau perjanjian lain yang dapat diprogram berdasarkan jumlah satoshi yang dihasilkan oleh transaksi.

Namun, perjanjian juga dapat menyebabkan penyalahgunaan atau kerentanan yang tidak terduga, sehingga komunitas juga berhati-hati tentang hal ini. Selain itu, peningkatan perjanjian juga perlu melibatkan peningkatan garpu lunak aturan konsensus. Mengingat keadaan seputar peningkatan taproot, kemungkinan besar peningkatan yang terkait dengan perjanjian juga akan memerlukan waktu untuk diselesaikan.

Terima Kasih Khusus

Terima kasih Ajian, FisherdanBenuntuk meninjau dan saran!

Referensi

• https://utxos.org/
• https://bitcoincovenants.com/
• Sebuah kumpulan sumber daya terkait perjanjian: https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
• https://anyprevout.xyz/
• Usulan OP_VAULT BIP 345：https://www.btcstudy.org/2023/04/13/proposal-perbaikan-bitcoin-345-op-vault-commit-0b0674c546/
• https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
• https://maltemoeser.de/paper/covenants.pdf
• https://bitcoinops.org/id/topics/op_cat/
• OP_CAT: https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
• Triks CAT dan Schnorr: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

Penafian: Materi ini hanya untuk informasi umum, dan tidak merupakan, juga tidak boleh diinterpretasikan sebagai, bentuk saran investasi, permintaan, atau tawaran investasi, dan tidak ada tanggung jawab atau tanggung jawab diterima oleh HashKey Capital terkait dengan penggunaan atau ketergantungan pada informasi tersebut.

Tetap terupdate dengan berita terbaru dari HashKey Capital -

Situs web — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn —https://www.linkedin.com/company/hashkeycapital/

pernyataan:

1. Artikel ini diperbanyak dari [medium], hak cipta milik penulis asli [Jeffrey HudanHarper Li], jika Anda memiliki keberatan terhadap cetak ulang, harap hubungi Belajar Gatetim , dan tim akan menanganinya sesegera mungkin sesuai prosedur yang relevan.

2. Penafian: Pandangan dan opini yang terdapat dalam artikel ini hanya mewakili pandangan pribadi penulis dan tidak merupakan saran investasi apa pun.

3. Versi bahasa lain dari artikel ini diterjemahkan oleh tim Gate Learn dan tidak disebutkan dalamGate.io, artikel terjemahan mungkin tidak boleh direproduksi, didistribusikan, atau diplagiat.