From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Dec 2025 02:05:38 -0800 Received: from mail-qt1-f186.google.com ([209.85.160.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vUMVN-0005qk-6C for bitcoindev@gnusha.org; Sat, 13 Dec 2025 02:05:38 -0800 Received: by mail-qt1-f186.google.com with SMTP id d75a77b69052e-4ee41b07099sf24172671cf.2 for ; Sat, 13 Dec 2025 02:05:36 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765620331; cv=pass; d=google.com; s=arc-20240605; b=a5GDaSYeuil7j8qnWiXGqbQ+31Q0XvlX694kua5CIlbS0r/vev/1Ru2zU3I9+Rqx6z 1VHI5DaMnX0uVdPVLeIa80AOkAIJeEeFu9eJ66U2aJFe9mwU/3Ygq24r7Bthz5jA7+qZ 2jZYfIqSQEGqcyvJO2mDwMXMWFvFz2ecISSFsjLLFfa0mfGwts9mqKVNM1uBdWNe0eLK SiXt6iMHuvBhwoFy8wEfIECLW+GgipkejoACacb6GRXninjljqQST2G6UBtOvG0gpaAB 1Y7d6nCSJnGcQMB5We/10iJ06Yq4jQM0/JSiPkAOOI1KFGr5GWGziTG7uC370MnZkCqR 1F6w== 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=4vECSszf/IPP1w+NEnz2izeIFaWrjV2cQOoPb+JRTWQ=; fh=rQCmgPFNCKgCRg2z3/p9MOtfMRCvj5RPAgXyWaUzWX8=; b=PUPBtt4v9Ud3cNKW4j4vc/IPdRAfUAP1NjOfWW8jJN3idOSkqaRfxpfmd8di2iJqHt Gf5Pqsta6EVnNqyCcrq6tC/DRfHGhD3tQ16McLIkhcb6lYcvgDXhwyYb6eFEkKRy6+P2 FcG/BI8VlE1+yYtEb7XsStGBjG1ddfCSiTltXxIe+nNCsNhUS9MZMSIYVqjrC4NDB0l8 GCxkOzZrBpCr70HXpJbvic2dQo4Hfslci8ssTsOiYWU4pvPq0B2Rylxrro/Oo2zJCveY mD/KSaBtFEz/6zl/FY1P+t9z7od9MKXyxnGNYCnmwp35R1XXAmK8ybjcwG3eAT/arwot yxZQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=S6BClYRS; spf=pass (google.com: domain of svcrobotics@gmail.com designates 2607:f8b0:4864:20::b131 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=1765620331; x=1766225131; 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=4vECSszf/IPP1w+NEnz2izeIFaWrjV2cQOoPb+JRTWQ=; b=n7LO5iatagXUG9cjJRnpR1pFpvTsCtj1mhE9GOh5QGY1elybp8s0kb1e6BI8fwm7Ux bqsHBeegCJ0MkWPEaOa8FwCCma/ZP9b+vrsFn+uPEqJPFTaL6/fCvMZw4Azrg4JuB4y0 fOjJ2knnlIMHre0XsqfdJ7lOvmcMRQx1owH96OCm6Nk86L7xOE/A+fo/eH16sqikQEit v+Oi4kuNFUfBg6D5OwWEo3kNElzzr6BLe9LI4Td/WiwgfDd5rycVeQQCg0T2JY61LU3r DXEbkA17efdAUycdAJWJOVxP37ivExJjpEudD9VBlnqF4E1Wc4yQJRb4+Xrz33Y0w7aF lHbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765620331; x=1766225131; 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=4vECSszf/IPP1w+NEnz2izeIFaWrjV2cQOoPb+JRTWQ=; b=FgQURz9GxEUywU0vJsTjz3LpcwSYyMFzrRHYFmHxF28435zf6hncGdA7F57piiGG8a uu2egsPFe8r4UiAqRgMsqBBdz+PRQMfSE6Co5z/qBR/lNTSS7RmfAVD3tdsftyJyjr/0 b93yzyrinpgV07X/HWbKRhd3dAOXCdwbldwZ5C7TbFKY9vdNKyXyRPa7pUglSH4xkmbN lQkFwAzn4gtE5+G9UW8YM4baT2XZSOrwdh7VxUSFJXPhi/CYIXEn1EDynwXC/5ezPUd4 MeQu/Rnk99HYbAmm/TuQXm3CxF7tj/f2wP5VxctKgTdHBErItPvsxUpoACc8SqmiS2zF de1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765620331; x=1766225131; 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=4vECSszf/IPP1w+NEnz2izeIFaWrjV2cQOoPb+JRTWQ=; b=jYepnW7nJZpD4vgU5rFfkzBgbMkXJGZT5CN+OYrkIjA6qoWpMxZNmeSs4GDZHVF5XF DUV3saCUFys7sWfSL9sF97015gcJw+VFV6Pjga0vCEl3xyDzWc4g8JqjMlfcAsE0zLJA 89Fc+5ClVpXSdiW14Iy7LROvmgkCqU7vPesSUJFazOERA4dryUReywVF5AfcPFVu6+PC jwkWVT0hO/CTP+tJ0R5/1x6hJHIO1ka9Uji3C89Sb6Gra2KZjaihEtkoNe6F7UzNkNjm A8EKO+tU8nFQMPrr40Vwa5zPZHPBI3hlh6QUImfKuyHh6DiMYQMzHQmtljaYurPD8A83 ++dA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCV10cro14oP4z4HisNc3KeCVaV+eZhJuAPk5dccwlw18rrJqN5hNf8nNMgyK5F1fmO3RlmC8hfcB0lJ@gnusha.org X-Gm-Message-State: AOJu0YxAPgu8HP3INGoMRrJKuHytDPiyGzf/jhaXNWcxEfp/mvCkFR/5 MIlUMK8cxdICOjQP+t9crq5orSsRRta6V0nuNAz4blQUyxDBrj8bkMNY X-Google-Smtp-Source: AGHT+IH6iigvD0YZQqHeoSQrMqEINKADFjLHUkCRJtGvpmT176nEhiVuL+SvHIDtFGxLhDZsW/Bk+Q== X-Received: by 2002:a05:622a:8d01:b0:4f1:e46b:9dcf with SMTP id d75a77b69052e-4f1e46ba93bmr3736551cf.26.1765620330619; Sat, 13 Dec 2025 02:05:30 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYZ/Mjg8JDzmtEYnzpDWrs6Y8vh4C0ljJ/3Im6Nj3lkwA==" Received: by 2002:a05:622a:1391:b0:4ee:1b36:aec4 with SMTP id d75a77b69052e-4f1ce9673ddls30957581cf.0.-pod-prod-08-us; Sat, 13 Dec 2025 02:05:24 -0800 (PST) X-Received: by 2002:a05:620a:711b:b0:8b2:6ac5:bce1 with SMTP id af79cd13be357-8bb3a248c9cmr758710685a.52.1765620324160; Sat, 13 Dec 2025 02:05:24 -0800 (PST) Received: by 2002:a05:6808:a608:20b0:450:d12c:eb7e with SMTP id 5614622812f47-453888e4f95msb6e; Thu, 11 Dec 2025 07:15:41 -0800 (PST) X-Received: by 2002:a05:6a00:b4f:b0:7e1:7a1c:68a8 with SMTP id d2e1a72fcca58-7f22ce1da8emr6963410b3a.15.1765466136942; Thu, 11 Dec 2025 07:15:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765466136; cv=none; d=google.com; s=arc-20240605; b=Vmy9ms5jKYbTWv+vTU3pF1vXbuov8U02vVIpyWo9/eV0jmVAcsQGwSs0MvoDdg6nSB UObHIppQZxTNSC6NCRqNv6Ywj8hCnxIUGfjF4A/MqLfFSIvpRj2m5kwPISw8GUVPCZNt 9lnXW0z7DGOEVszLoARDi3mIIDJzPDkJt07YhrFWis80L/LCDWxnRaGulq8lCyjOrD/a XCYf/j+BwoJe3dfwNwQa+Zhaju56OAOe1njl7wFuv/dZq6ZPFeE5DRdJn1QJYcxdp4CR HMRbwiFr/HC1y31M+Z/bH2EuvFNBfNQmsHN9T81uwXiXq/cOVXkfi5xxjGeXUJOTAGBm RiPw== 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=yIXXZccTomLvMJQ9zMMLaeJa42yjvR6zY7vTwMAWasU=; fh=m2IwlnuMmP6ceRgqI8U7RCh8Dkd3VeWlWEfxse0Wcvc=; b=dVhocBq3WJd9KbtaKH359fRzwflsz5iPn8fhjX87rgDECntGMf5hyN+OJONT6+uSOM V1I1QH+fV9ZUJ/EViFuMK0Zp5v+eB7wj6/dsku6c7m4jG76/UBV820h+7fpqrTEDV/sg N5pIJHyTUpmOKo4dgWiWzh3C/4qRiQNzCpSkikxkrGWE51cDzj83U75/wDc4LLBYT0fd lK1aUpbh96xr0+bovFSPuQG8asvgWyxCkdK4UmjEeE7hEWNWezUc51o4QmJ6AsyNaMaN vk0OUVvtLDDLJIEXyET8nl0f8w3UrpPVJ+6g3QdMqkIwQWwhWI6q6sa7RTbcIXOStxBB HTRg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=S6BClYRS; spf=pass (google.com: domain of svcrobotics@gmail.com designates 2607:f8b0:4864:20::b131 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-xb131.google.com (mail-yx1-xb131.google.com. [2607:f8b0:4864:20::b131]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-7f4c566b5d2si67839b3a.8.2025.12.11.07.15.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Dec 2025 07:15:36 -0800 (PST) Received-SPF: pass (google.com: domain of svcrobotics@gmail.com designates 2607:f8b0:4864:20::b131 as permitted sender) client-ip=2607:f8b0:4864:20::b131; Received: by mail-yx1-xb131.google.com with SMTP id 956f58d0204a3-64476c85854so177015d50.0 for ; Thu, 11 Dec 2025 07:15:36 -0800 (PST) X-Gm-Gg: AY/fxX55m7MUBHtgqQh8QJu5TYZVQu+nYkBe6z797n9MI9V23U6baTlm49ICmxF0Psf 4zErFxyrl9t1Z+ZxmMo6RmsMsqfESdBuvMVq7CBiao7F8ZcImPA6r9tIHg1mZmDe2Ryui2zEPdq 1wSmpnOCO67LiWb16M0bsAaIVKcZQiyao9c25FYghGuggyLnVn+F2kD5NAvvfK/1agpffbU0DD5 5NzUiM6X36kgvNygosJZuNFDdo9FIu0XMcHW6FINm4fCXuGIbtpykw9cOD8ZDGbeZgg5fXqgbkX dgDOiQY61PuExAiC0dlwffD1GV2fcF4gs6CaToXFul76gpieNA== X-Received: by 2002:a05:690c:2784:b0:78e:1aa5:e95f with SMTP id 00721157ae682-78e1aa5ec24mr32209117b3.13.1765466135760; Thu, 11 Dec 2025 07:15:35 -0800 (PST) MIME-Version: 1.0 References: <82546937-996d-495d-8a4e-66654306447cn@googlegroups.com> In-Reply-To: From: victor perez Date: Thu, 11 Dec 2025 16:15:26 +0100 X-Gm-Features: AQt7F2qktMyQtD1n_8I6hRPL8ygQBvV70K4CkA0YFsCycCTwgLn58vbM4devJ-g 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="000000000000e2935a0645ae9d4d" 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=S6BClYRS; spf=pass (google.com: domain of svcrobotics@gmail.com designates 2607:f8b0:4864:20::b131 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 (/) --000000000000e2935a0645ae9d4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine, Thanks a lot for your message and for pointing this out =E2=80=94 I complet= ely 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 what= the system implements. The construction I=E2=80=99m working on is indeed essentially a *2-of-2 mul= tisig 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=E2=80=99m not trying to innovate or red= efine the term =E2=80=9Cvault=E2=80=9D, but rather build a usable multisig recove= ry 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 implement= ed 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 approaches this architectu= re before going further. My intention isn=E2=80=99t 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 =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 no= w > a decaying multisig. Not trying to blame you in particular, but a vault i= n > 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 confusin= g > 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=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 PSB= T > 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-6665= 4306447cn%40googlegroups.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/= CAHyc38kweRwvji1NFPCXn3pXSZHtoT4b8sWLHNJ259H%2BGTKnHg%40mail.gmail.com. --000000000000e2935a0645ae9d4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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 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 v= ault in Bitcoin has (or used to have?) a specific meaning, and regardless grouping constructions with ve= ry different properties under a single label only creates confusion.
<= div style=3D"font-family:Arial,sans-serif;font-size:14px">
What you present is ess= entially Liana: https://gi= thub.com/wizardsardine/liana. Except that Liana uses relative timelocks= (CSV) because absolute timelocks (CLTV) put an expiration date on y= our descriptor, which adds lots of friction and can be quite confusing to l= ess 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 configu= re 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubs= cribe@googlegroups.com.
To view this discussion visit https://groups.= google.com/d/msgid/bitcoindev/82546937-996d-495d-8a4e-66654306447cn%40googl= egroups.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/CAHyc38kweRwvji1NFPCXn3pXSZHtoT4b8sWLHNJ259H%2BGTKnHg%40ma= il.gmail.com.
--000000000000e2935a0645ae9d4d--