From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 11 Dec 2025 03:32:03 -0800 Received: from mail-oi1-f185.google.com ([209.85.167.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vTetu-0001TW-HE for bitcoindev@gnusha.org; Thu, 11 Dec 2025 03:32:02 -0800 Received: by mail-oi1-f185.google.com with SMTP id 5614622812f47-4501735f488sf1093971b6e.2 for ; Thu, 11 Dec 2025 03:32:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765452716; x=1766057516; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=yPFiaCaupxWuWfLXZJNlAro2ENjyR6RkePZrL9+Nd0Y=; b=aulLYnZU7ZLeylPTj0aw6tWZ+ldHLa9/0k1cUwyIzdnjABuIwBgrRCP3JvSvw/q3z6 +JK/4M9nvcoJK0PkG3Qw11T00yX/vRC1bG/I/pFVzKOC06upOaChlYo4VvNevWAqo+c+ oijO61/uHkoB1je3IfavwD1y6fRHfa2aPzpIiQjsciqxavA8TOCuYTd6KfECKy4utoUo VRjv5SuGuE2zmdyW+pFeATv2qlKalSXS16ev59krtqa+pfwyRyzQ3X5B6RpFoYvAWcij bdRbswK5mTFWpnMQbuQWrf/eEbXfPD65BaOOKb3fO50kqGeo+c14mc5Fbk7C/qbAoQ4f gqSA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765452716; x=1766057516; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=yPFiaCaupxWuWfLXZJNlAro2ENjyR6RkePZrL9+Nd0Y=; b=mx43yPaWLCQJ0yRC/EvhrwtP9UZB8XqN+JIbNjscYV/q15AfUjbwgswKjqwexebMo5 QiWiBeNxc6W0DzJguTEN0saXF6a9GWJV8MdQs8rdzvit5U+xnvxUf34rUUM26E7e929C QosJQXZcWK7UB/Ks1HTcpX0WdyBTieYgpErRwtb155/xqCB7shsqeuaWiRF5GrwfrjXJ wvmck5GG+z5ZlrfO2K5PTfebJsN2hAMJXBioljuQXZgSiMTEFnpmLOY76Ldz0u8+dS4J 35zZ7Gx3nv9ff+eTLPuaNXWNtTbzLojH0dZS3GiNK56uRvxFsRO27BYQDhsPlZ/P4Hrb 8Jew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765452716; x=1766057516; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=yPFiaCaupxWuWfLXZJNlAro2ENjyR6RkePZrL9+Nd0Y=; b=v5zsTw7/IgHajxjqvb7Sbf8KAWIgiIgpGW+zp2U6zOZnOG00ueQ7TDrrx+a1wSMCUn 7ou858Ux9MBBupsKQktnJAFKBvgIBieKmI27eeJhM0643WnJZSX9fAd4vhlGBzYXwiHA AYfsMu/jmV/DEJrChl8rZ0+4gqhtasAl6wOLxHwb11Di0oLjP1/rcKJCOGt+4CnrEcQP kLBndSvsEJYnS2ya7X4C/VmTp3vpNap1lxybDmx1beTw9m9cYDIzN5zVkMNm8vTZrNbR mEmpwY6FBYJMuOH2/vetmL0JuDaShTwnV4uPAWKz67qYC7Z5GkAxdDt7jXxvhYczj1h2 U8fg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWnZQL9tAY9890/NGNDoSO8ca8p71wEeks3ewvn/TnynmfsUHmOnKzj9t9UlccXEvPCbSvEpB9nu+jx@gnusha.org X-Gm-Message-State: AOJu0Yw17fbxiQe38UlOkW4sCYlvK+vXrthyuWqY4cqSNIqqQessF9eW 7rrp40MhNEh7wE1VRy12g1uUil9zFuuVrxphILKfH9ML8Ul0ebAzTIhZ X-Google-Smtp-Source: AGHT+IHJObj80oTisXBjdHyfefP9YSOFsmGAC6rUvtoRIZsQFEpmVMSeKn9paK4JDid+l1SlvP7DaA== X-Received: by 2002:a05:6808:3206:b0:450:c648:4aeb with SMTP id 5614622812f47-455864ea65fmr3168338b6e.44.1765452716018; Thu, 11 Dec 2025 03:31:56 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWbwg0m0DnO6HPqR4hipXO6EDxjM/txJ3S+rovu3sCc3Zg==" Received: by 2002:a05:6871:a80c:10b0:3ec:53ac:b3af with SMTP id 586e51a60fabf-3f5d98ba7afls236724fac.1.-pod-prod-06-us; Thu, 11 Dec 2025 03:31:50 -0800 (PST) X-Received: by 2002:a05:6808:1b8c:b0:450:275b:d942 with SMTP id 5614622812f47-455863404ddmr2805705b6e.10.1765452710212; Thu, 11 Dec 2025 03:31:50 -0800 (PST) Received: by 2002:a05:690c:768f:b0:786:8d90:70d8 with SMTP id 00721157ae682-78c23b93f22ms7b3; Thu, 11 Dec 2025 03:30:47 -0800 (PST) X-Received: by 2002:a05:690e:255b:b0:644:36cb:8b59 with SMTP id 956f58d0204a3-6446eb2dc74mr3565847d50.76.1765452646575; Thu, 11 Dec 2025 03:30:46 -0800 (PST) Date: Thu, 11 Dec 2025 03:30:46 -0800 (PST) From: victor perez To: Bitcoin Development Mailing List Message-Id: <82546937-996d-495d-8a4e-66654306447cn@googlegroups.com> Subject: [bitcoindev] Feedback on a simple 2-path vault design (2-of-2 + CLTV recovery) and use of pruned nodes for UTXO retrieval MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_82932_1899270501.1765452646219" X-Original-Sender: svcrobotics@gmail.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 (/) ------=_Part_82932_1899270501.1765452646219 Content-Type: multipart/alternative; boundary="----=_Part_82933_361685922.1765452646219" ------=_Part_82933_361685922.1765452646219 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, I=E2=80=99m working on a small non-custodial vault system and would like to= collect=20 feedback on the safety and correctness of a simple script design, as well= =20 as on a question regarding pruned nodes and PSBT workflows. *Vault design*=20 The vault uses two spending paths: 1.=20 =20 *Normal spending path (immediate):* 2-of-2 multisig (key A + key B required) 2.=20 =20 *Recovery path (delayed):* After a predefined block height (CLTV), *key B alone* can spend: OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG=20 =20 Both paths behave as expected on regtest, including enforcement of the CLTV= =20 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= =20 devices. *Main question*=20 For the client software, I would like to use a *remote pruned Bitcoin Core= =20 node* (for storage and deployment reasons). The client retrieves UTXOs, fetches the required previous outputs for PSBT= =20 construction, and broadcasts the final transaction via RPC. *Is a pruned node fully reliable for such a workflow?* Specifically: -=20 =20 returning all UTXOs belonging to the vault address, -=20 =20 providing scriptPubKey, value, and other fields required in a PSBT input= , -=20 =20 validating the timelocked script spend, -=20 =20 broadcasting the final transaction. =20 Are there any known limitations, edge cases, or risks associated with=20 relying on a pruned node in this context, especially when spending from a= =20 script with multiple paths (2-of-2 + CLTV recovery)? Any comments on the script design itself (safety, best practices, or=20 possible improvements, including Taproot-based approaches) would also be=20 very welcome. Thanks for your time and insights. Best regards, Victor --=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/= 82546937-996d-495d-8a4e-66654306447cn%40googlegroups.com. ------=_Part_82933_361685922.1765452646219 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/82546937-996d-495d-8a4e-66654306447cn%40googlegroups.com.
------=_Part_82933_361685922.1765452646219-- ------=_Part_82932_1899270501.1765452646219--