From: Garlo Nicon <garlonicon@gmail.com>
To: Peter Todd <pete@petertodd.org>
Cc: "James O'Beirne" <james.obeirne@gmail.com>,
Antoine Poinsot <darosior@protonmail.com>,
Greg Sanders <gsanders87@gmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A Taproot-native (re-)bindable transaction bundle proposal
Date: Thu, 31 Jul 2025 09:35:32 +0200 [thread overview]
Message-ID: <CAN7kyNju09SsYKPBr8j4CiSYFFtWr5ef1KYT8j69YZGKkZCEug@mail.gmail.com> (raw)
In-Reply-To: <aHi80KYQB7ZnUiVl@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 4203 bytes --]
> 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 <pete@petertodd.org> napisał(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 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".
> >
> > 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 address
> > 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 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
> 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
> .
>
--
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/CAN7kyNju09SsYKPBr8j4CiSYFFtWr5ef1KYT8j69YZGKkZCEug%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5250 bytes --]
next prev parent reply other threads:[~2025-07-31 13:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-09 18:19 [bitcoindev] A Taproot-native (re-)bindable transaction bundle proposal Greg Sanders
2025-07-09 19:59 ` Rijndael
2025-07-09 20:05 ` Rijndael
2025-07-09 20:14 ` Ademan
2025-07-10 4:44 ` Brandon Black
2025-07-10 12:24 ` James O'Beirne
2025-07-11 18:37 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-07-11 22:59 ` James O'Beirne
2025-07-14 14:23 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-07-17 9:05 ` Peter Todd
2025-07-31 7:35 ` Garlo Nicon [this message]
2025-07-30 15:40 ` Sjors Provoost
2025-07-30 17:35 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-07-30 19:44 ` Greg Maxwell
2025-07-12 0:27 ` Murch
2025-07-12 3:44 ` /dev /fd0
2025-07-14 13:58 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-07-17 9:00 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAN7kyNju09SsYKPBr8j4CiSYFFtWr5ef1KYT8j69YZGKkZCEug@mail.gmail.com \
--to=garlonicon@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.com \
--cc=gsanders87@gmail.com \
--cc=james.obeirne@gmail.com \
--cc=pete@petertodd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox