Hello everyone,

I’m working on a small non-custodial vault system and would like to collect feedback on the safety and correctness of a simple script design, as well as on a question regarding pruned nodes and PSBT workflows.

The vault uses two spending paths:

1. Normal spending path (immediate):
   2-of-2 multisig (key A + key B required)

2. Recovery path (delayed):
   After a predefined block height (CLTV), key B alone can spend:

   <CLTV_height> OP_CHECKLOCKTIMEVERIFY OP_DROP <pubkey_B> OP_CHECKSIG

Both paths behave as expected on regtest, including enforcement of the CLTV height.

The goal is a simple inheritance/emergency mechanism:
– before the delay expires → strict 2-of-2
– after the delay → key B alone can recover funds
No custodial component; all spending is done via PSBTs signed on two Ledger devices.

For the client software, I would like to use a remote pruned Bitcoin Core node (for storage and deployment reasons).
The client retrieves UTXOs, fetches the required previous outputs for PSBT construction, and broadcasts the final transaction via RPC.

Is a pruned node fully reliable for such a workflow?
Specifically:

• returning all UTXOs belonging to the vault address,

• providing scriptPubKey, value, and other fields required in a PSBT input,

• validating the timelocked script spend,

• broadcasting the final transaction.

Are there any known limitations, edge cases, or risks associated with relying on a pruned node in this context, especially when spending from a script with multiple paths (2-of-2 + CLTV recovery)?

Any comments on the script design itself (safety, best practices, or possible improvements, including Taproot-based approaches) would also be very welcome.

Thanks for your time and insights.

Best regards,
Victor