From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 11 Jul 2025 11:48:30 -0700 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uaInN-0007XO-TT for bitcoindev@gnusha.org; Fri, 11 Jul 2025 11:48:30 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-2e9b1f85b2bsf2666914fac.0 for ; Fri, 11 Jul 2025 11:48:29 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1752259704; cv=pass; d=google.com; s=arc-20240605; b=OGPoc81Fx7e7VodkME+WnO+tYypxwbNwX6f+nak6MCYjAkm/Q6V8FToSoVKaeEoROD xy/acI+AyJbvuohFVu54Rfn1Du/A5Vlw6Ew4eYJY7tkdI65f0gYRtS0/gHONiJDDElNZ Jv3l3gxqVspfiU0luKf1smMQq/RbLhfUwSO9PSG3i94nGdxmEUohwJgpRnKXEnDYGf+j 47vA869iJJW0ndwZpicJPzWt2sVJae2xs6Jk/Zi8/E+QmUIEoFLs6gDagmP52VFhAzai zP43GHDM4PuZZdB0RZMkxNXnPFyXTnarS9NaQnm6TxzQZbYfMQdX81Uj1DkYCYqTbKBk ZzLg== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=4p8udwMCasT9M6dqToXPGyaO5p8CuZKsuvvVTWdILEo=; fh=8d9t483TS9r4bg/GeK4q16zz1DaZhBOixi3Dfaov7g8=; b=S529GnbCjhj6AX+tdGlPhED+ONlhVdl5iRnujQ3QnugO7cDEgbH2xfkmr5RBEL2oJs 5+0UISkqTJ7yHlIa6a3ykK5WGB1B2KO+BZNyxTBVdoYSqDlXmqGMb+RVONNuOtq5guy1 /dBOARgo+WIIGyJ72LfObm3QHgnBy7ij1RXSwSqGvcDJn5Z6AC3w9+bDjq+e43NN2IxE aX4teXp5mo+4H+HhpQ/2xhOL3Gi/3uNuFqLTWDb/OuUhVENmrm69o7NA3eDaL45KOD+P j8ASYFqdbsnyDuqqLX5Usq8xA4R2lqrsIcNrPydrOQVp0gsjcM8M9WzduJcZKAufGyRC MdIw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=bgPgI3I8; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1752259704; x=1752864504; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=4p8udwMCasT9M6dqToXPGyaO5p8CuZKsuvvVTWdILEo=; b=pArn13wDgEo9ESQ7wUoOr0zJhMZRNiUTOPxR9Ke6frw46BCiherQapeXcmxizWbhZH QEXlEuRyTSvXg8vCqIWbdcO78l3oGb4Cl/EWqP2GvkXeXOVQgO4wyhac4kSTApKLaIk8 fZewesR8xXAC42uQC5JKM4JRdt8/CVytKx/wYzKOLZXdDrdtcBCSvdd+8PArjDOneoiv vxgX7J229pgRvkMrcUi9sPbvHYBcY2SezW+iULzGgfIMJp/YCqNxnPoDKybHENnkCpoi /vguEie1WLm9Im3lg7DiXbRU87HX5CwLy3OV/k8AyoflprJBWerZrNBoqorBSAudR9Vq 72Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752259704; x=1752864504; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4p8udwMCasT9M6dqToXPGyaO5p8CuZKsuvvVTWdILEo=; b=G4fwN4H7fQVTmnRzEfVD+FeG/+jv9ST0YLkudXblfS+g1eNgdz2KRcsCi0Vlp59ciW I09IZtvjm2dPWuCQuwsOubGNVFkVMBfbwUv8SpQ4KWnh1n7iB82AC/Yi50loSoJjgYMA oGu5rhs1ngX9KcDoUbMPCx4hMA1k2gS0iy7QH/QdT4iiX4/rpmTPVUNz0gbKfz604/qq B8a1POyNuNJZoCf78n18Uk2fdDt0k2IjRu5xjP5AvV/eIcZTm3m0BAo+TK7KjlHv2Ru3 fijsW6QrWuNUpBbQEyreamGUMmW7xZH36ziGrP82FPd0TBH1+I/yIqDsQmsUOdLGM0N9 LP8Q== X-Forwarded-Encrypted: i=2; AJvYcCWwSYdiiAXCUPMmrcX9LzRXSdWf83tiNG2mnfp2q15/C01vKJssIiDlLWXzIxBuEBtLMBE2kHV5jblr@gnusha.org X-Gm-Message-State: AOJu0YxMlbN9xwaD044CDSPihoSYcxjLoKiRjMHmfsVoDGEAUNJHQFgr 7KdmT8aDYO/z0CeGLXThR6KvQFScKR09U5TctTsHL0noLO7vSiOUFN47 X-Google-Smtp-Source: AGHT+IF6ysly9W5Td3oLyt+3sheT3uaLG5H4zQjRMsap2YekDQYTjmviheV6eqfus0rGODYZ+Ro46g== X-Received: by 2002:a05:6871:a112:b0:2e4:4617:f6e1 with SMTP id 586e51a60fabf-2ff26e79dcamr3335938fac.2.1752259703542; Fri, 11 Jul 2025 11:48:23 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeoGk0yWFvg414lappG1GsapWsoejYQKDOmxPZvV0MVVQ== Received: by 2002:a05:6870:3054:b0:2c1:8546:7864 with SMTP id 586e51a60fabf-2ff0bcc7901ls824106fac.2.-pod-prod-07-us; Fri, 11 Jul 2025 11:48:20 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUphYo38UkbQ7QDNB0UcvP2NkH/bWmu2MPmoI1t2H/+X909fl1jJ5v0cG9BBPSb0KGurx/i6IFnzicc@googlegroups.com X-Received: by 2002:a05:6808:168a:b0:406:6e89:499f with SMTP id 5614622812f47-4153a27fef0mr3411628b6e.35.1752259700449; Fri, 11 Jul 2025 11:48:20 -0700 (PDT) Received: by 2002:a05:600c:6089:b0:450:ce23:93de with SMTP id 5b1f17b1804b1-4538ed863cams5e9; Fri, 11 Jul 2025 11:37:42 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVDUkUXd1KCFK7NfwO+gj1b0+iYc8u7grB6df54litBASc2VHjVAxFZJ0D2u9CZW+lPCHCD9UKYQ7Jc@googlegroups.com X-Received: by 2002:a05:6000:2806:b0:3b3:e29:bda7 with SMTP id ffacd0b85a97d-3b5f187d355mr2903866f8f.9.1752259055146; Fri, 11 Jul 2025 11:37:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1752259055; cv=none; d=google.com; s=arc-20240605; b=JHHx+FqVW1eGi/e5deBYdj3My9+eex2fZ2vbAXRetzB+YW81JCKa+a41KRc1ygMUne aSW+Js08cFIOTWHSq/PtduTk6Djj7C5iLltMEtnyMUmAs0YeI6DCFhzfDu0QEoIHAoBq X6BMJrAydpyQqpYcfqHxQw18NI1auwYR1LrQ3qr0FrZm4yxdd5ZVrNJ3dH5/SQFlTs/v cH3bEsEGj1aDYK5E6X67MVeMEqB+swXvqGkRpib+Ylgd1ea6Bwd8/Gf5QGR1TKMVppky 8MOLmWgmuEZ0gwnYzs7khJrzdTfnLO3Ip24EAImizP8TSC2QShQkszezeHkHwX18/nbN Mjcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=2za3/C6ASLTSdD5RbdySi8fGO/pUkU4IM76d3MkVAo8=; fh=2GrigbsrOQbyEDwLakImaK9x8AKyAYXirBaHYK+psY0=; b=bou+vMsVtfwhZaJoV2fKolE9YciFKu4zhO19Ub36705sM/Mw/Yk8cxDnn95dJJp4ex lleRhtpi0hvdCWsnojORZU4T60pX50yHbtSQ/d3wRrPJAr6mJuSEY47xL5Oddt8BrVV2 vgnT70K3DFZRSfmPqp4p3VlKy5JULCzlNHdDg9bQcBmYJm+hlQm+Wq7hTkIwaZh9jQle Ow2okIStSGxTjX5EjE+XDid5AYAtjH+MBoPsHyHDm/hZjyyDqfiu7bIro+glc89zBofD bFunhJV3tfxwVtr49tKChaFM4mfxsDWI4AtouLZYByjpEBjkeYhR6ybGM4QfRmRB/VDw A4Vg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=bgPgI3I8; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch. [185.70.43.16]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-3b5e8e139c3si126765f8f.8.2025.07.11.11.37.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Jul 2025 11:37:35 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) client-ip=185.70.43.16; Date: Fri, 11 Jul 2025 18:37:31 +0000 To: James O'Beirne From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Greg Sanders , Bitcoin Development Mailing List Subject: Re: [bitcoindev] A Taproot-native (re-)bindable transaction bundle proposal Message-ID: <_POzkO7sHDURx6skGAWsrxN_UUtN_6Ak6donzVhmzYzAV6Ej22jBnE2baxM_WtqxW2RNvDjze72kOVgowNhqGSJ1dg5m_HTO3FuG6QM5daw=@protonmail.com> In-Reply-To: References: <26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 3aa9fe5dd3be553a257cddb040f60faa4ce7a3f8 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=bgPgI3I8; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) Hi James, Thanks for your interest in our proposal. You point that the annex commitment may prevent someone who pre-committed to a spending transaction through OP_TEMPLATEHASH from using a different annex at spending time. Annex commitment is important for rebindable signatures, but also for committing to the spending transaction: it allows to be forward-compatible with future uses of the annex (from proof of publication not requiring an additional signature to being able to pre-commit to any consensus meaning the annex may be given in a future soft fork). In this regard it is no different from other fields of the transaction that are today defined at spend time and OP_TEMPLATEHASH would allow to pre-commit to. You list 3 examples where you claim a user who has committed to the transaction to spend his utxo, turns out to be willing to use a different annex than the one committed. The first example lacks citation: could you explain the exact scenario with CISA here? The next two examples i don't think make sense. First you point to my amounts check idea, but these only ever make sense if you haven't already completely committed to the spending transaction! If you have pre-committed to the spending transaction through OP_TEMPLATEHASH (or even OP_CTV for that matter), you have already committed to how the value from this output will flow into the spending transaction's outputs. Same for your third example, the SIGHASH_GROUP idea: what's the point in having a signature that commits to part of the spending transaction's outputs when all of those outputs are already set in stone through an OP_TEMPLATEHASH commitment? I think a better argument for your position is that pre-committing to the annex weakens the upgrade hook it provides: it could arguably increase the risk of invalidating someone's coins if/when the annex is given meaning in the future. I would object that first of all pre-committing to the offending annex only marginally makes it worse compared to pre-signing it, and more importantly if we think people would design software that create such transactions in spite of the very clear warning "users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS" then all bets are off. By this token, users may commit to other upgrade hooks: a higher nVersion, future Segwit versions in transaction outputs, etc. Your second main criticism concerns the lack of Segwit v0 support. You start by cherry-picking some data about Taproot's usage, so i'll ask you to please keep the discussion honest here. You state that between 0.1% and 0.75% of all bitcoins in existence are held in P2TR outputs, and use this figure to conclude the "overwhelming majority of **value transfer** in bitcoin is still happening in a pre-Taproot script context". This non-sequitur reads as though you'd already settled on the conclusion and were reaching for data that might appear to support it. In 2024 and 2025 between 20% and 40% of all onchain transfers used Taproot[^0] (vs between 1% and 3% for P2WSH). Even considering the value of these transfers gives a pretty clear trajectory: since the beginning of 2024 the percentage of BTC getting locked into P2TR outputs quadrupled from 2.2% to 8.5%[^1] (the percentage for P2WSH was steady from 16.4% to 16.8%). I strongly believe our default position should be to only enable new features in the latest iteration of the scripting system. While Segwit v0 fixed the most important quirks of legacy Script, Taproot/Tapscript finishes this work by removing the remaining instances of quadratic hashing, enforcing by consensus more malleability-related standardness rules, being compatible with batched validation today and a possible future CISA, and finally presenting the slight but still good to have privacy improvement that all outputs look the same before being spent (and sometimes even after being spent although it's harder to achieve). We should not provide new features for an outdated scripting context unless we have a strong reason to. I don't think you provide a strong reason not to stick to Tapscript. You claim that many industrial players would not be able to use OP_TEMPLATEHASH but you don't back it up with anything demonstrating those companies 1) desire to use OP_TEMPLATEHASH and jointly 2) are somehow unable to upgrade from P2WSH to Taproot. Regarding your non-blocking gripes, let me state that P2TH is still very much on the table (like any other change really). If an optimisation for congestion control is really important, using a new Segwit version would be worth it, and the implementation is trivial (and is even more so if you end up being correct regarding annex commitment). We are just all three of us very unconvinced that it is in fact worth it, as are many others it appears. Best, Antoine Poinsot [^0]: See https://mainnet.observer/charts/inputs-types-by-count and https://mainnet.observer/charts/output-type-distribution-count [^1]: Hovering the percentages for dates 2025-07-07 (closest i could get to today) and 2024-01-02 (closest i could get to 1st Jan 2024) at https://mainnet.observer/charts/output-type-distribution-amount. On Thursday, July 10th, 2025 at 9:04 AM, James O'Beirne wrote: > 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. -- 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/_POzkO7sHDURx6skGAWsrxN_UUtN_6Ak6donzVhmzYzAV6Ej22jBnE2baxM_WtqxW2RNvDjze72kOVgowNhqGSJ1dg5m_HTO3FuG6QM5daw%3D%40protonmail.com.