From: Anthony Towns <aj@erisian•com.au>
To: Pieter Wuille <bitcoin-dev@wuille•net>
Cc: Javier Mateos <javierpmateos@gmail•com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] New Proposal：String Substring Search in Bitcoin Script - OP_ISSUBSTR
Date: Wed, 9 Apr 2025 04:04:36 +1000 [thread overview]
Message-ID: <Z_VlNPeDS8Hk3Dyy@erisian.com.au> (raw)
In-Reply-To: <frERrHlzWhpskJw74fBQorSrXEaBP1d4XBUgM-Nkww_2ulhc7i2Lqmu2kcAlvh5fd7LzYiBmX5HNBtg7Ownbsa0KZ26ihfJjri6R01kuozA=@wuille.net>
On Tue, Apr 01, 2025 at 12:25:26PM +0000, Pieter Wuille wrote:
> On Monday, March 31st, 2025 at 4:41 PM, Javier Mateos <javierpmateos@gmail•com> 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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z_VlNPeDS8Hk3Dyy%40erisian.com.au.
next prev parent reply other threads:[~2025-04-09 9:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-17 16:14 weichu deng
2025-03-17 16:54 ` Peter Todd
2025-03-18 15:32 ` weichu deng
2025-03-18 21:33 ` Rijndael
2025-03-19 9:07 ` weichu deng
2025-03-20 0:23 ` Vojtěch Strnad
2025-03-28 22:40 ` Javier Mateos
2025-04-01 12:25 ` Pieter Wuille
2025-04-01 15:35 ` Martin Habovštiak
2025-04-08 18:04 ` Anthony Towns [this message]
2025-03-18 16:41 ` Erik Aronesty
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=Z_VlNPeDS8Hk3Dyy@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=javierpmateos@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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