Feedback on a simple 2-path vault design (2-of-2 + CLTV recovery) and use of pruned nodes for UTXO retrieval

The discussion initiated by Victor focuses on a non-custodial vault system he is developing, emphasizing its design, operation, and specific inquiries regarding the use of pruned nodes within Bitcoin's PSBT (Partially Signed Bitcoin Transactions) workflows. The vault's architecture incorporates two distinct spending paths to ensure both immediate access and secure, delayed recovery. The immediate spending path requires a 2-of-2 multisig configuration, necessitating both keys (A and B) for transaction authorization. In contrast, the recovery path introduces a time-delay mechanism, allowing key B alone to execute transactions after a predefined block height, leveraging the OP_CHECKLOCKTIMEVERIFY operation for enforcing this delay.

Victor's primary inquiry surrounds the feasibility of employing a remote pruned Bitcoin Core node within the client software, aimed at optimizing storage and deployment efficiencies. This setup is intended to manage UTXOs, facilitate PSBT construction by fetching necessary transaction outputs, and handle the broadcasting of finalized transactions through RPC calls. Concerns are raised about the pruned node's reliability in accurately returning all UTXOs associated with the vault's address, providing complete input details required for PSBTs, validating transactions against the timelocked script, and efficiently broadcasting transactions.

Additionally, Victor seeks feedback on the overall safety and best practices related to the script design of the vault system, expressing interest in potential improvements and the applicability of Taproot-based solutions. The goal behind these queries and the solicitation for insights is to refine the vault system's functionality, ensuring it serves as a robust inheritance or emergency fund mechanism without introducing custodial risks, thus maintaining the ethos of decentralized control inherent to Bitcoin's philosophy.