From: Brandon Black <freedom@reardencode.com>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] CHECKSIGFROMSTACK(VERIFY/ADD)
Date: Thu, 14 Nov 2024 14:02:49 -0800 [thread overview]
Message-ID: <ZzZziZOy4IrTNbNG@console> (raw)
Hi list,
As we're working toward numbering and merge for the CHECKSIGFROMSTACK
(CSFS) BIP, there are 2 open questions[1] that may be worth resolving
before it is merged as a draft:
* Should CHECKSIGFROMSTACKVERIFY (CSFSV) be added to pre-tapscript?
The proposed opcode always evaluates BIP340 Schnorr signatures
regardless of script version, so making it available in earlier script
versions makes Schnorr signatures available on those script versions for
certain use cases.
My personal thinking in initially including CSFSV in earlier script
versions was basically that it's compatible with NOP forking, so why
not. Because LNHANCE includes CTV which is designed as a NOP compatible
upgrade, also including CSFSV fits well with CTV.
The other side of the argument is that we shouldn't include
compatibility with earlier script versions unless there's a concrete
benefit to doing so. For CTV, the possibility of bare CTV is a
compelling reason to add it to earlier script versions, but there's not
a similarly compelling reason to include CSFSV.
Using a scarce NOP to provide Schnorr signed commitments to earlier
scripts may not be worthwhile.
* Should we include CHECKSIGFROMSTACKADD?
Obviously, if script multisig is going to be a common use case for
checking signatures on stack data CHECKSIGFROMSTACKADD simplifies the
corresponding scripts by a few WU per key. As MuSig2 and FROST are
progressing in standardization and implementation, I do not expect
script multisig to be a dominant use for these opcodes, so I did not
include CSFSA initially.
Here the argument is somewhat the inverse of CSFSV on legacy: We have
many OP_SUCCESSes available, so the cost of allocating one for CSFSA is
low, and the benefit is that making script multisigs with CSFSA (such as
those produced by miniscript) is simpler and less error prone.
--
I would love to hear thoughts about both of these questions from the
list, and will update the BIP and implementations of CSFS(V/A) based on
your feedback.
Thanks much!
--Brandon
[1]: https://github.com/bitcoin/bips/pull/1535#issuecomment-2111195930
--
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/ZzZziZOy4IrTNbNG%40console.
next reply other threads:[~2024-11-14 23:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-14 22:02 Brandon Black [this message]
2024-11-15 10:14 ` [bitcoindev] CHECKSIGFROMSTACK(VERIFY/ADD) 'moonsettler' via Bitcoin Development Mailing List
2024-11-15 14:57 ` Murch
2024-11-15 15:33 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
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=ZzZziZOy4IrTNbNG@console \
--to=freedom@reardencode.com \
--cc=bitcoindev@googlegroups.com \
/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