On Tue, Apr 01, 2025 at 12:25:26PM +0000, Pieter Wuille wrote: > On Monday, March 31st, 2025 at 4:41 PM, Javier Mateos > <[email protected]> wrote: > > The solution of splitting the string and using OP_CAT only works if the > > exact position of the substring is known. How would a case be handled where > > the substring could be in any position > Whoever produces the signature/witness for spending the coin always knows the > position already, so the script can always be modified to instead take that > position as an additional input. > This is a general principle: the point of scripts is verifying provided > information, not computing it. As another example, this means that there is > no need for a division or square root opcode if one has a multiplication > opcode.
I somewhat disagree with this: there are some concerns that are *easier* to express with different opcodes, and I think that's a factor worth considering. This came up with the OP_CAT based proof-of-work faucet [0] -- the idea there is that you provide a signature and some nonce data, and when you combine the two and hash the result, that result begins with some sufficient number of 0 bits (that then gets related back to a CHECKSEQUENCEVERIFY delay). OP_CAT is *sufficient* for testing this, because you just CAT the signature and nonce together and hash them, and can then again CAT the the 0-bits you expect together with some other data and check that all of those combined match the hash you calculated earlier. But it would be more efficient, and a little easier to code, if you could instead have used SUBSTR/LEFT to pull the initial bytes from the calculated hash and check that those have the expected number of leading 0-bits. More efficient, because you don't have to supply all the trailing bytes of the hash in the witness, and easier to code, because it's a bit more natural to think of manipulating the hash you calculated, rather than having to put user-provided data together and check that that actually matched what you would have extracted from the hash had you been able to do it that way. So just like we have unnecessary opcodes like "CHECKSIGVERIFY" (versus "CHECKSIG VERIFY"), I think it's still worth evaluating "SUBSTR" and "DIV" on questions of efficiency, even if they're not providing any additional expressivity -- ie, does it provide a meaningful improvement either for on-chain validation or when writing/maintaining scripts compared to other ways of achieving the same goal? (That said, I don't think "ISSUBSTR" is a great opcode; the original SUBSTR that specifies exactly where in the original string the substring appears seems more useful to me) Cheers, aj [0] https://delvingbitcoin.org/t/proof-of-work-based-signet-faucet/937 -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z_VlNPeDS8Hk3Dyy%40erisian.com.au.
