path: root/c8/fd808690151fa3ff5b58b24ead4bc15dd6cdec

Delivery-date: Sat, 14 Jun 2025 16:53:30 -0700
Received: from mail-oa1-f61.google.com ([209.85.160.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD4YRG7X5UDRB34WXDBAMGQENDYI7CI@googlegroups.com>)
	id 1uQagj-0001Hn-NX
	for bitcoindev@gnusha.org; Sat, 14 Jun 2025 16:53:30 -0700
Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-2e42bf99e78sf2929621fac.2
        for <bitcoindev@gnusha.org>; Sat, 14 Jun 2025 16:53:29 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1749945203; cv=pass;
        d=google.com; s=arc-20240605;
        b=NDqhILz6K2WCgK+oHYrrumXkK+qY9pyRjQrSgHST2A5BH14O2jX2sI0lRN/gZzM9Tf
         BIV24F7tUB0MIBFVtEI8kzZqLC7KnS1rdROyoYncZaHi1nXMaqh32YOg7+Kw7BsJ+T0P
         7/9dWnQ7ufPY2snuhSLLDITemXrR8gkXSHe3zHhEmi9AXqdAerTK0KO4HY7aU1q06Eof
         uVZGwicVODcmw0Mhjk/I4ksUBBu2L6zGZ7jM9H1o66D0CeJOJ8umR48pl0NcIqAb0t1g
         7zGWp9eVtSwoIfhIR6EFM2zXTpwcWStwPf3V0VYz1ITMIqH99OEeSwydNS1q0OYq9mjw
         tbiQ==
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=2H7ssuRDdu3NM0jvRQW/xWfbDU+8zlbHVKwz25u1tak=;
        fh=ofFQmKQs0XWuIJXde2vZPtAj7HdF4nZD0ndVTGlAz8k=;
        b=dbsSP2Zxk8osi1ZsZDXZBWP/+G91mDF4dg6jR5u3S3SyHu1VhlA2rqIAKQBIC3vBbZ
         s8l22gyx54QD9F1UJUldXyAb5aSe0Rz3XM4UVTsBpIgL/B45iJclRuH0eUASgi/moSOR
         iQCrBeo9uM1AsFY1N3LTEcm0fZ3twbfd1gcCoHbCrjGPu8zfx182+KCo1BMzapbBkU3o
         zlHYZhpdtKCR+oc8gTrCfFdfRg7bAPLIuH7iDdel2qioQMb6F1nh0sNVd9I6wLCGSyvD
         nEYOxDHTXEBm/hvw9QONheMdbaIyQtOStVISyfwYFK9LMJoXxolHJ+yZVIF/z60ffp4G
         tLBQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b="ij/8xkbM";
       spf=pass (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::112f as permitted sender) smtp.mailfrom=sanket1729@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=1749945203; x=1750550003; 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=2H7ssuRDdu3NM0jvRQW/xWfbDU+8zlbHVKwz25u1tak=;
        b=cJ1AYz23+8lNwhKcnJBeQFFH2wTg33vZsPHbfJLZUkq/FPtp8YoGmvCyMsJfbuYL21
         zSPLbpCs/ehZlaAtkarYZr4tXL+5eMHoRfJUU21hTA2vgwAFd0vrnVk7NuGdT9EUzmx2
         k7b5Pk/KygL+VSu5/rY27TckO4R7fFTlS3fAhtNU9hpBTTk74x5+5gYIlwEjVj0WNcYl
         liGtnDKVMbFfG+WbLhsplxtxH6bsOgrVOiUuqiUtiVbBHdthJDMWdB/yxMichRqlFItO
         QSjKu+qbK3hx31ei2jl6powGyj2fF11JdHJ0zhzrRsEepEWtMuWtwNNZPON6dZqL9GBR
         osDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749945203; x=1750550003; 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=2H7ssuRDdu3NM0jvRQW/xWfbDU+8zlbHVKwz25u1tak=;
        b=M+QzHIZqPXdMqgwUdy4BrG7KlXyhuYruLIimaNef9gCWqJwWAAqIVF4hZati+KNpSC
         7zPvydGSqckKBt3lHsw6RAH/XRsk+JSXfI2mNvgom3GmyyPuVUHr8XLzl2EnieF44WXe
         vA6QSYnr/c7haDpQs6VkGNRv0bb9XSkVOqVA/4oSLMKy5csDhkQob2V/yr7eRerRmJZL
         HqRrPlCQeE4dJt+YNTABen2x71q1SdTECiN6vqQCxXskYXZFlNc6Odc5NbmXld+4NRNe
         mHnM8Og23DI/pOIuVTTsnEaivgGT9o4QUfzFhq+au8cBE1ki1uVEPHMrVaDRpZCexC4D
         86Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749945203; x=1750550003;
        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-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=2H7ssuRDdu3NM0jvRQW/xWfbDU+8zlbHVKwz25u1tak=;
        b=Mboc+rFM7glkhTG2m5U7HIHodIwv3xbVLdUisrScupIP4HhzLpzzglg7+VopLMSe1w
         MjQTkd0xLYhWH5i/MkoSpOZ0Kxk4ryfXxXvHf+JTQ3KN4dLYEm7OWT/D7QgvoM3Ulo14
         h7GVVBCSPFnfXaTKpB9cLzRTkb5vZ8xVbcFGCpQQ0DA3+WoeEqyDJNsdcVHcvE7qXnH1
         pkU+l86EAOmUaCr2zOvQVN70u+Sgc3rbkAtND/4QUN6AngcJLfxLsI9wHS8C30D5bSqH
         0jK8zfC2DhV/MLBcImjssBPLxFv5LK6qP2+iIfqNphBYpwtBR/qr3kw5Q0b6/peM/2dy
         OElg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUBF1nVsrLbrWJiHwlscOjrkURqKcl90pFQ1SdeWn71NEoRS5K84FP3oJT7GOWKJ1V4QsZaJLY7vH/B@gnusha.org
X-Gm-Message-State: AOJu0YzeozM8rXZx5FsPecoQbuCYt2FqUx5o5hg4yh4uuBPAI7/l4jPe
	wyWZuJ/uGNaJh5qe1a9EwG/x5FkKauWxOYWBhoK6JkaKxBWFvSW9Ccvb
X-Google-Smtp-Source: AGHT+IFDc1s6Mmu2+h/+MJfYzGWkWkzLP159xoi+SKzlxDzLWdyfln6I3Hxcowmd9+eBym0zMCIzrw==
X-Received: by 2002:a05:6870:9a97:b0:2e8:f84b:84dd with SMTP id 586e51a60fabf-2eaf0825befmr2949377fac.5.1749945203413;
        Sat, 14 Jun 2025 16:53:23 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcCedJ+bBHNdz2s8JLgyvbMz+vmNJ53ObHdfA+brJotRA==
Received: by 2002:a05:6870:2424:b0:29f:bc7e:8f4e with SMTP id
 586e51a60fabf-2eab6f71582ls2827484fac.1.-pod-prod-05-us; Sat, 14 Jun 2025
 16:53:19 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVAwMHACkIyd3IMT5RNxbvwGgDCbI3Jq+nwIIX8CK2u6024ZnG5+PkC2znCyEDcKVdEywtyW9/GCw3x@googlegroups.com
X-Received: by 2002:a05:6808:690b:b0:401:cae9:4dc3 with SMTP id 5614622812f47-40a7c13a8b6mr2995443b6e.8.1749945199032;
        Sat, 14 Jun 2025 16:53:19 -0700 (PDT)
Received: by 2002:a54:4108:0:b0:3f6:a384:eb6f with SMTP id 5614622812f47-40a7187c42amsb6e;
        Sat, 14 Jun 2025 16:50:27 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCXjuOQFvnyDWpVXYmcJrsw2StO7zuTAuHvmIsBUnAF/pKLKLvgMjQ5EVCvTOjPLSpfPe9l30BkBnTfh@googlegroups.com
X-Received: by 2002:a17:902:e788:b0:235:2375:7e94 with SMTP id d9443c01a7336-2366b3c5b99mr70534295ad.24.1749945026431;
        Sat, 14 Jun 2025 16:50:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1749945026; cv=none;
        d=google.com; s=arc-20240605;
        b=D/K7BiR2xJyJxwka8QLJq0/NoixArrRbbU3YUDCzcV2U/4HRfnQSMF4eBl5C6RS0et
         TQhMHLhVCcv/d8pc+Bk4CMv5OyG3t4YvjOWqWI878duXMWqscbJ7zAG0EjyiUmMvz9dv
         RF8IAzkoba537AF0m9gOeZBXq3R5guN9HLpWukBskM1lk/1GutieUv5lYfTus8NuwBcI
         5APQfjMlwHA5kgpd9eIZbsAwjEIrjSYito/PYkPyivC6r+24NvX0MzkYULGIEYBtTNp9
         hRQB4HGkfFz2McZ8+dnrGO6H92EMQn6cQc0/YpP64FkWF7AMYfWr1t0C3UzvJOJoHHkR
         ei+g==
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=AZR3fI3Dn5eNxFJtvbzoLHfueMSc6kQEQY0DG/dBBDc=;
        fh=DhQ7dIDDz7U1zzgNCtlPxYMQlMoY5O+KO6LVoMYT6H4=;
        b=Z8o8nvgQh5iEoetTuwOvKKo1dGhluXWYRMIIiJcW8aj3rFHIUQXzP155mwUIMAzvpn
         jjD3K6z+L6sQ9/Iyo9RyQ0wlmrl3FuMUSjUItj5AQFQyDWWFLEx5fNfhFDAlg/7B/8Gu
         Y0E/FppqAajj0dVw+wIybRWUjg0D8jLMelr4I5YDr0kVccDmJ1mDj3HE8ylhGupYpOIQ
         MBluIhtLzAy8c8/CP0yYhgygYeDFsWqO2kFdp+vN9uQmrtk6SjcBwSJD3xrAcw6EpO22
         WsTTcba5AjMhawJaA9ArKz8L5gosX6Ew5toKR2Oe7S8R5dntbt1T0CCFA+gemm7E2h5o
         MW5A==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b="ij/8xkbM";
       spf=pass (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::112f as permitted sender) smtp.mailfrom=sanket1729@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com. [2607:f8b0:4864:20::112f])
        by gmr-mx.google.com with ESMTPS id d9443c01a7336-2365de40d74si1771775ad.8.2025.06.14.16.50.26
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 14 Jun 2025 16:50:26 -0700 (PDT)
Received-SPF: pass (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::112f as permitted sender) client-ip=2607:f8b0:4864:20::112f;
Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-70e447507a0so24310457b3.0
        for <bitcoindev@googlegroups.com>; Sat, 14 Jun 2025 16:50:26 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCVM9KuXQlaPH4c7WCIQJgA8oESBRTw9+o40a38j7lnAlkmKoyji3M57rTDDqCTiqB9jEKKpc12k2byF@googlegroups.com
