path: root/3c/2dda7b728b7c207ad71772655cd3b87314f315

Delivery-date: Sun, 15 Jun 2025 09:11:06 -0700
Received: from mail-oo1-f55.google.com ([209.85.161.55])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDFIP6H73EBBBEHBXPBAMGQESWB5WAQ@googlegroups.com>)
	id 1uQpwn-0005NB-L1
	for bitcoindev@gnusha.org; Sun, 15 Jun 2025 09:11:06 -0700
Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-610bf6f2c8bsf4045991eaf.3
        for <bitcoindev@gnusha.org>; Sun, 15 Jun 2025 09:11:05 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1750003860; cv=pass;
        d=google.com; s=arc-20240605;
        b=NeDEq4NX8MblsvDTnsRnB8rAlZNuU4MXtcP1UdW3MWt0zTXuS7J/anh8ndVcEKP2Du
         cAtqkcQnu6XDXV7fT7lmEbZilGX/M+5XPm2ezFuT6xAN2WGf6EeAD8buXUYw0EFkFSEM
         0V36+42jyRYPpqpibdFFBGGTaaK2w0LmLPwYnCbK70NbvSuS3IRh/slApFC8BxDrKcXa
         G/ydkvyB+GFPiJzwvUZi1STCZtgFO1xCdMqgGVmg19Z8fc3SNISSxxAKuMZEstEBxO0F
         65jwrhKfPZBowuto05iLRmYQdkw58QruO7ALocqUJmE4sKf1ilx1rLy6TjSD/YYYfHV5
         wixw==
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=czeFUc5Pq+hfJWKFSI/pO/A52QQ+Hy9tYwZM6yZdVAY=;
        fh=tm54mZQi+Qim3cL0kBKemkAlPnfsXCAv4mRi+HVtKr4=;
        b=R3ziqhlgCvr5nIsKT8O3oONo3QDw4w2FnpiICpuhfrpVz91ivTXR1DDd6FeKzWmkuT
         vFEg7isY4qImljTmRb+Vl2wd8fSUzxrh33pmXQxfBD29q9oDlShBARFxAvxPFz/mEXAl
         9mDmMHWA7ofPwSQsyDy04NfOF6OvrOWXLgTbgwNZ1gFaDjRJnqnqz99kd8hoxpu/qcPg
         PCZbBDDICpfNY4R8LgQwGAMeKa2g5/Z5e6XUqMssbggsMo7qfKWzjw2lstziIKZnFC8k
         XxwWsePh+9vt2WsWjmZRgHlcvnPu+9JP8tiOLbOeZ592Sk0LaLQ8wgf6NDTKIpVHtKWs
         fqpQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=Zx2HUzSL;
       spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::236 as permitted sender) smtp.mailfrom=jameson.lopp@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=1750003860; x=1750608660; 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=czeFUc5Pq+hfJWKFSI/pO/A52QQ+Hy9tYwZM6yZdVAY=;
        b=XgWUI1VQBkFA01lt4jh4/MpdmnNob4XGdS3sxjgoFyXd/llekCrwQBchjMecnldAPA
         JHrQ3rVYhr/AYZDg3fqW9UBe6Hgu13Cm5PnudpBQnAbDMxlgzFVCUOtBB3w1V30i6v/R
         NRZzHmI+wwRN4uDcGCPuppMjhOP8BRqod+mdf70qPgjQscx+jsknAKSUZqQmkplP6kEL
         Ob4zh89SLdIffnEWoUpebwUsZYweBVaS0zMNUnw6ms1q45hPpaLTOL9LaZ45JmZrhP4G
         ncVHZlRXYIugiAEHPgkXEX8SdSCJE5RdaxZQLH5auPjQeSUfuM3JcbDSqZgIe3ZwqnVm
         ZiRw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750003860; x=1750608660; 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=czeFUc5Pq+hfJWKFSI/pO/A52QQ+Hy9tYwZM6yZdVAY=;
        b=Y9RyOxFdVgGfb7OGK+zslLrosJ0pGb3h/vKTiyWRuiLGlGBJr54YKzoGdLizGI6M0D
         5I/IqsW4lzHsWAygJNbyiWkuojIBCFxuVnw8BlhKZI6mSlE8rnGfnu+s9MOx8vArl1ec
         gIuQOZUXjo56qBMK+YNLVuhUEZvB2jyqykLap+y+MjB+iayi6tsUsAXjl7RkVbJTQ8Om
         Uu/PJeJ8Hx42baYVdF1DjMZgkvHHL/C5Mu7o8M5s76Gx6z1SePSxAEEFt7SaYrJ379F4
         xV0Kf8h5FW1+7GQGrmvRxN3gRBV4Opwi5p1Z3SzRXxUE82VDv6DQisokvoDP8TpSywOu
         esPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750003860; x=1750608660;
        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=czeFUc5Pq+hfJWKFSI/pO/A52QQ+Hy9tYwZM6yZdVAY=;
        b=XRYn1HcUg94bVUaFdY588W6SnDUf2GhM0arM3MKwuytazHrKoTMLvFGLz305dOQ8e3
         JeiQXCRETS82hMoQmdJqtS8bGQfCHkSa7KUarZaOUpDIEZ6zCHrtBurTerJfv+co3HmO
         VbzuXSDf6G+bdO9m+QuYn4jbaQUpaTb54Rz04+aIgn8+UABydgZeg9lNa7q5+dhtRSxk
         om9qerAjC2L6wAsq+wrVL0WgV7YFFWOEbAYAUkNpgQKb7I35s4jf4eAE7lGfom03Yg1R
         D1oOQc6HMOztefPxwvzKlR9a+OXG7+FWcgjoP0+L18rMVMnvjP9XYHHhR6J/apt8Hzj3
         Z08A==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUOoA3/PiQFOTUd2E8qXVGVawI1WagTvQCfjghesNzbWbRAMW0BHURU8Gr6XpSsEPYNQEw+ZmaorqNI@gnusha.org
