FROST berarti Flexible Round-Optimized Schnorr Threshold. Ini adalah protokol tanda tangan ambang: cukup peserta menandatangani dengan kunci publik bersama tanpa menyatukan seluruh kunci rahasia di satu tempat selama penandatanganan.
Dalam skema 2 dari 3, dua bagian sah yang tersedia sudah cukup, sedangkan satu tidak dapat menghasilkan tanda tangan. Penyerang yang memperoleh dua juga memenuhi ambang. Bagian kunci jangka panjang bukan tanda tangan parsial untuk pesan tertentu; penandatanganan memerlukan protokol bersama dengan nilai sekali pakai yang baru. [RFC 9591 — FROST]
Pendistribusi tepercaya dapat membuat rahasia dan membagikan bagian, sehingga mengetahui seluruh kunci dan harus menanganinya dengan aman. DKG memungkinkan pembuatan bersama tanpa pendistribusi tunggal tersebut, tetapi menambahkan komunikasi dan verifikasinya sendiri. RFC 9591 terutama mengatur penandatanganan; lampiran pendistribusinya tidak berarti setiap penerapan otomatis memakai DKG. [RFC 9591 — FROST] [ZF FROST Book — key generation and recovery]
Pada putaran pertama peserta membuat dua nonce rahasia dan membagikan komitmen publiknya. Pada putaran kedua ia memeriksa pesan, daftar peserta, dan komitmennya sendiri, lalu menghitung bagian tanda tangan. Koordinator menggabungkan bagian-bagian itu. Faktor pengikat mengaitkan nonce dengan pesan dan kumpulan komitmen tertentu; dua putaran tidak menghitung pembuatan kunci sebelumnya. [RFC 9591 — FROST] [ZF frost-secp256k1-tr — Taproot implementation]
Penggunaan ulang nonce dapat membocorkan materi kunci rahasia. Setelah dipakai, nonce rahasia harus dinonaktifkan secara aman bahkan dalam upaya yang dibatalkan; pemulihan cadangan lama tidak boleh membuatnya dapat dipakai lagi. Keacakan, sesi bersamaan, dan pencatatan pemakaian yang persisten merupakan keamanan, bukan sekadar optimasi kecepatan. [RFC 9591 — FROST]
Koordinator mengumpulkan komitmen dan bagian tanda tangan; tanpa cukup bagian kunci, ia tidak berwenang menandatangani sendiri. Namun ia dapat menahan pesan atau menyebabkan pembatalan. Memeriksa bagian yang salah dapat mengidentifikasi pengirimnya, bukan menjamin sesi selesai. Transportasi terautentikasi dan cukup peserta yang tersedia tetap diperlukan. [RFC 9591 — FROST]
Untuk Bitcoin, hasilnya harus memenuhi pengodean, hashing, dan aturan tepat BIP 340 serta penyesuaian kunci Taproot bila diperlukan. Memilih secp256k1 dalam suite FROST umum saja tidak cukup. ZF menyediakan frost-secp256k1-tr terpisah untuk Taproot; periksa suite tertentu dan pengujiannya. Satu tanda tangan di rantai tidak dengan sendirinya mengungkap ambang internal. [ZF frost-secp256k1-tr — Taproot implementation] [BIP 340 — Schnorr Signatures for secp256k1]
Bagian memerlukan pengenal yang benar, informasi publik kelompok, dan perangkat lunak kompatibel. Memulihkan bagian yang hilang dengan bantuan peserta lain atau memperbarui bagian adalah protokol tambahan yang penerapan harus benar-benar dukung. Menyalin bagian yang sama tidak menambah peserta independen. Cadangan harus menjaga ambang sekaligus mencegah nonce terpakai kembali. [ZF FROST Book — key generation and recovery] [ZF frost-secp256k1-tr — Taproot implementation]
Setiap penandatangan harus memeriksa penerima, jumlah, biaya, dan aturan persetujuan, bukan membabi buta menandatangani hash koordinator. FROST menyediakan penandatanganan bersama, bukan kebenaran niat bisnis. Sebelum memakai, periksa versi implementasi, prosedur pemulihan, dan perilaku saat gagal; RFC informasional tidak mensertifikasi seluruh dompet. [RFC 9591 — FROST]
Untuk gambaran yang lebih utuh, baca entri ini bersama Schnorr signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing.