Hi Victor, Can we as a community stop calling everything vaults? We've seen vanilla multisig wallets being called vaults, then CTV transaction chains, and now a decaying multisig. Not trying to blame you in particular, but a vault in Bitcoin has (or used to have?) a [specific meaning](https://bitcoinops.org/en/topics/vaults/), and regardless grouping constructions with very different properties under a single label only creates confusion.
What you present is essentially Liana: [https://github.com/wizardsardine/liana](https://github.com/wizardsardine/liana/). Except that Liana uses relative timelocks (CSV) because absolute timelocks (CLTV) put an expiration date on your descriptor, which adds lots of friction and can be quite confusing to less technical users. By default Liana comes bundled with a pruned Bitcoin Core node and uses its watchonly wallet functionality to track your coins. For a remote node, Bitcoin Core's RPC interface is not adapted and Liana lets you configure an Electrum server instead. Regards, Antoine On Thursday, December 11th, 2025 at 6:31 AM, victor perez <[email protected]> wrote: > 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: > > - > > Normal spending path (immediate): > 2-of-2 multisig (key A + key B required) > > - > > 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/82546937-996d-495d-8a4e-66654306447cn%40googlegroups.com. -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ywe-dbEMw2fKIXvUV7gTVyZmJENCN20PSAbB-pZYGe-0Skd9OKGFxAOfOT17UUHcFOkw1j0BeNL-G5aEMe3HQlnh1pNuxpxGL4Z09oUkdTo%3D%40protonmail.com.
