path: root/12/5879b0dfa1eabda7908190c7a65f3e8ed6555e

Delivery-date: Thu, 10 Jul 2025 06:04:26 -0700
Received: from mail-oi1-f186.google.com ([209.85.167.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCV5B3G674FRBUHUX3BQMGQEFNOJAGI@googlegroups.com>)
	id 1uZqws-0005cA-3S
	for bitcoindev@gnusha.org; Thu, 10 Jul 2025 06:04:26 -0700
Received: by mail-oi1-f186.google.com with SMTP id 5614622812f47-40b99fd68fesf741550b6e.0
        for <bitcoindev@gnusha.org>; Thu, 10 Jul 2025 06:04:25 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1752152660; cv=pass;
        d=google.com; s=arc-20240605;
        b=anIKt835Xl8OBEWM7Wwn6fxxMaEW835cVzvPblAWhxs0lW4BeNox9PVFG81nO4zjq4
         /2PadzDqJ1pK2wWTnDoNmkm5dYskQbuinlC30kYnwAf4kyG09P3HvMz55eJyo1dDDdgM
         kUslZGAPE4aZRX5DHOCpYPIVQJCcBFsQab53TYm4fOO8BbI8av96NbZeVJ+UUQKOoPAA
         K66Enf5kr8ciZK/q0wDlHZGuJS3Z51/phDqzX3A4lYpwMJPOVUmIFmvjP1DXEdQNJyOQ
         WOALmxy9HxslPb9RIL1NF8yhrQR8rHLeFC5PGX/xJAw02Qd7YQuLgsqHUIrrX4bGEtxk
         IltA==
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=hxjFKZiAjB44/qu3vEGvnfghxOchufqpPLfc5hb5i8w=;
        fh=ht2i8hCp33GXhQmYbd6XsPZOhoKKLwDBl9JudiQi8sg=;
        b=QOWYkWb3YWWBbE5pl8ILCzRPZg58d1fB5atQJaILTVapO/sjxqcTHHMIHUitbNmYDX
         BlPddpSCh12W27C12f5uTLTQj+dfVAE+3kRfPNvZmIBe/JQ5JBjOP1Qur8j3nK8VSNQv
         ONSe0fk76WYf37pGU5OKe7n1GbpjS0bOUfd8npridZNYoGXNA88iLKpVjGSxGlUDDqUe
         PrpzWJbMt6SRr7UO5CDVXlUkIXsYeTRDHC8m1vKkNfbBnJlppMkvmflzCq4IsgFMx9V+
         YhqaEb2w/bDetlPEtsXhpJbrz7RZS2gCHdwFUslFTLM0KAxB+yM5I8m9i0q1yN8nhdlu
         f86w==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=Dv7wY5dB;
       spf=pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::42f as permitted sender) smtp.mailfrom=james.obeirne@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=1752152660; x=1752757460; 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=hxjFKZiAjB44/qu3vEGvnfghxOchufqpPLfc5hb5i8w=;
        b=IFsPpCOtsiS9yzjd/7UeQmXX5rVhA+9TEMe4BKpmFMZmrSz5JqwinkhlkHYsKVBeBc
         F+pEJMTtmY4n84ZbC9XS5pUu5s9lU9s76SRk46vz2IozApsmvAi4xpSt1/eQCTWTYGZI
         n6Pt0/iYFecmI3l05fGyYxSwiz0+630T8zwQ73aR7rrH2Vf57xaaTenJI5I9V8MqQHl2
         3o2G/rFwFI/96x1rsf18WkVc8Tbo/1OwDlgol3iq/DX/yR4x6CMmWoke3xDqJSEok3yi
         FyYThyp6hvmGF9Hlu8dDNJFUBsshz3oyK3sv6dfrh2JGzxm5UVBCE+0f9i64gN+OHX6Z
         SGIQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1752152660; x=1752757460; 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=hxjFKZiAjB44/qu3vEGvnfghxOchufqpPLfc5hb5i8w=;
        b=CVbii8PU9i510cCh+eotLp7ogKpCNoBUW7n+Rrdk56ZWAebbQRBW1yPuqTFGasiGth
         9REzwrNUxBHyxfzH09qECrBbHsr+8Mg1bcVsZysPQrQ/AMagFMn1+ob6uGTmFqa1zJVc
         7TT6MGa864f3g59+bgmN/YyzBCUi7JxqltLxAPjViRIWRVV8LlyZiqSs37Uq9lSONC6L
         MX1MBg3qJ2FlA0SWU+jZZh1saay7pRz7Yja6IXy9Qxr3N/1oq20YiFtc3PvXymBE9rGS
         u1R98DVgpKvVHwVsud+X/Y8tKMrwGSHae8nmTCodu8jDiXqWDLS/cVcmDCwgPnJmQRoI
         dfzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1752152660; x=1752757460;
        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=hxjFKZiAjB44/qu3vEGvnfghxOchufqpPLfc5hb5i8w=;
        b=Hs1mC9rhftKGzwgdDL2depWX10bRUjATW5ZRfbfljge1tA9HIEd7I/P5+EhCRE7csk
         UKEJf3oYNxaC2S3DIyPma4Cv+EA71erexovFqCzXn0gwUvl1VZVqD/xiML7IOpTwNVVk
         +GX1hUFwVN08M5ZGLC+hXaOvoHmweG/sk1GJWe64Hon/zhNxoyV1/+c7pqz2cn3AJDz/
         E5AnFsMry/OYVaNk3yVK3le7xyOFB7DZI4fBg6ZrGUjFzib9tCG2qjZJq3YaBpEX+xGL
         ty+0vUxuYSafaY4J6+8OcfAkS6BouzHtApBE7VZNBw/GQgG9FWEiYOYntOccis6Dl4ZS
         eQxg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVkVRveCXjdx29ycaWRRCrt34nhfhGmrWRzVW6zJ2lLBkcP4kwyp4ARCxOjw1zNRB5ks+Qu1acT/bFV@gnusha.org
