From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 14 Dec 2025 06:09:55 -0800 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vUmnJ-0002qG-SG for bitcoindev@gnusha.org; Sun, 14 Dec 2025 06:09:55 -0800 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-3f524bd05bbsf4261045fac.1 for ; Sun, 14 Dec 2025 06:09:53 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765721388; cv=pass; d=google.com; s=arc-20240605; b=hzFRG75N6z5TQYTa++0PvhR/4KlAVjuR/GCGpLCiJLg2yrYXPilKaS4iT9N907m2WR ON9XBaGye2gHbR/AgG1D81LpwHuukgkeh2AOCDzFnDQOkLzgsmPLTlNn6G+0LcU4KZNq jkG0dJZUP7ptLEh9qgkEB2Yd/uC4gMIlCfb0fokf9SwejlyQlV7Uc0eZwow2KBwckkJv vI7P3ilTrvSlXUHerosj/VDEdTUeZyqr/FQsKULWTrmzHaZBQsNOxkJBMT0wdKiUqBy2 Io5+bKmIxeMsSUDeKmrlftfuNhpHc4yInBDHw2DsIMvxrNrJ4lUM6O6e2TdA4Zl9/vem eVwA== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=hIMt4XHoUDdaRjI59ifEWdjIBCIaclHBv6zeqx4ZFq0=; fh=Fawx2Jknp0WK0jQUUHf+b9NiqDo6yA9oEc1oEIj2bfE=; b=aJmLCd+VSO0jY/f7JHPfaXDDMNhi2QAPOzu7eCgoQZYiPugNlg4sCdPzgqUv8ZlqcS oto7e7pxoW5gauGg3G1Rjb8DxxotVf0ntPnSj6LS7BYKcKFxT3Vm941DahePQtRVnBPH /bA6uqeSl4i6innQfFhXMdiClT6gXFrwcR/v8H2E9marrawZXQiCK1bsU/P/OCrfNB+j WWWVEL35cOlMSeTz3haQOK8P8h0JmnwHutD8bw78wArvhUfYxfEQ6S4881iGRWTvdr+K ND4xVnwwrRXQ8zLcVWRpqzgMGNJ2iTEwSeh+cNRzD+rp8DjCsWBFEkG184VEAxiMqskA t+cA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DJViiPLA; spf=pass (google.com: domain of svcrobotics@gmail.com designates 2607:f8b0:4864:20::b12a as permitted sender) smtp.mailfrom=svcrobotics@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765721388; x=1766326188; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=hIMt4XHoUDdaRjI59ifEWdjIBCIaclHBv6zeqx4ZFq0=; b=HDLbNlk8LRC7jSKg3SFBK7kbhXOWnP13rZW9cBSaPqHpWbLPvPLamjYTUtuc2avGdf 37VD+cr9z+qmH1h002jd2+8TVTpnkQ01CHwZKxIJUIaAL9x70zi8cReHHtQwxKosyxZv pCpJMVXjCeVMN56d9xnKMIaxhnOfjQpIxGgFHH71DqkXReQHPqwAW8+PF12sAuTtMmyi UeGV6NIdrXS/fEeARGIv1/wNpHBKPsoWnn6zleHkWhHmcxVNsjqXdGs7xU7uU/NM4OoF bcrc8sfDk6OQf4AxG/N9MZtnrfW9a2a50I+HDx08QVexzt0fv/ocubOyp8uZ9ZMrwSWD 7mRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765721388; x=1766326188; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hIMt4XHoUDdaRjI59ifEWdjIBCIaclHBv6zeqx4ZFq0=; b=JlQ9K54JTRu0rkRaya0YBOXCHG/77c1O1Gl0+gvI4C4VlN1IT9WmhT7F5lGMGcd6zw gZzavmp250mJ97XBXpMJ5sW3+PlVG598FMtODuVnwjA39hCSh4o/vVw2jUg0r1SAdB9S z+787P/V3il/61LA44IZegrimTDyw0FuouSPHCd4GHE0tg2F7QTg/Fs4clqua6mI+xLa re5e1PKjk5Z1VDa8oXKHzqzspCamsJ4/hmLT9xNfwQJ2YVh4YYj+w9FZgawlkJrtVM6s Qqy69UMGDiAKyrPYQ39/guvg2w1vz8scEOpbdk+3GeLjY6Ur3EHEgTqEmnDAStCgROiq szJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765721388; x=1766326188; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=hIMt4XHoUDdaRjI59ifEWdjIBCIaclHBv6zeqx4ZFq0=; b=V/RVHfpJQRvqc9kh0BeysjCq7EGFUikWOL7fWwh2rN8MxuvZBBVlnzmQ4YWhX+p3Cc FBmJm2qP4TyFT+B46RDN22T7CDuMZf+nWQRAiPLZOOsi5UNGLCjB1/7bWkqORaYyuPE/ ZfRJUK4Ec/JjWnBaSxAMMKcWeAySPoJjNq/XWMC64HF7hbVJPRBeSlALAP4m3fmRsVqx lFKI0VlEfyofgIKfo2qz4MKLcUKHPdqSZtkdH73GRJx69yqsg7Ex+F0D1TvDFSnkDd0r 8ZcO5NUqeD/eRCz4Je4HwAWwSNtW4Fwl3Q2jGGKw1zacxi5rbU7OyKGSfpGs9Me5ZobD hlTA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWjUT1eLMq9kUB0BZupdu/dx0d3g0d0pn0hh4ftfO9NjDqYyUfDX72USWoULyy98PKgYtbLr8nRQnFf@gnusha.org X-Gm-Message-State: AOJu0Yw7lk+e4PlAu6BPFc9iKfhctM/uJRV0C6st9bWR0R9cGq2weVh9 2vLSua7UY4nCyQVGNTBLGnJUe8wtzWk4isMI0vh6KgtECymfnqZO3A/g X-Google-Smtp-Source: AGHT+IGVc0uwzXNwIuPrqS60x1hGN6y4fu2k6mIWKC95naqYEB/46TYjMvwgn3myPBKP33dfat/fFQ== X-Received: by 2002:a05:6820:220e:b0:659:9a49:8fcc with SMTP id 006d021491bc7-65b452972c6mr3814154eaf.69.1765721387187; Sun, 14 Dec 2025 06:09:47 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWa1knVTId8VgSHfq4ywBOeOjnAv+W+l2RDXE2pdtgrdtw==" Received: by 2002:a05:6870:164a:b0:3ec:4eb6:abba with SMTP id 586e51a60fabf-3f5f877fc23ls1193052fac.1.-pod-prod-05-us; Sun, 14 Dec 2025 06:09:41 -0800 (PST) X-Received: by 2002:a05:6808:4f0c:b0:43f:7287:a5e3 with SMTP id 5614622812f47-455ac87c459mr3068227b6e.28.1765721381616; Sun, 14 Dec 2025 06:09:41 -0800 (PST) Received: by 2002:a05:690c:950d:b0:786:8d90:70d8 with SMTP id 00721157ae682-78e64591f1ems7b3; Sun, 14 Dec 2025 02:40:38 -0800 (PST) X-Received: by 2002:a53:b646:0:b0:645:5433:856c with SMTP id 956f58d0204a3-645555eb897mr4028605d50.34.1765708837716; Sun, 14 Dec 2025 02:40:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765708837; cv=none; d=google.com; s=arc-20240605; b=SKElGLu0S0EEm4la5qPUw+sn5GI/JVCOgpTO8YDwjmTdhY/0zObH//JCUiEcPthfei St61baFgarEit3/Ul9P52zJgfVZya1kz2nlMDEkpSrrR9tYgvLtKqw6rsmuPEQ4SFzO3 3BfTxcYDjH0yfj009PTF1cKVg76XPzdBQM5jh4+xrmKb3iSOy3W4g2jVrGGrgYl/v4S9 oUSTVeP4z36+PEkbkCoZDJn3Op3v9Bj+IykVDD8lBCXNobhsx4bz23QGHuMBR+mhfy3L CxrQsZfEkj12HNDejspBLC2PH9SoCj2Q3xRMSQUg7QL7p3cyka3O8oWibLIA6t7bpGfm iHHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=0UiaOMM7cE9BvedLcLib95T55IwXvLltZeB90zPGqLQ=; fh=m2IwlnuMmP6ceRgqI8U7RCh8Dkd3VeWlWEfxse0Wcvc=; b=YssmNGOFakh6g9Mrxi9U4eXkSBpwHGoChVnfmFRm1LM9Pp4r0z0UowunvI5u6UmKp4 1XCYeDBxluJM1QN7x2uI/McF74cbfQr5dm+qXC/cyN5WpsYRjBNqXSfmTjc6UaQ7g5u4 qtbT+5bjqwB4AzblbOfZrb1YL7IgLwwvWGwYKF9x8x9fyOP6VEKJSkn/A/yaPJmBe+lc TnsGl8oBjPEVSaVxWbeoCEuvWWZCVKVd4C3wDG9cFMbtSiRrUy24gATd8RmHJDf8X9hD IyfLC6ZouUoBLELJKHdBStlhe+KKc88UQKod2jiK4653U2DHRpK7yh8+/nO5jDKLBxWc L92Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DJViiPLA; spf=pass (google.com: domain of svcrobotics@gmail.com designates 2607:f8b0:4864:20::b12a as permitted sender) smtp.mailfrom=svcrobotics@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yx1-xb12a.google.com (mail-yx1-xb12a.google.com. [2607:f8b0:4864:20::b12a]) by gmr-mx.google.com with ESMTPS id 956f58d0204a3-64477da0fa0si478272d50.4.2025.12.14.02.40.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Dec 2025 02:40:37 -0800 (PST) Received-SPF: pass (google.com: domain of svcrobotics@gmail.com designates 2607:f8b0:4864:20::b12a as permitted sender) client-ip=2607:f8b0:4864:20::b12a; Received: by mail-yx1-xb12a.google.com with SMTP id 956f58d0204a3-6420c08f886so2750473d50.3 for ; Sun, 14 Dec 2025 02:40:37 -0800 (PST) X-Gm-Gg: AY/fxX4WhpnpCeuz6sMHv4VwIM2SP7cP6ZFsfsIyk69n4n6T6BbI9lnXawicUgocbn2 pnXvjeaiHA+0wXQfhXiJy4MolSoNL5fLkaK2D0BrX7Hf36vijMpu+s6wpHUFswKfx0D/tVzhjCq +W4P8DwFshLvFOVbxi3bBt5b16N2PhRGXXDpiDmr+Wb1HINo2QfxyeXvCiIhheT5ytvCpmW6Hgi xCKV+8vu1UgkoSRlTyn/mkZF+bI5AViiARUYJZgeHkSY6TVbUoWwKt8NfQJKgN02wxik0XfF6vP VGUwxTnXPy1qCcdwNIvGoILtgjiUr0LMeeO8yvT+kJUhZrELVA== X-Received: by 2002:a53:c082:0:b0:63f:c487:17ab with SMTP id 956f58d0204a3-64555651309mr6596089d50.47.1765708837168; Sun, 14 Dec 2025 02:40:37 -0800 (PST) MIME-Version: 1.0 References: <82546937-996d-495d-8a4e-66654306447cn@googlegroups.com> In-Reply-To: From: victor perez Date: Sun, 14 Dec 2025 11:40:27 +0100 X-Gm-Features: AQt7F2q9qvKxGV5nFlDfk5XxiUctYJXxSNJBTu8Pl_STWK42_rVAdp03OrUKQY4 Message-ID: Subject: Re: [bitcoindev] Feedback on a simple 2-path vault design (2-of-2 + CLTV recovery) and use of pruned nodes for UTXO retrieval To: Antoine Poinsot Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000042bca0645e720bb" X-Original-Sender: svcrobotics@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DJViiPLA; spf=pass (google.com: domain of svcrobotics@gmail.com designates 2607:f8b0:4864:20::b12a as permitted sender) smtp.mailfrom=svcrobotics@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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: -0.5 (/) --000000000000042bca0645e720bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine, Thank you very much for your detailed reply=E2=80=94it's extremely helpful. Following your advice, I'm going to simplify my work and first focus on a single spending path: a clean 2-of-2 (A + B) multisig, signed with two Ledgers. My goal is to get this flow stable end-to-end (descriptor creation, UTXO handling, PSBT flow, hardware signing, broadcast) before adding the recovery path with a timelock. Just to clarify the scope: my application is not meant to be a second Liana. It's an educational and experimental Ruby on Rails environment that I use to better understand Bitcoin in practice. The app combines several independent modules: - A vault module, where I experiment with descriptors, Miniscript/Taproot constructions, PSBTs, and hardware signing. - A BRC-20 and on-chain analytics module, which helps me explore data intelligence by extracting and analysing blockchain data. - A donation module in sats connected to my BTCPay Server. - Various dashboards for visualizing Bitcoin data. I should mention that I am currently not using regtest. All my experiments are done directly on mainnet with real BTC, because it helps me stay fully aware of real-world constraints and forces me to design things carefully. That said, based on your recommendations, I will start integrating regtest into my workflow so I can iterate faster and test edge-cases more safely. Your pointers toward Bitcoin Core's wallet API, BDK, Miniscript, and hardware-wallet policies give me a very clear roadmap for progressing in a structured way. Thanks again for your time and guidance=E2=80=94it truly helps. Best regards, Victor Le sam. 13 d=C3=A9c. 2025, 18:03, Antoine Poinsot = a =C3=A9crit : > Hi Victor, > > > If you have any recommendations on what pitfalls to avoid or reading > material on robust recovery designs, 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 investment: > 1. Go through the flow of using your construction with the Bitcoin Core > wallet API, which implements all those functionalities. For instance you > could take advantage of the multi-wallet functionality to simulate > different signers + one funding wallet. Have a Python script generating t= he > keys and registering the descriptor for each, and then receive coins from > the funding wallet 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 a= n > intentionally low recovery timelock, but using regtest will let you itera= te > faster. > 2. Implement this flow yourself using the BDK [0] library. This will > introduce you to more of the details of descriptor scanning using differe= nt > "chain sources", PSBT processing, all this without having to reimplement > all the minutiae. That said once you've got a prototype working you can > start diving deeper into the implementation of the BDK library, and if yo= u > are interested, into the implementation of the Miniscript language in the > Rust-Miniscript 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 critic= al > to the safety of your 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 signers out there: Ledger, Specter DIY, Bitbox, > Coldcard (Edge), Jade. For the details of communications with those devic= es > you may want to look into the Wizardsardine team's "async-hwi" and > associated libraries [3]. > 4. Finally, the devil is in the details. You asked about robust designs, > and that's what 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 wit= h > a reasonable UX, different recovery configurations, interface with variou= s > 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 such as Liana or Anchorwatch and digging throug= h > their open source codebase. Maybe also Nunchuk which is another mature > wallet that i hear started integrating support for Miniscript descriptors= . > > I'd recommend joining the discussion groups of the projects i mentioned > here, and maybe ##miniscript on Libera for the more technical Miniscript > questions (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: using= =E2=80=9Cvault=E2=80=9D > too loosely contributes to confusion, especially when Bitcoin vaults > historically referred to a very specific construction 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 m= ultisig > with a CSV-based recovery path*, very similar in spirit to *Liana*. My > goal is mostly educational and exploratory for now: understanding the ful= l > lifecycle (descriptor, address generation, UTXO tracking, PSBT building, > hardware signing, recovery flow). I=E2=80=99m not trying to innovate or r= edefine > the term =E2=80=9Cvault=E2=80=9D, but rather build a usable multisig reco= very 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=E2=80=99m running a *full Bitcoin Core node (non-pruned)= * > because it simplifies UTXO retrieval during development. I hadn=E2=80=99t > 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=E2=80=99ll definitely study how Liana approa= ches this > architecture 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 > (inheritance flows, user-friendly recovery logic, analytics, etc.) once t= he > foundations 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 > material 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 n= ow >> a decaying multisig. Not trying to blame you in particular, but a vault = in >> Bitcoin has (or used to have?) a specific meaning >> , 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 confusi= ng >> 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 nod= e, >> 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=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 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: >> 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 >> 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 Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/82546937-996d-495d-8a4e-666= 54306447cn%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/CAHyc38kweRwvji1NFPCXn3pXSZH= toT4b8sWLHNJ259H%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/= CAHyc38%3Da%3D7fCgPg10e%3DjkpiUA8qiJf%2BDAaoOaNcP1JajjsZTtw%40mail.gmail.co= m. --000000000000042bca0645e720bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,