X-Gm-Message-State: AOJu0Yw9jGGJnUF5ylwzFP/SJAocdCcKbayLbruOVuXv1jPaYOOGTDbC
	2Yq4NNPmCwqJWvPaLvCyhehRed4hHkDpSA2zbeH/vGwZDffVVAj9RpLd
X-Google-Smtp-Source: AGHT+IFnE1ivNwrE0xlo4pCXnoWKcgAjMxGS3WqUN9nvJpi/WURRYik43xeY8sEIiRhh7i32iqwOUw==
X-Received: by 2002:a05:6820:168d:b0:60f:847:8354 with SMTP id 006d021491bc7-61110f312abmr4121579eaf.7.1750003859807;
        Sun, 15 Jun 2025 09:10:59 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZe26DY8IMT0tEfxYBLhvxyH/76OzZo0y+44SzruGVlGQQ==
Received: by 2002:a05:6820:4002:b0:608:3554:1a64 with SMTP id
 006d021491bc7-610fd250587ls1225161eaf.0.-pod-prod-01-us; Sun, 15 Jun 2025
 09:10:56 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCU7VYNDd/ZeeT0hfwjbOTy/bTGe5yDnZERzwYBdcCB7YJuPmLAvudKF3Op63DIJ4J61XRCf6DHh90Yn@googlegroups.com
X-Received: by 2002:a05:6808:80a8:b0:406:697f:a62f with SMTP id 5614622812f47-40a7c1cf90cmr3787226b6e.10.1750003856295;
        Sun, 15 Jun 2025 09:10:56 -0700 (PDT)
Received: by 2002:a7b:c386:0:b0:450:ce23:93de with SMTP id 5b1f17b1804b1-453345232cams5e9;
        Sun, 15 Jun 2025 07:40:54 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVgeeJsKR/RzhH10ADTue0vTbDt5dJiy7DGRwQ1XDVyp7sCn8KlXGYYsmEeD4VBACub0ASwYSZnofUY@googlegroups.com
