From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 09 Jun 2025 14:19:28 -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 1uOjtu-0006Aa-Pg for bitcoindev@gnusha.org; Mon, 09 Jun 2025 14:19:28 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-2e91916a983sf1855983fac.2 for ; Mon, 09 Jun 2025 14:19:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749503961; cv=pass; d=google.com; s=arc-20240605; b=ZmahSFpO1w7YX6Rf3hF9/IJAtSxO4lvhHUkB0nnUPRx9askonx2UmLBoU1S22arN1z 7YQ4GF/wFjeYBugHsKpDSey3LROwCFd9+VJ9XO5nOk1SH9/mOSMIyT4qsU887HMl75Jv FSPPs8T08xdk3p5HcjrEyt80iXk0/syQ/d05k1N6IBXQ5A1aq0A4j8A4oSpddyKjaXsY 45AQhAE2tLsqRDcBiC0k1F15wWque0ZgQNQt8LH+S7siBfzVd3oz10FPPUbkhIgUlAJK 62CeWGuZdlJb+urzJZOaMqmxbqR86h//VYN+bT+hk/UH4BxAoSE08XG8oERaFY49Q80O fliw== 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=Nu9rHTonlrzzuXKNsIh0plxQm63Iv1K7F5oAYzBbTOk=; fh=Lr4ATVAg2gWr8FRYNLK1d7uXXH8to7Ua7MAqQyFgesw=; b=SjyxFed/T1Ylto20xOe9mMILuaOTKbikCGsGln202U+1GEAftTVzhQKMbpcwUvBDOO y9jyT5P/6w7YO3uREDxWyef85XREI+9pYVjoSDm81g2BGxOEw2vkN07TTD4iOu+og5Op JmwgPsUp2lJPebqE04e6g/QeG44KSxCnvmUYxvrp7YHzyA6j64QtPqDtFwXybRyyRwL5 YBBJuSlxkMeJKtQEw6ndoxEmIb1fWCEfSkGmhJobdjGmZevOFAFcvX4P7GEex5fRS1w1 dXU/H2jDDGjLAWUXsXEp9v9xw5ZSHrO/vHXB5Ar3u7XdgG4f38wQi4gQCnEBW/I+fV+6 XZxA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kbgA3jHY; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::2e as permitted sender) smtp.mailfrom=alicexbtong@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=1749503961; x=1750108761; 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=Nu9rHTonlrzzuXKNsIh0plxQm63Iv1K7F5oAYzBbTOk=; b=hPyh0Iyq0GOeF5EwxmNHz4SUUWisrzUY+o+V8V2bDIux3gtpnCyU18FQf/3i/8in+e GAyh0/yseQnLcV9QaL8r7FGzMd+/gNmbwT40q7cnIwLylX+KM9o7mou6zoi6AC7k5RhM d3BnQJVUIur5r5Sue8iV2h035gTwinLeYzBvMT5Piej8smXnnaG2NsiBNIQqDcT8yP6o S5y26gJK1SOAvAmplsIrNWNsnTZnJHz6ffKf5Ti/BuSixcp9j4vvvcA03qxeKXwirjUF bhKFkK/C27Q6amm00C4w8760oRO7lBblydUIKLH/FEuLoedLNNbmnIDkJe33wBejbllc FsyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749503961; x=1750108761; 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=Nu9rHTonlrzzuXKNsIh0plxQm63Iv1K7F5oAYzBbTOk=; b=Bi01hnVV+cHNbJDyCXXFKsk+VdBnHek0vlTCRM4+T7z/cp1/igYkcNdGaLAL79sz8d b/MdJet2KSgC3q8ZiZUjJWOdcB5u4qH8bw3v57U23J7JpDZxKsMUbdVOSiHkKTLY1bmt oZ1rB6zgSw8k0yxRfq/aP+MXZM5eWBkc8HQ06HnCL/5CFjZ+htIweXr1+zTWBJr+YhWV 9c0qj+5Ith+I6GnRu8aLYbzn32RNunP8ioNWTGYYGR7Os4f262OFce18Lx6DBanWuVc2 vH4c123UEZHJw5JxyVuD3XRrVAgvwz34m+rFQl8JX1TDZI2kLxbvOVOb2+N0iTGrkp5h r08w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749503961; x=1750108761; 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=Nu9rHTonlrzzuXKNsIh0plxQm63Iv1K7F5oAYzBbTOk=; b=thZdTaOw9MDYvS5H+jDcmy8QSnYVp5V/500WXp8vkVkBidxd8KJNFdnWOfR7jBGQaz S6wD2FSWeiOJkrqo9PLrYYG3WRgQCQtQt7xkvh3IpoddaZkrOl543CAQxn7CVo/qdqZd UZfNF554AhERLQONh6gnuzvodhWbe1CAKm3lU1Bqy6t19x2wtvxNB7MfSspvNnfrfJIC oujP9agE9Qs2aGPnwLTtTxYRlpI9CA1D+jeYaZqjBDZUOERDj3PkMH6qSYNn6RL4VeD1 b/OXe5oQADp4iUC9VMsKs/q0b77bd9cHKxXZeus3RG6QVRIHWngK0WvOIfAETafzjb6M a9cQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWZWfMn9512jB6YFH7XIFlxgtVNHXyr5pw1g/LlaOh1rVcLFuOfxWjQbHERV98D+EstK1JssJ41nXOQ@gnusha.org X-Gm-Message-State: AOJu0Yzdv+uA/5LZX4JslWETcVottBhNMXeVsgiNDo0C0hIEn7D2BdBw suT38IjGPnQNeGu8wxy8fMR0+tOxreHriKPVjM8XggsgCpKuR08TN0Ay X-Google-Smtp-Source: AGHT+IEsxUW5soqmpkhWifqSCxFpt5tunU+UHj/Z+t046IkkKpCODXxK7xXsuSKH7IFW5d4gsR9Nkg== X-Received: by 2002:a05:687c:2f86:b0:2df:5323:520b with SMTP id 586e51a60fabf-2ea7d283a51mr79303fac.19.1749503960828; Mon, 09 Jun 2025 14:19:20 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcU1RjpU0DIroH/xyscSpTHa4c12yM2fVaTQekqJFo6ag== Received: by 2002:a4a:d40e:0:b0:60a:248:c91 with SMTP id 006d021491bc7-60f282b86a8ls1062631eaf.0.-pod-prod-02-us; Mon, 09 Jun 2025 14:19:17 -0700 (PDT) X-Received: by 2002:a05:6808:221e:b0:3f8:b73b:682b with SMTP id 5614622812f47-40a56a7ac8cmr49093b6e.7.1749503956901; Mon, 09 Jun 2025 14:19:16 -0700 (PDT) Received: by 2002:a05:6808:2014:b0:3f9:f009:458e with SMTP id 5614622812f47-40905fa9e5fmsb6e; Mon, 9 Jun 2025 12:28:10 -0700 (PDT) X-Received: by 2002:a17:90b:4a47:b0:311:e2ce:66ea with SMTP id 98e67ed59e1d1-313463f2f44mr24603163a91.0.1749497289003; Mon, 09 Jun 2025 12:28:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749497288; cv=none; d=google.com; s=arc-20240605; b=SCDIAOhsv3F84SMjY/YN4KqITBGZNihDmGK+A8Qf/kpCDD8VT9msXJI9h8usO8McC5 Aqy9WwQ9xUkFhGZ92jyBkLIy0h8dF2n34CeeGINP58TIGqKO5tWI+KjIyYDvYOcF0Qrf 1ZoykdmIfKfQGSrvEJAsZY2VSi29sBK0RYVfmeKt2pdV/UsZ3hrQQTjNEWMHzt95lYgm uBR26k/F7Zh4ko6tFyl3lLqjcaTal9CWRX3Qjva/y1cq7RsNLiiAdl8pNn7hlUVuh6op Rt2wX5Gz2l3n8ygAoblaw+ueOuazjyd3n7vCfVWGDgKVLS27AZSNbRxNOdqg0mBmPt9O ULqg== 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=p6PcF2KbPTcIlMG+n9C3xN44xs+xNeL8YfMYe68Zxag=; fh=xW8bxyqQYHE1uH3XvdCMfZVppoYs0vQZCdqgnVz97es=; b=icZF69lJeHa7mRLksUSeUOEI/Q0Fl2Fo7D5vMX+oyHg949y0qSBlY3dlISBjxOQUSn bKorRVdpDl1vtbN2tSP30NffN/FYB50blpBPmF56dLKBYpiHtTA5nGp0FAdY55FJYVCd YUaQSTAsuZbR4rtqrmmcYDtYLzKvBloX9EC+GxcrK/M1qZ0idcqOcO1SPMAgf1kCNLPa HG/PWujgFZVynDmsmyrjxN9LF38xqqbqg11VRaaNJuDdRGWbBS6bfe0nzq/VLxaKOjDf gKPM2+GXJd2ZoUCTwYtj0MOZyEjDqeZEoFCWv8+EHQRmPq5SL6usKrLk4gmOxpruMGIC yV/g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kbgA3jHY; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::2e as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com. [2001:4860:4864:20::2e]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-3134a777e0dsi612713a91.0.2025.06.09.12.28.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Jun 2025 12:28:08 -0700 (PDT) Received-SPF: pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::2e as permitted sender) client-ip=2001:4860:4864:20::2e; Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-2da14a6f89aso1837386fac.2 for ; Mon, 09 Jun 2025 12:28:08 -0700 (PDT) X-Gm-Gg: ASbGncswhFe1GRbkfPYDGpG2sFVz88x6WrjFbe3JVSl83HfKKQ6/o+GJhDSdG5HyAaC MklOLDTFtKySnXkH73QkgvGC1f6N6zcO8XMGB4HgRjzOi1MQU8Ir4vlQXxV+Zb7WLvXQmQO0Qwy Qk10Of0pep8w+NrEONi59o6BDMoVP1c74nRHRPJfXxuM51CkwgObSGVoKPSR3h X-Received: by 2002:a05:6871:e299:b0:2ea:1e5d:8ad3 with SMTP id 586e51a60fabf-2ea1e608caemr5789221fac.22.1749497288063; Mon, 09 Jun 2025 12:28:08 -0700 (PDT) MIME-Version: 1.0 References: <6f78b702-4bd0-4aa4-ac51-b881d8df9f01@mattcorallo.com> <01f49d64-838e-4311-bf79-8c4130b40c8e@mattcorallo.com> In-Reply-To: <01f49d64-838e-4311-bf79-8c4130b40c8e@mattcorallo.com> From: "/dev /fd0" Date: Tue, 10 Jun 2025 00:57:58 +0530 X-Gm-Features: AX0GCFtbZnt8oSXVGB6Nf_oeQl2fGpIplwhBK-5KjC_bjaSZsBpsX5Je1x_-RU8 Message-ID: Subject: Re: [bitcoindev] CTV + CSFS: a letter To: Matt Corallo Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000006401e8063728946b" X-Original-Sender: alicexbtong@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kbgA3jHY; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::2e as permitted sender) smtp.mailfrom=alicexbtong@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 (/) --0000000000006401e8063728946b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Matt, > I mean, sure, compared to something trivial doing something marginally-trivial has a lot bigger > surface area. But that isn't really an argument unless we're talking about something truly > complicated, and TXHASH absolutely is not. If you are referring to [BIP 346][0], it is not *marginally* trivial compared to BIP 119. TxFieldSelector makes it super complex. That's without even considering the possibilities when combined with CSFS. > If that goal includes more flexible tx field commitments (I imagine it > certainly does!) then we should do that, rather than taking a detour we should make progress towards > the eventual goal! Sometimes the goal is easier to achieve through multiple steps with BIP 119 being the first step in this case. There are several reasons to prefer BIP 119 over BIP 346, and I have listed some of them below, based on rationales shared in the [covenants support wiki][1]: 1. All the possible configurations need to be tested. 2. State carrying UTXOs will bloat the UTXO set. 3. BIP 346 could be activated in 2030 or later, once we better understand how people are actually using covenants. This approach would be based on real-world usage rather than premature optimization without sufficient data= . [0]: https://github.com/bitcoin/bips/blob/debd349e6181d949cbea0691fcc0d67b265b02= a8/bip-0346.md [1]: https://en.bitcoin.it/wiki/Covenants_support /dev/fd0 floppy disk guy On Mon, Jun 9, 2025 at 11:23=E2=80=AFPM Matt Corallo wrote: > > > On 6/9/25 10:43 AM, James O'Beirne wrote: > > On Mon, Jun 9, 2025 at 9:51=E2=80=AFAM Matt Corallo > lists@mattcorallo.com>> wrote: > > > That said, I have yet to see a reasoned explanation of why we should > prefer CTV over TXHASH. > > > > From the author of TXHASH himself on Delving Bitcoin > > ( > https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-s= tep-towards- > > covenants/1509/15 < > https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-s= tep- > > towards-covenants/1509/15>): > > > > > Having implemented TXHASH, I would definitely not say that > > > it =E2=80=9Csimplifies the change=E2=80=9D. > > Who claimed TXHASH is simpler than CTV? > > > > The difference in both technical debt and > > > potential for bugs is an order of magnitude bigger for TXHASH than f= or > > > CTV. > > I mean, sure, compared to something trivial doing something > marginally-trivial has a lot bigger > surface area. But that isn't really an argument unless we're talking abou= t > something truly > complicated, and TXHASH absolutely is not. > > > > (Not to say that I don=E2=80=99t think TXHASH would be worthwhile, b= ut I > > > will definitely say that it has not received the attention I had > expected, > > > so I would definitely not want to put it on the table anytime soon.) > > I mean there's still debate around the exact format of CTV commitments (e= g > whether it commits to > scriptSigs, if it works outside of segwit, etc), saying that there's > debate over the format of > TXHASH isn't exactly a compelling argument either? Yes, it needs some > work, but the time we'll > invest in CTV isn't all that different from the time we'll invest in > TXHASH, once we pick a direction. > > > The use-cases that might merit such a jump up in complexity over CTV > > have not been enumerated to my knowledge. > > This is a much better argument :). I'm a bit skeptical, though, that its > quite this cut-and-dry. For > example, the utter hack of the BitVM-with-CTV variant pretty clearly > points to us needing a more > fully featured commitment gadget to enable these things without the > nonsense they had to resort to. > > Further, we should think at least somewhat about what we think a > reasonable end state is. As far as > I understand, most proponents of CTV+CSFS do not think that CTV+CSFS is > *all* we want, but rather a > first step towards some goal. If that goal includes more flexible tx fiel= d > commitments (I imagine it > certainly does!) then we should do that, rather than taking a detour we > should make progress towards > the eventual goal! > > > CTV also includes > > upgrade hooks to incorporate modifications should these additional > > uses be more fully understood. > > I do not understand why people make this argument. Yes, the encoding of > the opcode allows you to > turn it into an OP_NOP (or SUCCESS or whatever), that doesn't make it > "upgrade hook"-friendly. If we > think that we just want to do CTV but we want CTV to be upgradable later > to be TXHASH, then we first > need to define the TXHASH hash and bitfield format, so that we can take > the subset of it that > captures CTV and hard-code that. But, of course, if we do that work we > should clearly do TXHASH :). > > These really feel like the same arguments again and again. I just don't > find them even remotely > compelling. "Oh, well, if we want to figure out TXHASH someone would have > to define a bitfield > format and that will take years" is just nonsense. Hell, its already done= ! > Maybe we want to tweak > it, but honestly bikeshedding over a specific bitfield format sounds like > it'll take a hell of a lot > less time than trying to make sure we work out all the cases for what > someone might want to commit > to that we want them to commit to but not more and fix a specific set of > commitments! > > 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/01f49d64-838e-4311-bf79-8c41= 30b40c8e%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/= CALiT-ZqWjPM-dhAUfahG5AgNfQbLhn2Aa4%2BeLcrpugU4eZ4_vA%40mail.gmail.com. --0000000000006401e8063728946b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Matt,