Thank you very much for your detailed = reply=E2=80=94it's extremely helpful.

Following your advice, I&#= 39;m going to simplify my work and first focus on a single spending path: a= clean 2-of-2 (A + B) multisig, signed with two Ledgers. My goal is to get = this flow stable end-to-end (descriptor creation, UTXO handling, PSBT flow,= hardware signing, broadcast) before adding the recovery path with a timelo= ck.

Just to clarify the scope: my application is not meant to be a s= econd Liana. It's an educational and experimental Ruby on Rails environ= ment that I use to better understand Bitcoin in practice.

The app co= mbines several independent modules:

=C2=A0 - A vault module, where I= experiment with descriptors, Miniscript/Taproot constructions, PSBTs, and = hardware signing.
=C2=A0 - A BRC-20 and on-chain analytics module, which= helps me explore data intelligence by extracting and analysing blockchain = data.
=C2=A0 - A donation module in sats connected to my BTCPay Server.<= br>=C2=A0 - Various dashboards for visualizing Bitcoin data.

I shoul= d mention that I am currently not using regtest. All my experiments are don= e directly on mainnet with real BTC, because it helps me stay fully aware o= f real-world constraints and forces me to design things carefully. That sai= d, based on your recommendations, I will start integrating regtest into my = workflow so I can iterate faster and test edge-cases more safely.

