From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 14 Jun 2025 18:36:16 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.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 1uQcIB-0004HO-IR for bitcoindev@gnusha.org; Sat, 14 Jun 2025 18:36:16 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-2ea7f2993d4sf2694899fac.0 for ; Sat, 14 Jun 2025 18:36:15 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749951370; cv=pass; d=google.com; s=arc-20240605; b=BU35CztPToCUzjj3Y4TGgK2aWMtl3tXAgzg1GAcn19a7f5FzlxcM9L61fangL3G/hK AorjOO024aEnBj2A//LP6jVngdnvSJj97ALOZLIfJLQGk8r9ADLffkO42qcxvO42OumZ dvYDdV5h1+etrNEPxMcNC8oblF5h4Sffsa+mh6mo+Z64+Ry1POQoHJAKu4Cq7c5EdEhn 8ZNbg5y5Whwm5hUv/VKNcw9SwGQT2UDX5Dzs8rmoIJhzUPaDF/vbXKZK+ZCTilgE06kc r/S6xDbCqOPnccrNrCH3f2quYQKXSjJplA12fM5kCIeAt3qEmf6nimlIGeTz0pmA20FH cNhA== 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=Ot4xQHWAzXMHZVBSJZ7kVFj7X+t5xqEbuIpkv+VLyRs=; fh=l/SAlqLlZKQfRrlYprXArjVfwc0oj9qdOSzzd6sxQmw=; b=PIz6NVO2IbtocJ7JGitycKgNMAByAkhURUO3XY3b25pxyCwziXalbJd88Bd86sfBLP J3uqyBYe5Goy0WA4yugWOmX95AXy08k8Hf3v8+ACc+yMmvOXqDr85svxJWI722xP+WUC 3lZuTfPKJ+447guwtZgDKeCcIq51iHvahuj/eEGKggVHYBXP2Xy+TUGggqwk4nwHSCG3 7N66P3WcH7cb0Eps+0AVEaWUCGGAX+iisilVaYmrpzd2Yvshg1a5nT61Bpd0qW3/eb1X Tz+AxDZh5+P0/RkvS+Jr7KSDrB5Yw0rCo5ZJBC9igdBSmB0Gt1NjrgMdyVeSzQ5M5pRZ EEQA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=em4lSZR+; spf=pass (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::1133 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=1749951370; x=1750556170; 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=Ot4xQHWAzXMHZVBSJZ7kVFj7X+t5xqEbuIpkv+VLyRs=; b=SmbsHxjAaVLv1CfrunZTiJ6L4Qamrs6tjCZZdF45A3M1AH8rxxcX72FTLb7IQ9zXiW M3RRytJvD2E2qoagcyEH4K1RJ9BCJpfIUSUHZ3WpTs91D6nBMBx2E8Uiu0+/SpwJS4Yx ldtQieuR3p0VCn/CY7jvEC/0RGIdmXxHLFj0YNy03iZPBKMODV1bMzfemcGcR2Hk0bm1 haXajZCkfohBgZxiLNLqVAjt3EaxYPTrssJN9pKY+2AKxHdduO9ebxJKPnDd65ii1vPb fqIxQkrXgOJ77dQZlxx9nu2FtI1vTbr4c/Oqe+Cq0e2Hdj815WDu+6LPcT1qqeId9XXI 7CDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749951370; x=1750556170; 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=Ot4xQHWAzXMHZVBSJZ7kVFj7X+t5xqEbuIpkv+VLyRs=; b=VqjGJzijvTDpJ53Jl1ZvdzSvwv3H2HqqmMNYvuTQmZB9xqy82VlwkwzCLbPDciQoyY rhz6ACY8AKnBgDwVBuX7qnxrxo1ZmiYMJZ+tUb5YM16rHkz0oiF754rIzoE4z51VGh0f 7W3J/XsCIQ2r7qo1Je334wJpeSBVf3MDIKbnBOSwLvjKiNexVNIkn9eS8BCv5ZjU3QWj xlxIM7y2pdwymEu3O61mRj2UoHf0o4agZ2TXa4jJqlgszZEx9ssVB9EN3OJ86WM39woH ZJ8H5YAf+IcxCNi8aCPLCuAXer5JuqnebUKcgOnZzkfZkK7lo/n5qFEqiuzHjPxqTq05 FCjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749951370; x=1750556170; 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=Ot4xQHWAzXMHZVBSJZ7kVFj7X+t5xqEbuIpkv+VLyRs=; b=hn+V/NfK7k79trxfr0QwuUNTbHZcux3T9xmNgTkjRzWO8nrpET6vrnVjTh0Fyz6mLl e+J8/VxPP+2ypOY3TtXOb+XGe0yBuZJWtR+3PRJgDMwUtTzyHH0SLXsa823eiEdjjFOp 9IDXiBmqqHZdA91txQIlSMki91uMo25Bh8k4DAGQa1yqZmL8eGQ/tMKeWVtwz4L3DKGj +rhQ+Ri8+S4oDUljd35beJHXPG2v3Ie/KXdDTzgEKmsIH6bcv5L+1nbZcYX5fvJ3ywE4 lWU2A/lqYVuXmu1emIAVE268QwvxXJLnndqbXxMQyKdU2cs384jHSuCO/nggl7d/+xEP spfA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXRThEpalSiLWqevR8qxqTWLbu6CGmCWbP3gPOcOMC2lH/6Jw4jKbDHQYi3OhdGRRtvjN5BpAHsbrEN@gnusha.org X-Gm-Message-State: AOJu0Yw2iC/q/zgYcPPm8rTeDOZPuVfPvqXe3jNyC/oR8Jz9Ji/m9AHR 0Uov2m26KuhykiB3gA5Yix/4y9yHz0C2p+8mze8GX+nihY1yNYvxG+bO X-Google-Smtp-Source: AGHT+IHfXzU1bGCTWCINhQIhdeuNkav9Z6cjdI8/XWnxcBK2RlbLQO23JEv7vq+PgsfFaD0oKZsMmQ== X-Received: by 2002:a05:6871:e808:b0:2bc:7e72:2110 with SMTP id 586e51a60fabf-2eaf08dc516mr2719606fac.13.1749951369637; Sat, 14 Jun 2025 18:36:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZc78bq/NEaQzU8ECPvzcq9XgiQrjJkEuwNCxlq22NhGfQ== Received: by 2002:a05:6870:1796:b0:2c2:2ed7:fb78 with SMTP id 586e51a60fabf-2eab6b4c3dals2008470fac.0.-pod-prod-01-us; Sat, 14 Jun 2025 18:36:05 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXxyFa0NWTRaGoNAdz1Hea6aJGuhzM4xUXMqya7ifaUojZ5TyRG6AykgC88OiXDD2N0uaCO3DSdapyp@googlegroups.com X-Received: by 2002:a05:6808:2f12:b0:404:ed0d:79e5 with SMTP id 5614622812f47-40a7c24d0f1mr3081597b6e.30.1749951365407; Sat, 14 Jun 2025 18:36:05 -0700 (PDT) Received: by 2002:a05:6808:5001:b0:403:484c:9068 with SMTP id 5614622812f47-40a71a04700msb6e; Sat, 14 Jun 2025 17:20:19 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWkWaQVXJSwLZBOsmTXAuL6/UssksvnNkvgraNXOjQ3R8GDt3kOLdnSzSt8TYhJnSymJe7x6Kz8NzbR@googlegroups.com X-Received: by 2002:a17:90b:268c:b0:30e:9349:2da2 with SMTP id 98e67ed59e1d1-313f1c7d3d6mr6474031a91.4.1749946818640; Sat, 14 Jun 2025 17:20:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749946818; cv=none; d=google.com; s=arc-20240605; b=VLSk37jSfzGxOyI1fOOTB8Z94jXccj2dkNYQBsq1IAF0OGy13oojo9k7NjUyLj65ok m8a0psaw2tbcDytVgX8BjFZ8HnIPLZIZ2pshvdJcBT4sG+fBUTBw8BNAwRXXs4teRkcI Etb2WWj5GSRvMeNVxRmSwKHZNAvpDZ6+Uesr5vlHFVrheEniVUryx5OoylVu7I+flG1W kbP8BzMh2KSQCMov0gGf3amHsHCt7ySLeJq8gkAXRGZIsGt3UprQ/S68fyX7QWbunuMP XPWJ2xlGGcDXU4p21kIOhTcE79y9fu+m8TWMK6AgMltFJiAWZe4DizmIFoPvTfgb3fw8 GNTw== 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=EaU+UVo+Ik6zUeZ6bBCYdzExHqJOn3Ng09EcddRqj8E=; fh=V+RiDpgdbnWxWJ0Yv2N51FUdY8GBa1fxhI3hyl25a5A=; b=grUFPcmPgLleQBtUHOSviblyQ3rkgdLoJO23eeV6SSodNxHDXvSkkLEHA7SxcR9pWh wXDtuxzxxZbr3EZ7tu0S6VaesrIIRdfVgkkqybViURm67PjKUKFeOdPhusMuYES+R7rc 83NBMlp4YBK01NLN5wtr9+VhnE2MaFWQCTvHUo6oow17gk//g2lhSoF9uApiR1OSVslD MkfytuPHvnGu1wnqVDNUCeoNUUgWOJgibwXk0QthBQ7940rLNO0vm8w3Tl9OtkV2RRRB eAGQMaRz7jHVUfrZfRejYMjALpT7brMHwP3RbPsbtxUdDnspzapbskzgEqRNkn+UBd9Y Gi/A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=em4lSZR+; spf=pass (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::1133 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-x1133.google.com (mail-yw1-x1133.google.com. [2607:f8b0:4864:20::1133]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-313a4746c96si677846a91.0.2025.06.14.17.20.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Jun 2025 17:20:18 -0700 (PDT) Received-SPF: pass (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::1133 as permitted sender) client-ip=2607:f8b0:4864:20::1133; Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-70e5e6ab7b8so27962127b3.1 for ; Sat, 14 Jun 2025 17:20:18 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUikU0I0s9jdwDs1KHk8mFXTqLzK9svILDsIwhOUuda2nk4FXpVnZHb41dM3dpXTWD58cyVg5FrcSG5@googlegroups.com X-Gm-Gg: ASbGncv6itEyF8tH1atktZRjKh3/OXVbydIKpaTIdkSJZ8M++t8IB/rX9+PyB0t4Imi PPek5q+vWlJV9eXEmf+J+QD1DW37NZkvYxvChaki/k3y+M3pwpKj2OAuIDjs+tKz7jsMraphlsK +Xsfvg21CepxHG04D1I32C1DwaeyRM7ikOS7idBcx2mnU= X-Received: by 2002:a05:690c:6886:b0:6fb:ae6b:a340 with SMTP id 00721157ae682-71175456e3bmr65346717b3.30.1749946818156; Sat, 14 Jun 2025 17:20:18 -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: Sanket Kanjalkar Date: Sat, 14 Jun 2025 17:20:06 -0700 X-Gm-Features: AX0GCFvNdxc-7Tn5oWshaiUYo3jYRu-4lYKHSsC7eZbDl_8FR3y00MsgVuGokw0 Message-ID: Subject: Re: [bitcoindev] CTV + CSFS: a letter To: Greg Maxwell Cc: Jameson Lopp , Antoine Poinsot , Matt Corallo , Andrew Poelstra , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000078dcac0637913ea3" 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=em4lSZR+; spf=pass (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::1133 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --00000000000078dcac0637913ea3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 14, 2025 at 5:01=E2=80=AFPM Greg Maxwell w= rote: > On Sat, Jun 14, 2025 at 11:50=E2=80=AFPM Sanket Kanjalkar > wrote: > >> 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 purp= ose >> 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. >> > > Moving funds back to the initial key that the attacker already has > demonstrated the ability to release from doesn't seem useful to me. -- > though that is a thing the presigned example I gave doesn't do. > > >> 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 th= at >> is stolen but rather the authorization process or UI/UX hacks or somethi= ng >> else up the signing stack is compromised. Having reactive security to >> "undo" feels valuable in this scenario. >> > > Is there an example of a hack that has been defeated by one? It would be > interesting to see the exact workflow. > I presume in this case any rational attacker will not attempt something like this until they know they can succeed. A weaker argument here might be that this setup by itself would discourage attackers to attempt to continue :). I can try to look up examples for defeated hacks, but they might be hard to find. > > If the scheme is just released into a 'hot area' and the hot area keys > have the power to send the coins anywhere, presumably the attacker will > attack the hot area keys and wait for funds to be moved there and > instantly sweep once they're there. If the hot area keys are presumed > secure, then they can be multisig on the release from 'cold'. > Any amount of money that you move in hot wallet can be stolen. The point here would be limit the theft exposure, for example, you never have more than X BTC in hot wallets. I agree that this might be awkward to do in practice with CTV vaults because you have to move the entire UTXO into "hot area" in order to send change back. Having a powerful vault primitive helps avoid this issue with change amounts. But in case of CTV, this can be somewhat mitigated with careful UTXO management. When moving larger amounts across wallets, you would move them in increments of X BTC one by one limiting exposure. --=20 Sanket Kanjalkar --=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/= CAExE9c8Gs0toXmv-T3QrBBz9oDPT77VyvByiTL5fE37GOSo2xw%40mail.gmail.com. --00000000000078dcac0637913ea3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jun 14,= 2025 at 5:01=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> wrote:
On Sat, Jun 14, 20= 25 at 11:50=E2=80=AFPM Sanket Kanjalkar <sanket1729@gmail.com> wrote:
<= div dir=3D"ltr">
Do you mean arbitrary outpu= t address that is unknown at commitment time? Otherwise, I think the curren= t CTV vault does allow abort/allowing from "stage area" to "= hot area" or abort to "rescue area". While general purpose r= ecursive vaults will allow funds back into same "cold area", I th= ink it is possible to also move funds back into same back under the same co= ld keys with a bounded recursion CTV provides.

