path: root/e0/f7b3ac0b7ba0840aea8bf4d73840f7758672ad

Delivery-date: Wed, 30 Jul 2025 19:01:11 -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 <bitcoindev+bncBCJNLJPWXAIBBXE4VPCAMGQEJCSBYFI@googlegroups.com>)
	id 1uhIbW-0002Ku-G3
	for bitcoindev@gnusha.org; Wed, 30 Jul 2025 19:01:11 -0700
Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-2ff8a9716d2sf2251463fac.1
        for <bitcoindev@gnusha.org>; Wed, 30 Jul 2025 19:01:09 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1753927264; cv=pass;
        d=google.com; s=arc-20240605;
        b=NS/Ee085Ns9NZbJIXgtVBLaw8g01P4GeLLXy5bpMpyJiOFGCjs4ikK/FYInyst389V
         xIzi5AYU+bMz3kugbImrZob98YmMCZ0bYEf0VwYDhlWPn8YDbJh7lnVf8RvRNowMFsm2
         UD0RiwUo7EpZj44zdhY84Ll9vpObpKS67ETBy2I9lrMIMwrXzUOhtycF034sm9gPzpUP
         D0e7Glj/SXKJBMrw73+bt33zzH/M2QPKTcCxeEzugkV1tMd5fP3zC3AG3R1q9qiuApaL
         wNjMIId2eTlBEUkf8u6nLmw24qKZwWFmdT+bgp4hJVPdU0qik1vcPyOTP/OykhaH2TUH
         g0Vw==
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=OwzKtU8Bcptz22fmYUZpg/RVribGh8N7Z2KBPgCAfBY=;
        fh=Y372mxB+LUniwDeILMqKKRdTDvjXtP0CHEcE2zO4TWw=;
        b=DG9b38GbJdmC0jhtANSTxh2IWWon8W2P6/7AMmBQpu8D3L+LtMNgXk830pdOaxKUkg
         CQvxXmGQlFHWYod/9x63+sGDnqVQsZUTsQmvLotLBuI1nB8PYoGiiWbuR1XNsmtDqKWo
         MERykEiLTkcc3eWODCEPplCD+NvkaObghageRAZZhOq2kT8m91/enS3G6NBt/L0baBAu
         pu+PO7MGV52HNdHhXoY/PpZZX/tqgHgVPc3sADkbKRegBrPaYAX+xfO7OYsoeqS8IwDA
         RYSQg1HpAWgOiS/YYlLLD83XvvsLCMnM5qtpatPvH6W1/wZHUbCl2LnLaR7QOQrpSMik
         yE+g==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=F7Tcfmm6;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) smtp.mailfrom=gmaxwell@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=1753927264; x=1754532064; 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=OwzKtU8Bcptz22fmYUZpg/RVribGh8N7Z2KBPgCAfBY=;
        b=LM/kTxTHNUmyhoY2RS4q4TsftraiX+wqsDCATNtBlZ2DUpJ9yKf/Qe7AWNw7SrF69c
         /VY4ky8LaytTIEra93aMQrS64Pq2XnSqjikAyfI+/dc1XH/8A2d5bhWNqJlrGHpa9+kP
         Bw60Mww8T3ifV9RjfrUqZLKiUmIzOAOfy8EF8WiwvDHPcqFKjYPe/ofnytec/CV4MZUU
         2NYE64sapmXw/LBXx7vymMSXoVjw4xdCXgPKdxe1xRvPfG5uE9/IRPQpfIw3j8CeYAmS
         6ZgwuxcaP5Jet4ZtHyIRNDBeRhs1W4r0UZb62LYr40pDER9zWGqCI/XABxWClVJz0i32
         VRzw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1753927264; x=1754532064; 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=OwzKtU8Bcptz22fmYUZpg/RVribGh8N7Z2KBPgCAfBY=;
        b=R+w62w8vcJqfQ9vaNadQLbBOSzzkrMIRucuM8rdvA61IlOwXuozooCkyc/9YpmAv+o
         V/P7LTYEDORlUOgd8f3uPjSFn/Do4mQ133qkct8MrosV1Yzwdsip3GUjqH1gC4pW4sb/
         FbR0tem/yq9au4cr508n+n/icsfaaXnqssFukVl/AaHAYgAUQlPmrZjbSTL7It/Uoleb
         DQp/ZQbD5Q8w8rAzrnJ72fBHcI7a2j/vS+rNZUpddzatC83yUyQvGFs+coFbecVOFeWK
         TTF698hrrqluKlim65avF4SYOCHwyag3+8Pn2DejgsCz4xSH8Zjf4rrIug6BWsIEVsib
         p62w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1753927264; x=1754532064;
        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=OwzKtU8Bcptz22fmYUZpg/RVribGh8N7Z2KBPgCAfBY=;
        b=k/YxnTUYQ80jh8ZBKWSqXRKv1FwjDreGvKN9O4bkp8pz72GbzI+PI2Mruu/DIfPmP9
         9lo3wg8qqE6CLyzdUg54KGrVE42qkbtKFGHZttVAwy2Y3Jdxhf5f6AS1PzSrvMoKLopw
         MkPbJ55/fDSf5h3cLDFSi4nIa2FsnIizhBCgDPynAvb9JfPvJNBmL9H0tA0F4mDcRRqZ
         OpAG5C48hPLTdwx0RybufAUcv7g64pFfSiRVI33VGeajtyufCT8cjEfPNy3BG32uSmq/
         PwLk0pKVO+JDF3ySgsepmy5tG5oin9af0a4f2Y5HLJEcZHgL7IFsj0ryCoiUyQighdDY
         Ddmw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWNlodCfgVk959t+hvwfNJ09VVOrio4fuC17wmj7b3uMVy6cZivsMqJU9t+FqmKYbitI0xIHsnGrUtg@gnusha.org
X-Gm-Message-State: AOJu0YxtZ86D0y03Pdc7xv9N0KPC3n8vhV7oo2zu5L8K+Fw1ZaKNAsnC
	gQBRwMApJvTMp0Gb8OaW6vUDkakOuPFPAeR+i4Pjavq29gxt6sz2H/TC
X-Google-Smtp-Source: AGHT+IGWRBRF1nFIdMpgrHXQOobJNCfPIdreuMy8Cn2Nfxe+JCTgeohBqZdeJqYmILRhMmXB05Rubg==
X-Received: by 2002:a05:6871:d694:10b0:2eb:ace9:197a with SMTP id 586e51a60fabf-307aa51353bmr160518fac.5.1753927263757;
        Wed, 30 Jul 2025 19:01:03 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZclPLIpKUDXsdlRoE/OmUkFGws1TCNj3tybMAseKXSdlA==
Received: by 2002:a05:6871:5212:b0:2ff:2cba:32b with SMTP id
 586e51a60fabf-3078566686fls549680fac.2.-pod-prod-00-us-canary; Wed, 30 Jul
 2025 19:01:00 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUmhoOCs1Zi/BsT0C8xUJ/d2HPgwDEsburxwtPmlHcK6Gob1LiwcwBIFF9AZ05PONq9JKbm1iHI/OHA@googlegroups.com
X-Received: by 2002:a05:6808:220e:b0:41b:2876:a93b with SMTP id 5614622812f47-4335253da43mr160636b6e.6.1753927260475;
        Wed, 30 Jul 2025 19:01:00 -0700 (PDT)
Received: by 2002:a05:690c:2a44:b0:718:5fd:a4e7 with SMTP id 00721157ae682-71a46fa97adms7b3;
        Wed, 30 Jul 2025 12:44:34 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVMop5NrhrPZDVyXF5RrIOOO1PmXmHYkt6jlJgNlTD6J/3hXsg1L+18y6pcbFLnSmBgNZB3Li28xRPN@googlegroups.com
X-Received: by 2002:a05:6902:18d3:b0:e8e:219c:67c with SMTP id 3f1490d57ef6-e8e3181f908mr5459397276.5.1753904673021;
        Wed, 30 Jul 2025 12:44:33 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1753904673; cv=none;
        d=google.com; s=arc-20240605;
        b=A0MWkisiWSTjOy5YRPi2ZyQKAxg2T/YNaAOM8vmKm5ZIf44bS7eUY8s/Pe4xQlO2NQ
         QTBNF/LJxCTRW/yEl/KPm64oG9TCC6+NZL+lf5/s/tIYEXXPr9s+SNYh1yq4h9GZgCek
         pnvINwem7F3rsQTT8ZCDYoD/TlnELmufp4xnNGUB78wOuydyQEfGdQwEt1yUbKsBzoPC
         e768ZlhPhJ3dmZIdOl3uv4AqyZTcX4RVEKljHx2hDOKQj06CBMctPzAA1128j20Y8NMb
         yGwMchm+irVePi2VPqMGIY+hwDHuyaUlbaocbfBQKVEqCara4maR3QojzpMAhmlDRIz6
         yWfQ==
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=ex+/ixOgwhnz4FBFb9VtgYripi40DHYJ+lJn8a9RdeA=;
        fh=cj/Ixe6Kr95+GhJIVjeMXQpNhPTDvtLURqZ6lwNC7FQ=;
        b=M2un5g9JsMhg5jTAd0WxvhTUGLlrbFSWgnazDnN9JrNLBxoH07erQAqym/V114CGVT
         fat+FZCiDnjnn8zgJ5/Weodffa0/huMrSBfAjJD0p9WCAYfqk6IJYy4DIkbd0yPocT6k
         fxMdSDS2w7saqh5rjuK6tQiD3GDKHTcz4Q1JuCRBxOIeNGXnjCQ5faFYDUIeROA9yFsK
         wUZqb8H9BnWcU6jmawfCtn+ENgc4ZR3pLIrkmRA5CooFyVQHVqzc4L5c00XtOPAJLsR3
         Mn5ffFmk6dE4M16iwziT05JVjY/jrLBekqOEsDT/+QiO323ly3ggsJCayFY6/6kaTmGC
         PKwA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=F7Tcfmm6;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) smtp.mailfrom=gmaxwell@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com. [2607:f8b0:4864:20::102f])
        by gmr-mx.google.com with ESMTPS id 3f1490d57ef6-e8df8520670si597319276.2.2025.07.30.12.44.32
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 30 Jul 2025 12:44:32 -0700 (PDT)
Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) client-ip=2607:f8b0:4864:20::102f;
Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-31329098ae8so100599a91.1
        for <bitcoindev@googlegroups.com>; Wed, 30 Jul 2025 12:44:32 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCWKqHE928q6EHInw28g1kSSo3oqaLOFLtM4MkeKKRzr4+k2IjFAhBEWcGT7+ORZDBXhHTQVyBfmrqqc@googlegroups.com
X-Gm-Gg: ASbGncsgd/vh5j81DizFJjN3p5FsuRkg7DNbRqxFI9pZI31FeP+dU5vG3APfchAbqgr
	/DNiTY+Xl/cm7ttB96uSmfMSgQLaRe9cBmfGGd2hN9pGjM7V0GOdW5PSF9JInJv4YuZDVejpVTq
	oqIalDH5wJQxtyoIt8wohuFxVOiE32DsPu3FOwjvHwWSA7AjzbrjfLmDOvbkzfg+Mb18huJRQpx
	HxFUYQ=
X-Received: by 2002:a17:90b:1d8e:b0:30a:3e8e:ea30 with SMTP id
 98e67ed59e1d1-31f28cdbc30mr11598034a91.11.1753904671959; Wed, 30 Jul 2025
 12:44:31 -0700 (PDT)
MIME-Version: 1.0
References: <26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com>
 <CAPfvXf+E0YDzqY_jsGVoc4KKh_Kgsp-p20wNAD05tv_rMNG2sA@mail.gmail.com>
 <_POzkO7sHDURx6skGAWsrxN_UUtN_6Ak6donzVhmzYzAV6Ej22jBnE2baxM_WtqxW2RNvDjze72kOVgowNhqGSJ1dg5m_HTO3FuG6QM5daw=@protonmail.com>
 <4E54B8EA-9BE8-4660-AA29-72E14C3AADF5@sprovoost.nl> <ZVpECz43S3fTL1NKxxHANGsvtOJmQJmstZ6Xa9laLg7WkdmiLL10yqKgVjsOb0GZFkEpz4vaBfN-uy3mu7kFT41QFTuXD3a_tSoLpSIbIGs=@protonmail.com>
