Author: James O'Beirne 2023-01-20 17:43:14
Published on: 2023-01-20T17:43:14+00:00
The proposal being discussed encourages address reuse for vaults and may not be difficult to ensure unique addresses through key derivation. The proposal defers privacy-vs.-efficiency decision to the end user with privacy-conscious users trading batched operations for no privacy loss, while commercial users might reveal the related nature of coins being unvaulted or recovered. Users can keep the nature of still-vaulted coins hidden by varying the internal key used for OP_VAULT taptrees or using the optional "authorized recovery" feature and varying that sPK with a ranged descriptor. Recovery sweeps only happen in catastrophic cases, and most users are willing to make the privacy trade to retain ownership of their coins. Validating the revault output in the unvault trigger transaction would require the same check as the OP_UNVAULT script and require that the recovery script and delay are the same, but this could allow the holder of the unvault key to immediately spend the vault into a new vault configuration with a different unvault key. It is uncertain whether this change is more fundamental, and it would be easy to implement. The usage of OP_VAULT and OP_UNVAULT should be limited to tapscripts instead of bare and P2WSH outputs to simplify implementation.
Updated on: 2023-06-16T03:49:02.692684+00:00