From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 31 Jul 2025 06:00:01 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uhSt6-00076j-BV for bitcoindev@gnusha.org; Thu, 31 Jul 2025 06:00:00 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-2e9b1f85b2bsf1371070fac.0 for ; Thu, 31 Jul 2025 05:59:58 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1753966789; cv=pass; d=google.com; s=arc-20240605; b=RY4hGarVTOmGpluProjFeaipCVeMN+HemETZA9d1hcOyNrWyMKDDJalpwd1ktCexkO nJ4/wgXTpBeSLNI8QiWVGYP4n8l+xM6sebCYiXVbkvUkmtWPrLR5xBhNlocsCvZZ1OAa RlF9VSHFPsnewF7BoX2wpDo2DYnbPj3m5/HPHeOtl2o7ziU5M59brPH0Mbpe6CT16roQ Vi1hNnwzonDkRZZUDnNcVgGYIkI8U6lw6G3ShSGZIZ8+wpCBhHHhR8dfoX4nWG35ZgeW hXvO+B/6k+Bk//IPKkJ+Amj7KWpQ/eRLN15rDLrTPjL5wgdZ59gWPOLJzEuGv5zyv8S2 dWkA== 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=jV6SCyeFk1fZD3alxKxPZCgteLlT3FCu9CTLCWd87+k=; fh=72sC6XiUS1JzA62QC0EN+8eZxBxf6E6F6sWXXaADl40=; b=JtE+AD00pjknutaCD913QI9qqZUQqoKJRF8mTO0aUE+wZpchKBAr6sA5pFX/BxSfK5 bYFZFUgUMa/dV5BaajAuLHOtXnfyP9Jr71KA5xghf3pN7gML3xr5gPR+1G4kT428iZNQ RXZNF/05GZMzgB3hq2USq3fQVRwmczHXYN5CTj6PvaDm84ptgnppwvJ4BXGZAi85gYXa zNsFDS8JniHBNM6GWXoTBItTzFusEXQuQndVGc8QFoidiqmMKmztycTEJfZVCDX9lOBI cHiRcbIRHmYeraJer4N4pFZgiM+D+l51EDPY9v56xvfOkalOSoX1+FACH54WtmbiZcyB liUQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=iDo4l9Bt; spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=garlonicon@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=1753966789; x=1754571589; 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=jV6SCyeFk1fZD3alxKxPZCgteLlT3FCu9CTLCWd87+k=; b=BzE1UJdkuJ+zAxjcVsa0HJJj/aONW93+nRwmdf57deOdaafwPQ1+M2IwTm/3UTAeKk YArwxrlFo2iEyQS7rb3t2YgG2cck1Y3MgXWKuEMhM/hnsXR2BYVbun8ryZu7Qk7gCnlv 2sjvmU6KQRRdJQiXQqWcSAcUD5ynGpxoEpysAZvkFnSOOjHE5FsIv9fbfrTNvRi6xCYX MvSbgH4ugOovFRktP5tuAKvopX/yEOMwSrAAiy/kuTxiRbVR2OgPNaUUmCVm/JFh+CYC n51ciuMawgZ69os8S6NGtMcbiYANl21UIOztsmbdcKAp9k4JEEISplbMDHpFSHdDAByi X1QQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753966789; x=1754571589; 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=jV6SCyeFk1fZD3alxKxPZCgteLlT3FCu9CTLCWd87+k=; b=ZxHaI1Gb88NbR10TYFowdfoVLZYlmQ/F0Y5HiZUA17zmGptaXMDXrQ+gHkG+LUnBBk 30SdtyG7v4dJwVvmpMbMKPNdZ7+x1i+3UlvqFsAjtgqj1GBPEIaRWMnQIATOgHiiKSxx MSWFTu5cIQvCXi3XAGkUYVJXmVDkUn9uwjd7ytZY0BvOAzU2qlrzaZ+35tHeSOo5kGYd kwLLLqmMxNH3NAoognGeNmcmOCXWYpxCDwL7gEiCB7NT/TRAwu9xyaEiaFFJqDixrBLj GkwoUt3Z6ocXG2oPELV6jUbP4seaaXc/Bkq060k3XwzeXTbq9DBMlJRm8+nk2nAlmtwH 3ViA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753966789; x=1754571589; 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=jV6SCyeFk1fZD3alxKxPZCgteLlT3FCu9CTLCWd87+k=; b=C3FhZKpOgrCy0pdyZGNnrO6XbikhUF6lWhu0n/awrydYj7aQlBd52Xy6jYDW9QpJGP x/1rdzd2H0hvxIon0pl5JggtnhpmF8u1Dwfw+6pOyyttZzaKxX+YmG//7ZDrGVt6kQGg KcDJUNeDuDISsxseB/ItnxgE4nJZJEYmFDB0O9uy4s+G/7mylEKIwgmgh6kvo1QOSfkX sjFrIehOZtkxb4OEsfK/Vt2gyUuIKlI+uEkJfEdYqkvihdS55cSpmLRj88dltoB4MaKL 0SkKFJtVth9bfxxfuzFDO7lXhyeJjXNWUkieRQ9xz21FA8pdIB5nu9mb8HZVRTrbGPsC KBsg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXlnbY1jPUpvCdc22WRAOLd6XyB851cftIZh5COi3vuOP485pdPods07gqW7Qftg1+KFpoCC7hG/qc2@gnusha.org X-Gm-Message-State: AOJu0Yz0JALut0YecbY1gCUuFb9CHfOFSiQrlasntsrlsauP5+CDE1dE x2AIiCkXK4VCuNcIncs5xR5J7PFtKQTUvFPc30HKRpb8WVeo7zry+4PV X-Google-Smtp-Source: AGHT+IHDvsiyrmPA4dFmaGWnou3C0iFBhiHKz0jC5LjCPBUOL2ZEDOkP1kK9JqcV5qN0YVcMYLhXqw== X-Received: by 2002:a05:6871:5208:b0:2d5:ba2d:80e4 with SMTP id 586e51a60fabf-30785c114bamr4464921fac.24.1753966788831; Thu, 31 Jul 2025 05:59:48 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeq1R3DKq2r+A0Krr6mCSwvUxnYPv2AYUixWKiFl23Pkw== Received: by 2002:a05:6870:1096:b0:2da:fbc:5e7 with SMTP id 586e51a60fabf-307a7059fefls314523fac.0.-pod-prod-07-us; Thu, 31 Jul 2025 05:59:44 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWi2SjHWqez4LLPy1S237IxLHsVuMdu0DXAZhTXcdJ3TYIJjjPINgxttZhHwVJFmOpy9yQKTZVEo9xg@googlegroups.com X-Received: by 2002:a05:6808:884f:20b0:433:da21:4c60 with SMTP id 5614622812f47-433da215c37mr94816b6e.11.1753966784386; Thu, 31 Jul 2025 05:59:44 -0700 (PDT) Received: by 2002:a05:600c:1d96:b0:456:ce4:c44e with SMTP id 5b1f17b1804b1-458931541a1ms5e9; Thu, 31 Jul 2025 00:35:47 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWPh1ntZS3t6hFxG1Bh6i9LfdnTnvadBsrtlFtflgT7oiZBpEaQyGJa0O739SjepLrrf8D73CUrom57@googlegroups.com X-Received: by 2002:a05:600c:4448:b0:456:1e5a:885e with SMTP id 5b1f17b1804b1-45892b95341mr67472485e9.3.1753947345059; Thu, 31 Jul 2025 00:35:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1753947345; cv=none; d=google.com; s=arc-20240605; b=RJQNTooSUHavyl8J0juoB51NwAcjjdwtJQ9BKNLT+nKnyFgBv/dKYvlZeaxygk02qS XG8xId9HySN3WE9pRP/pRU9qI8XcrVOGg4ndh/ko0+OfYWrbgNSc3gn/yo/N6bC0FkH4 yb76w4d3muQJAm8r6T+h7YuaQ6HqENwKV1GmW7M58kq6S5w1r1gAVGP60Hx6jENrpQtd 0Zpsb0myES4Gn3z8zAP5kaK3ETmuXilHzxO1QlIou5JAV9b0HPzdCsXmavlgdyjpu3rg V2cXdNjkUEoT9FVvGVqCFnJknD+PAzQosNdythbCyQhgDpKH1wrK/WLhj8JvAusuV0CN 5Lug== 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=PPdimQHG51DCnQNzwrqT5eNlqx2365HpyC0p/8XfzCs=; fh=F4rWYVasNJM8pOvIlBCEfIXfOb2BiZornQq2LD59rLw=; b=SYOpF4flideNsInfedKL4LRnq7svc1BQ9SiPgG/OdhzycdhZ4oTbObHrCFNz/Bl+Xd 6qL/oUnM7046ZJonpPYvaOGEUBfZKZkmpIy2VjFdAsmFCuD+N614Yh3Mbbi3Mz4mdQeV YIKg2c+oRHpH6LHppibCUV6oVmIAatMTJebG6Kcn8/WL8L3NHqrQVUqkJwOzjpKWwu0U WlkuTPEwFfu9rWgLLsxSQISAePTZtzLwK/BpkKVIfXPapy4couCxuw6YbOq2vQqRrgd+ eCE2vHntkMHxe+uT1JdokAsqTr2Ro9aY4XANciXOwRWOqjOHqFEiNwiNJSJfoM/Pz3LS /97g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=iDo4l9Bt; spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=garlonicon@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com. [2a00:1450:4864:20::62c]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-45895377d6esi914185e9.1.2025.07.31.00.35.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Jul 2025 00:35:45 -0700 (PDT) Received-SPF: pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) client-ip=2a00:1450:4864:20::62c; Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-ae3b336e936so122265066b.3 for ; Thu, 31 Jul 2025 00:35:45 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWxCoiYCqTBoF5195I/Ku5E8hcv/pq1D7kHPYZhz/OyaEOjDudQYl4FSDgHxOrijGzQHTLysmSJwYGL@googlegroups.com X-Gm-Gg: ASbGnctzt7TiVFu1EG2fgSNUmkdNtayO+kusmU9iWOGgvD0cqoaW3/5lIBHbVpJmJL2 BjnsNO6PFIA6rJv+oabM2TtfgAKD9MK9zAyGCUes/Z8aDm65mGfHE6n7p0vvRE33gTHzgHmPtVv IzXNLZxDlJhPXLlbVRCVt9G2Rob0vscA5ZwdZBedC7V7NgSUAsru/4dNLOY1Gd4HN/7SB5wM6F6 eP+PA== X-Received: by 2002:a17:907:9406:b0:ae6:f087:953 with SMTP id a640c23a62f3a-af8fd6a2978mr654773266b.12.1753947344107; Thu, 31 Jul 2025 00:35:44 -0700 (PDT) MIME-Version: 1.0 References: <26b96fb1-d916-474a-bd23-920becc3412cn@googlegroups.com> <_POzkO7sHDURx6skGAWsrxN_UUtN_6Ak6donzVhmzYzAV6Ej22jBnE2baxM_WtqxW2RNvDjze72kOVgowNhqGSJ1dg5m_HTO3FuG6QM5daw=@protonmail.com> In-Reply-To: From: Garlo Nicon Date: Thu, 31 Jul 2025 09:35:32 +0200 X-Gm-Features: Ac12FXxr9jvEShBf8rUlrbmmcc1oVMxnsFy3iU8CE3RvtDmwUm3mf1HLtfajYWw Message-ID: Subject: Re: [bitcoindev] A Taproot-native (re-)bindable transaction bundle proposal To: Peter Todd Cc: "James O'Beirne" , Antoine Poinsot , Greg Sanders , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000667f33063b34b04b" X-Original-Sender: garlonicon@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=iDo4l9Bt; spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=garlonicon@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 (/) --000000000000667f33063b34b04b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > There are no sigificant obstacles to new code making use of taproot. Using OP_SIZE on top of Schnorr signature doesn't reveal Proof of Work behind it. But if it is done behind P2WSH, then it works much better (the smaller DER signature is, the more Proof of Work it requires). Which means, that if you want to have Proof of Work, and any conditions, then you are forced to use P2WSH or something older (but older things are non-standard). In theory, that kind of problems could be solved by new opcodes like OP_CAT, but then, they would open more use cases, which may have unknown side effects (like implementing BIP-300 or BIP-301 without any additional soft-fork). Also, if you use OP_CHECKMULTISIG, then it is guaranteed, that all signatures can sign the same z-value, if they want (which is useful, when ECDSA is used as a 256-bit calculator; if secp256k1 will ever be broken, and OP_CHECKMULTISIG won't be disabled, then I guess using it as a big number calculator will be the main use case). However, in Taproot, there is OP_CHECKSIGADD instead, and then, each OP_CHECKSIG call is executed on a different z-value, and it is much harder to force it to be the same for different signatures. Another combination, which can be used only in legacy scripts, is moving coins from random P2PK outputs with out-of-bounds SIGHASH_SINGLE, from known public keys, with unknown private keys. Then, even P2WSH cannot do that, because z-value cannot be controlled by the spender in any reasonable way (and different sighashes cannot be chained, because when txid inside input can change, then next signature in the chain can be invalid; it is hard to make a chain of one-input-one-output signatures, when all of them would use sighashes SINGLE with ANYONECANPAY, because adding any input or output to anything in that chain, will instantly invalidate all following signatures). czw., 17 lip 2025 o 12:04 Peter Todd napisa=C5=82(a): > On Fri, Jul 11, 2025 at 06:59:18PM -0400, James O'Beirne wrote: > > Hi Antoine, > > > > > You state that between 0.1% and 0.75% of all bitcoins in existence ar= e > > > 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". > > > > I think you might have misparsed my email; I wasn't using one > > observation to justify the other. > > > > I ran a script[0] to tally the value of newly created outputs by addres= s > > type, and the node tells me that 93.5% of all output-value created over > > the last three months is non-P2TR. > > The total output value created that is non-P2TR is irrelevant here: all > those > outputs are being created by existing production systems. Obviously, they > have > no reason to rush to implementing taproot. Heck, as I just mentioned > elsewhere, > even P2PKH addresses are *still* fairly commonly used even though there a= re > significant fee savings to upgrading. People just don't like upgrading > existing > - working - code unless there is a really good reason. > > What we're discussing here is a new scripting feature, that inevitably ar= e > only > useful for brand new code. There are no sigificant obstacles to new code > making > use of taproot. > > ACK new opcodes being taproot only. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > > -- > 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/aHi80KYQB7ZnUiVl%40petertodd= .org > . > --=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/= CAN7kyNju09SsYKPBr8j4CiSYFFtWr5ef1KYT8j69YZGKkZCEug%40mail.gmail.com. --000000000000667f33063b34b04b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> There are no sigificant obstacles to new code making = use of taproot.

Using OP_SIZE on top of Schnorr signature doesn'= t reveal Proof of Work behind it. But if it is done behind P2WSH, then it w= orks much better (the smaller DER signature is, the more Proof of Work it r= equires). Which means, that if you want to have Proof of Work, and any cond= itions, then you are forced to use P2WSH or something older (but older thin= gs are non-standard). In theory, that kind of problems could be solved by n= ew opcodes like OP_CAT, but then, they would open more use cases, which may= have unknown side effects (like implementing BIP-300 or BIP-301 without an= y additional soft-fork).

Also, if you use OP_CHECKMULTISIG, then it = is guaranteed, that all signatures can sign the same z-value, if they want = (which is useful, when ECDSA is used as a 256-bit calculator; if secp256k1 = will ever be broken, and OP_CHECKMULTISIG won't be disabled, then I gue= ss using it as a big number calculator will be the main use case). However,= in Taproot, there is OP_CHECKSIGADD instead, and then, each OP_CHECKSIG ca= ll is executed on a different z-value, and it is much harder to force it to= be the same for different signatures.

Another combination, which ca= n be used only in legacy scripts, is moving coins from random P2PK outputs = with out-of-bounds SIGHASH_SINGLE, from known public keys, with unknown pri= vate keys. Then, even P2WSH cannot do that, because z-value cannot be contr= olled by the spender in any reasonable way (and different sighashes cannot = be chained, because when txid inside input can change, then next signature = in the chain can be invalid; it is hard to make a chain of one-input-one-ou= tput signatures, when all of them would use sighashes SINGLE with ANYONECAN= PAY, because adding any input or output to anything in that chain, will ins= tantly invalidate all following signatures).

czw., 17 = lip 2025 o 12:04=C2=A0Peter Todd <= pete@petertodd.org> napisa=C5=82(a):
On Fri, Jul 11, 2025 at 06:59:18PM -0400, James= O'Beirne wrote:
> Hi Antoine,
>
> > You state that between 0.1% and 0.75% of all bitcoins in existenc= e are
> > held in P2TR outputs, and use this figure to conclude the
> > "overwhelming majority of **value transfer** in bitcoin is s= till
> > happening in a pre-Taproot script context".
>
> I think you might have misparsed my email; I wasn't using one
> observation to justify the other.
>
> I ran a script[0] to tally the value of newly created outputs by addre= ss
> type, and the node tells me that 93.5% of all output-value created ove= r
> the last three months is non-P2TR.

The total output value created that is non-P2TR is irrelevant here: all tho= se
outputs are being created by existing production systems. Obviously, they h= ave
no reason to rush to implementing taproot. Heck, as I just mentioned elsewh= ere,
even P2PKH addresses are *still* fairly commonly used even though there are=
significant fee savings to upgrading. People just don't like upgrading = existing
- working - code unless there is a really good reason.

What we're discussing here is a new scripting feature, that inevitably = are only
useful for brand new code. There are no sigificant obstacles to new code ma= king
use of taproot.

ACK new opcodes being taproot only.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aHi80KYQB7ZnUiVl%40pete= rtodd.org.

--
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/ms= gid/bitcoindev/CAN7kyNju09SsYKPBr8j4CiSYFFtWr5ef1KYT8j69YZGKkZCEug%40mail.g= mail.com.
--000000000000667f33063b34b04b--