> 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ł(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.