X-Gm-Message-State: AOJu0YwQe6il0Q+kVpAFsYKOoKPATP2sNeEzjt9HBFyT4fR0cJJQ7r1R
	NEHM0gGUN6kwiPOoNIzUPCrVzyBppPXOuVOUqw3UeWI2CHF2sSe6SgQc
X-Google-Smtp-Source: AGHT+IHLtlv/SbR3n75mHFnGkssnF5+ErKuE+5GlBqwF+lhzk2gL+Eo1LsOetyEUzVGM9tUjQyovlQ==
X-Received: by 2002:a05:6808:16a8:b0:40e:2285:50c6 with SMTP id 5614622812f47-413c34e5e29mr2392950b6e.10.1752152659333;
        Thu, 10 Jul 2025 06:04:19 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdQRcLARoP0pFxSEneKCbV5oSF12Izlcx0R40Qws7m0iQ==
Received: by 2002:a05:6820:4103:b0:611:6c4b:b4ae with SMTP id
 006d021491bc7-613d7db8898ls881054eaf.1.-pod-prod-00-us; Thu, 10 Jul 2025
 06:04:16 -0700 (PDT)
X-Received: by 2002:a05:6808:4f28:b0:40b:31ef:8784 with SMTP id 5614622812f47-413c30e5f77mr2302161b6e.7.1752152656308;
        Thu, 10 Jul 2025 06:04:16 -0700 (PDT)
Received: by 2002:a05:620a:8e01:b0:7c5:3b15:3956 with SMTP id af79cd13be357-7d43c74d538ms85a;
        Thu, 10 Jul 2025 05:24:33 -0700 (PDT)