X-Gm-Gg: ASbGncsitWv0T7RkiB5PgfWXzecMUlBjLP2el1ND459DPUsyWynxK9zISLvBwg2B/Ps
	GOrGg9QD+oJHnZmxwA1+4mnv8tKNTgDvm5A9CtfKFEXaUlfdFkJV+Bh5DNl7aG+Zjftb8bJP2vn
	S0oZXVAYvNywlV8QBVmrCqHLAX4Sy+wwaG/TYtE7daMFA=
X-Received: by 2002:a05:690c:39a:b0:70d:f673:140b with SMTP id
 00721157ae682-7117538e5b8mr61874357b3.14.1749945025338; Sat, 14 Jun 2025
 16:50:25 -0700 (PDT)
MIME-Version: 1.0
References: <aEdoIvOgNNtT6L4s@mail.wpsoftware.net> <CAPfvXfL=7bQvhN5ZOJoS-hQ8TmUku=mNhxNop=ZhcyH+kqs9jw@mail.gmail.com>
 <46349b6c-ccec-4378-8721-aecec22752e7@mattcorallo.com> <de023ffa-6f8b-44bc-8e4d-6012e2ba3ccen@googlegroups.com>
 <8d158e3d-b3cc-44b6-b71b-ab2e733c047c@mattcorallo.com> <CAPfvXfLc5-=UVpcvYrC=VP7rLRroFviLTjPQfeqMQesjziL=CQ@mail.gmail.com>
 <aEsvtpiLWoDsfZrN@mail.wpsoftware.net> <f8b37a59-0897-40df-a08e-7812c806a716@mattcorallo.com>
 <CADL_X_fxwKLdst9tYQqabUsJgu47xhCbwpmyq97ZB-SLWQC9Xw@mail.gmail.com>
 <psUO5AHTglJ3KiGM5tTd0sqrFDUexydKzfkOpjOHcWM97OdluX_hIplsXxl_9vzS1pPOqMek3rVBhlzWiPyuvFvz7VmG9FNXapkMG97a7xc=@protonmail.com>
 <CADL_X_faQhCGS78y0Nggm_h=x_cEtshhbrZDDhQ=FEgbDXkc-Q@mail.gmail.com>
 <CAAS2fgSo=pdRhj=MkRDObXm5GtKpP3R5T4yck_pwBpn3_72f5Q@mail.gmail.com>
 <CADL_X_dTK0AtaWQGLzcNBug1=4x7CYn8ypvWAtHVzyGht47wuw@mail.gmail.com> <CAAS2fgSmmDmEhi3y39MgQj+pKCbksMoVmV_SgQmqMOqfWY_QLg@mail.gmail.com>
