From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 14 Jun 2025 14:40:52 -0700 Received: from mail-oi1-f188.google.com ([209.85.167.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uQYcN-0003g6-SK for bitcoindev@gnusha.org; Sat, 14 Jun 2025 14:40:52 -0700 Received: by mail-oi1-f188.google.com with SMTP id 5614622812f47-40a5368899esf2737449b6e.2 for ; Sat, 14 Jun 2025 14:40:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749937246; cv=pass; d=google.com; s=arc-20240605; b=ci7OTPRzBakrd52nTbEfPHkkLAE1fRoJKUa9NPljyTpOe6fxFhzw5jeOawvYELstD0 1EnZKK9Y+lariHtjk0Vld0VR4wInp3Kz+Ql7jjEDsAsS/XBRFKqXj3Xh+hkhzlVnXH88 +d1V6H7Pb0aQyWb7YBHGSIZEQq9pTd0AkbLISl+70/pUvCCIMxAFyFIEYt6x0EsWCwVv 0oOTEaciHkOH38kQueNHyfROuTx7/52BfYfn4ojhPm/izgGdw6NMFld165Myy0LNSOu5 k9gwRSPaaspk8tY7fnNbc99wE4I0rU8b9JLmD3yaHihk5+7P1hC2QHfj3MRLV5w/J2wl OFIA== 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=e2sr0wUOuFWUqqDUjjRrLQ0SBpxa496dKKB1P9086Bg=; fh=jlom35f31mjh45TCWE04NO8GHv5VAveN8zKLzX7a1Yg=; b=Smr+Y1EDOLjjitQhCB9oR/VxSyFpcB70jTF3FSLf9mANGSVjOi3V965RorF2+4OWNK VdiGbv6VfHbxRmioqqpmB13BrI1e+Rc0SJ7Y7j1cyo8yMgq29kPmfNkiqSkUMl3Exwc8 QlVcjURAZwFL9ltsQo/9EAB0FfYwh8SmML6smoFVl0EVuVSH1LreVqBcNbyqCUIAHzdh NaVaqd5LA5aeyLRA3wuu/YQ/HKT7FobeV8gU1JzDdzqIYknoF3vB3XIEg3dm6GyfVVis UgRewFrw790atHziOjdI/filfRZ7yLxMM+FX5j6XLvl/mTnlCG66j6AfOSj/7D8COrKY Lyxw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="m/9SoXD7"; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::1031 as permitted sender) smtp.mailfrom=gmaxwell@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=1749937246; x=1750542046; 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=e2sr0wUOuFWUqqDUjjRrLQ0SBpxa496dKKB1P9086Bg=; b=TcrnQOq/gFDNqTCOmS+erUsDkc7SLpFuDaP0E5ZPQNmXB/UnB/wOboz/xs7NMppK3l G0obFPmipyz6ln1MyCa4hshCDphg1bITi73SPMnNMUm65jCQhWM57ThX/EY/WLI4ELFw SY4JmtM8VHLze9O/YauVrksencOA2rU/xKJw3WJhy8BaPp5io+FR3XNQ6ZB4Zk+R+ztB 9jXGCS6c0+bv66yHyTbG+nV+CxSvMucgak4/efkkqcLJ7MAUXQfyPEZY2TTQlfrlzdWj UuqgtK9IU35Tz2YQUwGGCs6/Sspy14L42ji5P4m80RgrD+s/7zgJeHm+BNjRljggVIzM 8Hmw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749937246; x=1750542046; 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=e2sr0wUOuFWUqqDUjjRrLQ0SBpxa496dKKB1P9086Bg=; b=JPX3m4PKQXRHwkrI2mHuUAB9m3XdrLT8apLQ+LoqQ/Y3tFP+gv6Tqi0EQTjreVhHPi eJCPcdxTzldDkgFj4u8ax7ISD8vhr8aY90wA20T5PCIp7nGDSfQaYTq+raTneo4r65D5 rsiFbTOnxk0A1kPw/k0kJPkZC4sq/9u3ZV3lVONhWIAss+dXlD2Q9C++hE2HVk6vfTym lcHyNEcv+F08aIsQD0zkkoyjCEEotBTwq9GggjCqrDhZUOvqWQ00xyTGItkTK8nU/46t xPJYojcohEi+KMPkAkTorq1tQ63AWQVWwvgZZuJPisPmi37UX0PLUHHXHa6PGKRE2b3i A6Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749937246; x=1750542046; 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=e2sr0wUOuFWUqqDUjjRrLQ0SBpxa496dKKB1P9086Bg=; b=VPkonU+FsrSU2ESgSSDYxpHTuGUlnih01LfXFBzH/7EJCgHMtqHe4G/r+uSLT6k3ez eXU8uaIAi6Hs5SvOrWkI+wF5eUZ/EjWrzxxFCRYarqXBGh98FnbMg74Q7HMPY+auAcFC onsoy5qSke5A7ey9PgBctmNLdbMiSiwoM6l8glgLpoR/7FkITaXvT3B2dFuJ8dx06aqz ib0OnsN4zkAxQNEzqlFhGZkelxbtXfASxhUCt5+tZQ5FIEaYSO8REcoWELfnWqbnr2XV LHZ9nyxhwS3Ul/EerqFlthCriz2jGqlm5fyfReIPaD/UqSGVjBfEE0k2hxLKphm5uOc6 Nj6A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUZbVPV6+IGb0FG5qc4BS0sKLu3waCAqnmf4Fjv6ptSuuYNL4Gi0fMNlIkc+5HwIwDq8kAb60+5X+eD@gnusha.org X-Gm-Message-State: AOJu0YzWlsNUHDYFmba4PESw8oFrN+TGUczflwjeSyOjMULGEUJ2DkZb YrJ9qghn7xKo9Xmbw3E5oQ3Y0xXNq9wOLCbCSUZVg9izUCykV3UmCBTh X-Google-Smtp-Source: AGHT+IETFWiHF4bBzgAHIYrskInyzomIDK5oknRQHUYJaCG1RpqusPZkji1kVc94CgNOMFmPOJnEZg== X-Received: by 2002:a05:6808:1a26:b0:409:f8e:7296 with SMTP id 5614622812f47-40a7be6d0e2mr2712227b6e.0.1749937246172; Sat, 14 Jun 2025 14:40:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdkCNyhTHXxObg4Mi/7b/LB2/P6cFY82W1ntGpczgYI/g== Received: by 2002:a05:6820:7712:b0:606:867a:26f1 with SMTP id 006d021491bc7-610fd385a77ls1369317eaf.1.-pod-prod-07-us; Sat, 14 Jun 2025 14:40:42 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWWFWTXE45ffsMLXOoAESldnBjFj5L60zRMAwUN+KJ0+xcQ0lFm3JyiE/xKeQC22x031IpxTi6Uwswg@googlegroups.com X-Received: by 2002:a05:6808:211a:b0:406:d4d2:ac06 with SMTP id 5614622812f47-40a7c109cd0mr2804217b6e.9.1749937242811; Sat, 14 Jun 2025 14:40:42 -0700 (PDT) Received: by 2002:a05:6808:6091:b0:3f9:f009:458e with SMTP id 5614622812f47-40a7193ecc8msb6e; Sat, 14 Jun 2025 14:31:17 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXUW14j5Ke+SO5002hgs5TYizomom9wIMZi81cXOmQatOrjozd5v6F0+9TZf/epH+8OaooeQKo8OuPE@googlegroups.com X-Received: by 2002:a05:6820:1b81:b0:60e:d4e0:7be8 with SMTP id 006d021491bc7-61110f4f14emr1994070eaf.2.1749936676620; Sat, 14 Jun 2025 14:31:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749936676; cv=none; d=google.com; s=arc-20240605; b=I33HV4plEEYZOXqnvDBJnppYrlB8lZkh7dDb64sO6mFx8L7uUKhhwuVfc0wQrRX0z+ HUWkgPITKis2PFEyxN0zimsKbNXRcsyouK6xX4BjE0pvlsVkPBbjeOVMHnrwpxTrRLAS pnaNPVwZVfQ4o+J1YoZmFR1QY2znkSDoF/ki/NLMW1z/McXWwve+eerkpzBCPeCMgSfD 5W6Wt5vqpDu1QuROXKIZn04pGMZPTSy3mW0azgn/kk9sVlN8FR3b+P3zxu73biCqUDY2 QwGeht3kjea/gS3u4KlYdQ1zyQAUugHPKlYMJT/LhcfJ+0UZK1mqxx++/f6bMwvV8iR6 acMg== 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=syXKM5QNGXgWDgnhcJHYShMnUyAYjDTLK45Fv4SQzkk=; fh=XatPwxylssez2ZbZPwLtGq4LMaThnOyej+Mlvnv8ifg=; b=WGDhAu4G6YpM7kUw3ZWzhQUVO9nJwsi+jByYwZAUOgYQJtkmhN7PU5TileXGjVlXjN ieNCxkTm5yUWIsyaUq/if+5+n9XXVCZ4OgPlXpqnHccn6nbjO9xJBl0CXhhtKX9aNUav rm1YYmVeKNarnxn8in0p/QEy2Z72GkaxHzwYvAxadfygwFBfxUTQkHcVvG/d/jAe5Rca xJUX2ytrQPT1iZXyHiTSQ3z0oZfuX5dquAdFLXCOZM6S47R47OpT07V8XTmObJ7XQVer gsRItsCUG0dpoJ+RJC7edTE5y5QNFlrKARfAZADxjCYGFtecsaLjcFPg3fuHWLK1x0eL zi6Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="m/9SoXD7"; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::1031 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com. [2607:f8b0:4864:20::1031]) by gmr-mx.google.com with ESMTPS id 006d021491bc7-61108dfd2b5si192482eaf.2.2025.06.14.14.31.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Jun 2025 14:31:16 -0700 (PDT) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::1031 as permitted sender) client-ip=2607:f8b0:4864:20::1031; Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-313910f392dso3017241a91.2 for ; Sat, 14 Jun 2025 14:31:16 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWrEVxiUmsJPquG9NuAkfAZhmrlKdZV4IZGNzldpJ5ps+co1BU7xJEKwmUmHKBwYEXCAHXhxwJ8hxRU@googlegroups.com X-Gm-Gg: ASbGncu+KJsqjzBYyZ3L2gYRxd09XGfwGsoXLMQ8Nby3rF1W5wATlmQI4LR7grylhdr DK94xWMJfnA+InjpIfVOJwoOZLvxBZQOrFZzqa9hmNvnj6mjFgD55DhssECK4oTGkVrRKz9IqEK dGtslVjNN6jRAEQYdy25vJYqcZ5ac/amrkFP2reBEfoyE= X-Received: by 2002:a17:90b:3e43:b0:312:1d2d:18e1 with SMTP id 98e67ed59e1d1-313f1d52d85mr5535576a91.22.1749936676039; Sat, 14 Jun 2025 14:31:16 -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: Greg Maxwell Date: Sat, 14 Jun 2025 21:31:03 +0000 X-Gm-Features: AX0GCFtcNC7YOSEKWga4nvYX6nx_YS3wl1hXadDLkmWP733rdwR1xbyTfGM1htA Message-ID: Subject: Re: [bitcoindev] CTV + CSFS: a letter To: Jameson Lopp Cc: Antoine Poinsot , Matt Corallo , Andrew Poelstra , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000f4725406378ee1ac" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="m/9SoXD7"; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::1031 as permitted sender) smtp.mailfrom=gmaxwell@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 (/) --000000000000f4725406378ee1ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 technical= ly > possible and what is practical, which is why I believe you can't find any > such software in existence. Using presigned transactions means you have t= o > regularly update your vault scheme whenever your UTXOs change. This becom= es > incredibly problematic if we're talking about a multisignature setup with > geographically distributed keys. And ephemeral keys relies upon user bein= g > 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 or 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 and 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 case > where key material is compromised. Vaults specifically allow for a user t= o > 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 approach does not allow you to stage an output address and then either abort or allow it to continue. (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/= CAAS2fgSmmDmEhi3y39MgQj%2BpKCbksMoVmV_SgQmqMOqfWY_QLg%40mail.gmail.com. --000000000000f4725406378ee1ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 14, 2025 at 8:17=E2=80=AFPM J= ameson Lopp <jameson.lopp@gmai= l.com> wrote:
=
Sure. As I mentioned in my article years ago, one c= an technically implement covenant functionality today via presigned transac= tions and ephemeral key material. But there is a vast gap between what is t= echnically possible and what is practical,=C2=A0which is why I believe you = can't find any such software in existence. Using presigned=C2=A0transac= tions means you have to regularly update your vault scheme whenever your UT= XOs change. This becomes incredibly problematic if we're talking about = a multisignature setup with geographically distributed keys. And ephemeral = keys relies upon user being able to securely delete key material, which com= es 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 multisigners, which has no= ne of the normal challenges for multisigning=C2=A0since they don't need= to retain information or 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 signatu= re in a taproot annex in the transaction paying the coins to the 'vault= ' script and then immediately all the participants have the required da= ta to deterministically=C2=A0construct the intermediate transaction.
<= div>
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=C2=A0a transac= tion to sweep funds to an emergency address is only particularly useful for= the situation in which key material becomes inaccessible. It doesn't r= eally help you in the case where key material is compromised. Vaults specif= ically allow for a user to recover from a situation in which a signing thre= shold of keys have been compromised.
But that is the only kind of vault you can construct from CTV i= sn't it?=C2=A0 One where the stationary output can go to one of multipl= e preconstructed outputs, typically one 'immediately' and the other= after a delay that starts when a particular transaction is released.=C2=A0= AFAICT, the CTV approach does not allow you to stage an output address and= then either abort or allow it to continue.

(thoug= h 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 i= ts 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/CAAS2fgSmmDmEhi3y39MgQj%2BpKCbksMoVmV_SgQmqMOqfWY_QLg%40ma= il.gmail.com.
--000000000000f4725406378ee1ac--