> I mean, sure, compared to= something trivial doing something marginally-trivial has a lot bigger> surface area. But that isn't really an argument unless we're = talking about something truly
> complicated, and TXHASH absolutely is= not.

If you are referring to [BIP 346][0], it is not=C2= =A0marginally trivial compared to BIP 119. TxFieldSelector makes it = super complex. That's without even considering the possibilities when c= ombined with CSFS.

> If that goal includes more flexible t= x field commitments (I imagine it
> certainly does!) then we should= do that, rather than taking a detour we should make progress towards
&g= t; the eventual goal!

Sometimes the goal is easier to ac= hieve through multiple steps with BIP 119 being the first step in this case= . There are several reasons to prefer BIP 119 over BIP 346, and I have list= ed some of them below, based on rationales shared in the [covenants support= wiki][1]:

1. All the possible configurations need= to be tested.
2. State carrying UTXOs will bloat=C2=A0the UTXO s= et.
3.=C2=A0BIP 346 could be activated in 2030 or later, once we = better understand how people are actually using covenants. This approach wo= uld be based on real-world usage rather than premature optimization without= sufficient data.


/dev/fd0
floppy disk guy

On Mon, Jun 9, 2025 at 11:23=E2=80=AFPM Matt Corallo <lf-lists@mattcorallo.com> wrote:
<= /div>