In-Reply-To: <CAAS2fgSmmDmEhi3y39MgQj+pKCbksMoVmV_SgQmqMOqfWY_QLg@mail.gmail.com>
From: Sanket Kanjalkar <sanket1729@gmail.com>
Date: Sat, 14 Jun 2025 16:50:13 -0700
X-Gm-Features: AX0GCFsXAxOx9-UFWI75YFGv7IKSg9vQ6EZcM7y-h48MCyiRICTWkJ1yENY8cEc
Message-ID: <CAExE9c8oWiy6GUaSMVf2Nxa+9a60e2Mw8fg_s8GT4TmfiPMKMQ@mail.gmail.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: Jameson Lopp <jameson.lopp@gmail.com>, Antoine Poinsot <darosior@protonmail.com>, 
	Matt Corallo <lf-lists@mattcorallo.com>, Andrew Poelstra <apoelstra@wpsoftware.net>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000009ca69c063790d326"
X-Original-Sender: sanket1729@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b="ij/8xkbM";       spf=pass
 (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::112f
 as permitted sender) smtp.mailfrom=sanket1729@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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--0000000000009ca69c063790d326
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 14, 2025 at 2:40=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> w=
rote:

> On Sat, Jun 14, 2025 at 8:17=E2=80=AFPM Jameson Lopp <jameson.lopp@gmail.=
com>
> wrote:
>
>> Sure. As I mentioned in my article years ago, one can technically
>> implement covenant functionality today via presigned transactions and
>> ephemeral key material. But there is a vast gap between what is technica=
lly
>> possible and what is practical, which is why I believe you can't find an=
y
>> such software in existence. Using presigned transactions means you have =
to
>> regularly update your vault scheme whenever your UTXOs change. This beco=
mes
>> incredibly problematic if we're talking about a multisignature setup wit=
h
>> geographically distributed keys. And ephemeral keys relies upon user bei=
ng
>> able to securely delete key material, which comes with its own host of
>> problems.
>>
>
> What's the problem for securely deleting?  The operation is atomic-- e.g.
> software can be written that performs it as a single step and never even
> hands the users the private key.  If you need to attest to a third party
> the ephemeral key can have 1-N multisigners, which has none of the normal
> challenges for multisigning since they don't need to retain information o=
r
> check anything (in fact, it could even be blinded).
>

