From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 14 Jun 2025 13:43:26 -0700 Received: from mail-oo1-f64.google.com ([209.85.161.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 1uQXim-00061V-SJ for bitcoindev@gnusha.org; Sat, 14 Jun 2025 13:43:26 -0700 Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-607dceb1c53sf2397629eaf.0 for ; Sat, 14 Jun 2025 13:43:24 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749933799; cv=pass; d=google.com; s=arc-20240605; b=CxD547dsnZ0RDfaupvVUIFH0+mdIOFewjCNqHAjpj7cl2Jv5CNUWQOpaNofXo6C9o+ EPJie7yRpQc2hEI7p2Wnd0AjH4gtHiwsqj4IJ/D7czzwPUCzzfsU4XMP7DLhl53blKjp QGm5Huy6Nh0CmFH95erJ0dBvxd9UHtHQGiRjdRt/aITaUp4OWFSn4DytCXWy8bx9bAVX M8WETMfmgFx2N/sWJtsTfFQ5tFnu6KsxTibTilXMm8jrGB6WqRcpQGN4Oyew0zCxU/9C gGFc5G5OaMzzBtj2RWIBl2PuvRjT5vWJXdcCnqdEnO6fQM8AlR15Wozcn6fu5WDex5nx bLBA== 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=9sJUoyeAfpEMxLXNsiCH94mVdCzJSF3m/Pui3ieV0Rg=; fh=EAVSDhNsdHPLvVNehlhsc561RQGMeK1NRJvvcGio2ho=; b=Fw1b4KOEtVN/1Z8SYIreYCw9YZqsxlXOZyMVlaxwNLVxaoIsKc7QvAKIJTjzbhs8yZ wFgRp6pxwR6G4ZGthUW+do03gLI/DJJkIsEHYIXp7baH8tne1wMaAlsy+NXykS2jPEUH TL1R4xvD+ZJXcEk6FzxHl5KCe0shklOV3KK89ngwZFyXlpMiv/4gsWEhBrFa2DYmgJUs Yzja5k69MLC9XBvwBE7lC8XC0FVYAdVymESFIvcmfMKrBpYklsHN1R/kev2226fKuc0p OGxYTrL0yDZPlL2bxjBf+PS0JgoClP3uHAHcWBBAZJmqqBoR+gXcyxF0JkZYiVME/OoA BDNg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=eaI8kvxG; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12b 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=1749933799; x=1750538599; 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=9sJUoyeAfpEMxLXNsiCH94mVdCzJSF3m/Pui3ieV0Rg=; b=cT94fpfBbbrIjc7JCcOVVn1bue4Opc3cw1buYzn3bIQHxty4y9luG5jIVA2ToUewub xFBsWev5KqlISOSv5PgidAApmvn2iOq3rQF4ai+AQ1/XJ10TG5SUzS5Pbdqn2sEkFmIk 5M2e5+Ls8m3lsjbZU8/Wk5XEnnqu5/2xjNzRp7/NYxhURHoF9Ot9MfyK4Xomi+NmOoCq blTeNrwRvo0Ojyy8zo+INqOy3AovozuzhJ1l+NGyfCFvKIl+fpj5zIF3GjXU/K5ulsXn Pxfn6u+7SoQROB7g4FSbRCn82SbYyYaqgbmd1WpRXCILw/sVFTS1ws+kNxMkpUv9Z1f0 mALw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749933799; x=1750538599; 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=9sJUoyeAfpEMxLXNsiCH94mVdCzJSF3m/Pui3ieV0Rg=; b=ItHOt4VtA/WuLYf55678Uv9PymPIyaSe7SDHJnv9E1aOrERpD4rTpnNPEyCFzLpOgD jp46Dc2MR1k0NAtm9uXqxRCuGfoEI3bnoUnng3Geb3yUO0KJcl4r3i83ahqLgmaegElk ZYezMUHcHMuCTHCtGRPkFVoVSNc+sy89jXevpyoKk6IX4wvWujC0J/3PJP9J/HfyOhhR nW+T/VKUBaA+rytInH20YMQRK+0flQt+NxPbyA4c9ROLbCsj5qUP0+f1J9EZEzFW7yD6 esr6p6icBCYOhs5WfGWtAmxCeWrFVn0sP0CBiW5zUuq0tQXD3N548Tmm20SDrDRmVfR4 uebQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749933799; x=1750538599; 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=9sJUoyeAfpEMxLXNsiCH94mVdCzJSF3m/Pui3ieV0Rg=; b=ce2ODBfnlYFApDNO8NgOlwc06YGj9ZNyeyra5zG+KppdSl9xL1f1fkvqpIIPbfvrp5 1ZS4llcjg//W2twU7aaApOjTiANP+fhZvC+TWbraQ+Jo1Y7Db40O4/G8k6gUiA2Rgcdh wFhSV4wzUlSaI6qVGunq64IXmO9pvTWKU1hbWCkdzePGIU2Dl9nJL0MQ0nWCNDC9EI5D 2CIV3xgyAvI4aSORDWJwpPwfzIwpOGB9cclqk7vub44x1u5CMku3vBkP0KcjFY16l4qy i3YKmienqKyJGM2jd+LzKYOcE1e/m51tU8uU1/3kPdeGAqFTHknclnRIvUFQkky+zG36 96/Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCX2pUiJ0HUMLMbUeKaNqt7LSK/A9pVODoPOnXUDmoL3B/OuEIN3m/haOEhp73gz70yBMutqEmjZHZ62@gnusha.org X-Gm-Message-State: AOJu0YxJP67VD2/AM/LOTkGQqiJJSMW7FEr5UK8Aji5BCWkHJwPO55fo 1sbjsuFNa6KyynmprrV8ogNNHufONTqqFYV5PBzekB6N2iHQ8MsBvNJT X-Google-Smtp-Source: AGHT+IEi1/LfrmC9KyrdZRpK3KV/ilSHEHdojaMYOEYFWLr4SnuATlW3AsUSqM9ucRUVoioD1Yohlg== X-Received: by 2002:a05:6871:8611:b0:2d4:7cfa:6f3 with SMTP id 586e51a60fabf-2eaf0b0a4damr2197798fac.20.1749933798769; Sat, 14 Jun 2025 13:43:18 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfYjVBkIRhb9jn29ADWH4kzZ5aY4Dde7r7TupWVowqI1g== Received: by 2002:a05:6870:d698:b0:2e9:9a5a:7609 with SMTP id 586e51a60fabf-2eab6f4e79cls2227902fac.1.-pod-prod-01-us; Sat, 14 Jun 2025 13:43:15 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXuv6QhqXQp2PBs4WG6GhbOPq4bsDKiB/yv8kSNi4ZY3NLVw0/HPfqlr4ZSRrO1QB/VkbrpiXEorAYW@googlegroups.com X-Received: by 2002:a05:6808:4fd3:b0:403:50e7:83db with SMTP id 5614622812f47-40a7c23a69cmr2390676b6e.25.1749933795911; Sat, 14 Jun 2025 13:43:15 -0700 (PDT) Received: by 2002:a7b:c386:0:b0:450:ce23:93de with SMTP id 5b1f17b1804b1-453345232cams5e9; Sat, 14 Jun 2025 13:17:47 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUeNKDfKnssyh4n1eYGdb1IadpyI8NiXhl++3ksZH2t9zxxS+xhbSqc8Fi87DAiqjyrg9b0tKPDjxsT@googlegroups.com X-Received: by 2002:a05:600c:1d0d:b0:441:b00d:e9d1 with SMTP id 5b1f17b1804b1-4533ca4658amr42525395e9.2.1749932265784; Sat, 14 Jun 2025 13:17:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749932265; cv=none; d=google.com; s=arc-20240605; b=BPE54OeNZM4WPCjTlwwqLXRcmLaILimVxwjNjksIeW1A2GsBAJtzk3Mi9XIflpXL0r ZBkvq6/tNb5vvX/3r45tVV0N33WjIHGcJ4muw5UXKVohz7XlXLtLkdESPs6W3h3fqwrL iadaUvX8dtZiO6ecACMNQR5tFc8mVWIy4rwmONjHxhEZs9a6KFWlurUPEAm6fRgU6Co2 szFZHghvbtc7Rjnt9SLFFFawL51xnDGHCISfsNgRUW8hqtIzNTzNAEYUNjZlX8Djn69D zQHTJNuj4zH3mW1rgf74g2dK/icvHYPx377I1I7HjsuYJtkNf6Rh4RX6Orh5FD/314gN Z/ww== 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=L5aLi5UkBEICzhbiXPdVBgFx6U4arqH5ppce4Pj+Rtw=; fh=NWfUzwsXTrlDIySOWwDOu6WcimjoGHXmtHJv1Rqk/Ig=; b=KUoJAti9lJ5m3GS4qMmRUpqb62yC4OAzq04zemORJETAvHlGf0cHVCug7v+3IegUdr gOlkIg43SNM/pDQt3fDlwcop1Y9Zlc48qoHerITvEi38hRzR0xTM4ZUuqcJqk9tnmZ4/ Ub7nE8wR1u+bQ9cV8raFMIHVy1GRIs0Tl3GvOhe+dqPci4sxpn+11FChY3NaCOjLB7J8 MLczHyiZeQ5uiHkergLy9M73aUOaiXTk2QnGm+DSr2bxm7ckFHxu1I6/6I9ww8W3Hsii WUcZH6yyn9hmz/Wv4Z5qNFyYKeQRSdqqmDsmgtHFkLvAZWUIzo9+LShLImZqqSt8wtam 62aw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=eaI8kvxG; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12b 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-lf1-x12b.google.com (mail-lf1-x12b.google.com. [2a00:1450:4864:20::12b]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4532e17319bsi1446745e9.1.2025.06.14.13.17.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Jun 2025 13:17:45 -0700 (PDT) Received-SPF: pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12b as permitted sender) client-ip=2a00:1450:4864:20::12b; Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-553644b8f56so3310476e87.1 for ; Sat, 14 Jun 2025 13:17:45 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCV/gtuAbqurAitGJgDPa0H+t1MyyVoChk4THCvsUcPCjeNGpZlv5njP2mMFJy44eE0+j9VckHLQL34h@googlegroups.com X-Gm-Gg: ASbGncs65Rrjl6mX/GrBv3v6oYaaci2EL2iZjpQkuP8Kk9+Jd2YVPKCKcP5jpsUD//R MQAZhlXpi50PCp3BsyzwfSuhEKLmK4PUJg0vgwMa8TP/QjbB/CujHNXzuEF+PukaPmbUaEnvHh7 heeK4wM9KdEwAP15EdhhS3Q3ncDhzTKwQDFt0VQdpMeEA= X-Received: by 2002:a05:6512:6cd:b0:553:af02:78db with SMTP id 2adb3069b0e04-553b6e7804fmr897622e87.5.1749932264694; Sat, 14 Jun 2025 13:17:44 -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: Sat, 14 Jun 2025 16:17:32 -0400 X-Gm-Features: AX0GCFstv4xqJ6znbXSxOQLijapc1F-_6XJZZ5-Wv6WqmEEoxegKf1jOZryQpDI Message-ID: Subject: Re: [bitcoindev] CTV + CSFS: a letter To: gmaxwell Cc: Antoine Poinsot , Matt Corallo , Andrew Poelstra , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000004a94106378ddb09" 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=eaI8kvxG; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12b 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 (/) --00000000000004a94106378ddb09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 14, 2025 at 12:06=E2=80=AFPM gmaxwell wrot= e: > I'm struggling to figure out what kind of useful 'vault' could be > constructed from CTV that isn't equivalent to "presign a transaction that > sweeps your funds to an emergency address". Can someone clue me in? > 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 technically 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 to regularly update your vault scheme whenever your UTXOs 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 comes with its own host of problems. James went into further detail as to why presigned transaction based vaults are simply unworkable: https://delvingbitcoin.org/t/the-unsuitability-of-presigned-transactions-fo= r-vaults/113 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 to recover from a situation in which a signing threshold of keys have been compromised. > It might be helpful to point to examples of where similar techniques are > used in other blockchains that already facilitate their construction. Th= is > isn't bitcoin-twitter, it's permissible to observe some other system bei= ng > used in useful ways... > > > > > > On Sat, Jun 14, 2025 at 2:08=E2=80=AFPM Jameson Lopp > wrote: > >> Casa (and many other companies focused on custody products) would love t= o >> see vaulting functionality. I don't think any of us are too hung up on t= he >> details of the particular implementation - we would rather have a "good" >> tool than not have any tool because consensus has not been achieved for = a >> "perfect" solution. >> >> What is the problem that makes vaults desirable? It's frankly because >> there's no such thing as perfect security. Even if one designs an >> architecture that is nearly perfectly secure against external threats, t= he >> issue of internal threats (such as oneself, via social engineering) will >> remain. The ability to require high value funds to sit in a "quarantine = / >> cooldown" address for some period of time before they can be sent to an >> arbitrary address enables additional security measures a la watchtowers = to >> be designed. Being your own bank is still an incredibly scary propositio= n >> because it's quite difficult to design custody solutions that tolerate >> failures without leading to catastrophic loss. The more tools that custo= dy >> application engineers have available to them, the more guardrails we can >> build into wallet software, and thus hopefully the more comfortable we c= an >> make the general public with the idea of taking on the responsibility of >> self custody. >> >> To be clear, I'm not aware of CSFS improving the vaulting functionality >> already available via CTV. As far as I can tell, CSFS is one of the leas= t >> controversial opcodes proposed in a long time and just seems to be an >> all-around win with no risks / trade-offs, so why not bundle it in? >> >> I'm not sure how to parse Antoine's claim that CTV+CSFS doesn't enable >> vaults given that there has already been a CTV vault client proof of >> concept for 3 years: https://github.com/jamesob/simple-ctv-vault >> >> On Fri, Jun 13, 2025 at 9:07=E2=80=AFAM Antoine Poinsot >> wrote: >> >>> Jameson, >>> >>> Thanks for sharing. Although i grew more skeptical of the reactive >>> security model of vaults as i implemented them in practice for real use= rs, >>> i can appreciate people's mileage may vary. >>> >>> That said, consensus-enforced vaults require a mechanism to forward any >>> amount received on a script A to a pre-committed script B. CTV+CSFS doe= s >>> not enable this, and a primitive that actually does (like CCV) is more >>> controversial because of its potency. I see the CTV+CSFS bundle as >>> maximizing "bang for your buck" in terms of capabilities enabled compar= ed >>> to the accompanying risk. If we do want vaults, then we need to get pas= t >>> the MEVil concerns and much more interesting primitives are actually on= the >>> table. >>> >>> I also appreciate that CTV is nice to have for CCV vaults, but a >>> potential future use case that is not enabled by one proposal cannot be >>> used to motivate said proposal. >>> >>> Best, >>> Antoine Poinsot >>> On Friday, June 13th, 2025 at 7:15 AM, Jameson Lopp < >>> jameson.lopp@gmail.com> wrote: >>> >>> > Unlike a generic "We Want Things" sign-on letter, individual messages >>> indicating desire to utilize features is way more compelling. >>> >>> Then I submit my essay from 2 years ago ( >>> https://blog.casa.io/why-bitcoin-needs-covenants/) and will quote >>> myself: >>> >>> "There are clearly a LOT of use cases that could potentially be unlocke= d >>> with the right kind of covenant implementation. Personally, having spen= t 8 >>> years working on high security multi-signature wallets, I'm most intere= sted >>> in vaults. I believe the value they offer is quite straightforward and = is >>> applicable to every single self-custody bitcoin user, regardless of wha= t >>> type of wallet they are running." >>> >>> - Jameson >>> >>> On Thu, Jun 12, 2025 at 6:54=E2=80=AFPM Matt Corallo >>> wrote: >>> >>>> To be fair to James, in my (luckily rather brief) experience with >>>> Bitcoin-consensus-letter-writing, >>>> its nearly impossible to forge a statement that everyone agrees to tha= t >>>> is consistently interpreted. >>>> >>>> Matt >>>> >>>> On 6/12/25 3:51 PM, Andrew Poelstra wrote: >>>> > Le Thu, Jun 12, 2025 at 02:38:13PM -0400, James O'Beirne a =C3=A9cri= t : >>>> >> >>>> >> As the person who coordinated the letter, I can say that this is no= t >>>> an >>>> >> accurate characterization of the signers' intent. Everyone who sign= ed >>>> >> explicitly wants to see the imminent review, integration, and >>>> activation >>>> >> planning for CTV+CSFS specifically. The letter is intentionally >>>> concise to >>>> >> make sure there are no misunderstandings about that. >>>> >> >>>> >> I spoke to each person on the original list of signatories who >>>> either did >>>> >> (or didn't) sign and this was made very clear. Some people didn't >>>> sign as a >>>> >> result of what the letter says. >>>> >> >>>> > >>>> > The letter asks Core to "prioritize the review and integration" on a= n >>>> > accelerated timeline, and that this will "allow" for "activation >>>> planning". >>>> > >>>> > Early drafts of the letter did ask for actual integration and even >>>> > activation, but I did not sign any of those early drafts. It was not >>>> > until the language was weakened to be about priorities and planning >>>> (and >>>> > to be a "respectful ask" rather some sort of demand) that I signed o= n. >>>> > >>>> > >>>> > The letter is concise but unfortunately I think Matt is correct that >>>> it >>>> > offers a broad range of interpretations, even among the signers. >>>> > >>>> > >>>> >>>> -- >>>> 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/f8b37a59-0897-40df-a08e-7= 812c806a716%40mattcorallo.com >>>> . >>>> >>> -- >>> 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/CADL_X_fxwKLdst9tYQqabUsJg= u47xhCbwpmyq97ZB-SLWQC9Xw%40mail.gmail.com >>> . >>> >>> >>> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CADL_X_faQhCGS78y0Nggm_h%3D= x_cEtshhbrZDDhQ%3DFEgbDXkc-Q%40mail.gmail.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/= CADL_X_dTK0AtaWQGLzcNBug1%3D4x7CYn8ypvWAtHVzyGht47wuw%40mail.gmail.com. --00000000000004a94106378ddb09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jun 14,= 2025 at 12:06=E2=80=AFPM gmaxwell <gmaxwell@gmail.com> wrote:
I'm struggling to figure out = what kind of useful 'vault' could be constructed from CTV that isn&= #39;t equivalent=C2=A0to "presign a transaction that sweeps your funds= to an emergency address".=C2=A0 Can someone clue me in?

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 wh= at is technically possible and what is practical,=C2=A0which is why I belie= ve you can't find any such software in existence. Using presigned=C2=A0= transactions means you have to regularly update your vault scheme whenever = your UTXOs change. This becomes incredibly problematic if we're talking= about a multisignature setup with geographically distributed keys. And eph= emeral keys relies upon user being able to securely delete key material, wh= ich comes with its own host of problems.

James wen= t into further detail as to why presigned transaction based vaults are simp= ly unworkable:=C2=A0https://delvingbitcoin.org/t/t= he-unsuitability-of-presigned-transactions-for-vaults/113
As I see it, a setup where you presign=C2=A0a transaction to sw= eep funds to an emergency address is only particularly useful for the situa= tion in which key material becomes inaccessible. It doesn't really help= you in the case where key material is compromised. Vaults specifically all= ow for a user to recover from a situation in which a signing threshold of k= eys have been compromised.


It might be help= ful to point to examples of where similar techniques are used in other bloc= kchains that=C2=A0already=C2=A0facilitate their construction.=C2=A0 This is= n't bitcoin-twitter,=C2=A0 it's permissible=C2=A0to observe some ot= her system being used in useful ways...


=



On Sat, Jun 14, 2025 at 2:08=E2=80=AFPM James= on Lopp <jam= eson.lopp@gmail.com> wrote:
Casa (and many other companies focused = on custody products) would love to see vaulting functionality. I don't = think any of us are too hung up on the details of the particular implementa= tion - we would rather have a "good" tool than not have any tool = because consensus has not been achieved for a "perfect" solution.=

What is the problem that makes vaults desirable? It'= ;s frankly because there's no such thing as perfect security. Even if o= ne designs an architecture that is nearly perfectly secure against external= threats, the issue of internal threats (such as oneself, via social engine= ering) will remain. The ability to require high value funds to sit in a &qu= ot;quarantine / cooldown" address for some period of time before they = can be sent to an arbitrary address enables additional security measures a = la watchtowers to be designed. Being your own bank is still an incredibly s= cary proposition because it's quite difficult to design custody solutio= ns that tolerate failures without leading to catastrophic loss. The more to= ols that custody application engineers have available to them, the more gua= rdrails we can build into wallet software, and thus hopefully the more comf= ortable we can make the general public with the idea of taking on the respo= nsibility of self custody.

To be clear, I'm no= t aware of CSFS improving the vaulting functionality already available via = CTV. As far as I can tell, CSFS is one of the least controversial opcodes p= roposed in a long time and just seems to be an all-around win with no risks= / trade-offs, so why not bundle it in?

I'm no= t sure how to parse Antoine's claim that CTV+CSFS doesn't enable va= ults given that there has already been a CTV vault client proof of concept = for 3 years: https://github.com/jamesob/simple-ctv-vault

=
On Fri, Ju= n 13, 2025 at 9:07=E2=80=AFAM Antoine Poinsot <darosior@protonmail.com> wrote:<= br>
Jameson,

Thanks for sharing. Although i grew more= skeptical of the reactive security model of vaults as i implemented them i= n practice for real users, i can appreciate people's mileage may vary.<= /div>

<= div style=3D"font-family:Arial,sans-serif;font-size:14px">That said, consen= sus-enforced vaults require a mechanism to forward any amount received on a= script A to a pre-committed script B. CTV+CSFS does not enable this, and a= primitive that actually does (like CCV) is more controversial because of i= ts potency. I see the CTV+CSFS bundle as maximizing "bang for your buc= k" in terms of capabilities enabled compared to the accompanying risk.= If we do want vaults, then we need to get past the MEVil concerns and much= more interesting primitives are actually on the table.

I also appreciate that CTV is ni= ce to have for CCV vaults, but a potential future use case that is not enab= led by one proposal cannot be used to motivate said proposal.

Best,
Antoine Poinsot
On Friday, June 13th, 2025 at 7:15 AM, Jameson Lopp <jameson.lopp@gmail.com= > wrote:
> Unlike a generic "We Want Things&quo= t; sign-on letter, individual messages indicating desire to utilize feature= s is way more compelling.

Then I submit my essay from 2 = years ago (https://blog.casa.io/w= hy-bitcoin-needs-covenants/) and will quote myself:

"There are clearly a LOT of use cases that could potentially be = unlocked with the right kind of covenant implementation. Personally, having= spent 8 years working on high security multi-signature wallets, I'm mo= st interested in vaults. I believe the value they offer is quite straightfo= rward and is applicable to every single self-custody bitcoin user, regardle= ss of what type of wallet they are running."

= - Jameson

On Thu, Jun 12, 2025 at 6:54=E2=80=AFPM Matt Corallo <lf-lists@mattcorallo.com> wrote:
To be fair to James, in my (lu= ckily rather brief) experience with Bitcoin-consensus-letter-writing,
its nearly impossible to forge a statement that everyone agrees to that is = consistently interpreted.

Matt

On 6/12/25 3:51 PM, Andrew Poelstra wrote:
> Le Thu, Jun 12, 2025 at 02:38:13PM -0400, James O'Beirne a =C3=A9c= rit :
>>
>> As the person who coordinated the letter, I can say that this is n= ot an
>> accurate characterization of the signers' intent. Everyone who= signed
>> explicitly wants to see the imminent review, integration, and acti= vation
>> planning for CTV+CSFS specifically. The letter is intentionally co= ncise to
>> make sure there are no misunderstandings about that.
>>
>> I spoke to each person on the original list of signatories who eit= her did
>> (or didn't) sign and this was made very clear. Some people did= n't sign as a
>> result of what the letter says.
>>
>
> The letter asks Core to "prioritize the review and integration&qu= ot; on an
> accelerated timeline, and that this will "allow" for "a= ctivation planning".
>
> Early drafts of the letter did ask for actual integration and even
> activation, but I did not sign any of those early drafts. It was not > until the language was weakened to be about priorities and planning (a= nd
> to be a "respectful ask" rather some sort of demand) that I = signed on.
>
>
> The letter is concise but unfortunately I think Matt is correct that i= t
> offers a broad range of interpretations, even among the signers.
>
>

--
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 bitcoindev+unsubscribe@goo= glegroups.com.
To view this discussion visit https://groups.google.com/d= /msgid/bitcoindev/f8b37a59-0897-40df-a08e-7812c806a716%40mattcorallo.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 bitcoindev+unsubscribe@googl= egroups.com.
To view this discussion visit https://groups= .google.com/d/msgid/bitcoindev/CADL_X_fxwKLdst9tYQqabUsJgu47xhCbwpmyq97ZB-S= LWQC9Xw%40mail.gmail.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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit http= s://groups.google.com/d/msgid/bitcoindev/CADL_X_faQhCGS78y0Nggm_h%3Dx_cEtsh= hbrZDDhQ%3DFEgbDXkc-Q%40mail.gmail.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/CADL_X_dTK0AtaWQGLzcNBug1%3D4x7CYn8ypvWAtHVzyGht47wuw%40ma= il.gmail.com.
--00000000000004a94106378ddb09--