On 6/9/25 10:43 AM, James O'Beirne wrote:
> On Mon, Jun 9, 2025 at 9:51=E2=80=AFAM Matt Corallo <lf-lists@mattcorallo.com <mailto:lf-
> lists@mattc= orallo.com>> wrote:
>=C2=A0 > That said, I have yet to see a reasoned explanation of why = we should prefer CTV over TXHASH.
>
>=C2=A0 From the author of TXHASH himself on Delving Bitcoin
> (https://d= elvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards= -
> covenants/1509/15 <https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first= -step-
> towards-covenants/1509/15>):
>
>=C2=A0 >=C2=A0Having implemented TXHASH, I would definitely not say = that
>=C2=A0 > it =E2=80=9Csimplifies the change=E2=80=9D.

Who claimed TXHASH is simpler than CTV?

>=C2=A0 > The difference in both technical debt and
>=C2=A0 > potential for bugs is an order of magnitude bigger for TXHA= SH than for
>=C2=A0 > CTV.

I mean, sure, compared to something trivial doing something marginally-triv= ial has a lot bigger
surface area. But that isn't really an argument unless we're talkin= g about something truly
complicated, and TXHASH absolutely is not.

>=C2=A0 > (Not to say that I don=E2=80=99t think TXHASH would be wort= hwhile, but I
>=C2=A0 > will definitely say that it has not received the attention = I had expected,
>=C2=A0 > so I would definitely not want to put it on the table anyti= me soon.)