> From a durability perspective you also have the same issue of maintaining
> a script, if you're avoiding that by always constructing it
> programmatically and backing up the scheme, you can more or less do that
> with the presigned approach: just stick the ephemeral signature in a
> taproot annex in the transaction paying the coins to the 'vault' script a=
nd
> then immediately all the participants have the required data to
> deterministically construct the intermediate transaction.
>
> The result is essentially identical properties to a 'vault' constructed
> with CTV and needs no consensus change.
>
> As I see it, a setup where you presign a transaction to sweep funds to an
>> emergency address is only particularly useful for the situation in which
>> key material becomes inaccessible. It doesn't really help you in the cas=
e
>> where key material is compromised. Vaults specifically allow for a user =
to
>> recover from a situation in which a signing threshold of keys have been
>> compromised.
>>
>
> But that is the only kind of vault you can construct from CTV isn't it?
> One where the stationary output can go to one of multiple preconstructed
> outputs, typically one 'immediately' and the other after a delay that
> starts when a particular transaction is released.  AFAICT, the CTV approa=
ch
> does not allow you to stage an output address and then either abort or
> allow it to continue.
>
Do you mean arbitrary output address that is unknown at commitment time?
Otherwise, I think the current CTV vault does allow abort/allowing from
"stage area" to "hot area" or abort to "rescue area". While general purpose
recursive vaults will allow funds back into same "cold area", I think it is
possible to also move funds back into same back under the same cold keys
with a bounded recursion CTV provides.


