What does a digital signature prove?

A signed instruction can still be a bad instruction

Suppose a club uses a signing key to authorize room bookings. The message says “Reserve room B for Thursday.” A verifier checks the signature using the club’s known public key and the exact message bytes.

Successful verification supports a narrow conclusion: under the scheme’s security assumptions, the signature is valid for that message and public key. It does not establish that room B is available, that Thursday is a sensible choice, or that the signer has not been tricked.

Key identity matters. If an attacker sends their own public key along with a perfectly valid signature, the math may check out while the association with the club is false. The verifier needs a trustworthy reason to use that particular public key.

A signature is bound to what was signed

Change the message after signing and verification normally fails. But the scope is exactly the data covered by the signature scheme and signing process. If the application signs only a booking number, the room and day might remain outside the signed statement.

Bitcoin adds protocol-specific rules for the data committed to by transaction signatures. The existence of a signature should not be read as “every displayed field was necessarily authorized in the way I assume.” Developers need to understand the relevant signature-hash mode and script rules.

Four questions that belong beside verification

1. Which key? Is it the expected key, and how was that association established?
2. Which message? Are the displayed fields the same bytes or structured data covered by the signature?
3. Which context? Could the signed statement be replayed in a different setting?
4. Which authority? Do the application’s rules allow this key to make this change?

For the club, a signed string saying approve:42 is ambiguous unless both sides agree what 42 identifies. Adding context, object identity, and suitable freshness rules is an application design task. There is no universal message template that solves every replay problem.

Bitcoin uses more than one signature scheme. ECDSA appears in established spending types, while BIP 340 defines Schnorr signatures used in the Taproot family of rules. Our lesson explains the relationship between signing and verification without implementing either scheme.

A compromised key can create signatures that verify. Verification does not report whether the human intended the action, whether the device was secure, or whether the signer is trustworthy. Those are separate operational and social questions.

Design the statement before the signature

Write two versions of a fictional club approval:

Version A: approve
Version B: Club demo / booking 42 / room B / Thursday / revision 3

List what a verifier can distinguish in version B that was absent in A. Expected answers include the application context, the object, and the particular revision. This is a reasoning exercise, not a secure serialization standard.

Now imagine a valid signature for version B sent with a public key the club has never seen. Should the application approve the booking? Expected result: no automatic approval. It first needs an authorized key association and its other business checks. Cryptographic validity is one input to that decision.