X-Received: by 2002:a05:6214:4f14:b0:702:c5d4:3c32 with SMTP id 6a1803df08f44-70495a20242mr38906876d6.9.1752150271067;
        Thu, 10 Jul 2025 05:24:31 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1752150271; cv=none;
        d=google.com; s=arc-20240605;
        b=hAhHW389MhS+LD2PxRxroQtdtvpCaq/3X0Vv1a8JEZ/m1EphT+0Sem5bcQOQoC3f9o
         uWBhuaxLs/hGDAPkvUnZQ+IcAtBF2srvweuVSw8BUYh+VWYvHF+S5YneqP1Po51gvhPf
         NSL4ncOnXpuLYBROkGvETvUwUyMlX/qy9AcuS+dU4h6h6J/apnSI6pCPebXGgwE24l9o
         v5YO13c+aipYiC7BqnYHRbAALv2ghEQW39Gfz2nFNnOsvyz83yoS+8oEWO2W534Ptspp
         98wjt+yOj1LL6plT3QOywHlckaoBGzfNDLhQeJVJCt6NKDh0zAvMZH5xM9pfxFVy5gsH
         Kcrg==
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=BGjSOrikdfJzH0YRYTjdH9g84qM4WrIDYDdf8pPQUfA=;
        fh=sjkP8zjFS5lFlY+fNUHD47XPXx06dShKmNgWs4F+if8=;
        b=QAqHa64gBBScGUcEplnptNEgGxc7+rJLDlD4HtoNBpFpj4m1epRHfLDvoHDI1w8zLG
         TbI7m3QNNOkcPW+Qvf9lrQCkniKd7bQsJ+m0MvlLreFz+O4cieDI2xeRBY1nSFWOYZZq
         Yc+AdmkRjHZwGUP6qiR9YWx37PYkyXzmg206yqIw53lffAWRnE347bJd/rPiF985SSGh
         K5HlAai3PQDciI0oqG7dfjzk0rGzF5JUyYyJSpiTwf1o3YuG8D6nUE3bVU/B00Vj7bk2
         Rn2vNkCQTkGfkYn2Xfg/lCpQdRBWKtac5ExArK87pFzef0fqU2bMPo2WHFlaSwXx4LSt
         qyjA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=Dv7wY5dB;
       spf=pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::42f as permitted sender) smtp.mailfrom=james.obeirne@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com. [2607:f8b0:4864:20::42f])
        by gmr-mx.google.com with ESMTPS id 6a1803df08f44-70497db8a41si538626d6.8.2025.07.10.05.24.31
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 10 Jul 2025 05:24:31 -0700 (PDT)
Received-SPF: pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::42f as permitted sender) client-ip=2607:f8b0:4864:20::42f;
Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-74ad4533ac5so1748906b3a.0
        for <bitcoindev@googlegroups.com>; Thu, 10 Jul 2025 05:24:31 -0700 (PDT)
X-Gm-Gg: ASbGncsJep48BMbcnJ3guYlIOkdwhATAYGWDDf/qJMmcVRy9c4/pH7jDLIJfjm4gGKt
	a+lQPIKSaRbLxacullbBWv7J+yYCVurzWFMhox3CcIrl3ZrXGV4pZN6cjAPeaeSdNyXSwaOG+gf
	KuaA4RuIFtZ/h8A8o8B6ZLpUx7KneCEvKT3qtzv11J
X-Received: by 2002:a17:90a:e996:b0:31c:39c2:b027 with SMTP id
 98e67ed59e1d1-31c3cf5e35bmr4077621a91.7.1752150269899; Thu, 10 Jul 2025
 05:24:29 -0700 (PDT)
MIME-Version: 1.0
References: <26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com>
In-Reply-To: <26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Thu, 10 Jul 2025 08:24:17 -0400
X-Gm-Features: Ac12FXy5-e-hNsyWsD1_SrATpvKVDrQa8HlHlXAewEb6PUkaMcYQILn6dM1wLI8
Message-ID: <CAPfvXf+E0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA@mail.gmail.com>
Subject: Re: [bitcoindev] A Taproot-native (re-)bindable transaction bundle proposal
To: Greg Sanders <gsanders87@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000006e399406399246b6"
X-Original-Sender: james.obeirne@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=Dv7wY5dB;       spf=pass
 (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::42f
 as permitted sender) smtp.mailfrom=james.obeirne@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 (/)

--0000000000006e399406399246b6
Content-Type: text/plain; charset="UTF-8"

Hi Greg,

Congratulations on the BIPs and happy to see a concrete counterproposal
from you and the coauthors.

While the simplicity of the BIPs and draft implementation are
refreshing, I see a few issues relative to BIP-119:

# Annex commitment

TEMPLATEHASH commits to the annex, whereas CTV does not. I think this
poses some potential issues.

We don't know what the annex will be used for yet. BIP-341, where the
annex is defined, writes

> Until the meaning of this field is defined by another softfork, users
> SHOULD NOT include annex in transactions, or it may lead to PERMANENT
> FUND LOSS. [0]

To date, no other widely adopted BIP has spelled out exactly what the
annex will ultimately be used for.

The germane thing in this case is that the annex contents are specified
at *spend time*, whereas the CTV or TEMPLATEHASH hash must be
precomputed before the creation of the UTXO.

If the hash must know the contents of the annex prior to spend time, it
fundamentally constrains how the annex can be used in conjunction with
TEMPLATEHASH (since you have to anticipate the contents of the annex).

Some conceivable uses of the annex that have been floated are:

- for cross-input signature aggregation,
- for amount checks in aggregate vault operations[1],
- for implementing some SIGHASH_GROUP-like function[2].

To me it isn't inconceivable, and is perhaps even likely, that the use
of the CTV-like functionality and some of the above future examples
might overlap.

