From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 24 Jun 2025 09:01:03 -0700 Received: from mail-oo1-f59.google.com ([209.85.161.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uU651-0008Kx-6O for bitcoindev@gnusha.org; Tue, 24 Jun 2025 09:01:03 -0700 Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-611051d18fesf429845eaf.1 for ; Tue, 24 Jun 2025 09:01:02 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1750780857; cv=pass; d=google.com; s=arc-20240605; b=EtV4unjZHlF3/Egv/jF6IyKe+5ithNVIrX/WpMzI5d3L+QKKjSIze+HGbJrFdgA+4a MdyRG1JVPZn+gyf/QvuPr7cPhf0ys4OldL6YG98scsOtbQreD/fS0FAsZGvbo7CvU29O M7Qq0A9Q10V2owkidVK9fGE3lZQuS0RY2lBK51XIZGElsxBFnThz5q/yjSReAGA2lUZD xwoWZv5/U9Z8xTNpkIF2zQkrL4j0XXRh31CQ0Y0owqbjmjHMQ4IpBFNY4U9F26p/c9E2 LgMFBkz9GNS5Am35k1jOXYxmEm9BOWK+40lpTf0Hx+ONuYzmhkL0f0tvEmDeEFaNs41X 241A== 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:in-reply-to:from:content-language :references:to:subject:mime-version:date:message-id:sender :dkim-signature; bh=ctRt0ppjtcUJcLDWL1d025NR3u0gSg+DT+lZMsJz/kk=; fh=CWpG9zqrHk7CyDomW9V2pwXyrnLGnE6u3Wd2CO+umho=; b=k3RhunP7+Zzw4vyBr1/WeIVbOkx/aaAF8q9DQINHoy/wOwkYvkdOnEFwvkd3tIpexN BisdmJk5seyJYBjlaSfvFdK5w8lIMZojKOs8vnEGz2gGKDv9dfJL+dX3vk2vq/CUZIns opPZhgPKqkk9fb4NfXdX07XOK4xssvjtSAravFqYNN5hv9Up9YdVOVnRDQwma6MGyiBg mRpbSgVrp3WETG63oCWGOK3u7NeHKHO5gl6XkkEDLwYGfsvuZ6pZdgaVMFS5ERBAlyvk 6ifEFw3BFszbGWU/0AmyCmWoCIFxTZqRsYqr1KVJAXGuU9wSziSNLutas+RS+lsoRDw+ uG7A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1750778463 header.b=asLfboNr; dkim=pass header.i=@clients.mail.as397444.net header.s=1750778466 header.b=C+20759k; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1750780857; x=1751385657; 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:in-reply-to:from:content-language:references:to :subject:mime-version:date:message-id:sender:from:to:cc:subject:date :message-id:reply-to; bh=ctRt0ppjtcUJcLDWL1d025NR3u0gSg+DT+lZMsJz/kk=; b=lP38kZP874Z0MxFjjX48FiME11VYcznH/aShMbjrS+QVoUCajrtXpeHT+9uIRAd7MC 8YkjQl0fn1bImk959TdpegfY+Y+b9VQQ7ekimlEpoCzOm6sl1C8yY9+eF9ln3gH2HLve kho/ZcjXcOeRpf+AIB243WfA6nFZfUo3U5+reT9Ieh6RxDM4QLTOXqzngU0zK06aYvJy WT80XaxTQjFGpPqtXllG3ZXAIqXlZo9U/up9+iuN06P5q1G3LJzc3dgDrXRMvKJAHdSd 3GhMllvUqQTf9NlZtfS3OrQv1bqPiZkjJd3aPWl3EgnsUG2WlR1nPb9wA8kB6tnfgcoe 7pjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750780857; x=1751385657; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:from:content-language:references:to :subject:mime-version:date:message-id:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=ctRt0ppjtcUJcLDWL1d025NR3u0gSg+DT+lZMsJz/kk=; b=NjlgXMZveA4ovCbLL3am07KD6IJfJ/qOubEu3jM1I1lbHGZ3DLm4Hlj1NcXdr9fpeC tLZkvzpS0llDruomMmGGBVp6Nz4l4ZDGNujMNJw2uWp3a0cMPFcg/xhmf/iSKqv02+qL /cbDBm4vGBv8uHXFhoQLwUN+IrlPltl5mwHrZnqzA4e89e1FrNcLtqFk7QphZ6kiGPEJ xZwks9zxT4CaLke/hxw+B/qYypaDDpx0rbUyCsU5r0lXgpDZQMqY8ccPWRAENxCKysZ0 nVqvAo52nkWWFylshSX1068wC43lhX87vRz54Uom+jEdrbyIOGqwPQZJc6a+1pXBLQFS I5tQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCU7Kkw/TmKtI2HV23IGTxxvZDlHOEZQtyGyD15ZKN7aRFuSWQmvGPzhyQyMM5fICg2LTiNLNhv6Ejwi@gnusha.org X-Gm-Message-State: AOJu0YxabofJtrSxHMVbrD+1CLIjea9uXrExhc1v6DZskdPlCHHnQSDk Mh7J586c/Dtxv0bRB2LsTgl88qlgOUYJ0xRyw/PMjaURIuTzbGTArj4x X-Google-Smtp-Source: AGHT+IFtyNkKc+1ggR2AXddOHpANc1kT5rYZd2Snj5GTJ+R+lDsIKBsCySjt+H2B+jrpUY4j6m5jUg== X-Received: by 2002:a05:6871:7984:b0:2cb:c780:ac52 with SMTP id 586e51a60fabf-2eeee4dabd7mr11180370fac.23.1750780856399; Tue, 24 Jun 2025 09:00:56 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdQCB/ENJzR+CQs9pM/HSsDN1D6nLIwO9RH1GD2OOpMyg== Received: by 2002:a05:6870:1b88:b0:2eb:b30a:f5e0 with SMTP id 586e51a60fabf-2ebb30b04e6ls3726257fac.1.-pod-prod-03-us; Tue, 24 Jun 2025 09:00:52 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUR0rnSstm8pcOUO8PVzLcgAn4dNBCy2wqxL0vWPayuo7LX6fwhlu/0e3ys1n8nE2QZPu2x/27csEbt@googlegroups.com X-Received: by 2002:a05:6808:130c:b0:404:e2fe:ee91 with SMTP id 5614622812f47-40ac6ed7ce3mr14730538b6e.8.1750780852624; Tue, 24 Jun 2025 09:00:52 -0700 (PDT) Received: by 2002:a05:6808:848c:b0:3f6:a384:eb6f with SMTP id 5614622812f47-40aa32aa09cmsb6e; Tue, 24 Jun 2025 08:54:11 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVchnfHgfdBEXNmshd7x7flEnqw4/l0QES/g3+8nz5spuTTkNtFAI04Uv2PPXvP2qVcbfFtnYovZwXk@googlegroups.com X-Received: by 2002:a05:6602:15c2:b0:86c:f8ba:5f08 with SMTP id ca18e2360f4ac-8762d18892bmr1946548439f.1.1750780451009; Tue, 24 Jun 2025 08:54:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1750780450; cv=none; d=google.com; s=arc-20240605; b=MZz0RV7j/vZwF8iIA6021vxWc1T0/LZ3L4lTSbL69l+QPPR9uhZea1Uv1s8c+CDmd3 8psR4mgoYvgzU3M8F5dlG/bljR/ySMEz6KUMCdAyO94SW+ussXE733eCjSDGvf+kum9x acQUxk5R77a9mgNLZkylPcIM3ahSVos88WDumUJZ03c5LXkTVrdqGBGWYLetvPgAAsg+ nRzklaRhjr0NJ56d6xrjvG9SZa0gfc+cEugIt7pfpHTz/nxJqDvAMMBW0m5g6Aejy17W zPESj5QEXE1WuZI5Kbj6TdcbftE3neC+ZC2powK/tN4aRoDdP9qpx0nsU8zHcl8WWK/1 z+TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:mime-version:date:message-id:dkim-signature :dkim-signature; bh=G12RUMHFtKxC9GchJsvgPpMBET1Nb/U/vh+Fq5ksgx4=; fh=02nJZxx48b/TyKrcvewNiN7FJtTrEjLEvj+vPN5r4s8=; b=d8dmNDW4J8DXX5nrBrmj3gVbPgXdAK30XscFG4NtIPsOuLyJi2fF61YAwA53b7EGkz sm43V2agb21Mrp9dNVrpQflprrc35fRVSr9gIryU7LgP7c/hCW53Wyrahs71fhZB253P adVLEyYQPjDwPzEc+ODSI4JV9eNlT3BygUJcDz0eznCETorxwNojVIoZ4H/2QDh++kLn IyggIh4U+KVaD5sTad7VJxwnK7uZbk1o95k9kbFLo2UJSpvJ85/TCWplKA/hcwupZtmK AsZYKbEcAJrKILmUiINAC3y0NADk44RNDfHpEcQPStBQ+6+O0M3hOO2K0TTRvKdEl1iD wlyQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1750778463 header.b=asLfboNr; dkim=pass header.i=@clients.mail.as397444.net header.s=1750778466 header.b=C+20759k; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [2620:6e:a000:1::99]) by gmr-mx.google.com with ESMTPS id 8926c6da1cb9f-5019e0516absi464930173.5.2025.06.24.08.54.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jun 2025 08:54:10 -0700 (PDT) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) client-ip=2620:6e:a000:1::99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1uU5yK-002Zgw-18; Tue, 24 Jun 2025 15:54:08 +0000 Message-ID: <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com> Date: Tue, 24 Jun 2025 11:54:02 -0400 MIME-Version: 1.0 Subject: Re: [bitcoindev] What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS To: Antoine Poinsot , Bitcoin Development Mailing List References: Content-Language: en-US From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1750778463 header.b=asLfboNr; dkim=pass header.i=@clients.mail.as397444.net header.s=1750778466 header.b=C+20759k; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.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.8 (/) Thanks, responding to one specific point: On 6/23/25 9:14 AM, 'Antoine Poinsot' via Bitcoin Development Mailing List wrote: > Yet another alternative is a set of more powerful capabilities, enabling the use cases that "commit to next transaction" > and "verify a BIP340 signature for an arbitrary message" enable and more. For instance replacing "commit to the exact > transaction which must spend this output" with "programmable introspection on the spending transaction's fields" has > been considered. However this approach increases implementation complexity and broadens the risk surface[^8] Responded to below [1] > which > warrants a compelling demonstration that arbitrary transaction introspection does enable important use cases not > achievable with more minimal capabilities. I'm somewhat skeptical that showing this isn't rather simple, though I admit I've spent less time thinking about these concepts. ISTM even something as simple as a rate-limit requires more full-featured introspection than only "commit to the exact next transaction" can provide. For example, a trivial construction would be something which requires that transactions spending an output have an output which claims at least Amount - Rate, which requires both more full-featured introspection as well as a bit of math. Given one of the loudest groups advocating for the additional features of CTV+CSFS are enterprise or large-value personal custody providers, it seems somewhat of a loss to not work our way towards really basic features for this use-case. More generally, more full-featured introspection like TXHASH provides a lot of flexibility in the constructs people can build. For example, allowing BYO fees in the form of an additional input + output in a transaction, rather than fixing an anchor output in the fixed "next transaction" commitment to allow for fees (and then requiring the same additional input + output later). There's also open questions as to the incentive-compatibility of anchors in a world with expensive block space, as OOB fees become much cheaper. Indeed, ISTM many use-cases for a construction like TXHASH become a lot more substantial with Math (though, again, I spend less time thinking about the use-cases of these things than most, so I'm sure others have more examples), I'm quite skeptical that *just* looking at an individual fork on its own is the right benchmark. Sure, functionality in proposed changes to Bitcoin's consensus need to be well-justified, but they don't need to be well-justified *purely on their own*. We add things like OP_SUCCESS opcodes in soft forks specifically to expand the set of things we can do later, not specifically in this fork. If we assume that we end up wanting things like velocity limits (which I imagine we would?) then it seems to me we should do a logical fork that adds features today, but which will allow us to make minimal extensions in the future to further expand its use-cases later. Taking a more myopic view of the present and ignoring the future results in us doing one thing today, then effectively replacing it later by adding more flexibility in a new opcode later, subsuming the features of what we do today. I don't see how this results in a net reduction in risk to Bitcoin, rather just means more total work and more cruft in Bitcoin's consensus. [1] Responding to the MEVil question OOO because I think the above should go first :). Indeed, more flexible introspection provides for a difference in risk to the system (though its worth noting we cannot both argue that there is no "demonstrated utility" *and* that the utility of a change is so substantially higher that it adds material risk to the system in the form of MEVil from its use-cases). However, given the uses of the Bitcoin chain today, it seems entirely possible (assuming sufficient adoption) that we end up with a substantial MEVil risk with or without any functionality expansion. This mandates a response from the Bitcoin development community in either case, and I'm confident that response can happen faster than any reasonable soft fork timeline. While its possible that existing CSV-based MEVil risk never grows beyond its current anemic state (due to preferences for stronger trust models from their users), and that there's a particularly clever design using expanded introspection that improves the trust model such that suddenly CSV-based protocol use explodes, ISTM given the risk and the need to mitigate it on its own, taking decisions that are sub-optimal for Bitcoin's consensus on this basis isn't accomplishing much and has real costs. Matt -- 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/8a9a2299-ab4b-45a4-8b9d-95798e6bb62a%40mattcorallo.com.