Delivery-date: Thu, 25 Apr 2024 04:45:19 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of apoelstra@wpsoftware.net designates 66.183.0.205 as permitted sender) client-ip=66.183.0.205;
Date: Thu, 25 Apr 2024 11:44:40 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] BIP for OP_CHECKSIGFROMSTACK
Message-ID: <ZipCKAcV49-xPhSs@camus>
References: <ZinmVPFt9VQn8QLF@console>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="OoC1cQBOMjISW3fx"
Content-Disposition: inline
In-Reply-To: <ZinmVPFt9VQn8QLF@console>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--OoC1cQBOMjISW3fx
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

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.

--OoC1cQBOMjISW3fx
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmYqQicACgkQxYjWPOQb
l8Exywf/SysZh8Aj+T0CgXdUNKRNzVU6IvqkhsBatNOL9HrzovmWgXqDXoVtNKCp
Tk+A4G77BFCrnXRXPDwaya2EfWL0MU2rYSYn238zqacz+trT2uT71WFp+0/MX4K9
I2OcvKlC2IC6DxssB0+Tb/3vIIrMCisSQfdzXsFsX+lOoGsCXuimAp5ev6y0WrS+
VmjYOeccrbOGAOyVFNsDv1If1ScslWTn6wi2gQJeJPo4ZafyJoh5Bb5MRxCVvEoh
fM2LB7FvwW/mE4Ai0/8cuHzrC/LafyJS+56QzCifJayGQzudWBVyOVCXcS6z2x3R
IS4hXsNHdhncw5Ebz/wxnl0gTwHD1w==
=0e96
-----END PGP SIGNATURE-----

--OoC1cQBOMjISW3fx--