Người ta đã tuyên bố rằng OP_IF luôn là không cần thiết trong các Script taproot. Điều này là sai. Script này được trích dẫn từ @mononautical thực tế là rẻ hơn nếu được gộp lại: tất cả các đường chi tiêu đều yêu cầu 4 khóa công khai. Sau 4 OP_CHECKSIGADD, phần còn lại của Script ít hơn 32 byte, vì vậy việc để nó gộp lại là rẻ hơn. Khi tách ra, bạn loại bỏ phần đuôi của Script đang kiểm tra thời gian khóa, nhưng thêm 32 byte vào khối điều khiển vì Script giờ đây ở độ sâu 1 thay vì 0. Do đó, một trình biên dịch tối ưu hóa cho chi phí chi tiêu _sẽ_ tạo ra Script gộp lại (tức là một taptree với một lá duy nhất), vì nó rẻ hơn một chút ngay cả trong đường chi tiêu chính (3 trong 4). Người dùng tối ưu hóa hoàn toàn cho quyền riêng tư rất có thể sẽ muốn tách nó ra. Nói cách khác, việc tạo ra taptree tốt nhất là một bài toán tối ưu hóa với hai biến: chi phí chi tiêu và quyền riêng tư, và rất thường bạn không thể tối ưu hóa cho cả hai cùng một lúc. Tôi mong rằng hầu hết người dùng sẽ không tối ưu hóa tuyệt đối cho bất kỳ biến nào một cách độc quyền, mà sẽ chọn một taptree với chi phí khá tốt và quyền riêng tư khá tốt. Đối với script mà @mononautical cho thấy ở đây, một taptree chỉ với hai lá sẽ khá tốt: đường chính chỉ là một 3 trong 4 đơn giản và nó sẽ được sử dụng cho hầu hết các chi tiêu, và phần còn lại của các điều kiện chi tiêu (có thể được gộp lại trong một tapleaf duy nhất) hy vọng sẽ không bao giờ chạm vào chuỗi. Khi bạn đưa MuSig và FROST vào phương trình, có nhiều biến hơn: MuSig và FROST có thể giảm chi phí và cải thiện quyền riêng tư, nhưng chúng tăng yêu cầu tương tác và độ phức tạp trong việc triển khai. Các nhà phát triển và người dùng sẽ chọn gì? Tôi không biết! Chỉ có những kẻ ngốc mới không có nghi ngờ.