From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Dec 2025 09:08:35 -0800 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vUT6g-0003Vj-7B for bitcoindev@gnusha.org; Sat, 13 Dec 2025 09:08:35 -0800 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-3ed1784353esf3385189fac.3 for ; Sat, 13 Dec 2025 09:08:34 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765645708; cv=pass; d=google.com; s=arc-20240605; b=Xx7X4N+X5mhYGgeptWqXI/eDZwWu1RJvugNVzusVuCfpkBYuXpL1ruzdQsHUnhinGO dSedAkS3zEhhglWnvzF7OUdA3CSOIXCyqvRahxmGeRvz7t49cvvNSlrIYWfsLpC54Vmy PIjGvx1cIlXbjAHCBFM5jt1dxaCp5UosqkKKCzojYlO01/I6NW5EyJMJzem+G7PnTD/Q mL83dkfom/ayhPjoANfbTFPj7zhrJa+dBNhRRNz/WRsKL7lq4FBID7vyLwZkWeTbbN9L R9jN1H4HB1bQ1gA20KyzOOtghUbkXvFuKI1KnwdvBnFQ6M4M4p4EXWV/NAEJA9fv/J3t 0AGg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=oRmt5/VBSmy16RF85kJEF6Z5epJfANj3JPORd9wG1Kk=; fh=8Z59VhXFfjE5G9OjXKHRnxGV0ekI1aEOQ7a8Vxz14fQ=; b=RiPSDTLjR7lqVDOmPPlixmoCrpUKMVU6xs/08RrxRfHA9LDBNc8WutDLNm9OgNHsoC cQFoYM5A8TaDVOgNjE9Fq9GY/GE00SnCCi9DX5DzJdV/HoJERwTPMapS8G0DOOFTBvXS 3XBuhUlkJPQQ8IKPZa7+g5phIsdII1CadQl/9Xp0oE+LRua7sQVnVRmCbDQGArxNFoV4 pwMkwFq6V6VAEUDfQlMjQN1ftyAAuShl/864BSDLq16xHeqE79t1+PFLMrQ+xzlKRqci 4yuWZnejtextcryvCfzgV6Tpo/P+kbDeN0Ctdbwz0EyzlzuKlMA+H19c1ZYf6QwjfFeX MQ4A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="lPk/iLzG"; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.103 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765645708; x=1766250508; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=oRmt5/VBSmy16RF85kJEF6Z5epJfANj3JPORd9wG1Kk=; b=DtPenawqO8DfEbydRO9JaGKAQmeRubiI6XsQeMwt78KKC+CePjEaQ7MINwXyUpTKYW 5S3sytn1Lr5JZ6DRx457oa7+ZhG0MOirUj+OjMEPJ0byCAWHgYENrnSwoflB4T0pOyfB PmYP86DqPncq8WUvOyxDyar/Ud07chn9KiI4ia7e9aKNVBEpKnAyD8dN+UiyDFqQHF55 g8MmlOsV4u1M3+APaSoHxG6Ey/SPB2XsOfIp70zsrbcrg0k7YyTq5vF3LNA5x7HVIx2+ aIbQCDtDstmD9ACHbEv+2PFL6Eg2aCX7arsgSAlr0UwRZu8geacaJwopNdmTvZffCaf7 FsbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765645708; x=1766250508; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oRmt5/VBSmy16RF85kJEF6Z5epJfANj3JPORd9wG1Kk=; b=RaUVT+Gvi/HXHnmLInVFg9JZ+bO+7fCvXbx4bcKwWXSe12iS3jdVbkEUvgF2SnT01E jpzT5E7t8U27p1g07nqW6tZ6axb/6dP56J6ev40a2sXeOKa+6aeqHVyceE5FX4ma6eao 5C0qxOHZPjMqEZfSLPAGabhXE/Mgyphu0HsNUmXHHrxlkW/9LvhjH5GKUrF79y0zvNlF vIFZUuynPFOe4k5oXJdnqMj/tfeJhyUy0LwB6uuHrEAj57QT5JWb3Rc7QJuKAdtCgqCd fjqa4YXeEYJL4NznGLhCNCEuLOC3lZ6SPvoxXqbkeSoLSxaFdvq/Rl2GAktUniFVPkDi B3Ug== X-Forwarded-Encrypted: i=2; AJvYcCVG8b9OUghVLGZWyhJxifiYO54VBuASoJ2sGFpJl/RxWbcbAI6RXfkzX1Gcfrtwj0MMZxzkHCFoOLg9@gnusha.org X-Gm-Message-State: AOJu0Ywa+XKo3VEN4kbx8EpkDrXECeNJgBSg5GEST3grrB62tU+98/3N JfK3uBZZ8GA0mc8I5z/0Q1w0yN2g1Ta9dWwtEJvHlFD05ne3hx02HlM9 X-Google-Smtp-Source: AGHT+IFIrWdq7jLwxXpMN8fP6HTufaxCuPtTl4eXDSkut6dN4fL2vDHcfYMy0Q4V1dndch1vi+MhuQ== X-Received: by 2002:a05:6871:7d86:b0:3f6:2118:2d37 with SMTP id 586e51a60fabf-3f62118be5cmr481656fac.42.1765645707547; Sat, 13 Dec 2025 09:08:27 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZ0QlkX/25N7pbFLaDfzL+AI6P34Wlhhf1R8MQf1pGVPw==" Received: by 2002:a05:6870:164a:b0:3ec:4eb6:abba with SMTP id 586e51a60fabf-3f5f877fc23ls923893fac.1.-pod-prod-05-us; Sat, 13 Dec 2025 09:08:23 -0800 (PST) X-Received: by 2002:a05:6808:c22c:b0:450:cc88:ecdf with SMTP id 5614622812f47-455ac9890c8mr2935374b6e.45.1765645703652; Sat, 13 Dec 2025 09:08:23 -0800 (PST) Received: by 2002:a05:600c:15c3:b0:477:b663:eee5 with SMTP id 5b1f17b1804b1-47a8de0345bms5e9; Sat, 13 Dec 2025 09:03:07 -0800 (PST) X-Received: by 2002:a05:600c:34c3:b0:47a:7fdd:2906 with SMTP id 5b1f17b1804b1-47a8f8c47c2mr64974575e9.12.1765645384879; Sat, 13 Dec 2025 09:03:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765645384; cv=none; d=google.com; s=arc-20240605; b=QEkFw/fw9WMzarhKiRtqsis1WR1Dv9cxDqSLjO6cWSr7N/64sSfms1ya9RG4cQtxHg 4t9kNrMkaGQKpyHkSmyVp3obrbqSJfMLWszT9+sIMbTocaeCT0xmQK3I2jwWm4jjBb3O rgERPUtLv0fA6Y75nTvDRNsIsc7BQRPVfUOEv11V0idxaImDKiv4a7A5hheWIlsVBMhG hGhitKZy58A4YXRQ5/B2zrGUFtkl6YQ6aNf/npgeOmxdm55YBbjiVFr6U1fj8wR1QT4v liLbFl4/XgZzxpU4yX/bEV45zTFiHYP774qjqLpJyXsYZQK8G+urVRvp3U5ZRsaPXgzs oYeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=XJYMBNCoI9EF1I1vue5F/qGc5ZiqOd6NcjLr6yVpqjg=; fh=WNoHR1GJUIcpyzk9HruMkt4cUNByuksWuGekomM+v2o=; b=aAk5hwZoIH9l0f50YGssO7dpDxAhDQFhgqeMEuh1IiJYM1jis9X5Ma0Wqod4D8HUCO 38fkldFOZWGUjySkkPDfB3pMN2yHOMgsn+hHx6/mVgiDfns5Cpw/FJTfiZSSkoH/AQ+L pzb7gzI6CB2ZqOA5Oh6gJ9r7teG4Y6JBfy8bDNXm5tGGZgMVSsNArrbfwb1+aDvNEpWQ UbyOdUndJrj4lF2hnz/DVNOcr2sn9L6y4H4mLV6YAaVeU29NqXE1YWXdsuPrhCaq21Wo NmRyHIKD1TgLyhn/+WvFhfw0KL8DcAUZlpGT7+47HaKj8fjQWTn7j7q/4BaQKsV6JoSW IO0A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="lPk/iLzG"; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.103 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-43103.protonmail.ch (mail-43103.protonmail.ch. [185.70.43.103]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-42fa8a69635si161764f8f.3.2025.12.13.09.03.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Dec 2025 09:03:04 -0800 (PST) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.103 as permitted sender) client-ip=185.70.43.103; Date: Sat, 13 Dec 2025 17:03:01 +0000 To: victor perez From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Feedback on a simple 2-path vault design (2-of-2 + CLTV recovery) and use of pruned nodes for UTXO retrieval Message-ID: In-Reply-To: References: <82546937-996d-495d-8a4e-66654306447cn@googlegroups.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 80bc8bc1f4b0e545b31ace5b31db85631445631b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_m3KrRe3zeKMjQYiTkLPcsB2LnEUXpshcBforqMtqg" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="lPk/iLzG"; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.103 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) --b1=_m3KrRe3zeKMjQYiTkLPcsB2LnEUXpshcBforqMtqg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Victor, > If you have any recommendations on what pitfalls to avoid or reading mate= rial on robust recovery designs, I=E2=80=99d be glad to hear them. Since you mentioned that your purpose was educational, i would recommend, o= rdered by amount of time investment: 1. Go through the flow of using your construction with the Bitcoin Core wal= let API, which implements all those functionalities. For instance you could= take advantage of the multi-wallet functionality to simulate different sig= ners + one funding wallet. Have a Python script generating the keys and reg= istering the descriptor for each, and then receive coins from the funding w= allet and go through the PSBT signing flow for both spending paths to send = them back to the funder. You could do that on Signet with an intentionally = low recovery timelock, but using regtest will let you iterate faster. 2. Implement this flow yourself using the BDK [0] library. This will introd= uce you to more of the details of descriptor scanning using different "chai= n sources", PSBT processing, all this without having to reimplement all the= minutiae. That said once you've got a prototype working you can start divi= ng deeper into the implementation of the BDK library, and if you are intere= sted, into the implementation of the Miniscript language in the Rust-Minisc= ript library [1]. Since you asked about the pitfalls of implementing such a= construction, this is where you'll learn about a lot (but not all) of them= . The inner working of Bitcoin Script is both critical to the safety of you= r funds, and at times very surprising. Nowadays, it is neatly abstracted to= higher layers by Miniscript in a safe(r) manner. Digging down this rabbit = hole will teach you why a lot of things work the way they do. 3. Investigate how hardware signing devices interface with more complicated= wallet spending policies. Learn about Salvatore Ingala's "wallet policies"= [2] and try implementing signing against one of the compatible hardware si= gners out there: Ledger, Specter DIY, Bitbox, Coldcard (Edge), Jade. For th= e details of communications with those devices you may want to look into th= e Wizardsardine team's "async-hwi" and associated libraries [3]. 4. Finally, the devil is in the details. You asked about robust designs, an= d that's what most time consuming. You can build a prototype that implement= s the core functionalities in a few weeks, maybe a few days now with BDK. B= ut a robust software that can adapt to various usage types with a reasonabl= e UX, different recovery configurations, interface with various signers and= chain sources, can take years to get right. If you are interested in that = aspect i'd recommend playing with more mature Miniscript-using projects suc= h as Liana or Anchorwatch and digging through their open source codebase. M= aybe also Nunchuk which is another mature wallet that i hear started integr= ating support for Miniscript descriptors. I'd recommend joining the discussion groups of the projects i mentioned her= e, and maybe ##miniscript on Libera for the more technical Miniscript quest= ions (Bitcoin Stackexchange is good for that too). Best, Antoine Poinsot [0] https://github.com/bitcoindevkit [1] https://github.com/rust-bitcoin/rust-miniscript [2] https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki [3] https://github.com/wizardsardine/async-hwi -------- Original Message -------- On Saturday, 12/13/25 at 05:05 victor perez wrote: > Hi Antoine, > > Thanks a lot for your message and for pointing this out =E2=80=94 I compl= etely understand your remark about the terminology. You=E2=80=99re right: u= sing =E2=80=9Cvault=E2=80=9D too loosely contributes to confusion, especial= ly when Bitcoin vaults historically referred to a very specific constructio= n with enforced spending paths and secure delays. > I=E2=80=99ll adjust my wording going forward and be more precise about wh= at the system implements. > > The construction I=E2=80=99m working on is indeed essentially a 2-of-2 mu= ltisig 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, ha= rdware signing, recovery flow). I=E2=80=99m not trying to innovate or redef= ine the term =E2=80=9Cvault=E2=80=9D, but rather build a usable multisig re= covery system before exploring more advanced designs. > > Your point about absolute timelocks (CLTV) is well taken. I switched to C= SV for the same reason you mentioned: CLTV introduces an implicit expiratio= n that is difficult to communicate to non-technical users. CSV makes the co= nstruction more flexible and avoids descriptor obsolescence. > > Regarding node operation: > For the moment I=E2=80=99m running a full Bitcoin Core node (non-pruned) = because it simplifies UTXO retrieval during development. I hadn=E2=80=99t i= mplemented pruned-node compatibility yet, but seeing that Liana handles thi= s cleanly with a pruned watch-only wallet + Electrum fallback is extremely = helpful context. I=E2=80=99ll definitely study how Liana approaches this ar= chitecture before going further. > > My intention isn=E2=80=99t to reinvent Liana, but rather to build somethi= ng minimal for learning, and then expand it into a broader project (inherit= ance flows, user-friendly recovery logic, analytics, etc.) once the foundat= ions are solid. > > Thanks again for taking the time to point me in the right direction =E2= =80=94 it=E2=80=99s really appreciated. > If you have any recommendations on what pitfalls to avoid or reading mate= rial on robust recovery designs, I=E2=80=99d be glad to hear them. > > Best regards > > Victor > > Le jeu. 11 d=C3=A9c. 2025, 15:14, Antoine Poinsot a =C3=A9crit : > >> 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 differ= ent 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 re= lative timelocks (CSV) because absolute timelocks (CLTV) put an expiration = date on your descriptor, which adds lots of friction and can be quite confu= sing 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 wrote: >> >>> Hello everyone, >>> >>> I=E2=80=99m working on a small non-custodial vault system and would lik= e to collect feedback on the safety and correctness of a simple script desi= gn, 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: >>> >>> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG >>> >>> Both paths behave as expected on regtest, including enforcement of the = CLTV height. >>> >>> The goal is a simple inheritance/emergency mechanism: >>> =E2=80=93 before the delay expires =E2=86=92 strict 2-of-2 >>> =E2=80=93 after the delay =E2=86=92 key B alone can recover funds >>> No custodial component; all spending is done via PSBTs signed on two Le= dger devices. >>> >>> Main question >>> >>> For the client software, I would like to use a remote pruned Bitcoin Co= re node (for storage and deployment reasons). >>> The client retrieves UTXOs, fetches the required previous outputs for P= SBT 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 inpu= t, >>> >>> - >>> >>> validating the timelocked script spend, >>> >>> - >>> >>> broadcasting the final transaction. >>> >>> Are there any known limitations, edge cases, or risks associated with r= elying on a pruned node in this context, especially when spending from a sc= ript with multiple paths (2-of-2 + CLTV recovery)? >>> >>> Any comments on the script design itself (safety, best practices, or po= ssible 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 Grou= ps "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/bitcoin= dev/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/bitcoinde= v/CAHyc38kweRwvji1NFPCXn3pXSZHtoT4b8sWLHNJ259H%2BGTKnHg%40mail.gmail.com. --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= vSl9GmLdknrrpIJWieOlkhLVW7xpRcZyMwZiLX2B7kZsRPcRshjdNU5HphnHZObCNyrdfiY9xhX= J-vhgRs3vTYOjIwSjgXeWaUIOgUhgAvg%3D%40protonmail.com. --b1=_m3KrRe3zeKMjQYiTkLPcsB2LnEUXpshcBforqMtqg Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Victor,

