From: victor perez <svcrobotics@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Feedback on a simple 2-path vault design (2-of-2 + CLTV recovery) and use of pruned nodes for UTXO retrieval
Date: Thu, 11 Dec 2025 03:30:46 -0800 (PST) [thread overview]
Message-ID: <82546937-996d-495d-8a4e-66654306447cn@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2358 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 2913 bytes --]
next reply other threads:[~2025-12-11 11:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 11:30 victor perez [this message]
2025-12-11 14:14 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-12-11 15:15 ` victor perez
2025-12-13 17:03 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-12-14 10:40 ` victor perez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82546937-996d-495d-8a4e-66654306447cn@googlegroups.com \
--to=svcrobotics@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox