From: victor perez <svcrobotics@gmail.com>
To: Antoine Poinsot <darosior@protonmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [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 16:15:26 +0100 [thread overview]
Message-ID: <CAHyc38kweRwvji1NFPCXn3pXSZHtoT4b8sWLHNJ259H+GTKnHg@mail.gmail.com> (raw)
In-Reply-To: <ywe-dbEMw2fKIXvUV7gTVyZmJENCN20PSAbB-pZYGe-0Skd9OKGFxAOfOT17UUHcFOkw1j0BeNL-G5aEMe3HQlnh1pNuxpxGL4Z09oUkdTo=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 6249 bytes --]
Hi Antoine,
Thanks a lot for your message and for pointing this out — I completely
understand your remark about the terminology. You’re right: using “vault”
too loosely contributes to confusion, especially when Bitcoin vaults
historically referred to a very specific construction with enforced
spending paths and secure delays.
I’ll adjust my wording going forward and be more precise about what the
system implements.
The construction I’m working on is indeed essentially a *2-of-2 multisig
with a CSV-based recovery path*, very similar in spirit to *Liana*. My goal
is mostly educational and exploratory for now: understanding the full
lifecycle (descriptor, address generation, UTXO tracking, PSBT building,
hardware signing, recovery flow). I’m not trying to innovate or redefine
the term “vault”, but rather build a usable multisig recovery system before
exploring more advanced designs.
Your point about *absolute timelocks (CLTV)* is well taken. I switched to
CSV for the same reason you mentioned: CLTV introduces an implicit
expiration that is difficult to communicate to non-technical users. CSV
makes the construction more flexible and avoids descriptor obsolescence.
Regarding node operation:
For the moment I’m running a *full Bitcoin Core node (non-pruned)* because
it simplifies UTXO retrieval during development. I hadn’t implemented
pruned-node compatibility yet, but seeing that Liana handles this cleanly
with a pruned watch-only wallet + Electrum fallback is extremely helpful
context. I’ll definitely study how Liana approaches this architecture
before going further.
My intention isn’t to reinvent Liana, but rather to build something minimal
for learning, and then expand it into a broader project (inheritance flows,
user-friendly recovery logic, analytics, etc.) once the foundations are
solid.
Thanks again for taking the time to point me in the right direction — it’s
really appreciated.
If you have any recommendations on what pitfalls to avoid or reading
material on robust recovery designs, I’d be glad to hear them.
Best regards
Victor
Le jeu. 11 déc. 2025, 15:14, Antoine Poinsot <darosior@protonmail.com> a
écrit :
> 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. 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 <
> svcrobotics@gmail.com> 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:
>
> 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
> .
>
>
>
--
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/CAHyc38kweRwvji1NFPCXn3pXSZHtoT4b8sWLHNJ259H%2BGTKnHg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8327 bytes --]
next prev parent reply other threads:[~2025-12-13 10:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 11:30 victor perez
2025-12-11 14:14 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-12-11 15:15 ` victor perez [this message]
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=CAHyc38kweRwvji1NFPCXn3pXSZHtoT4b8sWLHNJ259H+GTKnHg@mail.gmail.com \
--to=svcrobotics@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.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