X-Received: by 2002:a05:6000:2306:b0:3a4:d79a:35a6 with SMTP id ffacd0b85a97d-3a572396fbamr6079939f8f.14.1749998452145;
        Sun, 15 Jun 2025 07:40:52 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1749998452; cv=none;
        d=google.com; s=arc-20240605;
        b=OKA584Ff7bV6f8+0mZOxGM4Uj6QBsaCPPEJZ5NfS5TsIedwjXouiXS4OLbO4iAA9RH
         dGewa3cHQsqylEtNfBuzW31S5LDU1FN0Hc9TL3tyJwg1MV+348TrX9FVMUSKHIHHnVzd
         e5i/pDL+5jAmiEyd3Rq7NpS8PbDr36UfIqEYTHh+805XN7koS7DNwDHi+Ia7deqYjw6d
         TEpRNR4zSA+tERkkZVJ1f/WNlK1zGVuPlzCieOKY4P98HmW3+JXe9FJEzepe3+3I8Z+X
         NILSeXwiQ/YUHcv8B4L5+t0/j5A3ot0e4MF+Xe6U34Lp9xKUL/nUrM1Xmfcjsz+A2MH3
         GoMw==
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=vkaBEkEvW6juJnGfMCDWnQI4KxL2VcsrvzdOtBDlbT0=;
        fh=zXPFHM68tm3GRQuyEVpfvUT4Az4HNpElNj3Rn5ON1Eo=;
        b=bhbRyH3kUA4va30snTh2Zf9Tol3KNRY1Ua8DMqfHeBN0tZ0ainpIPzQkAdnFbY1KQS
         N1nFRqeIxrJr8TLFeA5wy87PyjE3klCe6WuGcPYQNMeS8/4uxthYiuLET9WcrU3ijgus
         3jqger31qMXG6Ve5b0bdhhx43NUFJnnbnn7ZzGZQLW4HF2/7juTHyVw6EG8MaaAJcwAI
         PCFBHNkqtb5rnahWv6bSHmWjAKm6TDmpFQBk9qeZKEai9YYCCf30U34zGo+xwVrg8WtU
         7ZbgkxUVDgVhf/j8KVmoFke0EfDV0fPaadO930hji4It3LypmzMdUygnBdoIPrMOSdit
         jqfQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=Zx2HUzSL;
       spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::236 as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com. [2a00:1450:4864:20::236])
        by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-3a568af0623si129567f8f.7.2025.06.15.07.40.52
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 15 Jun 2025 07:40:52 -0700 (PDT)
Received-SPF: pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::236 as permitted sender) client-ip=2a00:1450:4864:20::236;
Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-32b2d60f8caso29754791fa.1
        for <bitcoindev@googlegroups.com>; Sun, 15 Jun 2025 07:40:52 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCVPMdo96YWU5s5YtxnqZcNJCBYRszCi6MY8J+6pR3CP1nuogCwS/gKot3maAM0CdrbMG2trIrXX3E/+@googlegroups.com
X-Gm-Gg: ASbGncs641jgKtx/KZV2XKw9wZlA0H0kuSJTm/OiFgQTA2NpeKAogoWeYnqcwT92iDX
	SsTBXK3agww1Y2xTZ5xRJYZrtRo0GVdv3CtvwBS/hQP7ZY8Cw1M08+g1GK/7qunROytYRLW8z4y
	hXOwHfrGtCU/7RUj9DGVnAWyDoYcflhqR3YTj73Au7n6I=
X-Received: by 2002:a05:6512:2395:b0:545:d70:1d0e with SMTP id
 2adb3069b0e04-553b6e714aemr1380587e87.3.1749998451167; Sun, 15 Jun 2025
 07:40:51 -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: Jameson Lopp <jameson.lopp@gmail.com>
