From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 25 Jun 2025 09:54:53 -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 1uUTOe-000257-B4 for bitcoindev@gnusha.org; Wed, 25 Jun 2025 09:54:53 -0700 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-6114d2ae259sf110177eaf.2 for ; Wed, 25 Jun 2025 09:54:51 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1750870486; cv=pass; d=google.com; s=arc-20240605; b=eQutyTeKFEcSR5Ax3uIvjszogMuoKDOc2e/JYAWURYISW7qHdlFAYRrPFd4CMvzJp1 NzfpfgFHNu3ENsWKVa8YfWUqkobhd/5w6Lr6L/fgmaPMvwUJF164tmJ1der0rugtkfUB aXf51bm3EcRNRRmiTPVze509ioUB9rbGjH2tzB7W1nka1szMLW6tM21nWuBYjfgbDAer tZp9t8iKMuG0cch6qFVG3LKYH2oyeQkTnC6rot1KZoHem3oa3q455JzwxBT9bAY0z+Bz f/V8nO4jD0+02tU99pvbVXFP39fLR/5nznN39s9OY2+xPh6+QFyl2vlArIgH5eNMzqkS gx+w== 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:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=fvKVUHI9MbWNtr+tYQ0k/IEI26jdaFDENMecJE1OfTc=; fh=YQaMNTHO/jyPKrgThu6NMXSVYwRsoZ10gSOcT2EMoB8=; b=Tg12EcVxIiYQ4zVpRMCOKdA+afcQSJ/BvQtrwVAHbagYxNPJ+NHu1/MjnT/gyWapRw zMaDyNWkF2DAslMDQHdpRsfjKm6Pl7jXkL0E0MO+DWoIuTHK5DK6/4Fua0Cbt3AbNpFV bn4e59YjZ6trG4h7/TwdEsu8oUKLmYtPwNiulk8mK17MCwEpWOB4Zu6zJUgzhWKjYaA8 cjOuVrX0W4ExoIgbFTkdNAsyW0vBQtxY0DSm4yYkrBOPscJQx1esuvAbMUafxfv5PF1d KywrcxX4DkQ7npGR2MWkifLzRcuLUeY9qauNa6NA30FyrhLs7KsEWkbW/90O6Q6cETc4 T7EA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=XkDF+To7; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1750870486; x=1751475286; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=fvKVUHI9MbWNtr+tYQ0k/IEI26jdaFDENMecJE1OfTc=; b=gSyPSmdFerTyxqAci97tLRlRU8lex3q98EQOzLEh4pCnRTH3yvt1s7Ukf13GfqZokg mTrMAnZHbaY+BvS6OnfKDDFZCfYM3vTmuxLSuWd5eABrnQZCigR+8rHNaVI2gYhKGWWi LSHv+E8SN1eAP2yCiNmlAc2Sg8F1XdEYe4Z4F4srEKPy89ylufc4Tirz9yDL2FIJYAjA 8tT7/35FSGRK+/2AUuh/TfFnphs5JAROBJ0xjQy3Ud3DoJt46TsNscUgezJASOdsdm4E Zb93aKDlxej2v/PrVOYAK2uehkwRP3dMaUlJT8sstK5MmaW3oeyDaRSppYLWNsRi9zjl 5Neg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750870486; x=1751475286; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fvKVUHI9MbWNtr+tYQ0k/IEI26jdaFDENMecJE1OfTc=; b=quo/h3VVl5bszCmtWgUT7O+7IZyNMnY1LV3pzeP72am/XToqujrMnW15vCPx6HEB9U Uk9CsTVIIXWkstczM4qEsxWN7rUHdWVSgC3WOho6GNo9dKjVInKukNXhkpD/4Bi3M4ZP PoNQi96ylI5nedbLc3x1cB5KBlRBZkFnVwbfyWI8q+lfkjADYCnbpleJ7iTQKF8GhV7F 6Wc+GG1cKecJRchl1Skb96hGXst64rfYhdKGy5hvTsUIrKMeTBZxrYf4fjzObo0Ju7xA 0PELmVk8cyAH//3y1J/0PUzd7JLJCPdcC6gEORQv5tT8H9csCJCZxmKMCk3LlyQX+CoB WPNw== X-Forwarded-Encrypted: i=2; AJvYcCXrF5uMdB9+R1E4IiBd59cDc4FQ0OS24oJu3SuYKatZXVUUnyipiF5N06547dEYu/KN0hb6deW91n19@gnusha.org X-Gm-Message-State: AOJu0Yx+DV1grpIcALhxM/Y38TBpxrWQFajhhjFCs9fy82x7w1f8RH3Y CQ1jtZX1R88IYXb2cZ1lIqmryzMmEJ/Fu86pxITje3qTo9xzCezWn2Hz X-Google-Smtp-Source: AGHT+IEEfHlqyy6oi04UJFffEF70DqNzKfCkdjHEgIeXQbkrMEdvrGWyHfWGNqPxAv/3o1w1cx341g== X-Received: by 2002:a05:6870:a44d:b0:2d4:ce45:6983 with SMTP id 586e51a60fabf-2efb219afe6mr2628370fac.10.1750870485759; Wed, 25 Jun 2025 09:54:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZf88YpJwKexYT79WBUEszStY5XfY7CvHeb/ucVrOCGycQ== Received: by 2002:a05:6871:7893:b0:2ea:72d5:87e8 with SMTP id 586e51a60fabf-2efcf1d59afls34027fac.1.-pod-prod-08-us; Wed, 25 Jun 2025 09:54:43 -0700 (PDT) X-Received: by 2002:a05:6808:140a:b0:408:e690:7e38 with SMTP id 5614622812f47-40b0574c32dmr3426287b6e.16.1750870482988; Wed, 25 Jun 2025 09:54:42 -0700 (PDT) Received: by 2002:a05:600c:1d14:b0:450:9f02:8bd with SMTP id 5b1f17b1804b1-453818ec63ems5e9; Wed, 25 Jun 2025 09:50:22 -0700 (PDT) X-Received: by 2002:a05:600c:8519:b0:453:b44:eb69 with SMTP id 5b1f17b1804b1-45381aaf7cbmr37404175e9.13.1750870219346; Wed, 25 Jun 2025 09:50:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1750870219; cv=none; d=google.com; s=arc-20240605; b=R56SmguFn927lWGZmNzz5TD5u65Pg///jql3ItXYEz2EsuK5CwQElOI4mb2Q8xfQLy J8LKLd4lTm1dM/WNZZmKGeqKK4Fvp8CK/7D00qbyMECmUt7L4MpzD2Ix45GlVr3qqDxD +bo6/egrOakj8d+kijipR30uGav+MDWftvYQfQJf3dbESY+me2xwini3G5Ty/yo8Dngl 580Rvf+oGEjbEkt8TNlHCkOJ+M3hRP5MiGHYwubWAHaO7j8qfGZwA+YjaCHrZsKkEXc5 e19pwF2ISwntfaWNVUef3A1nWmZth8ZvjdGhUwzYPIDzX+VDDOuheIFOikO+1lBheL7e gP/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=KLqB0QZDwsaG7Cy2Ql8cp17mIromAm3UZJ0jQBK5c0s=; fh=xW8bxyqQYHE1uH3XvdCMfZVppoYs0vQZCdqgnVz97es=; b=fEC0mVSc5yTIaeue+L+vDwc2l+h8gyQEx+74u4leKHmbPb6FgezMDY2awGUnMZItu1 YYZ6zWpPeD0GGpLUAXTMQPV4XG6O6NWhPy7CI63p7BI5pQRtR3EfsOOxrCTa3E7/XYm9 tps3uMmis9FJ1tL/uN7U9Us5mdshorMzoPvUoddaa6MpW+k/qlG/jkEwf0dqO3aYcvfq PyTuH9ZSX87kQtMEUxS54ZtZAMSdkbYnst+F1VVBnNMOG8G9+FIK25czKqVdtpjxXKXM gOcG6iYcKWH3OjBovJlr2o7GO8e8VEMQIuzAGwWDUntzoVN79v6XRb1V0HEDzLohAoTw UZ3w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=XkDF+To7; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch. [79.135.106.29]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-45382372e92si371065e9.2.2025.06.25.09.50.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Jun 2025 09:50:19 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) client-ip=79.135.106.29; Date: Wed, 25 Jun 2025 16:50:15 +0000 To: Matt Corallo From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS Message-ID: <73PXNVcmgiN2Kba63P2SRZfs42lvgME_8EF-DlYtkOSY8mLRxEXPEw5JAi5wtPU2MEMw1C6_EDFHKKrhaa1F53OgIJOcam-kbOUP3aG2_e0=@protonmail.com> In-Reply-To: <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com> References: <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: a76eb1c7d56beb30e30365c2286bf622fe520800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=XkDF+To7; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) Thanks for sharing some objections. Here is my attempt at addressing them. > 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 trivia= l construction would be > something which requires that transactions spending an output have an out= put which claims at least > Amount - Rate, which requires both more full-featured introspection as we= ll as a bit of math. Yes. These capabilities are really only useful for reducing interactivity i= n second-layer protocols. They do not (reasonably) help for vaults and we do not claim it as a use ca= se. Previous efforts to promote opcodes implementing those capabilities have un= fortunately fallen into the trap of overpromising and claiming use cases they do not really enable.= But this should not make us overlook what they are really good at: interactivity reduction. Do you think that the use cases presented in OP, if demonstrated, are not e= nough to warrant soft forking in a primitive enabling them? > Given one of the loudest groups advocating for the additional features of= CTV+CSFS are enterprise > or large-value personal custody providers Yes. We intentionally do not mention vaults as a use case in our steelman. = We should not change Bitcoin on the basis of misleading use cases. If people are interested in v= aults, they should sponsor efforts on a different set of capabilities. Probably "programmable = forwarding of value from inputs to outputs", "programmable forwarding of spending conditions from in= puts to outputs" and maybe "commit to the exact transaction spending an output" (or more powerful intr= ospection). The lack of a similar enthusiasm for proposals enabling most or all of thes= e functionalities (like Salvatore Ingala's BIP334 or previously James O'Beirne's and Greg Sanders' = BIP345) suggests such loud support are in fact in favour of "just doing something" and rationaliz= e nice-sounding use cases backward from this proposal (but vaults!) because it appears to them to be = "further down the road". I think this view is very dangerous and is part of our motivation for redir= ecting discussions toward what these capabilities actually enable. > it seems somewhat of a loss to not work our way towards really basic feat= ures for this use-case. I personally grew more skeptical of the reactive security model of vaults a= fter working on it. Your mileage may vary and that's fine if people want to work on capabilities tha= t actually enable vaults, but i don't think they should be a required use cases and block introducing= primitives that substantially improve existing layer 2s and make new ones possible. > Indeed, ISTM many use-cases for a construction like TXHASH become a lot m= ore substantial with Math > [...], I'm quite skeptical that *just* looking at an individual fork on i= ts own is the right > benchmark. I agree that modularity and forward composability with potential future upg= rades are arguments in favour of a more flexible approach. But those need to be balanced with the = additional risk and implementation complexity such an approach entails. I'm happy to be convinc= ed if supporters of this approach demonstrate the added flexibility does enable important use cases = and the risks associated are manageable. But if nobody is interested in doing so, i don't think it's= reasonable to hold off a safer upgrade as long as it is demonstrated to provide substantial benefits= . It's also unclear that we should stop at "programmable introspection" in th= is case. Why not also include "programmable amount / spending condition forwarding" too, which wo= uld give you vaults? Why not even CAT, which is a neat tool in many situations and would let ZK peop= le experiment with validation rollups? And at this point, it would seem wiser to just work on = a sane Bitcoin Script replacement rather than throwing buckets of opcodes at it and hoping it hol= ds off. Which as we say in OP i don't think is realistic. > I don't see how this results in a net reduction in risk to Bitcoin, rathe= r just means more total > work and more cruft in Bitcoin's consensus. In theory, i agree. But by this token the same goes for every future extens= ion that introduces more expressivity to Bitcoin Script. This ties back to the stopping point: why a= dd more cruft to the existing interpreter when we could all focus on BTCLisp instead? It's also the case that even if future extensions introduce a superset of t= he capabilities being discussed, it's unlikely that such simple ones like "just commit to the nex= t transaction" and "verify a signature for an arbitrary message" would ever be made fully redu= ndant. Finally, when considering technical debt we should also weigh the actual co= st of the implementation of these simple capabilities. Signature verification on arbitrary message r= euses existing signature checking logic. Similarly, committing to the next transaction can heavily l= ean on existing Taproot signature messages, only minimally departing when necessary, and be impleme= nted in a strictly simpler manner than the existing CTV proposal. A minimal implementation of = these capabilities would not introduce significant technical debt. Interestingly, this argument applies more to introducing more involved capa= bilities like arbitrary transaction introspection, because of the substantially larger technical de= bt it would impose to first support in Bitcoin Script instead of focusing on a replacement with t= ransaction introspection from the get go. > 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). Yes we can? It's reasonable to see how arbitrary introspection could be use= ful in various handwavy ways, and therefore how they can be used for undesirable applications, whil= e also not having an important use case it enables clearly defined, much less demonstrated. > However, given the uses of the Bitcoin chain today, it seems entirely pos= sible (assuming > sufficient adoption) that we end up with a substantial MEVil risk with or= without any > functionality expansion. Sure, but I=E2=80=99d argue that the presence of risk now is a reason to be= more cautious about adding to it, rather than accepting it as inevitable. Best, Antoine On Tuesday, June 24th, 2025 at 12:00 PM, Matt Corallo wrote: >=20 >=20 > Thanks, responding to one specific point: >=20 > On 6/23/25 9:14 AM, 'Antoine Poinsot' via Bitcoin Development Mailing Lis= t wrote: >=20 > > Yet another alternative is a set of more powerful capabilities, enablin= g the use cases that "commit to next transaction" > > and "verify a BIP340 signature for an arbitrary message" enable and mor= e. For instance replacing "commit to the exact > > transaction which must spend this output" with "programmable introspect= ion on the spending transaction's fields" has > > been considered. However this approach increases implementation complex= ity and broadens the risk surface[^8] >=20 >=20 > Responded to below [1] >=20 > > which > > warrants a compelling demonstration that arbitrary transaction introspe= ction does enable important use cases not > > achievable with more minimal capabilities. >=20 >=20 > I'm somewhat skeptical that showing this isn't rather simple, though I ad= mit I've spent less time > thinking about these concepts. ISTM even something as simple as a rate-li= mit requires more > full-featured introspection than only "commit to the exact next transacti= on" can provide. For > example, a trivial construction would be something which requires that tr= ansactions 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 a= dvocating for the > additional features of CTV+CSFS are enterprise or large-value personal cu= stody providers, it seems > somewhat of a loss to not work our way towards really basic features for = this use-case. >=20 > More generally, more full-featured introspection like TXHASH provides a l= ot of flexibility in the > constructs people can build. For example, allowing BYO fees in the form o= f 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 inpu= t + output later). There's > also open questions as to the incentive-compatibility of anchors in a wor= ld with expensive block > space, as OOB fees become much cheaper. >=20 > Indeed, ISTM many use-cases for a construction like TXHASH become a lot m= ore substantial with Math > (though, again, I spend less time thinking about the use-cases of these t= hings 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 t= o 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 t= hings we can do later, not > specifically in this fork. >=20 > 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 whi= ch will allow us to make > minimal extensions in the future to further expand its use-cases later. T= aking 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. >=20 > [1] >=20 > Responding to the MEVil question OOO because I think the above should go = first :). >=20 > 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 sys= tem 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 ri= sk with or without any > functionality expansion. This mandates a response from the Bitcoin develo= pment community in either > case, and I'm confident that response can happen faster than any reasonab= le soft fork timeline. >=20 > 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 miti= gate 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. >=20 > Matt >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/8a9a2299-ab4b-45a4-8b9d-95798e6bb62a%40mattcorallo.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/= 73PXNVcmgiN2Kba63P2SRZfs42lvgME_8EF-DlYtkOSY8mLRxEXPEw5JAi5wtPU2MEMw1C6_EDF= HKKrhaa1F53OgIJOcam-kbOUP3aG2_e0%3D%40protonmail.com.