How are private and public keys connected?

How does the mechanism work?

A signature binds spending authority to transaction data under the applicable spending rules. A verifier checks it with a public key. You do not send the secret key along with the payment.

An address is another layer: it encodes a destination associated with spending conditions. It is not simply the secret key written in a different alphabet. A wallet may manage many keys and destinations while presenting a single balance.

Read a signature as a statement about a particular message under particular conditions. It is not a reusable permission slip for every future payment. An interface that asks for a signature should show what is being authorised and obtain the relevant transaction context. Public verification lets many independent nodes reach the same result without sharing a secret. That property is useful precisely because no central password checker is required. It also means that a valid-looking public key or signature copied from another transaction cannot be treated as evidence for this one. The verifier must check their actual relationship to the current signed data.

How large are the objects being checked?

A private key is a number in the permitted range of the secp256k1 curve. Its usual binary representation occupies 32 bytes. A compressed public key occupies 33 bytes, including a prefix that identifies which curve point is intended. Those lengths describe encoded objects, not a measure of how much bitcoin a key controls. The same key can authorise outputs with very different values.

For a worked protocol example, compare a compressed public key with a Taproot x-only public key. The former uses 33 bytes; the latter uses 32 bytes because its encoding follows a convention for the omitted coordinate information. The Schnorr signature defined for Taproot is 64 bytes before any optional signature-hash-type byte. Counting these objects helps explain why spending constructions affect transaction weight.

Keep the operations separate when you read a transaction. Public-key derivation turns a private scalar into a curve point. Signing uses the secret and a message commitment. Verification uses public information to check the signature against that commitment. Hashing may appear within these operations, but a public key is not simply the SHA-256 hash of a private key.

You can understand verification without generating a usable secret. Imagine an otherwise identical payment with its recipient amount changed after signing. Under the normal signature mode that commits to the outputs, that altered transaction has a different message commitment. The old signature should fail verification. Other signature modes deliberately commit to different portions, so always identify the mode before making an absolute claim about which edits are covered.