I mean there's still debate around the exact format of CTV commitments = (eg whether it commits to
scriptSigs, if it works outside of segwit, etc), saying that there's de= bate over the format of
TXHASH isn't exactly a compelling argument either? Yes, it needs some w= ork, but the time we'll
invest in CTV isn't all that different from the time we'll invest i= n TXHASH, once we pick a direction.

> The use-cases that might merit such a jump up in complexity over CTV > have not been enumerated to my knowledge.

This is a much better argument :). I'm a bit skeptical, though, that it= s quite this cut-and-dry. For
example, the utter hack of the BitVM-with-CTV variant pretty clearly points= to us needing a more
fully featured commitment gadget to enable these things without the nonsens= e they had to resort to.

Further, we should think at least somewhat about what we think a reasonable= end state is. As far as
I understand, most proponents of CTV+CSFS do not think that CTV+CSFS is *al= l* we want, but rather a
first step towards some goal. If that goal includes more flexible tx field = commitments (I imagine it
certainly does!) then we should do that, rather than taking a detour we sho= uld make progress towards
the eventual goal!

> CTV also includes
> upgrade hooks to incorporate modifications should these additional
> uses be more fully understood.

I do not understand why people make this argument. Yes, the encoding of the= opcode allows you to
turn it into an OP_NOP (or SUCCESS or whatever), that doesn't make it &= quot;upgrade hook"-friendly. If we
think that we just want to do CTV but we want CTV to be upgradable later to= be TXHASH, then we first
need to define the TXHASH hash and bitfield format, so that we can take the= subset of it that
captures CTV and hard-code that. But, of course, if we do that work we shou= ld clearly do TXHASH :).

These really feel like the same arguments again and again. I just don't= find them even remotely
compelling. "Oh, well, if we want to figure out TXHASH someone would h= ave to define a bitfield
format and that will take years" is just nonsense. Hell, its already d= one! Maybe we want to tweak
it, but honestly bikeshedding over a specific bitfield format sounds like i= t'll take a hell of a lot
less time than trying to make sure we work out all the cases for what someo= ne might want to commit
to that we want them to commit to but not more and fix a specific set of co= mmitments!

Matt

--
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 https://groups.google.com/d/msgid/bitcoindev/0= 1f49d64-838e-4311-bf79-8c4130b40c8e%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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CALiT-ZqWjPM-dhAUfahG5AgNfQbLhn2Aa4%2BeLcrpugU4eZ4_vA%40ma= il.gmail.com.
--0000000000006401e8063728946b--