In-Reply-To: <ZVpECz43S3fTL1NKxxHANGsvtOJmQJmstZ6Xa9laLg7WkdmiLL10yqKgVjsOb0GZFkEpz4vaBfN-uy3mu7kFT41QFTuXD3a_tSoLpSIbIGs=@protonmail.com>
From: Greg Maxwell <gmaxwell@gmail.com>
Date: Wed, 30 Jul 2025 19:44:20 +0000
X-Gm-Features: Ac12FXzJhHsF4eXvbUUV7p5avMlVXbNf1A4dsEJbCp4KY_wn5zO-1NacsqR5-Js
Message-ID: <CAAS2fgSh+W_zKigMJ147wJiS4eUxyLrqJi6qrnweTgH7G9jgoA@mail.gmail.com>
Subject: Re: [bitcoindev] A Taproot-native (re-)bindable transaction bundle proposal
To: Antoine Poinsot <darosior@protonmail.com>
Cc: Sjors Provoost <sjors@sprovoost.nl>, "James O'Beirne" <james.obeirne@gmail.com>, 
	Greg Sanders <gsanders87@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000f131cc063b2ac02d"
X-Original-Sender: gmaxwell@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=F7Tcfmm6;       spf=pass
 (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::102f
 as permitted sender) smtp.mailfrom=gmaxwell@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 (/)

--000000000000f131cc063b2ac02d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The burden should be on the proposers to show that their proposal is safe,
cost minimized, etc.

Significant design went into tapscript to make it safer and easier to add
opcodes,  I spent a while searching and none of the authors of these
proposals were standing up saying those improvements were irrelevant.
Supporting it in multiple places is larger and more complex itself, but it
is especially so when the result is missing out on improvements that make
it easier and more accurate to analyze the safety of the addition.

That's not to say that it should absolutely not be done, but there ought to
be a really clear and non-speculative case made for it.

I'd like to know more about this claim wrt HSMs and schnorr signatures, --
who is claiming this, over which products, and how does that interact e.g.
with CTV where there isn't even a signature?






On Wed, Jul 30, 2025 at 6:29=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Devel=
opment
Mailing List <bitcoindev@googlegroups.com> wrote:

> Hi Sjors,
>
> I am not discounting that argument, i addressed it. To reiterate, i
> believe (as do others apparently) that unless
> there is a good reason not to we should only add new features in the
> latest, sanest, version of the scripting system.
>
> Furthermore, Bitcoin's last soft fork aimed to provide a way to have the
> output type not leak any information about
> the receiver's spending conditions (as well as possibly reducing
> information leak at spend time, too). In the last
> upgrade, Bitcoin users opted in to a design such as using Tapscript would
> be indistinguishable at reception time,
> at the price of making Tapscript spends slightly more expensive.
> Incentivizing to use older, distinguishable, output
> types by adding new features there (thereby even making it cheaper to use
> than proper Tapscript) would be completely
> inconsistent with this. For what it's worth, this was also recently
> discussed by one of the Taproot authors in the
> context of BIP360:
> https://delvingbitcoin.org/t/changes-to-bip-360-pay-to-quantum-resistant-=
hash-p2qrh/1811/11
> .
>
> Therefore, our starting position when considering upgrades to the
> scripting system should be to keep to Tapscript.
> I am happy to change my mind about making OP_TEMPLATEHASH and/or OP_CSFS
> available in P2WSH, but i have yet to see
> a compelling reason to do so.
>
> Best,
> Antoine Poinsot
>
> On Wednesday, July 30th, 2025 at 12:06 PM, Sjors Provoost <
> sjors@sprovoost.nl> wrote:
>
> >
> >
> > Regarding the (lack of) support of v0 SegWit, James O'Beirne wrote:
> >
> > > 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."
> >
> >
> >
> > I wouldn't discount that argument though. It's very nice to not have to
> think about any of the problems that v1 (taproot) already fixed. We know
> that review has been a major bottleneck for these proposals.
> >
> > That said, it may be useful to have a "patch" for both the BIP text and
> the implementation that does support v0. I'm sure it's a lot less scary
> than pre-SegWit support.
> >
> > > One concrete impediment to Taproot adoption among custodians is the
> lack
> > > of native HSM support for the Schnorr signature scheme. It's reasonab=
le
> > > to believe that some already-deployed HSM contexts may never get to
> > > Taprootability.
> >
> >
> >
> > I find it worrying that companies claiming to build military grade ultr=
a
> secure hardware, that are used protect hundred of billions of dollars, ha=
ve
> refused to implement Schnorr signatures for 5+ years now.
> >
> > It also means they can't support MuSig2 and instead have to use ECDSA
> signature aggregation. They also can't support script path spending, whic=
h
> isn't great for privacy.
> >
> > I guess we'll have to wait until enough other crypto chains migrate to
> Schnorr so there's enough trade volume to justify paying an engineer to
> spend two weeks fixing this firmware.
> >
> > That said, I don't use such services (for more than a few minutes) and =
I
> don't think we should "force" people to upgrade by stubbornly not
> supporting v0.
> >
> > - Sjors
> >
> > > Op 11 jul 2025, om 20:37 heeft 'Antoine Poinsot' via Bitcoin
> Development Mailing List bitcoindev@googlegroups.com het volgende
> geschreven:
> >
> >
> > [...]
> >
> > > Your second main criticism concerns the lack of Segwit v0 support. Yo=
u
> 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 quadruple=
d
> 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 i=
t
> up with anything
> > > demonstrating those companies 1) desire to use OP_TEMPLATEHASH and
> jointly 2) are somehow unable to
> > > upgrade from P2WSH to Taproot.
> >
> >
> > --
> > 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/4E54B8EA-9BE8-4660-AA29-72E1=
4C3AADF5%40sprovoost.nl
> .
>
> --
> 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/ZVpECz43S3fTL1NKxxHANGsvtOJm=
QJmstZ6Xa9laLg7WkdmiLL10yqKgVjsOb0GZFkEpz4vaBfN-uy3mu7kFT41QFTuXD3a_tSoLpSI=
bIGs%3D%40protonmail.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/=
CAAS2fgSh%2BW_zKigMJ147wJiS4eUxyLrqJi6qrnweTgH7G9jgoA%40mail.gmail.com.

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

<div dir=3D"ltr"><div>The burden should be on the proposers to show that th=
eir proposal is safe, cost minimized, etc.</div><div><br></div><div>Signifi=
cant design went into tapscript=C2=A0to make it safer and easier to add opc=
odes,=C2=A0 I spent a while searching and none of the authors of these prop=
osals were standing up saying those improvements were irrelevant.=C2=A0 Sup=
porting it in multiple places is larger and more complex itself, but it is =
especially so when the result is missing out on improvements that make it e=
asier and more accurate to analyze the safety of the addition.</div><div><b=
r></div><div>That&#39;s not to say that it should absolutely not be done, b=
ut there ought to be a really clear and non-speculative case made for it.</=
div><div><br></div><div>I&#39;d like to know more about this claim wrt HSMs=
 and schnorr signatures, -- who is claiming this, over which products, and =
how does that interact e.g. with CTV where there isn&#39;t even a signature=
?</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br=
></div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Jul 30, 2025 at 6:29=E2=80=AFPM &#39;=
Antoine Poinsot&#39; via Bitcoin Development Mailing List &lt;<a href=3D"ma=
ilto:bitcoindev@googlegroups.com">bitcoindev@googlegroups.com</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Sjors,<br>
<br>
I am not discounting that argument, i addressed it. To reiterate, i believe=
 (as do others apparently) that unless<br>