Rather than bundling a commitment to the annex with TEMPLATEHASH, it
would seem more prudent to defer treatment of the annex until we've
decided what it is. It might ultimately make sense to have some
orthogonal opcode ("OP_CHECKANNEX" or something) that allows script
authors to explicitly specify annex expectations.


[0]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
[1]:
https://github.com/bitcoin/bitcoin/commit/2c63a983ddb7f2b7eaaedc8313fbeaf8f7c1b128
[2]: https://gnusha.org/pi/bitcoindev/20220305055924.GB5308@erisian.com.au/


# No witness v0 (segwit) support

I think the lack of TEMPLATEHASH's availability in a witness v0 script
context will significantly limit its deployability for at least the next
few years and possibly permanently for some users.

Right now two separate estimates put Taproot usage (by value) at
0.1% or 0.75% as of May 2025[3][4]. This is nearly four years after its
activation. We can't say exactly why users aren't upgrading, but the
reality is that the overwhelming majority of value transfer in bitcoin
is still happening in a pre-Taproot script context.

One concrete impediment to Taproot adoption among custodians is the lack
of native HSM support for the Schnorr signature scheme. It's reasonable
to believe that some already-deployed HSM contexts may never get to
Taprootability.

While the TEMPLATEHASH authors don't acknowledge vaults in their
proposal, there is popular demand for CTV on the basis of being both a
simple vaulting mechanism[5] and a necessary ingredient for more ergonomic
vaults[6]. Much of my own professional grounding for supporting CTV stems
from this use.

TEMPLATEHASH's lack of witness v0 support hampers this use, and prevents
many industrial users who are (for varying reasons) stuck in a wit-v0
world from making use of the simple vaulting primitives that much CTV
interest comes from.

[3]: https://www.unchained.com/blog/bitcoin-address-types-compared
[4]: https://research.mempool.space/utxo-set-report/
[5]: https://github.com/jamesob/simple-ctv-vault

To date I haven't heard any concrete downside of including witness v0
support for an opcode like this other than "it's marginally more to
think about during review."

The reality is that we're still living in a witness v0 world; there will
be significant amounts of wit v0 traffic for the foreseeable future. To
throw that context aside is to ignore many potential users.

# Non-blocking gripes

I'm disappointed by the lack of consideration for the succinct "deferred
payout" or "congestion control" use that is provided by either bare CTV
or your P2TH ("witness v2") patch, but that isn't surprising given the
unwillingness on the part of the authors to acknowledge the potential
value of that use.

Even though it's disappointing to me, its absence here wouldn't hold up
my support for the proposal.

---

I'm glad to see progress on the prospect of making bitcoin's script more
useful, thanks for your work.

James

-- 
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/CAPfvXf%2BE0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA%40mail.gmail.com.

--0000000000006e399406399246b6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Greg,<br><br>Congratulations on the BIPs and happy to s=
ee a concrete counterproposal<br>from you and the coauthors.<br><br>While t=
he simplicity of the BIPs and draft implementation are<br>refreshing, I see=
 a few issues relative to BIP-119:<br><br># Annex commitment<br><br>TEMPLAT=
EHASH commits to the annex, whereas CTV does not. I think this<br>poses som=
e potential issues.<br><br>We don&#39;t know what the annex will be used fo=
r yet. BIP-341, where the<br>annex is defined, writes <br><br>&gt; Until th=
e meaning of this field is defined by another softfork, users<br>&gt; SHOUL=
D NOT include annex in transactions, or it may lead to PERMANENT<br>&gt; FU=
ND LOSS. [0]<br><br>To date, no other widely adopted BIP has spelled out ex=
actly what the<br>annex will ultimately be used for.<br><br>The germane thi=
ng in this case is that the annex contents are specified<br>at *spend time*=
, whereas the CTV or TEMPLATEHASH hash must be<br>precomputed before the cr=
eation of the UTXO.<br><br>If the hash must know the contents of the annex =
prior to spend time, it<br>fundamentally constrains how the annex can be us=
ed in conjunction with<br>TEMPLATEHASH (since you have to anticipate the co=
ntents of the annex).<br><br>Some conceivable uses of the annex that have b=
een floated are:<br><br>- for cross-input signature aggregation,<br>- for a=
mount checks in aggregate vault operations[1],<br>- for implementing some S=
IGHASH_GROUP-like function[2].<br><br>To me it isn&#39;t inconceivable, and=
 is perhaps even likely, that the use<br>of the CTV-like functionality and =
