Signing is the act that moves bitcoin: the wallet uses a private key to produce a digital signature over the transaction's exact contents, and every node on the network verifies that signature against the corresponding public key. Since the 2021 Taproot upgrade, Bitcoin supports two signature schemes side by side — ECDSA, the original, and Schnorr, the newer — and both let thousands of independent verifiers check a spend without ever learning the secret behind it.
Bitcoin Trader publishes information, not investment advice. Crypto assets are volatile and losses are possible; this piece explains cryptography in ordinary terms and recommends nothing.
What does a private key actually look like?
A bitcoin private key is a 256-bit random number — effectively a digit between one and about 10 to the 77th power. From it, elliptic-curve multiplication over the secp256k1 curve derives the public key, and the public key is then hashed into the familiar address formats. The direction of the math matters: going from private to public is a one-way trip that costs microseconds, while reversing it is, as far as anyone has shown, computationally infeasible.
Modern wallets do not juggle single keys. BIP 32 hierarchical derivation turns one master secret into billions of child keys organized in a tree, which is why a twelve-word seed phrase can back up countless addresses. Each derived key independently signs, and each address stands alone to outside observers.
What exactly is being signed?
Not a message about intent — the transaction data itself. The wallet serializes the inputs being spent, the outputs and amounts, fee data and metadata, and computes the hash of that byte string. The signature is produced over this hash, so any edit to the transaction, down to one satoshi in any output, invalidates the signature.
This is the anti-tamper property. A party cannot take your approval of a 0.1 BTC payment and rewrite it into 1 BTC: the signature covers the whole construction, and nodes replay the identical check. It is also why the device screen deserves attention before signing — the signature faithfully approves whatever data it was given, whether or not the display showed it honestly.
ECDSA versus Schnorr: what changed with Taproot?
ECDSA, Bitcoin's original algorithm, works but has an awkward property: signatures involve a random nonce, and reusing or partially leaking that nonce across two signatures has let attackers recover private keys in real incidents across the industry. Schnorr, enabled for bitcoin by the Taproot upgrade that activated in November 2021, is deterministic in construction and simpler to prove secure.
Schnorr also composes. Multiple signatures can be aggregated so a k-of-k multisig looks identical on-chain to a single signature — same size, same appearance — which improves both capacity and privacy for complex spending policies. Wallets adopting Taproot paths get these properties; legacy addresses continue on ECDSA, and the two interoperate at the protocol level.
How do multiple devices sign the same transaction?
Partially signed bitcoin transactions — PSBT — are the coordination format. One wallet builds the transaction and exports a file containing the structure with no signatures; each signer adds its signature in turn, offline if desired, and the final collector merges everything into a broadcast-ready transaction. Hardware wallets and multisig quorums depend on PSBT because no single machine ever holds all the keys.
Air-gapped devices often carry PSBTs by QR code or SD card, keeping the signing machines physically disconnected. The choreography is deliberate friction: construction, review, sign, merge — four steps that each happen where they can be checked.
Can a signature leak the key?
Used correctly, no; used sloppily, historically yes. The known failure is nonce reuse in ECDSA — the PlayStation 3 key recovery and a series of bitcoin wallet incidents in the early 2010s all traced to repeated or biased nonces. Modern wallets derive nonces deterministically from the key and message, which removes the randomness that caused those failures.
The longer-horizon question is quantum computing. Bitcoin's curve cryptography is vulnerable in principle to a sufficiently large fault-tolerant quantum computer, and no such machine exists today; NIST finalized its first post-quantum cryptography standards in August 2024 so that systems can migrate before one does. Bitcoin's public keys behind hashed addresses add a layer of protection until a spend reveals them, and migration would itself be a protocol change on the scale of past soft forks.
What should a user verify before signing?
Three things, all displayed on the signing device rather than the computer: the recipient address, the amount, and the fee. Address-malware attacks work by swapping destinations on the computer screen while the device shows the truth; the signature step is the last honest checkpoint. Small test sends and hardware-screen verification are the boring disciplines that defeat them.
The signature itself will faithfully approve whatever it is fed. That is its virtue — and the reason the human reading the screen is part of the cryptosystem.
Why do addresses look so different from each other?
Bitcoin addresses are encodings of verification information, and three generations coexist. Legacy addresses begin with a 1 and commit to the hash of an ECDSA public key. SegWit addresses — the ones starting with bc1q and using Bech32 encoding — carry the same structure with witness data separated, lowering fees per spend. Taproot addresses, bc1p, commit to a Schnorr key and enable the aggregated signatures described above. All three remain spendable; the differences are efficiency and capability, with each newer format cheaper to spend from and more private for complex scripts.
Bech32 itself was a BIP-mandated design decision worth noticing: its alphabet excludes visually confusable characters and its error-detection code catches most typos outright — address-malware works precisely because addresses are not human-readable, and better encodings shrink the human-error surface without pretending to eliminate it. The address is not the destination; it is a commitment to the keys that can spend from it — which is why verifying on the signing device, character by character at the edges, remains the discipline no encoding replaces.
What is a watch-only wallet?
A watch-only wallet imports an extended public key — the master public half of a BIP 32 derivation tree — and can generate every address and observe every balance without ever holding a private key. It is the operational split at the heart of cold storage: the online machine runs the watch-only wallet, building transactions and tracking activity, while the keys live offline and sign only what the watch-only side prepares, via PSBT.
The power and the peril are the same xpub. Anyone holding it can see every address in the tree and every balance — total visibility, zero spendability — so leaking an extended public key is a privacy catastrophe rather than a theft. Wallet software that shares xpubs for convenience, including some backup and portfolio tools, transmits exactly that surveillance surface, which is why the export control on public keys, not just private ones, is part of serious wallet hygiene.
For more context, read How Bitcoin Cold Storage and Self-Custody Work.
For more context, read bitcoin improvement proposal.
For more context, read What a Bitcoin UTXO Is and Why It Matters.
