From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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: <46349b6c-ccec-4378-8721-aecec22752e7@mattcorallo.com> <8d158e3d-b3cc-44b6-b71b-ab2e733c047c@mattcorallo.com> In-Reply-To: From: Jameson Lopp Date: Sun, 15 Jun 2025 10:40:38 -0400 X-Gm-Features: AX0GCFu_VOBswT5k-I1CL0yBjq7Dn6EqB1_bgT6obPwg_5dQaNXXGv3jCuuNsVg Message-ID: Subject: Re: [bitcoindev] CTV + CSFS: a letter To: Greg Maxwell Cc: Antoine Poinsot , Matt Corallo , Andrew Poelstra , Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 w= rote: > On Sat, Jun 14, 2025 at 8:17=E2=80=AFPM Jameson Lopp > 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


On Sat, Jun 14,= 2025 at 5:31=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> wrote:
On Sat, Jun 14, 20= 25 at 8:17=E2=80=AFPM Jameson Lopp <jameson.lopp@gmail.com> wrote:
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'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= 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.

What'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't need to retain information or check anything (in fact, it = could even be blinded).

<= br>
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 i= s highly unlikely to be compromised. I'm not aware of any of the hardwa= re manufacturers offering functionality for generating and signing with eph= emeral keys.
=C2=A0
From= a durability perspective you also have the same issue of maintaining a scr= ipt, 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 tra= nsaction paying the coins to the 'vault' script and then immediatel= y all the participants have the required data to deterministically=C2=A0con= struct the intermediate transaction.

The result is= essentially identical properties to a 'vault' constructed with CTV= and needs no consensus change.

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

But that is the only= kind of vault you can construct from CTV isn't it?=C2=A0 One where the= stationary output can go to one of multiple preconstructed outputs, typica= lly one 'immediately' 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.

I was referri= ng to presigned=C2=A0transactions for which the original signing keys still= exist, so we're probably talking past each other a bit.=C2=A0

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


=C2=A0

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