there is a good reason not to we should only add new features in the latest=
, sanest, version of the scripting system.<br>
<br>
Furthermore, Bitcoin&#39;s last soft fork aimed to provide a way to have th=
e output type not leak any information about<br>
the receiver&#39;s spending conditions (as well as possibly reducing inform=
ation leak at spend time, too). In the last<br>
upgrade, Bitcoin users opted in to a design such as using Tapscript would b=
e indistinguishable at reception time,<br>
at the price of making Tapscript spends slightly more expensive. Incentiviz=
ing to use older, distinguishable, output<br>
types by adding new features there (thereby even making it cheaper to use t=
han proper Tapscript) would be completely<br>
inconsistent with this. For what it&#39;s worth, this was also recently dis=
cussed by one of the Taproot authors in the<br>
context of BIP360: <a href=3D"https://delvingbitcoin.org/t/changes-to-bip-3=
60-pay-to-quantum-resistant-hash-p2qrh/1811/11" rel=3D"noreferrer" target=
=3D"_blank">https://delvingbitcoin.org/t/changes-to-bip-360-pay-to-quantum-=
resistant-hash-p2qrh/1811/11</a>.<br>
<br>
Therefore, our starting position when considering upgrades to the scripting=
 system should be to keep to Tapscript.<br>
I am happy to change my mind about making OP_TEMPLATEHASH and/or OP_CSFS av=
ailable in P2WSH, but i have yet to see<br>
a compelling reason to do so.<br>
<br>
Best,<br>
Antoine Poinsot<br>
<br>
On Wednesday, July 30th, 2025 at 12:06 PM, Sjors Provoost &lt;<a href=3D"ma=
ilto:sjors@sprovoost.nl" target=3D"_blank">sjors@sprovoost.nl</a>&gt; wrote=
:<br>
<br>
&gt; <br>
&gt; <br>
&gt; Regarding the (lack of) support of v0 SegWit, James O&#39;Beirne wrote=
:<br>
&gt; <br>
&gt; &gt; To date I haven&#39;t heard any concrete downside of including wi=
tness v0<br>
&gt; &gt; support for an opcode like this other than &quot;it&#39;s margina=
lly more to<br>
&gt; &gt; think about during review.&quot;<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; I wouldn&#39;t discount that argument though. It&#39;s very nice to no=
t have to think about any of the problems that v1 (taproot) already fixed. =
We know that review has been a major bottleneck for these proposals.<br>
&gt; <br>
&gt; That said, it may be useful to have a &quot;patch&quot; for both the B=
IP text and the implementation that does support v0. I&#39;m sure it&#39;s =
a lot less scary than pre-SegWit support.<br>
&gt; <br>
&gt; &gt; One concrete impediment to Taproot adoption among custodians is t=
he lack<br>
&gt; &gt; of native HSM support for the Schnorr signature scheme. It&#39;s =
reasonable<br>
&gt; &gt; to believe that some already-deployed HSM contexts may never get =
to<br>
&gt; &gt; Taprootability.<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; I find it worrying that companies claiming to build military grade ult=
ra secure hardware, that are used protect hundred of billions of dollars, h=
ave refused to implement Schnorr signatures for 5+ years now.<br>
&gt; <br>
&gt; It also means they can&#39;t support MuSig2 and instead have to use EC=
DSA signature aggregation. They also can&#39;t support script path spending=
, which isn&#39;t great for privacy.<br>
&gt; <br>
&gt; I guess we&#39;ll have to wait until enough other crypto chains migrat=
e to Schnorr so there&#39;s enough trade volume to justify paying an engine=
er to spend two weeks fixing this firmware.<br>
&gt; <br>
&gt; That said, I don&#39;t use such services (for more than a few minutes)=
 and I don&#39;t think we should &quot;force&quot; people to upgrade by stu=
bbornly not supporting v0.<br>
&gt; <br>
&gt; - Sjors<br>
&gt; <br>
&gt; &gt; Op 11 jul 2025, om 20:37 heeft &#39;Antoine Poinsot&#39; via Bitc=
oin Development Mailing List <a href=3D"mailto:bitcoindev@googlegroups.com"=
 target=3D"_blank">bitcoindev@googlegroups.com</a> het volgende geschreven:=