> If you have any recommenda= tions on what pitfalls to avoid or reading material on robust recovery desi= gns, I=E2=80=99d be glad to hear them.

Since you mentioned that your= purpose was educational, i would recommend, ordered by amount of time inve= stment:
1. Go through the flow of using your construction with the= Bitcoin Core wallet API, which implements all those functionalities. For i= nstance you could take advantage of the multi-wallet functionality to simul= ate different signers + one funding wallet. Have a Python script generating= the keys and registering the descriptor for each, and then receive co= ins from the funding wallet and go through the PSBT signing flow for both s= pending paths to send them back to the funder. You could do that on Signet = with an intentionally low recovery timelock, but using regtest will let you= iterate faster.
2. Implement this flow yourself using the BDK [0= ] library. This will introduce you to more of the details of descripto= r scanning using different "chain sources", PSBT processing, all this witho= ut having to reimplement all the minutiae. That said once you've got a prot= otype working you can start diving deeper into the implementation of the BD= K library, and if you are interested, into the implementation of the Minisc= ript language in the Rust-Miniscript library [1]. Since you asked about the= pitfalls of implementing such a construction, this is where you'll learn a= bout a lot (but not all) of them. The inner working of Bitcoin Sc= ript is both critical to the safety of your funds, and at times very surpri= sing. Nowadays, it is neatly abstracted to higher layers by Minis= cript in a safe(r) manner. Digging down this rabbit hole will tea= ch you why a lot of things work the way they do.
3. Investigate h= ow hardware signing devices interface with more complicated wallet spending= policies. Learn about Salvatore Ingala's "wallet policies" [2] and tr= y implementing signing against one of the compatible hardware signers out t= here: Ledger, Specter DIY, Bitbox, Coldcard (Edge), Jade. For the details o= f communications with those devices you may want to look into the Wizardsar= dine team's "async-hwi" and associated libraries [3].
4. Finally,= the devil is in the details. You asked about robust designs, and that's wh= at most time consuming. You can build a prototype that implements the core = functionalities in a few weeks, maybe a few days now with BDK. But a robust= software that can adapt to various usage types with a reasonable UX, diffe= rent recovery configurations, interface with various signers and chain sour= ces, can take years to get right. If you are interested in that aspect i'd = recommend playing with more mature Miniscript-using projects such as Liana = or Anchorwatch and digging through their open source codebase. Maybe also N= unchuk which is another mature wallet that i hear started integrating suppo= rt for Miniscript descriptors.

