path: root/2d/c3a0ddbc734576250b65eea5e2efd8bac3ad9b

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 <bitcoindev+bncBCU2P6FJ3EBBBVM7TXBAMGQEQ2D7LDY@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <bitcoindev@googlegroups.com>; 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: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
 <6f78b702-4bd0-4aa4-ac51-b881d8df9f01@mattcorallo.com> <CAPfvXf+t33u1ghz39cqYn4k5ErmxTkUv0njF9Zwbz_2UkdTjAg@mail.gmail.com>
 <01f49d64-838e-4311-bf79-8c4130b40c8e@mattcorallo.com>
In-Reply-To: <01f49d64-838e-4311-bf79-8c4130b40c8e@mattcorallo.com>
From: "/dev /fd0" <alicexbtong@gmail.com>
Date: Tue, 10 Jun 2025 00:57:58 +0530
X-Gm-Features: AX0GCFtbZnt8oSXVGB6Nf_oeQl2fGpIplwhBK-5KjC_bjaSZsBpsX5Je1x_-RU8
Message-ID: <CALiT-ZqWjPM-dhAUfahG5AgNfQbLhn2Aa4+eLcrpugU4eZ4_vA@mail.gmail.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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 <lf-lists@mattcorallo.=
com>
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 <lf-lists@mattcoral=
lo.com
> <mailto:lf-
> > 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

<div dir=3D"ltr">Hi Matt,<div><br></div><div>&gt; I mean, sure, compared to=
 something trivial doing something marginally-trivial has a lot bigger</div=
>&gt; surface area. But that isn&#39;t really an argument unless we&#39;re =
talking about something truly<br>&gt; complicated, and TXHASH absolutely is=
 not.<div><br></div><div>If you are referring to [BIP 346][0], it is not=C2=
=A0<i>marginally</i> trivial compared to BIP 119. TxFieldSelector makes it =
super complex. That&#39;s without even considering the possibilities when c=
ombined with CSFS.</div><div><br>&gt; If that goal includes more flexible t=
x field commitments (I imagine it</div>&gt; certainly does!) then we should=
 do that, rather than taking a detour we should make progress towards<br>&g=
t; the eventual goal!<div><br></div><div>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]:</div><div><br></div><div>1. All the possible configurations need=
 to be tested.</div><div>2. State carrying UTXOs will bloat=C2=A0the UTXO s=
et.</div><div>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.</div><div><br></div><div>[0]:=C2=A0<a href=3D"https://git=
hub.com/bitcoin/bips/blob/debd349e6181d949cbea0691fcc0d67b265b02a8/bip-0346=
.md">https://github.com/bitcoin/bips/blob/debd349e6181d949cbea0691fcc0d67b2=
65b02a8/bip-0346.md</a><br>[1]:=C2=A0<a href=3D"https://en.bitcoin.it/wiki/=
Covenants_support">https://en.bitcoin.it/wiki/Covenants_support</a></div><d=
iv><br></div><div>/dev/fd0</div><div>floppy disk guy</div></div><br><div cl=
ass=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Mon, Jun 9, 2025 at 11:23=E2=80=AFPM Matt Corallo &lt;<a href=3D"ma=
ilto:lf-lists@mattcorallo.com">lf-lists@mattcorallo.com</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 6/9/25 10:43 AM, James O&#39;Beirne wrote:<br>
&gt; On Mon, Jun 9, 2025 at 9:51=E2=80=AFAM Matt Corallo &lt;<a href=3D"mai=
lto:lf-lists@mattcorallo.com" target=3D"_blank">lf-lists@mattcorallo.com</a=
> &lt;mailto:<a href=3D"mailto:lf-" target=3D"_blank">lf-</a> <br>
&gt; <a href=3D"mailto:lists@mattcorallo.com" target=3D"_blank">lists@mattc=
orallo.com</a>&gt;&gt; wrote:<br>
&gt;=C2=A0 &gt; That said, I have yet to see a reasoned explanation of why =
we should prefer CTV over TXHASH.<br>
&gt; <br>
&gt;=C2=A0 From the author of TXHASH himself on Delving Bitcoin<br>
&gt; (<a href=3D"https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consens=
us-on-a-first-step-towards-" rel=3D"noreferrer" target=3D"_blank">https://d=
elvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards=
-</a> <br>
&gt; covenants/1509/15 &lt;<a href=3D"https://delvingbitcoin.org/t/ctv-csfs=
-can-we-reach-consensus-on-a-first-step-" rel=3D"noreferrer" target=3D"_bla=
nk">https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first=
-step-</a> <br>
&gt; towards-covenants/1509/15&gt;):<br>
&gt; <br>
&gt;=C2=A0 &gt;=C2=A0Having implemented TXHASH, I would definitely not say =
that<br>
&gt;=C2=A0 &gt; it =E2=80=9Csimplifies the change=E2=80=9D.<br>
<br>
Who claimed TXHASH is simpler than CTV?<br>
<br>
&gt;=C2=A0 &gt; The difference in both technical debt and<br>
&gt;=C2=A0 &gt; potential for bugs is an order of magnitude bigger for TXHA=
SH than for<br>
&gt;=C2=A0 &gt; CTV.<br>
<br>
I mean, sure, compared to something trivial doing something marginally-triv=
ial has a lot bigger <br>
surface area. But that isn&#39;t really an argument unless we&#39;re talkin=
g about something truly <br>
complicated, and TXHASH absolutely is not.<br>
<br>
&gt;=C2=A0 &gt; (Not to say that I don=E2=80=99t think TXHASH would be wort=
hwhile, but I<br>
&gt;=C2=A0 &gt; will definitely say that it has not received the attention =
I had expected,<br>
&gt;=C2=A0 &gt; so I would definitely not want to put it on the table anyti=
me soon.)<br>
<br>
I mean there&#39;s still debate around the exact format of CTV commitments =
(eg whether it commits to <br>
scriptSigs, if it works outside of segwit, etc), saying that there&#39;s de=
bate over the format of <br>
TXHASH isn&#39;t exactly a compelling argument either? Yes, it needs some w=
ork, but the time we&#39;ll <br>
invest in CTV isn&#39;t all that different from the time we&#39;ll invest i=
n TXHASH, once we pick a direction.<br>
<br>
&gt; The use-cases that might merit such a jump up in complexity over CTV<b=
r>
&gt; have not been enumerated to my knowledge.<br>
<br>
This is a much better argument :). I&#39;m a bit skeptical, though, that it=
s quite this cut-and-dry. For <br>
example, the utter hack of the BitVM-with-CTV variant pretty clearly points=
 to us needing a more <br>