Moving funds back to the initial key that the att= acker already has demonstrated the ability to release from doesn't seem= useful to me.=C2=A0 -- though that is a thing=C2=A0the presigned example I= gave doesn't do.


Final= ly, on the usefulness of vaults; based on my own observation of all the hac= ks (bitcoin and wider crypto), in most cases it is not the key that is stol= en but rather the authorization process or UI/UX hacks or something else up= the signing stack is compromised. Having reactive security to "undo&q= uot; feels valuable in this scenario.=C2=A0
<= div>
Is there an example of a hack that has been defeated by = one?=C2=A0 It would be interesting to see the exact workflow.
I presume in this case any rational attacker will not= attempt something like this until they know they can succeed. A weaker arg= ument here might be that this setup by itself would discourage attackers to= attempt to continue :). I can try to look up examples for defeated hacks, = but they might be hard to find.

=
If the scheme is just released into a 'hot area' and the hot a= rea keys have the power to send the coins anywhere, presumably the attacker= will attack the hot area keys and wait for funds to be moved there and ins= tantly=C2=A0sweep once they're there.=C2=A0 If the hot area keys are pr= esumed secure, then they can be multisig on the release from 'cold'= .
Any amount of money that you move in h= ot wallet can be stolen. The point here would be limit the theft exposure, = for example, you never have more than X BTC in hot wallets. I agree that th= is might be awkward to do in practice with CTV vaults because you have to m= ove the entire UTXO into "hot area" in order to send change back.= Having a powerful vault primitive helps avoid this issue with change amoun= ts. But in case of CTV, this can be somewhat mitigated with careful UTXO ma= nagement.

When moving larger amounts across wallets, you would move = them in increments of X BTC one by one limiting exposure.=C2=A0
=


--
Sanket Kanjalkar

--
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/ms= gid/bitcoindev/CAExE9c8Gs0toXmv-T3QrBBz9oDPT77VyvByiTL5fE37GOSo2xw%40mail.g= mail.com.
--00000000000078dcac0637913ea3--