How Blockchain Wallets Use Public-Key Cryptography to Sign Transactions
Ask someone where their crypto is and they will point at a phone. Nothing on that phone is a coin. A blockchain is a ledger of outputs and balances, and each entry belongs to whoever can produce a valid signature for it. Wallets are, in the end, key managers: they generate secrets, derive addresses from them, and sign transactions without ever exposing the secret itself. Understanding that split — private key, public address, signature — turns a lot of confusing wallet behaviour into something you can reason about.
Two keys, two very different jobs
Public-key cryptography hands you a matched pair of numbers. One is secret, the other is meant to be published. They are linked by math that runs easily in one direction and not practically at all in the other.
The private key
A private key is just a large random number. On Bitcoin and Ethereum it is an integer below the order of the secp256k1 elliptic curve — a value with roughly 256 bits of range. That randomness is the entire security model: if nobody can guess your number, nobody can move your funds.
Most wallets never ask you to handle that number directly. They generate a seed phrase — twelve or twenty-four words — and derive every key in the wallet from it. The seed is the master secret. Write it on paper, keep it offline, and understand that anyone who reads it can rebuild every address you own.
The public key and the address
The public key comes from multiplying a fixed point on the curve by the private key. Going backwards — recovering the private key from the public key — is the elliptic curve discrete logarithm problem, and no practical method for it exists on these curves.
An address is a shortened, checksummed form of the public key, and the recipe differs by chain:
- Bitcoin: SHA-256, then RIPEMD-160, then a version byte and a checksum, encoded as Base58Check or bech32.
- Ethereum: Keccak-256 of the uncompressed public key, last twenty bytes, displayed with a 0x prefix.
- Others: Ed25519 on Solana, Schnorr on Taproot-era Bitcoin — different curves and encodings, same underlying idea.
An address is a mailbox anyone can drop value into. The private key is the only thing that opens it.
What a signature actually proves
A digital signature answers exactly one question: did the holder of this private key authorize this exact message? Nothing more.
Three properties matter in daily use. The signature cannot be forged without the key. It is bound to the content, so changing a single byte — the amount, the destination, the nonce — makes verification fail. And it can be checked by anyone holding the public key, which is why a node on the other side of the world can validate your transaction without asking you a thing.
Signatures are not encryption. They hide nothing: sender, recipient, and amount stay visible on a public chain. Spending from an older-style Bitcoin address also reveals your public key, which links addresses together more effectively than most newcomers expect.
It helps to know that message signing and transaction signing use the same machinery but different consequences. Signing a plain login message moves no funds. Signing a token approval or a contract call can grant a stranger spending rights over your balance. Read the payload — especially the amounts and the contract address — before you approve anything.
Signing a transaction, step by step
- Build. The wallet assembles inputs, outputs, amounts, fee, and the account nonce or chain ID.
- Serialize. Those fields are packed into a canonical byte sequence. Deterministic encoding matters, because two different serializations produce two different digests.
- Hash. The bytes are hashed — double SHA-256 for Bitcoin, Keccak-256 for Ethereum. The signature covers the digest, not the raw transaction.
- Sign. In ECDSA the wallet computes two numbers, r and s, plus a recovery id or sighash flag. Reusing the same ephemeral value across two different messages leaks the private key, which is why modern wallets derive it deterministically.
- Broadcast. The signed transaction is sent to peers. The private key stays exactly where it was.
How the network checks your work
A node receiving that transaction does not take the signature on faith. It recomputes the digest from the bytes it received, then runs the verification equation against your public key. It also confirms the inputs exist, have not already been spent, and satisfy the script or contract conditions, and that the fee and nonce make sense. If any check fails, the transaction is dropped — often silently.
This is why a transaction cannot be edited in flight. A relay or miner that swaps the recipient produces a digest that no longer matches the signature, and the whole thing dies at the door.
Where the keys live
Hot wallets keep keys in memory on a networked device, protected by a password. Convenient, and exposed to malware, clipboard hijackers, and phishing pages.
Hardware wallets hold the key in a dedicated chip. The transaction goes in, the signature comes out, and the key never touches your computer. Malware can still trick you into signing something you did not intend, so read the details on the device screen before approving.
Multisignature and threshold wallets split authority so no single key can move funds alone. More setup, considerably less single-point failure.
Habits that protect the key
- Back up the seed phrase on paper or metal, offline. Never as a photo, an email draft, or a note in a synced app.
- Never type seed words into a website or app that asks for them. No legitimate service needs them.
- Check the recipient address on the signing device screen. It is the only verification that defeats clipboard malware.
- Send a small test amount before moving a large sum to a new address.
- Keep a small spending wallet separate from a long-term one.
- For substantial holdings, consider multisig — and rehearse recovery before you actually need it.
A sufficiently powerful quantum computer running Shor's algorithm would break the elliptic-curve math behind today's signatures. No such machine exists now, and the practical answer is migration to post-quantum schemes as they mature, not alarm. The likelier loss by far is a lost seed phrase or a convincing phishing page, and both are preventable with the habits above. Treat this as general information rather than financial advice; where meaningful sums are involved, treat key management as a security project and bring in someone qualified if you are unsure.
Photo: Roger Brown / Pexels




