Public-key cryptography uses a pair of related keys. In a digital signature scheme, the private key signs data and the public key lets others verify the signature. In a crypto payment, address derivation constructs a shareable destination under the network's rules. For a fund reconciling a transfer, checking where an output was sent and establishing who can authorise a later spend are separate tasks. Standards for Efficient Cryptography 1 (SEC 1), §§3.2 and 4.1
From a secret scalar to a public point
In elliptic-curve cryptography, a private key is an integer between and , where is the order of the agreed base point . In other words, is the smallest positive multiple of that gives the group's identity. The public key is the curve point . The multiplication uses the curve's point addition rule. Computing from is efficient. Recovering from and is the elliptic-curve discrete logarithm problem, which is assumed to be computationally infeasible for suitably chosen secrets on curves such as secp256k1. SEC 1, §§2.2.1, 3.2 and Appendix B.1 · Standards for Efficient Cryptography 2 (SEC 2), §2.4.1
A doubling you can do by hand
Take the toy curve , the base point and the scalar . Coordinates are residues from 0 through 16. To compute , take the tangent at . The slope rule is for nonzero . At the denominator is , whose inverse modulo is because . Then the slope and doubled coordinates are
Geometrically, the tangent meets the curve at with multiplicity two and again at . Negating that third point's coordinate modulo gives . Substituting into the curve equation gives residue on both sides. The toy group contains 19 points including the identity, leaving only 18 nonzero scalars to try. It offers no security. SEC 1, §2.2.1
The tangent appears as discrete residues. Its third intersection gives the negative of the doubled point.
How Bitcoin makes a legacy P2PKH address
For a pay-to-public-key-hash (P2PKH) address on Bitcoin mainnet, start with a serialized secp256k1 public key. In the 33-byte compressed format, the first byte is 0x02 for an even coordinate or 0x03 for an odd one, followed by the 32-byte coordinate. The 65-byte uncompressed format uses 0x04 followed by both coordinates. SEC 1, §2.3.3 · SEC 2, §2.4.1
- Hash those public-key bytes with SHA-256, then hash the resulting bytes with RIPEMD-160. This produces a 20-byte public-key hash.
- Prepend the mainnet P2PKH version byte 0x00. Hash that 21-byte payload twice with SHA-256 and take the first four bytes of the result as the checksum.
- Append the checksum to the payload and encode the combined bytes in Bitcoin's Base58 alphabet, preserving each leading zero byte as a leading 1. This is Base58Check.
The byte representation matters. The public base point printed in SEC 2 yields a mainnet P2PKH address beginning 1BgGZ9… in compressed form and 1EHNa6… in uncompressed form. These are truncated test examples from a publicly known point. Both encodings represent the same point, but their byte strings hash differently. The recipe is specific to this output type and network. Bitcoin's P2SH convention, for example, hashes a serialized redeem script and uses a different version byte. SEC 2, §2.4.1 · Bitcoin Developer Reference, Address Conversion
What the network checks when the output is spent
A payer decodes the P2PKH address and creates an output whose spending condition contains the public-key hash. Spending that unspent transaction output (UTXO) requires the serialized public key and an ECDSA signature over the transaction data selected by the signature's hash type. Nodes check that the supplied key bytes hash to the value in the output and use the public key to verify the signature. The private scalar stays with the signer. Bitcoin Developer Guide, Transactions and Signature Hash Types
An address describes where to pay. A signature authorises the data it covers under the spending condition. If a service holds the signing key, an on-chain signature check and the service's internal approval of a customer's withdrawal are different events. That distinction matters when analysing wallet and key custody or attributing addresses to an entity. Bitcoin Developer Guide, Transactions
Sources
- Standards for Efficient Cryptography 1 (SEC 1), version 2.0, §§2.2.1, 2.3.3, 3.2 and 4.1, and Appendix B.1, on point arithmetic, serialization, key pairs, ECDSA and the discrete logarithm problem.
- Standards for Efficient Cryptography 2 (SEC 2), version 2.0, §2.4.1, for the secp256k1 domain parameters and both base-point encodings.
- Bitcoin Developer Reference, Address Conversion, for the P2PKH and P2SH hashes, network version bytes, checksum and Base58 encoding.
- Bitcoin Developer Guide, Transactions, for the P2PKH spend and signature hash types.