From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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" Date: Thu, 10 Jul 2025 08:24:17 -0400 X-Gm-Features: Ac12FXy5-e-hNsyWsD1_SrATpvKVDrQa8HlHlXAewEb6PUkaMcYQILn6dM1wLI8 Message-ID: Subject: Re: [bitcoindev] A Taproot-native (re-)bindable transaction bundle proposal To: Greg Sanders Cc: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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
Hi Greg,

Congratulations on the BIPs and happy to s= ee a concrete counterproposal
from you and the coauthors.

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

# Annex commitment

TEMPLAT= EHASH commits to the annex, whereas CTV does not. I think this
poses som= e potential issues.

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

> Until th= e meaning of this field is defined by another softfork, users
> SHOUL= D NOT include annex in transactions, or it may lead to PERMANENT
> FU= ND LOSS. [0]

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

The germane thi= ng in this case is that the annex contents are specified
at *spend time*= , whereas the CTV or TEMPLATEHASH hash must be
precomputed before the cr= eation 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 us= ed in conjunction with
TEMPLATEHASH (since you have to anticipate the co= ntents of the annex).

Some conceivable uses of the annex that have b= een floated are:

- for cross-input signature aggregation,
- for a= mount checks in aggregate vault operations[1],
- for implementing some S= IGHASH_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 bund= ling a commitment to the annex with TEMPLATEHASH, it
would seem more pru= dent=C2=A0to defer treatment of the annex until we've
decided what i= t is. It might ultimately make sense to have some
orthogonal opcode (&qu= ot;OP_CHECKANNEX" or something) that allows script
authors to expli= citly specify annex expectations.


[0]: https://github.com/bitcoi= n/bips/blob/master/bip-0341.mediawiki
[1]: https= ://github.com/bitcoin/bitcoin/commit/2c63a983ddb7f2b7eaaedc8313fbeaf8f7c1b1= 28
[2]: https://gnusha.org/pi/bitcoindev/20220305055924.GB53= 08@erisian.com.au/


# No witness v0 (segwit) support

I= think the lack of TEMPLATEHASH's availability in a witness v0 scriptcontext will significantly limit its deployability for at least the next<= br>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 M= ay 2025[3][4]. This is nearly four years after its
activation. We can= 9;t say exactly why users aren't upgrading, but the
reality is that = the overwhelming majority of value transfer in bitcoin
is still happenin= g in a pre-Taproot script context.

One concrete impediment to Taproo= t adoption among custodians is the lack
of native HSM support for the Sc= hnorr 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, th= ere is popular demand for CTV on the basis of being both a
simple vaulti= ng mechanism[5] and a necessary ingredient for more ergonomic
vaults[6].= Much of my own professional grounding for supporting CTV stems
from thi= s use.

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

[3]: https://www.unchained.com/bl= og/bitcoin-address-types-compared
[4]: https://research.mempool.space/utxo-set-repo= rt/
[5]: htt= ps://github.com/jamesob/simple-ctv-vault

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

The reality is that we're still living in a wit= ness v0 world; there will
be significant amounts of wit v0 traffic for t= he foreseeable future. To
throw that context aside is to ignore many pot= ential users.

# Non-blocking gripes

I'm disappointed by t= he 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 po= tential
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 bit= coin's script more
useful, thanks for your work.

James

--
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/CAPfvXf%2BE0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA%40ma= il.gmail.com.
--0000000000006e399406399246b6--