> (though I remain dubious as to the utility of that improvement, since if
> you can secure the rescue/abort key you could use the process for the
> primary.)
>
Primary key is used often for regular withdrawals from the vault. The
rescue/abort key will only be used in case there is something wrong. If
there is something that you don't intent you use at all, you can go 10
extra steps to secure it. Maybe store in secure guarded physical locations,
or require offchain security authorization protocols to secure them. You
might not do these for regular primary keys if you intend to use them often=
.

 And even if you secure rescue key as the primary key, there is still value
because the attacker has to get both of them. We can see that in practice,
people use multisig instead of single-sig even though both keys are
probably secured to the same degree of security.


Finally, on the usefulness of vaults; based on my own observation of all
the hacks (bitcoin and wider crypto), in most cases it is not the key that
is stolen but rather the authorization process or UI/UX hacks or something
else up the signing stack is compromised. Having reactive security to
"undo" feels valuable in this scenario.

>
>
>
>
> --
> 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/CAAS2fgSmmDmEhi3y39MgQj%2BpK=
CbksMoVmV_SgQmqMOqfWY_QLg%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSmmDmEhi3y39MgQj%2Bp=
KCbksMoVmV_SgQmqMOqfWY_QLg%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter>
> .
>


--=20
Sanket1729

--=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/=
CAExE9c8oWiy6GUaSMVf2Nxa%2B9a60e2Mw8fg_s8GT4TmfiPMKMQ%40mail.gmail.com.

--0000000000009ca69c063790d326
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 14,=
 2025 at 2:40=E2=80=AFPM Greg Maxwell &lt;<a href=3D"mailto:gmaxwell@gmail.=
com">gmaxwell@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">On Sat, Jun 14, 20=
25 at 8:17=E2=80=AFPM Jameson Lopp &lt;<a href=3D"mailto:jameson.lopp@gmail=
.com" target=3D"_blank">jameson.lopp@gmail.com</a>&gt; wrote:</div><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_quote"><div>Sure. As I mentioned in my artic=
le years ago, one can technically implement covenant functionality today vi=
a presigned transactions and ephemeral key material. But there is a vast ga=
p between what is technically possible and what is practical,=C2=A0which is=
 why I believe you can&#39;t find any such software in existence. Using pre=
signed=C2=A0transactions means you have to regularly update your vault sche=
me whenever your UTXOs change. This becomes incredibly problematic if we&#3=
9;re talking about a multisignature setup with geographically distributed k=
eys. And ephemeral keys relies upon user being able to securely delete key =
material, which comes with its own host of problems.</div></div></div></blo=
ckquote><div><br></div><div>What&#39;s the problem for securely deleting?=
=C2=A0 The operation is atomic-- e.g. software can be written that performs=
 it as a single step and never even hands the users the private key.=C2=A0 =