I'd recommend joini= ng the discussion groups of the projects i mentioned here, and ma= ybe ##miniscript on Libera for the more technical Miniscript questions (Bit= coin Stackexchange is good for that too).

Best,
Antoine Poinsot 

[0] https://git= hub.com/bitcoindevkit
[1] https://github.com/rust-bitcoin/ru= st-miniscript
[2] https://github.com/bitcoin/bips/blob/maste= r/bip-0388.mediawiki
[3] https://github.com/wizardsardine/as= ync-hwi



-------- Original = Message --------
On Saturday, 12/13/25 at 05:05 victor perez <svcrobo= tics@gmail.com> wrote:

Hi Antoine,

Thanks a lot for your message and for pointing this out =E2=80=94 I comp= letely understand your remark about the terminology. You=E2=80=99re right: = using =E2=80=9Cvault=E2=80=9D too loosely contributes to confusion, especia= lly when Bitcoin vaults historically referred to a very specific constructi= on with enforced spending paths and secure delays.
I=E2=80=99ll adjust my wording going forward and be more precise about what= the system implements.

The construction I=E2=80=99m working on is indeed essentially a = 2-of-2 multisig with a CSV-based recovery path, very similar in sp= irit to Liana. My goal is mostly educational and explorato= ry for now: understanding the full lifecycle (descriptor, address generatio= n, UTXO tracking, PSBT building, hardware signing, recovery flow). I=E2=80= =99m not trying to innovate or redefine the term =E2=80=9Cvault=E2=80=9D, b= ut rather build a usable multisig recovery system before exploring more adv= anced designs.

