path: root/46/d05d097b37d98e23bb042282766333e32d179b

Delivery-date: Thu, 10 Jul 2025 02:35:16 -0700
Received: from mail-qk1-f184.google.com ([209.85.222.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDVJRHEUX4BRBSMSX3BQMGQENWJN2CY@googlegroups.com>)
	id 1uZngR-0007e9-VK
	for bitcoindev@gnusha.org; Thu, 10 Jul 2025 02:35:16 -0700
Received: by mail-qk1-f184.google.com with SMTP id af79cd13be357-7d0981315c8sf60356485a.0
        for <bitcoindev@gnusha.org>; Thu, 10 Jul 2025 02:35:15 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1752140109; cv=pass;
        d=google.com; s=arc-20240605;
        b=PyoTuoKbjBqOny6AcPj7/BifbEiqjC5zrKnAK5vy8DwF6f9W4uSKQRbF4+mnJOjZZK
         5b7enVQbs6CIt6j9wgDYCYgqhL3yXH8KN+Yp6iXJwgALTuWWvNDVPFSVhE/QiJcnugwU
         v2Cf/SRwEJVSFK1tDdSm+hEYN3BSy2o5PrB53PfYcxNMiiJ1HsJM24S4HM//1LBOzY21
         pNg+9OGYn34e4yKN2Zy3/rF4b/GdVM8QjY2INCLfJhg8dniBg6hWyESxyXEGJuKgSN4S
         27aGAJb4UwT1AU0vEBfcVnvadvES9Xlge1qt7sJ2vZ8NJXwK4nr2ZNp4+WpNhXsE7QyV
         OQ0g==
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:in-reply-to:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:sender
         :dkim-signature;
        bh=+VV4Jdj0ynKIPwiI7BXejSSCQ3tyvb5G75SjI3biNRA=;
        fh=rtzyxKhMrCUAA3ZCjVUEWiQ/7jnNjVGG9YczmgjOpQo=;
        b=lVL75wxgCf/pYbG4GEHSzqD6dCVAl0W7lh2uMJhYDgJTbS3jVB8KW5OUyGT6a6Izsk
         XirnMSlSwhoL9BuxeIx0BWNzzSE345Vyr/Pvfw0o1ICe4V1LhFsZ1qPy5Brer+3YJN8J
         lpQSma92TO/p5MSU7An6+h3NcnOf8zFikMYUFEKlL7a65oib3+G0k10KxBmwL0fbMIad
         0e0g6IPwWFgQiCXmp5UkEJLU3GzzOncLTfeDcwzjbvCJO5xokhsuV8684MarS+LeNqOg
         WzKLWm4R8KXyQSAaTN6uJnacZ9torHJ+irjXlSe+0Ei4wSIUrP5KsDuH/RYEgpyasykW
         lTYQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@reardencode.com header.s=mail header.b=VuABdyJg;
       spf=pass (google.com: domain of freedom@reardencode.com designates 206.125.169.165 as permitted sender) smtp.mailfrom=freedom@reardencode.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=reardencode.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1752140109; x=1752744909; 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:in-reply-to:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date:sender:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+VV4Jdj0ynKIPwiI7BXejSSCQ3tyvb5G75SjI3biNRA=;
        b=nELo9+yUYzJf3b37w8wotNV4UA7jCgbyNtXeGFOjibE/UCb36D1XaCm+63s6dSv+1a
         h/pKlm/G5712NvNcCgyGS3Iwlxii9/ziqOkxdSYYzDx2z84CgCO9E3jXy9+V4UqItbjL
         OChmZXaLnDnSshdmNc7YRa+/ZGg2pTD8vTiwdoOLUMlUfPi34Bftyp816xp7xith6xAv
         HlXiVfkojcdgK47LDQth3jLnhEr44Banafg5sNRXIIQvGtWNz7G2S+jl+uFUQa/P32bR
         QqKxW8i88w+NzBKEwqPDboaTwn6feotm37W1raKSWpckrTcWt/vRvSW6Q+JxebvxpIrD
         PvOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1752140109; x=1752744909;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:in-reply-to:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=+VV4Jdj0ynKIPwiI7BXejSSCQ3tyvb5G75SjI3biNRA=;
        b=VDU/s+LoTaM7sClsY2jaLmYU8bpzCLqnfxpn9FsrjtufkrYIJwdnQRPzvabO/Aycrj
         j39JZBKvEih/oziGpdKh+BHd+GIbqzTrLF7KWJkdEzQThISbKv4ok0XaqglRmx/sPY4j
         fRdPkmyDlH9ofamdgqr7FQa9lkSCtXMGF54Id71y0AvlHCd8uhgQIqTKyFbx1WvQYhj0
         CNpQ5x8vj8tyG3JfTPXWKauRh9sti55vBoWzCMVh3JwopWIckaBjvKO3Err411pkg/Sg
         tHgn3drLuXt9Sv/U0EvDPgO+HaxWO5rQ4ukxX+eVHrMCjctSccvJ7Iv8iMbrh9YrLtrI
         CnaA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUoT7+UrSvCktbJRDFuiO98/nAHoGx7RmvgA9smRfagmmpOltA++bpwTgkf7TgV0R3qUXgzR755t4M7@gnusha.org
X-Gm-Message-State: AOJu0YxRrJCOsM/kjogSM9q+huRdQJMUEAndEsrv5/7HSwt6YQhroLDH
	ROlf8mewcUtcJOSy06FX++qcinHUzAAu5+P2oDADMGym+vtXKrvniF0G
X-Google-Smtp-Source: AGHT+IGoXGWGiqlQHv9X9IAFOkGDujGNLSjY2RkhXDzHGrMBdtOO8qsVPOtApmyHkBUso01IYzuRGA==
X-Received: by 2002:a05:620a:4586:b0:7d3:d17c:e9e3 with SMTP id af79cd13be357-7dcccbb7425mr294711085a.53.1752140109060;
        Thu, 10 Jul 2025 02:35:09 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeEa+s9yidLaeGYSdwscISsGBGCvMdxIxtVx+Y8F5yupA==
Received: by 2002:ad4:5f4a:0:b0:6f8:afe1:86df with SMTP id 6a1803df08f44-7049559e336ls10425166d6.0.-pod-prod-08-us;
 Thu, 10 Jul 2025 02:35:05 -0700 (PDT)
X-Received: by 2002:a05:6214:31a1:b0:6fa:cb9b:a793 with SMTP id 6a1803df08f44-7049811ff80mr21536756d6.26.1752140105589;
        Thu, 10 Jul 2025 02:35:05 -0700 (PDT)
Received: by 2002:a05:6808:4a11:b0:40c:fd76:4b4 with SMTP id 5614622812f47-40cfd760570msb6e;
        Wed, 9 Jul 2025 21:44:08 -0700 (PDT)
X-Received: by 2002:a05:6808:5182:b0:404:a28c:ca4b with SMTP id 5614622812f47-413f54f64damr1033222b6e.20.1752122648343;
        Wed, 09 Jul 2025 21:44:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1752122648; cv=none;
        d=google.com; s=arc-20240605;
        b=hG4mdpC4wqGD8gwKAJqg/q6Y30B2cct/M+iGiOgtlj8y7o+UboE3w5I6X544s5L6WN
         NrR6qGRl44Sq2GDUkUxyUlAMDwyL1UFrR8VL/LangJ1K/LQovcVKALDP8WqNO+4M5nJO
         mCFBu+0HM4ivWz09LF/uy4NRRfpZtEXiwsamE+4JhQhO9iqOjfy/nNtmMxdR+/mM9Ybc
         K10KT0O4NZ+3uZ6GafwOoRXaum9qq0+WO/HgJeX8VlthDaiZf680Nd7u5Se7VjdBoykj
         dWqIr6fujS6GnppSUI3z9O5OncRxSV11ES4KB8QNyaOhcWDNyQ74e8P+rBsGz9iYL6/j
         cE5w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:dkim-signature:date;
        bh=vKx5Q75640l8tq3/rIDRDJK5FM+k6+u5o4uzmOEdHE0=;
        fh=sjkP8zjFS5lFlY+fNUHD47XPXx06dShKmNgWs4F+if8=;
        b=MD7R03CfyKUQ7tVBWuQq32aCyFBV5PGZPOMHfDPp+o0knGAWlLbXCKdzRw9DQ0Sybx
         KDEfz3QnxRFz1mFUyIUpNfeY7yU57LCXq4A844WgMJd6wSuj+ESlaSY4LOmYmj8KjFfu
         SonUkxckU2CgY4t1HG8FhGKU7T/IKlH7laW0uzWdy4+Vh7/kd0vyW7XK5xrs99Iu4RY2
         b8jHswVg4usH4hX4oK4MP49vCQwJ/n2gbKZIStp8fLAXhLXox02hc8ycObnC8FmOLYb/
         XQnRTAkp3fqw0ogdTFbv8MIOsMt4a0Rv92E+jHtLYAEl0ULskeRAjdKK47PbQNk5bPW0
         PtYQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@reardencode.com header.s=mail header.b=VuABdyJg;
       spf=pass (google.com: domain of freedom@reardencode.com designates 206.125.169.165 as permitted sender) smtp.mailfrom=freedom@reardencode.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=reardencode.com
Received: from mail.reardencode.com (mail.reardencode.com. [206.125.169.165])
        by gmr-mx.google.com with ESMTPS id 006d021491bc7-613d9ca53a6si28934eaf.0.2025.07.09.21.44.08
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 09 Jul 2025 21:44:08 -0700 (PDT)
Received-SPF: pass (google.com: domain of freedom@reardencode.com designates 206.125.169.165 as permitted sender) client-ip=206.125.169.165;
Date: Wed, 9 Jul 2025 21:44:00 -0700
From: Brandon Black <freedom@reardencode.com>
To: Greg Sanders <gsanders87@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A Taproot-native (re-)bindable transaction bundle proposal
Message-ID: <aG9FEHF1lZlK6d0E@console>
References: <26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com>
X-Operating-System: Linux 6.6.36 x86_64
X-Original-Sender: freedom@reardencode.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@reardencode.com header.s=mail header.b=VuABdyJg;       spf=pass
 (google.com: domain of freedom@reardencode.com designates 206.125.169.165 as
 permitted sender) smtp.mailfrom=freedom@reardencode.com;       dmarc=pass
 (p=NONE sp=NONE dis=NONE) header.from=reardencode.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.8 (/)

Hi Greg,

First, thank you for working on these important consensus changes.

## Comparison of hashes.

Compared to CTV, TEMPLATEHASH drops nInputs, nOutputs, and scriptSigs;
and adds the taproot annex presence flag and taproot annex.

Compared to SIGHASH_ANYSCRIPTANYPREVOUT|ALL, TEMPLATEHASH drops
hash_type, _this_ sequence, key_version, and codesep_pos; and adds _all_
sequences.

This puts TEMPLATEHASH in a pretty comfortable middle ground between
CTV's hash and ANYSCRIPTANYPREVOUT's. It indirectly commits to the
number of inputs via sequences, is capable of creating stable txids with
1 input, and makes no concession to constructing the hash on the stack
nor to legacy script.

## Capabilities

As has been previously discussed, all protocols that are possible with
LNHANCE are possible with CTV+CSFS alone. That remains true with
TEMPLATEHASH+CSFS. The other two LNHANCE opcodes are optimizations. This
proposal includes INTERNALKEY for its ability to save 32WU in common
protocols where the taproot internal key can be reused in scripts (e.g.
Lightning Symmetry). The final LNHANCE opcode, PAIRCOMMIT, is omitted
from this proposal and its optimization capacity is enabled for certain
specific cases by TEMPLATEHASH committing to the taproot annex. For
protocols which need to bind and make available one additional data push
with a spend (either pre-committed or spend-time committed), this is
sufficient.

One comment on the commitment to the annex: In my X spaces today, we
discussed whether this restricts future uses of the annex in practice.
We concluded that while it does eliminate certain perverse ways of
implementing certain annex extensions, it does not seem to eliminate any
possible protocol application. E.g. once we have an opcode that is
expected to be used in pre-committed transaction scripts in the wild, we
cannot make a consensus rule that requires all taproot spends to have a
non-empty annex.

## Efficiency

Comparing this proposal to LNHANCE and other earlier proposals in terms
of its efficiency for implementing common proposed protocols: unless a
protocol requires multiple data commitments (e.g. a complex delegation
to key_a after locktime_a or key_b after locktime_b), this proposal will
be within the range of +1WU to -33WU.

For protocols that could have used bare CTV, this proposal is 69WU less
efficient, but as of this writing the only protocol that is known to
take advantage of bare CTV is congestion control trees. I am not aware
of any concrete proposal to implement these. 

For protocols that do require multiple data commitments, each additional
data commitment requires an additional pubkey and 3 signatures to
implement Key Laddering. Adding PAIRCOMMIT or CAT to consensus would
eliminate this.

Concretely, I believe this proposal will be 32WU more efficient in the
Lightning Symmetry uncontested close case.

## Closing thoughts

I'm happy to see this tightly scoped tapscript only opcode package
proposed. As of this writing, I do not have any technical misgivings
about this selection of opcodes and functionality.

I hope to see this proposal garner review from the broader technical
community!

Thanks again for your work,

--Brandon

On 2025-07-09 (Wed) at 11:19:22 -0700, Greg Sanders wrote:
> Hello all,
> 
> This is a bit of a follow-up from "What's a good stopping point? ... 
> CTV/CSFS..." from [^1]
> 
> > There has been several objections to this proposal, which we can group 
> into three categories:
> exploration of alternatives, demonstration of usage, and design of the 
> operations to achieve these capabilities
> 
> For this e-mail I would like to address the third point proactively: design 
> of the operations to achieve these capabilities.
> 
> Antoine Poinsot, Steven Roose, and I have been working on a familiar, yet 
> concrete technical proposal that focuses on three well-understood 
> capabilities:
> 
> 1. "Next transaction" capability, ala BIP119
> 2. "Verify signature of message on stack", ala BIP348
> 3. "Push taproot internal key onto stack", ala BIP349
> 
> These first two capabilities can offer radical simplifications
> to well-understood systems when combined. The third is a simple
> update that dovetails with the first two.
> 
> The BIP text is 
> here(https://github.com/instagibbs/bips/blob/bip_op_templatehash/bip-templatehash-csfs-ik.md) 
> and PR here(https://github.com/instagibbs/bips/pull/1), with full 
> motivation for this particular bundle and rationale discussing 
> alternatives. Our main contribution is a fully specified `OP_TEMPLATEHASH` 
> as a drop-in replacement for BIP119 `OP_CHECKTEMPLATEVERIFY`. 
> `OP_TEMPLATEHASH` is a simpler and more modern implementation of the "next 
> transaction" capability. It differs in committing to the Taproot annex and 
> being otherwise Taproot native, which allows us to:
> 
> - Use the `OP_SUCCESS` upgrade hooks in place of legacy `OP_NOP`s and be 
> able to push the template hash on the stack making the flagship use case of 
> rebindable signatures more efficient.
> - Re-use the existing pre-computed Taproot sighash fields only instead of 
> introducing new ones (substantially simplifying the implementation and 
> review of the specifications).
> - Not commit to the spending transaction's scriptSigs (which are both 
> unecessary and may incentivize ad-hoc uses of legacy input scripts as 
> programs).
> - Not unnecessarily modify the less well-understood legacy Script.
> 
> Another notable difference is the lack of "bare CTV" analogue, which is 
> implemented here(https://github.com/instagibbs/bitcoin/tree/p2th) but left 
> out of the bundle due to lack of demonstrated utility.
> 
> The BIP for `OP_TEMPLATEHASH` is 
> here(https://github.com/instagibbs/bips/blob/bip_op_templatehash/bip-templatehash.md) 
> and a complete implementation is provided 
> here(https://github.com/instagibbs/bitcoin/pull/3). The bundle itself is 
> heavily inspired by 
> "LNHANCE"(https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376).
> 
> We are hopeful that an opcode/implementation-focused discussion can be held
> concurrently with other efforts such as discussions as to whether
> or not this capability set is a good stopping point, including whether
> this bundle is worth implementing on its own at all, as well as what
> level of assurances we should have as far as tooling and proof of concepts
> is concerned.
> 
> Best,
> Greg
> 
> (1) https://groups.google.com/g/bitcoindev/c/-qJc1EWQzY0

-- 
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/aG9FEHF1lZlK6d0E%40console.