Date: Sun, 15 Jun 2025 10:40:38 -0400
X-Gm-Features: AX0GCFu_VOBswT5k-I1CL0yBjq7Dn6EqB1_bgT6obPwg_5dQaNXXGv3jCuuNsVg
Message-ID: <CADL_X_cc2UdbFkFjL7ma9q=3mdgWs-s7+31UH62bdacmOLXK3A@mail.gmail.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: 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="0000000000000a17d506379d446d"
X-Original-Sender: jameson.lopp@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=Zx2HUzSL;       spf=pass
 (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::236
 as permitted sender) smtp.mailfrom=jameson.lopp@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 (/)

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

On Sat, Jun 14, 2025 at 5:31=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).
>
>
It's the same problem as securely generating and storing keys. In order for
presigned transaction vaults to actually be trustworthy then ephemeral key
usage needs to occur on a hardened offline device that is highly unlikely
to be compromised. I'm not aware of any of the hardware manufacturers
offering functionality for generating and signing with ephemeral keys.


> 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.
>

I was referring to presigned transactions for which the original signing
keys still exist, so we're probably talking past each other a bit.

>
> (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. ... and because of the lack of implementation of these tools in
> systems where its already easy to do so...)
>
>
>
>

--=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/=
CADL_X_cc2UdbFkFjL7ma9q%3D3mdgWs-s7%2B31UH62bdacmOLXK3A%40mail.gmail.com.

--0000000000000a17d506379d446d
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 5:31=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).</div><div><br></div></div></div></blockquote><div><=
br></div><div>It&#39;s the same problem as securely generating and storing =
keys. In order for presigned transaction vaults to actually be trustworthy =
then ephemeral key usage needs to occur on a hardened offline device that i=
s highly unlikely to be compromised. I&#39;m not aware of any of the hardwa=
re manufacturers offering functionality for generating and signing with eph=
emeral keys.</div><div>=C2=A0</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 class=3D"gmail_quote"><div></div><div>From=
 a durability perspective you also have the same issue of maintaining a scr=
ipt, if you&#39;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 tra=
nsaction paying the coins to the &#39;vault&#39; script and then immediatel=
y all the participants have the required data to deterministically=C2=A0con=
struct the intermediate transaction.</div><div><br></div><div>The result is=
 essentially identical properties to a &#39;vault&#39; constructed with CTV=
 and needs no consensus change.</div><br><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>As I see i=
t, a setup where you presign=C2=A0a transaction to sweep funds to an emerge=
ncy address is only particularly useful for the situation in which key mate=
rial becomes inaccessible. It doesn&#39;t really help you in the case where=
 key material is compromised. Vaults specifically allow for a user to recov=
er from a situation in which a signing threshold of keys have been compromi=
sed.</div></div></div></blockquote><div><br></div><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 preconstructed outputs, typica=
lly one &#39;immediately&#39; and the other after a delay that starts when =
a particular transaction is released.=C2=A0 AFAICT, the CTV approach does n=
ot allow you to stage an output address and then either abort or allow it t=
o continue.</div></div></div></blockquote><div><br></div><div>I was referri=
ng to presigned=C2=A0transactions for which the original signing keys still=
 exist, so we&#39;re probably talking past each other a bit.=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div><br></div><div>(though I remain dubious as to the uti=
lity of that improvement, since if you can secure the rescue/abort key you =
could use the process for the primary. ... and because of the lack of imple=
mentation of these tools in systems where its already easy to do so...)</di=
v><div><br></div><div><br></div><div>=C2=A0</div></div></div>
</blockquote></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/CADL_X_cc2UdbFkFjL7ma9q%3D3mdgWs-s7%2B31UH62bdacmOLXK3A%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CADL_X_cc2UdbFkFjL7ma9q%3D3mdgWs-s7%2B31UH62bdacmOLXK3A%=
40mail.gmail.com</a>.<br />

--0000000000000a17d506379d446d--