Your point about absolute timelocks (CLTV) is well take= n. 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 obsolescen= ce.

Regarding node operation:
For the moment I=E2=80=99m running a full Bitcoin Core node (non-pr= uned) because it simplifies UTXO retrieval during development. I h= adn=E2=80=99t implemented pruned-node compatibility yet, but seeing that Li= ana handles this cleanly with a pruned watch-only wallet + Electrum fallbac= k is extremely helpful context. I=E2=80=99ll definitely study how Liana app= roaches this architecture before going further.

My intention isn=E2=80=99t to reinvent Liana, but rather to build someth= ing minimal for learning, and then expand it into a broader project (inheri= tance flows, user-friendly recovery logic, analytics, etc.) once the founda= tions are solid.

Thanks again for taking the time to point me in the right direction =E2= =80=94 it=E2=80=99s really appreciated.
If you have any recommendations on what pitfalls to avoid or reading materi= al on robust recovery designs, I=E2=80=99d be glad to hear them.

Best regards

Victor 


Le jeu. 11 = d=C3=A9c. 2025, 15:14, Antoine Poinsot <darosior@protonmail.com> a =C3=A9crit&= nbsp;:
Hi Victor,

Can we as a community stop callin= g everything vaults? We've seen vanilla multisig wallets being called vault= s, 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, and regardles= s grouping constructions with very different properties under a single labe= l only creates confusion.

