Author: Billy Tetrud 2023-01-31 15:02:51
Published on: 2023-01-31T15:02:51+00:00
A simple way to do a wallet vault without requiring any key deletion has been proposed in the discussion around James' OP_VAULT proposal. The proposal involves creating an N-of-N multisig address and pre-signing some transactions from it with N-1 keys to an address with several timelocked spend paths. This allows for a fallback where funds can always be spent immediately if all the keys are used, but the usage of any of the pre-signed transactions leads to an address that guarantees a clawback within a time window. However, this approach presents some challenges, including the need to make sure all watchtowers received the cancel signature before signing the Unvault transaction and the inability to have policies on the Spend transaction. These issues can be solved with covenants. It was noted that such a design is basically a (simple) instantiation of Revault, which allows for the use of cosigning servers that act as anti-replay oracles to have policies on the spend. More information can be found at https://github.com/revault. The proposal has the usual downsides of pre-signed vaults, such as the need to backup these transactions for each vaulting, complications involving the flexibility (or lack thereof) of fees, and inflexibility in how much to unvault (must be the whole utxo, no change). It could, however, be augmented with various techniques to make fee handling more flexible (anchor outputs, multiple versions of the presigned transactions with different fees, etc.). More complicated presigning schemes could allow for some flexibility in unvaulting amount (e.g., by sending change back into the vault and creating additional presigned transactions for that new output). A stolen key can steal funds from the interim address by racing the owner with their transaction once the necessary delay has passed, similar to the downside of OP_CTV vaults, although James' OP_VAULT opcode wouldn't have this problem.
Updated on: 2023-06-16T04:02:35.020425+00:00