From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] BIP for OP_CHECKSIGFROMSTACK
Date: Thu, 25 Apr 2024 11:44:40 +0000 [thread overview]
Message-ID: <ZipCKAcV49-xPhSs@camus> (raw)
In-Reply-To: <ZinmVPFt9VQn8QLF@console>
[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]
On Wed, Apr 24, 2024 at 10:12:52PM -0700, Brandon Black wrote:
> Hello list,
>
> Back in 2021, Jeremy wrote[0] about bringing OP_CHECKSIGFROMSTACK (or
> OP_CHECKDATASIG) to bitcoin. That email proposed adopting the
> specification from Bitcoin Cash for Bitcoin, but it is not directly
> suitable, as it verifies DER encoded ECDSA signatures and not R||S
> encoded BIP340 Schnorr signatures. The BIP here included, and proposed
> for the BIPs repository[2] is a bitcoin-specific design for
> OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY. It further differs
> from Jeremy's email by specifying the repurposing of a NOP (NOP5) for
> OP_CHECKSIGFROMSTACKVERIFY to bring data signature verification to all
> script types, not only tapscript (although this is subject to
> change)[1].
>
Thanks for this detailed writeup. This all looks good to me. In
particular it's nice to have the BIP-342 upgrade feature (unknown
pubkeys are OP_SUCCESS) and support for batch verification (invalid
signatures are required to be the empty vector).
One minor open question is whether CSFS should exactly share the set of
public keys that CHECKSIG does. That is, should it be possible in a
future softfork to give CSFS a new type of pubkey that CHECKSIG does not
support, or vice-versa.
This doesn't actually need to be answered as part of a CSFS proposal; it
can be decided later when we have a usecase for this upgrade path. But
it may affect the choice of language when talking about the opcode so
it's worth thinking about whether we should assume it's possible for the
pubkey types to diverge. (For my part I say they should stay the same;
it's hard to imagine otherwise, and given that the proposal initially
uses exactly the set of pubkeys that CHECKSIG does, feels very pedantic
to suggest that they're different.)
--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
--
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 on the web visit https://groups.google.com/d/msgid/bitcoindev/ZipCKAcV49-xPhSs%40camus.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-04-25 11:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-25 5:12 Brandon Black
2024-04-25 11:44 ` Andrew Poelstra [this message]
2024-05-14 21:55 ` Brandon Black
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=ZipCKAcV49-xPhSs@camus \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.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