ví dụ OP_IF taproot này thực sự đáng lo ngại hơn cho đề xuất RDTS so với những gì tôi đã nhận ra ban đầu. đó thực sự là một chính sách ví miniscript: thresh(3,pk(A),pk(B),pk(C),pk(D),older(T1),older(T2)) nghĩa là "một multisig 3 trên 4, giảm xuống 2 trên 4 sau thời gian T1, và 1 trên 4 sau thời gian T2"

có hai giao dịch liên quan diễn ra gần nhau, mỗi giao dịch thực hiện một trong các điều kiện chi tiêu theo thời gian. chính xác là loại hoạt động mà bạn có thể mong đợi từ một người đang thực hiện các bài kiểm tra chính thức cuối cùng trước khi nạp tiền thật vào một ví dựa vào kịch bản khóa này.

vì đây là một tapscript sử dụng OP_IF, bất kỳ khoản tiền nào nhận được bởi ví như vậy sau khi kích hoạt RDTS sẽ bị đóng băng. chủ sở hữu cũng sẽ không thể di chuyển đồng tiền của họ để làm mới các khóa thời gian tương đối, có thể buộc một sự giảm sút an ninh không mong muốn và thảm khốc.

xem xét, ví dụ, rằng loại chính sách miniscript này có thể được sử dụng cho một kế hoạch thừa kế hoặc mô hình lưu ký hợp tác. ví dụ, chủ sở hữu giữ ba chìa khóa, và chuyển chìa khóa thứ tư cho một người thừa kế hoặc nhà cung cấp dịch vụ chìa khóa phục hồi.

miễn là họ còn sống, chủ sở hữu có thể định kỳ làm mới các khóa thời gian bằng cách gửi lại đồng tiền cho chính họ, giữ quyền kiểm soát duy nhất đối với quỹ. nếu họ mất một chìa khóa, họ có thể chờ cho khóa thời gian đầu tiên hết hạn, hoặc nhờ người giữ chìa khóa khác giúp khôi phục quyền truy cập.

khi họ qua đời, người thừa kế sẽ có quyền truy cập đơn phương vào di sản của họ ngay khi thời gian khóa thứ hai hết hạn. tuy nhiên, việc RDTS đóng băng ví có thể khiến chủ sở hữu không kịp làm mới đồng coin của họ, để lại họ dễ bị đánh cắp sớm bởi người nắm giữ khóa khác.

Theo như tôi có thể thấy, loại ví taproot miniscript này có thể được tạo ra trong phần mềm tiêu dùng ngày nay. Ví dụ, đây là cách thiết lập nó như một ví miniscript tùy chỉnh trong ứng dụng di động của Nunchuk.