What you present is essentially Liana: https://github.com/wizardsardine/liana. Except that Liana uses relativ= e timelocks (CSV) because absolute timelocks (CLTV) put an expiratio= n date on your descriptor, which adds lots of friction and can be quite con= fusing 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 l= ets you configure an Electrum server instead.

Regards,
Antoine
On Thursday, December 11th, 2025 at 6:31 AM, victor perez <sv= crobotics@gmail.com> wrote:

Hello everyone,

I=E2=80=99m working on a small non-custodial vault system and would like= to collect feedback on the safety and correctness of a simple script desig= n, 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 sp= end:

    <CLTV_height> = OP_CHECKLOCKTIMEVERIFY OP_DROP <pubkey_B> OP_CHECKSIG

Both paths behave as expected on regtest, including enforcement of the C= LTV height.

The goal is a simple inheritance/emergency mechanism:
=E2=80=93 before the delay expires =E2=86=92 strict 2-of-2
=E2=80=93 after the delay =E2=86=92 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 Bit= coin 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 re= lying on a pruned node in this context, especially when spending from a scr= ipt with multiple paths (2-of-2 + CLTV recovery)?

Any comments on the script design itself (safety, best practices, or pos= sible 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 e= mail 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 e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAH= yc38kweRwvji1NFPCXn3pXSZHtoT4b8sWLHNJ259H%2BGTKnHg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= vSl9GmLdknrrpIJWieOlkhLVW7xpRcZyMwZiLX2B7kZsRPcRshjdNU5HphnHZObCNyrdfiY9xhX= J-vhgRs3vTYOjIwSjgXeWaUIOgUhgAvg%3D%40protonmail.com.
--b1=_m3KrRe3zeKMjQYiTkLPcsB2LnEUXpshcBforqMtqg--