Published on: 2023-01-20T17:43:14+00:00
The proposal being discussed is centered around the implementation of efficient wallet vaults. It suggests encouraging address reuse for vaults and ensuring unique addresses through key derivation. The proposal allows privacy-conscious users to trade batched operations for no privacy loss, while commercial users may reveal the related nature of coins being unvaulted or recovered. To maintain the privacy of still-vaulted coins, users can vary the internal key used for OP_VAULT taptrees or utilize the optional "authorized recovery" feature by varying the sPK with a ranged descriptor. Recovery sweeps only occur in catastrophic cases, and most users are willing to sacrifice some privacy for the ownership of their coins. However, it is uncertain whether this change is more fundamental, but it is relatively easy to implement.The proposal suggests limiting the usage of OP_VAULT and OP_UNVAULT to tapscripts instead of bare and P2WSH outputs in order to simplify implementation. It also discusses the possibility of storing a recovery address with every key to the vault and gating the recovery path with an arbitrary scriptPubKey. However, adding this feature may introduce complexity to downstream code that needs to handle special cases.There is an ongoing discussion about the verification process of a node for the destination of a spend using an OP_VAULT output and its corresponding OP_UNVAULT script. The proposal provides the option to store a recovery address with each key, but the recovery path can be gated by an arbitrary scriptPubKey. The proposal aims to meet all criteria for efficient wallet vaults and allows batching as well.There have been suggestions from Greg Sanders and AJ Towns to improve the proposal. These suggestions include allowing OP_UNVAULT outputs to live behind scripthashes, introducing an extra "revault" output in unvault trigger transactions, and implementing a replacement parameter for the recovery script. These changes aim to enhance efficiency, flexibility, and security in the proposed vault design.Another topic of discussion is the verification process of a node to ensure that the destination of an OP_VAULT output uses the appropriate OP_UNVAULT script. There are concerns about compatibility with SIGHASH_GROUP and the use of the OP_BEFOREBLOCKVERIFY opcode, which may affect the reorgability of transactions. The proposal includes a static intermediate address that does not have any unique values for a particular vault, allowing for dynamic unvaulting using OP_PUSHOUTPUTSTACK.The author has implemented three changes based on suggestions from Greg Sanders and AJ Towns. These changes include allowing OP_UNVAULT outputs to live behind scripthashes, introducing an extra "revault" output, and implementing a replacement parameter for the recovery script. The author believes these suggestions have improved the proposal and plans to make minor updates to the paper and write a BIP draft soon.A proposal for a targeted wallet vault opcode has been suggested to limit objections and complexity. It aims to provide efficient vault storage and allow batching in a single transaction. However, there are concerns about the verification of the destination of an OP_VAULT output and the security of the recovery path. The proposal suggests storing a recovery address with every key to minimize the risk of lost or stolen funds. The idea of making the recovery-path authorization behavior variable has also been proposed for flexibility.In a discussion on the bitcoin-dev mailing list, Andrew Chow raises concerns about a proposal that encourages address reuse for vaults. He suggests ensuring unique addresses through key derivation and limiting the usage of OP_VAULT and OP_UNVAULT to tapscripts to simplify implementation. James O'Beirne has implemented a vault design called OP_VAULT and seeks feedback on its viability. The discussion covers various aspects of the design, including privacy, batched operations, and the verification process. Suggestions for improvements have been made, and a BIP draft may be written.The conversation between James O'Beirne and Andrew Poelstra focuses on the design of OP_VAULT, a new opcode for Bitcoin script. They discuss the size and complexity of the witness script, the use of recovery-path construction, and the potential for batching inputs and outputs. The benefits of using taproot to hide the vault operations are highlighted, and suggestions for improvements are made.In a discussion about Bitcoin vaults, questions arise about the recovery path and its security measures. Various proposals, including the use of signatures and OP_NOP repurposing, are discussed. The possibility of using CTV and template malleability is considered but deemed inappropriate for vaults. The benefits of batching withdrawals and the inability to batch unvaults in Revault are also debated.The author has received a suggestion from Greg about improving the "output flow" of a vault use. The current draft implementation allows all outputs except the OP_UNVAULT trigger to hide their true script until spend. However, there is ongoing discussion about potentially rearranging the commit structure.
Updated on: 2023-08-02T08:46:51.905810+00:00