some of the above future examples<br>might overlap.<br><br>Rather than bund=
ling a commitment to the annex with TEMPLATEHASH, it<br>would seem more pru=
dent=C2=A0to defer treatment of the annex until we&#39;ve<br>decided what i=
t is. It might ultimately make sense to have some<br>orthogonal opcode (&qu=
ot;OP_CHECKANNEX&quot; or something) that allows script<br>authors to expli=
citly specify annex expectations.<br><br><br>[0]: <a href=3D"https://github=
.com/bitcoin/bips/blob/master/bip-0341.mediawiki">https://github.com/bitcoi=
n/bips/blob/master/bip-0341.mediawiki</a><br>[1]: <a href=3D"https://github=
.com/bitcoin/bitcoin/commit/2c63a983ddb7f2b7eaaedc8313fbeaf8f7c1b128">https=
://github.com/bitcoin/bitcoin/commit/2c63a983ddb7f2b7eaaedc8313fbeaf8f7c1b1=
28</a><br>[2]: <a href=3D"https://gnusha.org/pi/bitcoindev/20220305055924.G=
B5308@erisian.com.au/">https://gnusha.org/pi/bitcoindev/20220305055924.GB53=
08@erisian.com.au/</a><br><br><br># No witness v0 (segwit) support<br><br>I=
 think the lack of TEMPLATEHASH&#39;s availability in a witness v0 script<b=
r>context will significantly limit its deployability for at least the next<=
br>few years and possibly permanently for some users.<br><br>Right now two =
separate estimates put Taproot usage (by value) at<br>0.1% or 0.75% as of M=
ay 2025[3][4]. This is nearly four years after its<br>activation. We can&#3=
9;t say exactly why users aren&#39;t upgrading, but the<br>reality is that =
the overwhelming majority of value transfer in bitcoin<br>is still happenin=
g in a pre-Taproot script context.<br><br>One concrete impediment to Taproo=
t adoption among custodians is the lack<br>of native HSM support for the Sc=
hnorr signature scheme. It&#39;s reasonable<br>to believe that some already=
-deployed HSM contexts may never get to<br>Taprootability.<br><br>While the=
 TEMPLATEHASH authors don&#39;t acknowledge vaults in their<br>proposal, th=
ere is popular demand for CTV on the basis of being both a<br>simple vaulti=
ng mechanism[5] and a necessary ingredient for more ergonomic<br>vaults[6].=
 Much of my own professional grounding for supporting CTV stems<br>from thi=
s use.<br><br>TEMPLATEHASH&#39;s lack of witness v0 support hampers this us=
e, and prevents<br>many industrial users who are (for varying reasons) stuc=
k in a wit-v0<br>world from making use of the simple vaulting primitives th=
at much CTV<br>interest comes from.<br><br>[3]: <a href=3D"https://www.unch=
ained.com/blog/bitcoin-address-types-compared">https://www.unchained.com/bl=
og/bitcoin-address-types-compared</a><br>[4]: <a href=3D"https://research.m=
empool.space/utxo-set-report/">https://research.mempool.space/utxo-set-repo=
rt/</a><br>[5]: <a href=3D"https://github.com/jamesob/simple-ctv-vault">htt=
ps://github.com/jamesob/simple-ctv-vault</a><br><br>To date I haven&#39;t h=
eard any concrete downside of including witness v0<br>support for an opcode=
 like this other than &quot;it&#39;s marginally more to<br>think about duri=
ng review.&quot;<br><br>The reality is that we&#39;re still living in a wit=
ness v0 world; there will<br>be significant amounts of wit v0 traffic for t=
he foreseeable future. To<br>throw that context aside is to ignore many pot=
ential users.<br><br># Non-blocking gripes<br><br>I&#39;m disappointed by t=
he lack of consideration for the succinct &quot;deferred<br>payout&quot; or=
 &quot;congestion control&quot; use that is provided by either bare CTV<br>=
or your P2TH (&quot;witness v2&quot;) patch, but that isn&#39;t surprising =
given the<br>unwillingness on the part of the authors to acknowledge the po=
tential<br>value of that use.<br><br>Even though it&#39;s disappointing to =
me, its absence here wouldn&#39;t hold up<br>my support for the proposal.<b=
r><br>---<br><br>I&#39;m glad to see progress on the prospect of making bit=
coin&#39;s script more<br>useful, thanks for your work.<br><br>James<br><br=
></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/CAPfvXf%2BE0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAPfvXf%2BE0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA%40ma=
il.gmail.com</a>.<br />

--0000000000006e399406399246b6--