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.

Vault design

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.

Main question

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

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/82546937-996d-495d-8a4e-66654306447cn%40googlegroups.com.