fully featured commitment gadget to enable these things without the nonsens=
e they had to resort to.<br>
<br>
Further, we should think at least somewhat about what we think a reasonable=
 end state is. As far as <br>
I understand, most proponents of CTV+CSFS do not think that CTV+CSFS is *al=
l* we want, but rather a <br>
first step towards some goal. If that goal includes more flexible tx field =
commitments (I imagine it <br>
certainly does!) then we should do that, rather than taking a detour we sho=
uld make progress towards <br>
the eventual goal!<br>
<br>
&gt; CTV also includes<br>
&gt; upgrade hooks to incorporate modifications should these additional<br>
&gt; uses be more fully understood.<br>
<br>
I do not understand why people make this argument. Yes, the encoding of the=
 opcode allows you to <br>
turn it into an OP_NOP (or SUCCESS or whatever), that doesn&#39;t make it &=
quot;upgrade hook&quot;-friendly. If we <br>
think that we just want to do CTV but we want CTV to be upgradable later to=
 be TXHASH, then we first <br>
need to define the TXHASH hash and bitfield format, so that we can take the=
 subset of it that <br>
captures CTV and hard-code that. But, of course, if we do that work we shou=
ld clearly do TXHASH :).<br>
<br>
These really feel like the same arguments again and again. I just don&#39;t=
 find them even remotely <br>
compelling. &quot;Oh, well, if we want to figure out TXHASH someone would h=
ave to define a bitfield <br>
format and that will take years&quot; is just nonsense. Hell, its already d=
one! Maybe we want to tweak <br>
it, but honestly bikeshedding over a specific bitfield format sounds like i=
t&#39;ll take a hell of a lot <br>
less time than trying to make sure we work out all the cases for what someo=
ne might want to commit <br>
to that we want them to commit to but not more and fix a specific set of co=
mmitments!<br>
<br>
Matt<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/01f49d64-838e-4311-bf79-8c4130b40c8e%40mattcorallo.com" rel=3D"n=
oreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/0=
1f49d64-838e-4311-bf79-8c4130b40c8e%40mattcorallo.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CALiT-ZqWjPM-dhAUfahG5AgNfQbLhn2Aa4%2BeLcrpugU4eZ4_vA%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CALiT-ZqWjPM-dhAUfahG5AgNfQbLhn2Aa4%2BeLcrpugU4eZ4_vA%40ma=
il.gmail.com</a>.<br />

--0000000000006401e8063728946b--