Yo= ur pointers toward Bitcoin Core's wallet API, BDK, Miniscript, and hard= ware-wallet policies give me a very clear roadmap for progressing in a stru= ctured way.

Thanks again for your time and guidance=E2=80=94it truly= helps.

Best regards,
Victor


Le sam. 13 d=C3=A9c. 2025, 18:03, Antoine Poinsot <darosior@protonmail.com> a =C3=A9crit=C2=A0:=
Hi Victor,

>=C2=A0If 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=C2=A0through 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=C2=A0for 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= ]=C2=A0library. This will introduce you to more of the details of descripto= r scanning using different "chain sources", PSBT processing, all = this without having to reimplement all the minutiae. That said once you'= ;ve got a prototype working you can start diving deeper into the implementa= tion of the BDK library, and if you are interested, into the implementation= of the Miniscript language in the Rust-Miniscript library [1]. Since you a= sked about the pitfalls of implementing such a construction, this is where = you'll learn about a lot (but not all)=C2=A0of them. The inner working = of=C2=A0Bitcoin Script is both critical to the safety of your funds, and at= times very surprising. Nowadays, it is=C2=A0neatly abstracted to higher la= yers=C2=A0by Miniscript in a safe(r)=C2=A0manner.=C2=A0Digging down this ra= bbit hole will teach you why a lot of things work the way they do.
3. Investigate how hardware signing devices interface with more complicat= ed wallet spending policies. Learn about Salvatore Ingala's "walle= t policies" [2]=C2=A0and try implementing signing against one of the c= ompatible hardware signers out there: Ledger, Specter DIY, Bitbox, Coldcard= (Edge), Jade. For the details of communications with those devices you may= want to look into the Wizardsardine team's "async-hwi" and a= ssociated libraries [3].
4. Finally, the devil is in the details.= You asked about robust designs, and that's what most time consuming. Y= ou 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, different recovery configurati= ons, interface with various signers and chain sources, can take years to ge= t right. If you are interested in that aspect i'd recommend playing wit= h more mature Miniscript-using projects such as Liana or Anchorwatch and di= gging through their open source codebase. Maybe also Nunchuk which is anoth= er mature wallet that i hear started integrating support for Miniscript des= criptors.