If you need to attest to a third party the ephemeral key can have 1-N multi=
signers, which has none of the normal challenges for multisigning=C2=A0sinc=
e they don&#39;t need to retain information or check anything (in fact, it =
could even be blinded).=C2=A0</div></div></div></blockquote><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><div><br></div><div>From a durability perspective you also have the sam=
e issue of maintaining a script, if you&#39;re avoiding that by always cons=
tructing it programmatically and backing up the scheme, you can more or les=
s do that with the presigned approach: just stick the ephemeral signature i=
n a taproot annex in the transaction paying the coins to the &#39;vault&#39=
; script and then immediately all the participants have the required data t=
o deterministically=C2=A0construct the intermediate transaction.</div><div>=
<br></div><div>The result is essentially identical properties to a &#39;vau=
lt&#39; constructed with CTV and needs no consensus change.</div><br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_quote"><div>As I see it, a setup where you presign=C2=A0a transaction=
 to sweep funds to an emergency address is only particularly useful for the=
 situation in which key material becomes inaccessible. It doesn&#39;t reall=
y help you in the case where key material is compromised. Vaults specifical=
ly allow for a user to recover from a situation in which a signing threshol=
d of keys have been compromised.</div></div></div></blockquote><div><br></d=
iv><div>But that is the only kind of vault you can construct from CTV isn&#=
39;t it?=C2=A0 One where the stationary output can go to one of multiple pr=
econstructed outputs, typically one &#39;immediately&#39; and the other aft=
er a delay that starts when a particular transaction is released.=C2=A0 AFA=
ICT, the CTV approach does not allow you to stage an output address and the=
n either abort or allow it to continue.</div></div></div></blockquote><div>=
Do you mean arbitrary output address that is unknown at commitment time? Ot=
herwise, I think the current CTV vault does allow abort/allowing from &quot=
;stage area&quot; to &quot;hot area&quot; or abort to &quot;rescue area&quo=
t;. While general purpose recursive vaults will allow funds back into same =
&quot;cold area&quot;, I think it is possible to also move funds back into =
same back under the same cold keys with a bounded recursion CTV provides.<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div><br></div><div>(though I remain dubious=
 as to the utility of that improvement, since if you can secure the rescue/=
abort key you could use the process for the primary.)</div></div></div></bl=
ockquote><div>Primary key is used often for regular withdrawals from the va=
ult. The rescue/abort key will only be used in case there is something wron=
g. If there is something that you don&#39;t intent you use at all, you can =
go 10 extra steps to secure it. Maybe store in secure guarded physical loca=
tions, or require offchain security authorization protocols to secure them.=
 You might not do these for regular primary keys if you intend to use them =
often.<br><br>=C2=A0And even if you secure rescue key as the primary key, t=
here is still value because the attacker has to get both of them. We can se=
e that in practice, people use multisig instead of single-sig even though b=
oth keys are probably secured to the same degree of security.=C2=A0 =C2=A0<=
br><br><br>Finally, on the usefulness of vaults; based on my own observatio=
n of all the hacks (bitcoin and wider crypto), in most cases it is not the =
key that is stolen but rather the authorization process or UI/UX hacks or s=
omething else up the signing stack is compromised. Having reactive security=
 to &quot;undo&quot; feels valuable in this scenario.=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_quote"><div><br></div><div><br></div><div>=C2=A0</div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAS2fgSmmDmEhi3y39MgQj%2BpKCbksMoVmV_SgQmqMOqfWY_QLg%40mail.gma=
il.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https:=
//groups.google.com/d/msgid/bitcoindev/CAAS2fgSmmDmEhi3y39MgQj%2BpKCbksMoVm=
V_SgQmqMOqfWY_QLg%40mail.gmail.com</a>.<br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr">Sanket1729<br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAExE9c8oWiy6GUaSMVf2Nxa%2B9a60e2Mw8fg_s8GT4TmfiPMKMQ%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAExE9c8oWiy6GUaSMVf2Nxa%2B9a60e2Mw8fg_s8GT4TmfiPMKMQ%40ma=
il.gmail.com</a>.<br />

--0000000000009ca69c063790d326--