<br>
&gt; <br>
&gt; <br>
&gt; [...]<br>
&gt; <br>
&gt; &gt; Your second main criticism concerns the lack of Segwit v0 support=
. You start by cherry-picking some<br>
&gt; &gt; data about Taproot&#39;s usage, so i&#39;ll ask you to please kee=
p the discussion honest here. You state<br>
&gt; &gt; that between 0.1% and 0.75% of all bitcoins in existence are held=
 in P2TR outputs, and use this<br>
&gt; &gt; figure to conclude the &quot;overwhelming majority of value trans=
fer in bitcoin is still happening in<br>
&gt; &gt; a pre-Taproot script context&quot;. This non-sequitur reads as th=
ough you&#39;d already settled on the<br>
&gt; &gt; conclusion and were reaching for data that might appear to suppor=
t it. In 2024 and 2025 between 20%<br>
&gt; &gt; and 40% of all onchain transfers used Taproot[^0] (vs between 1% =
and 3% for P2WSH). Even<br>
&gt; &gt; considering the value of these transfers gives a pretty clear tra=
jectory: since the beginning of<br>
&gt; &gt; 2024 the percentage of BTC getting locked into P2TR outputs quadr=
upled from 2.2% to 8.5%[^1] (the<br>
&gt; &gt; percentage for P2WSH was steady from 16.4% to 16.8%).<br>
&gt; &gt; <br>
&gt; &gt; I strongly believe our default position should be to only enable =
new features in the latest<br>
&gt; &gt; iteration of the scripting system. While Segwit v0 fixed the most=
 important quirks of legacy Script,<br>
&gt; &gt; Taproot/Tapscript finishes this work by removing the remaining in=
stances of quadratic hashing,<br>
&gt; &gt; enforcing by consensus more malleability-related standardness rul=
es, being compatible with batched<br>
&gt; &gt; validation today and a possible future CISA, and finally presenti=
ng the slight but still good to<br>
&gt; &gt; have privacy improvement that all outputs look the same before be=
ing spent (and sometimes even after<br>
&gt; &gt; being spent although it&#39;s harder to achieve). We should not p=
rovide new features for an outdated<br>
&gt; &gt; scripting context unless we have a strong reason to.<br>
&gt; &gt; <br>
&gt; &gt; I don&#39;t think you provide a strong reason not to stick to Tap=
script. You claim that many industrial<br>
&gt; &gt; players would not be able to use OP_TEMPLATEHASH but you don&#39;=
t back it up with anything<br>
&gt; &gt; demonstrating those companies 1) desire to use OP_TEMPLATEHASH an=
d jointly 2) are somehow unable to<br>
&gt; &gt; upgrade from P2WSH to Taproot.<br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" t=
arget=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
&gt; To view this discussion visit <a href=3D"https://groups.google.com/d/m=
sgid/bitcoindev/4E54B8EA-9BE8-4660-AA29-72E14C3AADF5%40sprovoost.nl" rel=3D=
"noreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev=
/4E54B8EA-9BE8-4660-AA29-72E14C3AADF5%40sprovoost.nl</a>.<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/ZVpECz43S3fTL1NKxxHANGsvtOJmQJmstZ6Xa9laLg7WkdmiLL10yqKgVjsOb0GZ=
FkEpz4vaBfN-uy3mu7kFT41QFTuXD3a_tSoLpSIbIGs%3D%40protonmail.com" rel=3D"nor=
eferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/ZVp=
ECz43S3fTL1NKxxHANGsvtOJmQJmstZ6Xa9laLg7WkdmiLL10yqKgVjsOb0GZFkEpz4vaBfN-uy=
3mu7kFT41QFTuXD3a_tSoLpSIbIGs%3D%40protonmail.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/CAAS2fgSh%2BW_zKigMJ147wJiS4eUxyLrqJi6qrnweTgH7G9jgoA%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAAS2fgSh%2BW_zKigMJ147wJiS4eUxyLrqJi6qrnweTgH7G9jgoA%40ma=
il.gmail.com</a>.<br />

--000000000000f131cc063b2ac02d--