From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 11 Dec 2025 06:23:45 -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 1vTha4-0006id-C3 for bitcoindev@gnusha.org; Thu, 11 Dec 2025 06:23:44 -0800 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-3e890e6be00sf120669fac.3 for ; Thu, 11 Dec 2025 06:23:44 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765463018; cv=pass; d=google.com; s=arc-20240605; b=lguN1YJ4ex9w3dIxPSfKb7fh44xfIK8OUuwxBa6320n5xSTStCqSJWYd6ApFx0YpQy wILZMk8u5pNIm3lPTOByNkYbVWfqa11bmIdsiYfaQW43W++uB37df/4OkfGb6iqrwO2Z 2MRpjo1B5dtKIctLo5RUaJAMveFKx02G3FT+ADi446ek8M7DtJpZaT4Pc2eytjOQpZsU zOrxyPqTutk1EpJaYafsfwwqEcvMlsUF2UL3HBBoSO8y8M8Vd1n97CUtnXMEKmZjvrAL pLImHNKSIakxcQskOn0SrikAg94piUcMelwVp/gZldCs98s8seX76Q8YMIsIM44fNDRz L+qQ== 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=SHMTVUQPHbhyw3qInstPo9jrwq7Q6ry8eMX0M5hsw64=; fh=3tKj+yjWkQOfEJqrFafTniPE34n9mJJiUMEip8GqYRU=; b=BOIhyiTC7rjZ7IT1uCRZUlpVNmnuntx46Go5vz7yVXUBUucbfUcB0mbShMosutnWPB a/tseFLOHCLgVAMEN0DETdjazMtN1M1ZNpKAkxlYvsTP1GbomWfbF0UhMY7LUakKEzzj XBChFjud7343s0ll+XyB1E9hg1kpyGfiIbGZGGzlG4MslwVLplS5G+8xmjRGy9aYRvkK iBlz53wWIycFQU7OLCa6D3v58zlSx4d8AsDXi+G8tT9cpZTYE823bRiclgs1u8UnIKBF e52uAfA+DFpI4a0XStJ/0zjfRyEOHFl66Yf4d90/lgVUOn6RAaa2xBmEGgWCGfb0JdRh CGww==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=P7tOUZ2s; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.18 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=1765463018; x=1766067818; 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=SHMTVUQPHbhyw3qInstPo9jrwq7Q6ry8eMX0M5hsw64=; b=qPGbeLua5WfFiaDvuTDUS4uEc+4nmi/UUPA55DrID566b4P5KCZGfo/gFtG30BMzax AsC7jAx8Tfz5a/kYsiQ9FbitgNJktBloh4+8bC+ii3XS1IuCGY7yGP2Pk+LfxUyy/ltl gMvDQI81E7H+0gsdiqrTghC8vagciy1NWLJyvU8VTwUQIpIhVfPqfarVVy0ownX5hyse YT7LcYVFikHuiuIXt3gXF5sRePoARxTJIbYEbWuGT0MRiqrglXKvtG+bFPyuqjszIsKM WlyVH4MeD7/Q7smD2BhJ6+5ezLfenxH6T76vmp1kugERb7cERyEbfLLmfamR7ZG0biJH zwXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765463018; x=1766067818; 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=SHMTVUQPHbhyw3qInstPo9jrwq7Q6ry8eMX0M5hsw64=; b=icgRurYTOED46WGafe+08grE80/fEtgqLWaQ011DfYPA0a1MIhTWKXRFdyurA6KRFN FOsVaXbI7V3uNqfUNdEpZjt4o/5Xq6pgiSf3orSlqs6g/qan00UbnC8jl2krjjxYEM5v 723axmR7CRC4XNpZv2XULnwe74SXG4+O/Gue39Ame9m3yyG63uDfFVCBZHTmlVXBdBiV h3x2S50cAArF/5zeV4Kmu7lp81uaSW2aIW4cCHlGN6ImlmYOb1M0kboC9329LLAta7yt pp48QDf4t1GdiLr3v9/bhuLeXdNH7prpCHlAMy2lssJZr4BgLopxxf2XdB7G05FVAi0K 4n3w== X-Forwarded-Encrypted: i=2; AJvYcCUI4NKiuZhtsqYax8u+J0DOXv6JX6Z0xelcauBTIgd6khHUBLH200wLgVbNgHzCx+F5/uRjSoDjnDqo@gnusha.org X-Gm-Message-State: AOJu0YwBBpcSRB1Dn32F92WdmtF337oj+r40I4BFjOmSLBEx2pe+VtDG BCmMszzLCHhhP7RhJPRVEWwzyis2NrJTQs1+ncjnr3wgVkj3nU4w4FPl X-Google-Smtp-Source: AGHT+IFj/1JmWY7CGJv4rn90R1oMg3zyLiDg1bD061C6UfEfP+akAdbDVxMb13AhBCE/UXyc8j/dtA== X-Received: by 2002:a05:6870:b69c:b0:3e8:3382:aaf9 with SMTP id 586e51a60fabf-3f5bdbd4c39mr3914480fac.37.1765463017852; Thu, 11 Dec 2025 06:23:37 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYEwbaQJ8JhOntn9jBdxaTO10/E+9R6wQmg9SQ4HiNgXQ==" Received: by 2002:a05:6870:5589:b0:3e8:2785:9a19 with SMTP id 586e51a60fabf-3f5d9d76730ls450337fac.1.-pod-prod-08-us; Thu, 11 Dec 2025 06:23:33 -0800 (PST) X-Received: by 2002:a05:6808:13cc:b0:44d:a3e3:40a9 with SMTP id 5614622812f47-45586554e0cmr3372342b6e.8.1765463013556; Thu, 11 Dec 2025 06:23:33 -0800 (PST) Received: by 2002:a05:690c:9314:b0:78a:986f:9439 with SMTP id 00721157ae682-78c5aaeb8d7ms7b3; Thu, 11 Dec 2025 06:14:50 -0800 (PST) X-Received: by 2002:a05:690c:2784:b0:78e:1aa5:e95f with SMTP id 00721157ae682-78e1aa5ec24mr27947667b3.13.1765462489200; Thu, 11 Dec 2025 06:14:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765462489; cv=none; d=google.com; s=arc-20240605; b=cqI42TFLF8W8nWc9n8rnxkD92DFnUojBoxndEzWiQi8jTnXOI6aH/4ebBD8YG/3Yxo CEtRuXMNOI4ONNZaVDHchfp3IHDpGQxAjEwnoTRCXjUQFEsACKKRW7JCyYxSB+yshKSf JScdrzau8BoRavHDAAe7B+lVYb7zO9hLDSkrMOvH+Kwy9SLZ+6JjDCfkrvnm457D7IY2 UieY8v3PbF1w6CZhFMRWVierlTwv2VeoXIweqOqbYgj8MT0KpOme38cNdqSr3rp1vH+D jkYzmTQ4MgABtEUNML97rlNG7eEBJbcV/DF5OMPEXgT2BsFxYmE45sPrA+ZiAHqtYgvE +aGA== 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=06GU6LLCg1EaFblvU5vJKYAE3C6X8cEZyRl5hwZV2ys=; fh=WNoHR1GJUIcpyzk9HruMkt4cUNByuksWuGekomM+v2o=; b=aftEhGV3kGLda00HuPG8v4Ao2XieY2yUKXwjcP5EFILC4c7r9/BanBbJPG7GTJWTlf +wtkenDzd4g3nP5eSEX7QelGU8F6XTKnOeEZUTwtjGG3WvjEcBz8ZAaJeegma5+lwWig ByJyLeOj+FNVgXHW0ShuXuIwtWJDh2CYjF45FcgM8Td726IY8tGlV+7DNiJPBpvtKy/t 0DII8Vpfc750s2dsB+04rWQkvnTFs4EYZV5p9uImGNRwsCufqJRkiWobXQJg/y8/LTyv X/PJPDov5iTMH4nyRNrstFRixHI5xAl8IoJJPP5LYLuuburv6bJb+zHTHb1OlZpKdcOS zazQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=P7tOUZ2s; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.18 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch. [109.224.244.18]) by gmr-mx.google.com with ESMTPS id 00721157ae682-78d69b4c5b4si1744047b3.0.2025.12.11.06.14.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Dec 2025 06:14:49 -0800 (PST) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 109.224.244.18 as permitted sender) client-ip=109.224.244.18; Date: Thu, 11 Dec 2025 14:14:42 +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: <82546937-996d-495d-8a4e-66654306447cn@googlegroups.com> References: <82546937-996d-495d-8a4e-66654306447cn@googlegroups.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: c3c8220d63355e56ddf54dbcbfb8619271bc5617 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_VTL6y3lCZzhqnXEUEhO8o1VIDUM6dMjriu7Js59is" 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=P7tOUZ2s; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.18 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=_VTL6y3lCZzhqnXEUEhO8o1VIDUM6dMjriu7Js59is Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Victor, Can we as a community stop calling everything vaults? We've seen vanilla mu= ltisig wallets being called vaults, then CTV transaction chains, and now a = decaying multisig. Not trying to blame you in particular, but a vault in Bi= tcoin has (or used to have?) a [specific meaning](https://bitcoinops.org/en= /topics/vaults/), and regardless grouping constructions with very different= properties under a single label only creates confusion. What you present is essentially Liana: [https://github.com/wizardsardine/li= ana](https://github.com/wizardsardine/liana/). Except that Liana uses relat= ive timelocks (CSV) because absolute timelocks (CLTV) put an expiration dat= e 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, Bit= coin Core's RPC interface is not adapted and Liana lets you configure an El= ectrum 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 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: > > - > > 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 CL= TV 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 Ledg= er 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 rel= ying on a pruned node in this context, especially when spending from a scri= pt with multiple paths (2-of-2 + CLTV recovery)? > > Any comments on the script design itself (safety, best practices, or poss= ible improvements, including Taproot-based approaches) would also be very w= elcome. > > 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/bitcoinde= v/82546937-996d-495d-8a4e-66654306447cn%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/= ywe-dbEMw2fKIXvUV7gTVyZmJENCN20PSAbB-pZYGe-0Skd9OKGFxAOfOT17UUHcFOkw1j0BeNL= -G5aEMe3HQlnh1pNuxpxGL4Z09oUkdTo%3D%40protonmail.com. --b1=_VTL6y3lCZzhqnXEUEhO8o1VIDUM6dMjriu7Js59is Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Victor,<= /div>

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 decayin= g multisig. Not trying to blame you in particular, but a vault in Bitcoin h= as (or used to have?) a specific meaning, and regardless grouping = constructions with very different properties under a single label only crea= tes confusion.

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

By default Liana comes bundled with a pru= ned 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 <svcro= botics@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 &= 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/= ywe-dbEMw2fKIXvUV7gTVyZmJENCN20PSAbB-pZYGe-0Skd9OKGFxAOfOT17UUHcFOkw1j0BeNL= -G5aEMe3HQlnh1pNuxpxGL4Z09oUkdTo%3D%40protonmail.com.
--b1=_VTL6y3lCZzhqnXEUEhO8o1VIDUM6dMjriu7Js59is--