I'd recommend joining=C2=A0the discu= ssion groups=C2=A0of the projects i mentioned here, and maybe ##miniscript = on Libera for the more technical Miniscript questions (Bitcoin Stackexchang= e is good for that too).

Best,
Antoine P= oinsot=C2=A0




-------- Original Message --------On Saturday, 12/13/25 at 05:05 victor perez <svcrobotics@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=C2=A0


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

Can we as a community stop calling everyth= ing vaults? We've seen vanilla multisig wallets being called vaults, th= en 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 reg= ardless grouping constructions with very different properties under a singl= e label only creates confusion.

What you present is essentially Liana: https://github.com/wizardsardine/liana. Except that Liana u= ses relative timelocks (CSV) because absolute timelocks (CLTV) put a= n expiration date on your descriptor, which adds lots of friction and can b= e quite confusing to less technical users.

By default Liana comes bundled with a pruned Bitc= oin Core node and uses its watchonly wallet functionality to track your coi= ns. 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=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 &= quot;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 &= quot;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.goog= le.com/d/msgid/bitcoindev/CAHyc38kweRwvji1NFPCXn3pXSZHtoT4b8sWLHNJ259H%2BGT= KnHg%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/CAHyc38%3Da%3D7fCgPg10e%3DjkpiUA8qiJf%2BDAaoOaNcP1Ja= jjsZTtw%40mail.gmail.com.
--000000000000042bca0645e720bb--