Miniscript là gì là câu hỏi nhiều người chạm phải khi muốn dùng ví Bitcoin multisig mà vẫn kiểm soát được logic ký. Bitcoin Script nguyên bản cho phép bạn viết bất kỳ logic nào, nhưng chính sự tự do đó lại khiến phần mềm ví không thể phân tích, không biết trước khi nào giao dịch sẽ hợp lệ, và không tính được phí chính xác. Miniscript ra đời để sửa đúng ba chỗ đó, mà vẫn giữ nguyên khả năng ký thực tế của Bitcoin.
Bài viết này đi từ vấn đề của OP_CHECKMULTISIG, giải thích vì sao ví cần một ngôn ngữ script hạn chế, rồi xem cách descriptor dùng Miniscript để biểu diễn ví đa chữ ký M-of-N và các chính sách phức tạp hơn.
Vấn đề gốc: Bitcoin Script quá linh hoạt
Bitcoin Script là ngôn ngữ Turing-complete chạy trên mọi node. Một scriptPubKey có thể chứa bất kỳ logic nào, kể cả vòng lặp. Vấn đề nằm ở chỗ phần mềm ví chạy trên máy của bạn, không phải trên mạng.
Hệ quả trực tiếp là những điều sau trở thành bất khả thi trong thực tế:
- Không phân tích được. Ví không xác định được một script có thỏa mãn bằng những chữ ký nào, nên không thể cảnh báo người dùng trước khi giao dịch bị kẹt vĩnh viễn trên chuỗi.
- Không biết trước phí. Chữ ký Schnorr thường 64 byte, ECDSA khoảng 71 byte. Không có cách nào biết trước số chữ ký sẽ cần, nên phí ước lượng luôn là phỏng đoán.
- Không biết ký theo thứ tự nào. Đây là điểm dễ sai nhất với
OP_CHECKMULTISIG, mà phần lớn người dùng không hề biết.
OP_CHECKMULTISIG và lỗi off-by-one
OP_CHECKMULTISIG là opcode multisig gốc của Bitcoin. Nó có hai đặc tính lịch sử gây khó chịu:
Thứ nhất, nó xóa thêm một phần tử stack không dùng. Do một lỗi cố hữu từ đầu, opcode này bỏ đi một phần tử “dummy” trên stack. Dummy có thể mang bất kỳ giá trị nào mà script vẫn chạy, nên về lý thuyết nó không ảnh hưởng an toàn. Tuy vậy, BIP-147 bổ sung quy tắc NULLDUMMY bắt buộc dummy phải là mảng byte rỗng. Bitcoin Core đã áp dụng quy tắc này như chính sách relaying, và từ khoảng tháng 8/2015 không còn giao dịch vi phạm nào được ghi lên chuỗi.
Thứ hai, chữ ký phải đúng thứ tự. Cơ chế là: mỗi khóa công khai thử một lần, nếu thất bại thì không được kiểm tra lại. Hệ quả là chữ ký phải đặt đúng thứ tự với các khóa công khai tương ứng trong script. Với ví 3 trong 5, chỉ cần sắp xếp sai thứ tự là giao dịch không bao giờ hoàn thành, và tiền sẽ bị khóa vĩnh viễn.
Với người dùng cuối, một quy tắc bất khả diễn giải bằng hình vẽ là lý do thực tế để ví phải né OP_CHECKMULTISIG và chuyển sang Schnorr cùng một ngôn ngữ an toàn hơn.
Miniscript định nghĩa là gì
Miniscript là tập con có cấu trúc của Bitcoin Script, được đặc tả trong BIP-379. Nó không phải ngôn ngữ mới, không thay đổi consensus, và không thay đổi cách Bitcoin xác thực giao dịch. Nó chỉ là một cú pháp hạn chế mà phần mềm ví có thể phân tích được.
Bản đặc tả hiện ở trạng thái Draft, và quan trọng là nó loại trừ P2SH: chỉ áp dụng cho P2WSH qua biểu thức wsh() và cho Tapscript qua tr().
Hệ thống kiểu dữ liệu của Miniscript
Miniscript gắn mỗi biểu thức một kiểu để phần mềm biết trước tính chất an toàn. Có bốn kiểu cơ bản: B (byte), V (đúng/sai), K (khóa công khai), W ( witnessScript). Sau đó là các modifier đánh dấu tính đúng đắn và khả năng bị làm lỗi, trong đó đáng nhớ nhất là s (có kiểm tra chữ ký) và f (không thể bị làm lỗi).
Điểm an toàn quan trọng nhất trong đặc tả: một script thỏa điều kiện mà không cần chữ ký số là không an toàn. Kẻ tấn công có thể sửa nLockTime hoặc nSequence để mở thêm nhánh timelock và mở khóa tài sản sớm hơn dự kiến. Chính vì vậy thuộc tính s là bắt buộc, và các hàm hash trong Miniscript đều ép độ dài đầu vào đúng 32 byte để chặn kiểu tấn công griefing này.
Descriptor: nơi Miniscript thực sự được dùng
Miniscript không tồn tại trong phối cảnh trống. Nó là phần lõi của BIP-380, đặc tả cú pháp descriptor, cho phép ví biểu diễn toàn bộ cấu trúc ký bằng một chuỗi văn bản thay vì con số hex khó kiểm soát.
Ví multisig M-of-N điển hình được biểu diễn bằng multi() hoặc sortedmulti() theo BIP-383. Điểm đáng chú ý: BIP-383 quy định multisig P2SH chỉ nhận tối đa 15 khóa công khai nén, vì redeemScript sẽ vượt giới hạn 520 byte cho một stack element. Còn với P2WSH, giới hạn của Miniscript là 20 khóa.
Descriptor còn kết thúc bằng một checksum 8 ký tự, tính theo cùng nguyên lý với bech32. Chi tiết này nghe nhỏ nhưng quan trọng: nó cho phép phát hiện descriptor bị sai chính tả khi nhập thủ công, thay vì phát hiện khi tiền đã không cứu được.
OP_CHECKSIGADD và giới hạn tài nguyên trong Tapscript
Trong Tapscript, OP_CHECKMULTISIG biến mất và được thay bằng OP_CHECKSIGADD (opcode 186), định nghĩa trong BIP-342. Lý do nằm ở batch verification: một opcode tương đương phải chạy cả nhóm chữ ký cùng lúc, nên không thể bỏ ngỏ việc kiểm tra từng khóa một như kiểu cũ.
Cơ chế hoạt động: biểu thức multi_a(k, key_1, ..., key_n) dịch thành chuỗi CHECKSIG rồi CHECKSIGADD liên tiếp, kết thúc bằng NUMEQUAL. Chữ ký hợp lệ thì bộ đếm tăng thêm một; chữ ký là vector rỗng thì giữ nguyên bộ đếm; bất kỳ giá trị nào khác làm script không hợp lệ.
Giới hạn tài nguyên cũng khác giữa hai loại script:
| Điều kiện | P2WSH | Tapscript |
|---|---|---|
| Kích thước script | Trên 3600 byte là non-standard | Bị chặn gián tiếp bởi block weight |
| Số opcode không push cộng số khóa trong CHECKMULTISIG | Trên 201 là invalid theo consensus | Dùng sigops budget riêng |
| Witness stack | Trên 100 phần tử là non-standard | Không còn giới hạn 10000 byte của legacy |
Đây chính là loại chi tiết mà ví cần để tính phí: biết trước bao nhiêu chữ ký, dung lượng witness bao nhiêu, thì mới estimate được chính xác.
Miniscript giải quyết những chính sách phức tạp nào
Ví dụ thực tế đắt giá nhất không phải multisig thuần, mà là chính sách có nhánh dự phòng. Trình biên dịch tham chiếu tại bitcoin.sipa.be/miniscript biên dịch chính sách and(pk(A), or(pk(B), or(9@pk(C), older(1000)))) thành: chủ ví A phải ký, và sau đó hoặc B ký, hoặc đủ 9 người trong nhóm C ký, hoặc sau 1000 block thì A ký một mình được.
Đó là chính sách “cần xác thực hai lớp, nhưng sau 90 ngày thì một mình cũng xong”, dùng cho ví doanh nghiệp mà không muốn mất tiền vì một người biến mất. Trước Miniscript, cách duy nhất là tự tay viết Bitcoin Script và tự chịu trách nhiệm.
Giới hạn thực tế cần biết
Nói rõ để tránh hiểu nhầm:
- Miniscript không phải consensus. Mạng Bitcoin không “hiểu” Miniscript; nó chỉ hiểu Bitcoin Script. Các script Miniscript sinh ra thường là non-standard theo nghĩa cũ, nên phần mềm cũ có thể không hiểu.
- Chỉ
pk(),pkh(),multi()vàmulti_a()trùng với descriptor cũ. Biểu thức mới không tương thích ngược với ví cũ. - Chi phí tính toán khi biên dịch không tự động tối ưu hoàn hảo. Người dùng phải chọn giữa script gọn và script rẻ phí.
Lịch sử triển khai
Miniscript không phải lý thuyết trên giấy:
- Bản tham chiếu C++ của Pieter Wuille được đưa vào Bitcoin Core qua loạt PR #24147 (backend), #24148 (watch-only) và #24149 (ký), phát hành trong Bitcoin Core 25.0.
- Hỗ trợ Tapscript đến với PR #27255, phát hành trong Bitcoin Core 26.0, cho phép biểu thức Miniscript trong descriptor Taproot cho các RPC làm việc với descriptor.
- Ledger Bitcoin App 2.2.0, MyCitadel 1.3.0 và Specter-DIY 1.5.0 đều đã tích hợp.
Chi tiết quy trình ký multisig 2-of-2 với Electrum, trong đó mỗi bên giữ xpub của bên kia và ký tuần tự qua QR hoặc Cosigner Pool, được mô tả tại tài liệu Electrum. Bối cảnh tổng thể về cách Miniscript được tích hợp dần vào hệ sinh thái Bitcoin có tại Bitcoin Optech.
Kết luận
Miniscript là câu trả lời cho một câu hỏi khó: làm sao giữ được sự linh hoạt của Bitcoin Script mà vẫn làm được phần mềm ví đáng tin? Câu trả lời là giới hạn ngôn ngữ xuống đúng mức mà máy có thể phân tích, rồi dùng chính giới hạn đó để tính phí, dự đoán số chữ ký, và cảnh báo người dùng trước khi tiền bị kẹt.
Nếu bạn đang cân nhắc ví multisig, hãy chọn ví hỗ trợ descriptor và Miniscript, sao lưu seed phrase ra giấy hoặc kim loại, và luôn kiểm tra descriptor có checksum trước khi dùng.
