How Does Crypto Actually Work? Keys, Consensus, and Transactions

What does it mean to own cryptocurrency?

The familiar phrase "the coins are in your wallet" is a useful interface metaphor and a poor technical description. A blockchain stores state: unspent outputs on Bitcoin, account balances and contract storage on Ethereum, or program-owned accounts on Solana. A wallet reads that state, constructs instructions and produces whatever authorisation the network requires.

For a conventional self-custody account, that authority may reduce to one private key. But the broader rule is more accurate: ownership is control of the valid spending policy. A Bitcoin output can require a script or multiple signatures. An Ethereum contract account can require multisignature approval, a passkey module, a timelock or social recovery. A threshold-signing system can distribute one signing authority across several key shares. A custodian can hold the cryptographic authority while the customer holds only a contractual claim against the custodian.

This distinction explains why "not your keys, not your coins" is a warning about counterparty exposure rather than a complete security strategy. Holding the keys removes one intermediary and adds direct operational responsibility. Neither custody model is automatically safe merely because it is labelled centralised or self-custodial.

What do private keys, public keys and addresses actually do?

Most major chains use public-key cryptography for digital signatures. The wallet generates or accesses secret material, derives public information and creates a signature over a precisely defined message. Verification is fast; deriving the private key from the public key is considered computationally infeasible under the mathematical assumptions of the scheme and with correctly generated keys. "Infeasible" is the correct claim: security is conditional on the algorithm, implementation, random-number generation and current computing capabilities.

What a signature proves

A valid signature proves that the required secret or signing quorum authorised a particular digest under the specified signature algorithm. It also lets a verifier detect changes to the signed payload. It does not prove that the signer read the wallet screen, understood a token approval, knew the recipient, was not coerced, or owned the funds in a legal sense. That gap between cryptographic authorisation and human intent is where many wallet drainers and impersonation scams operate.

What can undermine signature security?

• Weak or biased key generation that produces guessable secret material.
• Nonce reuse or leakage in ECDSA or Schnorr-style signatures, which can expose a private key.
• Malware, side channels or physical attacks that extract secret material from a device.
• A wallet signing a different payload from the one the user believed it displayed.
• A smart-account, multisig or threshold implementation accepting an invalid or unauthorised policy path.
• Future cryptanalytic or quantum advances that invalidate current hardness assumptions.

Takeaway: Public-key cryptography removes the need to reveal the secret during verification. It does not remove the need for secure key generation, trustworthy signing software and accurate transaction review.

What exactly does a wallet sign?

The wallet interface turns human intent into a structured message. That translation is security-critical. On Bitcoin, the transaction selects specific unspent outputs as inputs, creates new outputs with spending conditions, specifies amounts and fees, and applies a signature-hash mode that determines which parts each signature commits to. On Ethereum, a normal transaction includes fields such as chain identifier, account nonce, destination, value, gas limit, fee caps and optional data that can invoke a contract.

Contract interactions can encode far more than a payment. A signature may approve a token allowance, trade through a decentralised exchange, delegate an EOA to code under EIP-7702, transfer an NFT, vote in a governance system or call a function whose outcome depends on current on-chain state. The network sees valid bytes; it does not know whether the wallet explained them well.

Before signing, verify at least these fields

• Network and chain: the intended chain, Layer 2 or sidechain, not merely the asset ticker.
• Asset and contract: the correct native asset or token contract, including decimals and token standard.
• Destination: the full recipient, contract, bridge or exchange deposit address and any required memo or tag.
• Amount and scope: exact transfer amount, minimum received amount, spending cap or approval scope.
• Action: transfer, swap, approval, permit, delegation, staking action, contract deployment or arbitrary message signature.
• Fee bounds: Bitcoin feerate and total fee, or Ethereum gas limit, base-fee exposure, priority fee and maximum fee.
• Expiry and replay domain: chain identifier, nonce, deadline and the application or contract for which the signature is valid.
• Policy path: which keys, co-signers, modules or recovery mechanisms are authorising the action.

Hardware wallets help, but they do not understand economics

A hardware wallet can keep a private key away from a general-purpose computer and sign only after confirmation on a trusted display. That protects against many extraction attacks. It cannot make a malicious approval harmless, prove that a contract address is reputable, detect every address-poisoning substitution or guarantee that a shortened display contains enough information. A secure device is most useful when the user can independently interpret what it shows.

What happens after you press Send?

Step 1: local construction and signing

The wallet chooses inputs or the next account nonce, estimates fees, creates the payload and signs it. This can happen on a phone, in a browser wallet, on a hardware device, through a multisignature coordinator or across an MPC signing session. The secret key should not be transmitted to the network; only the transaction and signature are needed for verification.

Step 2: node validation and relay

The first node checks syntax, signatures, available funds or UTXOs, nonce, size, gas and other rules. It also applies local policy: a transaction can be consensus-valid yet not meet a node's relay or mempool requirements. Nodes have independent pending pools and can disagree about what they currently hold. There is no single global mempool that every machine shares.

Step 3: block construction

Bitcoin mining pools build candidate blocks from valid transactions they know about, considering fees, dependencies and their own policies. Ethereum validators may build locally or use specialised builders that optimise transaction ordering and bid for the proposal opportunity. Private order flow can bypass the public mempool, and maximal extractable value can affect ordering.

Step 4: independent block verification

After a block is proposed, other nodes do not accept it because the producer is trusted. They independently verify the block and every relevant state transition. A producer that includes an invalid spend, exceeds limits or violates consensus rules creates a block that honest nodes reject, regardless of its fee revenue or resource weight.

Step 5: inclusion, reorganisation and settlement

Inclusion is the first confirmation. Competing blocks can briefly exist at the chain tip, and the fork-choice rule determines which branch becomes canonical. Transactions from an abandoned block may return to pending, conflict with another transaction or disappear from a node's view. Deeper confirmations or explicit checkpoint finality reduce this risk.

Why do transactions wait, and how do fees work?

Bitcoin: paying for virtual block space

Bitcoin transaction fees are the difference between input value and output value. Wallets and Bitcoin Core commonly express the bid as satoshis per virtual byte (sat/vB), which lets miners compare transactions of different virtual sizes. Inputs, outputs and witness data determine size; the amount of bitcoin transferred does not.

Dependencies matter. A low-fee parent and high-fee child may be evaluated together, and current Bitcoin Core mempool logic reasons about connected transaction groups rather than treating every transaction as fully independent. Replace-by-fee and child-pays-for-parent can improve inclusion when the transaction and wallet support them. A replacement is not a guaranteed cancellation: competing transactions race until one confirms.

Ethereum: gas, base fee and priority fee

Ethereum charges for computation and state access in units of gas. A transaction sets a gas limit and fee caps. The protocol calculates a base fee that is burned; the sender can add a priority fee, and the maximum fee limits the per-gas price. Unused gas is not charged. A contract call that reverts can still consume gas, because validators executed the computation.

Ethereum account transactions execute in nonce order. An underpriced or unseen earlier nonce can block later transactions from the same account even when those later transactions offer higher fees. A same-nonce replacement can supersede a pending transaction if the receiving node or wallet policy accepts the higher bid.

Ordering is not only a fee leaderboard

On Ethereum, builders and searchers may order bundles to capture arbitrage, liquidations or other MEV. Users may submit through private channels to reduce public exposure. On Bitcoin, pools can apply custom policies or include transactions received out of band. Fees remain central, but "highest fee always goes first" is an oversimplification.

Takeaway: The fee market prices scarce inclusion resources. It does not verify the recipient, guarantee the application's honesty or compensate for a transaction signed under false pretences.

How do Bitcoin, Ethereum and Solana record ownership?

Bitcoin: the UTXO model

A Bitcoin wallet balance is a convenient sum of unspent transaction outputs it can satisfy. A transaction consumes existing outputs and creates new ones. Inputs point to earlier outputs; scripts and signatures prove the spending conditions are met. If input value exceeds the intended payment and fee, the wallet normally creates a change output.

Ethereum: account and contract state

Ethereum maintains a global state containing externally owned accounts and contract accounts. An EOA has a balance, nonce and key-based authority; a contract account has code and storage. A transaction from an EOA can transfer ETH, deploy a contract or call code that updates many accounts and token ledgers in one atomic execution.

Solana: program-owned accounts

Solana separates executable programs from the accounts that hold mutable data. Each account has an address and an owner program that controls changes to its data or debits. User signer accounts use public-key addresses, while program-derived addresses let a program authorise for deterministic off-curve accounts without a private key.

Takeaway: "The blockchain stores balances" is accurate for some systems and misleading for others. The durable idea is that nodes maintain a deterministic state derived from accepted transactions and blocks.

What does blockchain consensus actually include?

Validity comes first

Every full node evaluates blocks against the rules it runs. Bitcoin nodes verify scripts, UTXO availability, block structure and monetary constraints. Ethereum execution clients verify transactions and state transitions while consensus clients verify proposer and attestation rules. A block that fails validity does not enter the valid-chain competition at all.

Sybil resistance and proposer selection

Open networks need a way to prevent one participant from gaining influence by creating millions of identities. Proof of work ties influence to computational work; proof of stake ties it to bonded capital. Each mechanism allocates block-production or voting opportunities according to a scarce resource.

Fork choice

Temporary disagreement is normal in distributed systems. Bitcoin nodes choose the valid chain with the greatest accumulated proof of work. Ethereum uses LMD-GHOST to follow the valid branch with the greatest effective attestation weight. Fork choice answers which current branch to build on; it is not the same as finality.

Finality and recovery

Bitcoin does not label a block permanently final; confidence increases with depth. Ethereum uses Casper FFG checkpoints to create an explicit finalised state when the required supermajority votes are present. If Ethereum ever produced conflicting finalised histories, protocol messages alone could not choose between them; recovery would require social coordination.

How does proof of work secure Bitcoin?

A miner assembles a candidate block, varies header fields and computes SHA-256 hashes. Each hash is a lottery ticket. The protocol adjusts difficulty every 2,016 blocks so that blocks average roughly ten minutes over time. The winning miner receives the block subsidy - 3.125 BTC since the April 2024 halving - plus transaction fees, provided the block is valid and accepted by the network.

The energy cost is not used to compute ordinary transaction validity. It makes producing an alternative chain expensive and gives nodes an objective accumulated-work rule for choosing between valid branches. Once electricity is consumed, it cannot be recovered; specialised hardware may retain resale or mining value. Security therefore depends on the distribution of hashpower, hardware and energy access, pool coordination, network connectivity and the economic value at risk.

What majority hashpower can and cannot do

The phrase "51 percent attack" is shorthand. Below half, an attacker can still have a non-zero chance of replacing shallow history; above half, sustained domination becomes reliable under simplified assumptions. The practical risk depends on duration, network conditions and how quickly recipients respond by delaying settlement.

Takeaway: Proof of work governs competition between valid histories. It does not give miners authority to rewrite signature rules, seize arbitrary coins or redefine supply for nodes that reject those changes.

How does proof of stake secure Ethereum?

Time is divided into 12-second slots and 32-slot epochs. One validator is selected to propose a block in a slot, while committees attest to their view of the chain. Every active validator normally attests once per epoch. After Pectra, 32 ETH remains the activation minimum; validators that opt into compounding credentials can have an effective balance up to 2,048 ETH.

Ethereum uses separate key roles. Validator duties use BLS signing keys so attestations can be aggregated efficiently. Withdrawal authority can be held separately and, after Pectra, execution-layer credentials can trigger exits. A normal Ethereum EOA key is therefore not automatically the same key that performs validator duties.

Attack thresholds describe different capabilities

Slashing and inactivity are different

Slashing punishes specific contradictory signatures such as double proposals, double votes or surround votes. The immediate loss for an isolated validator is not necessarily its entire balance; correlated mass slashing can impose far larger losses. Validators that are merely offline usually incur smaller penalties. If finality stops for more than four epochs, the inactivity leak gradually reduces inactive effective balances until the remaining active validators can regain a two-thirds supermajority.

Takeaway: Proof of stake places capital inside the protocol's penalty system, but "an attack burns all stake" is false. Capabilities, evidence and penalties differ by attack, and catastrophic safety recovery includes a social layer.

When is a crypto transaction final?

Bitcoin: confirmation depth

The block containing a transaction is confirmation number one. Each later block increases the accumulated work an attacker would need to replace it. Six confirmations, about an hour on average, is a common convention for high-value settlement, not a universal rule or a guarantee. Small payments may be accepted sooner; extremely valuable or adversarial transactions may justify more depth.

Ethereum: latest, safe and finalised

Ethereum clients can distinguish the newest canonical head from a safe view and a finalised view. Finality means reverting the block would require a critical consensus failure and make at least one-third of total staked ETH provably slashable and burnt from the validators responsible, with the exact penalty scaling with how many are slashed together. It is a cryptoeconomic guarantee, not a claim that software, governance or social recovery are metaphysically incapable of changing history.

Layer 2 systems add more clocks

A transaction on a rollup or other Layer 2 can be accepted by the sequencer before its data or proof is posted to the base layer. Optimistic systems may have challenge periods; validity-proof systems wait for proof generation and verification; bridges and exchanges may add their own thresholds. "Confirmed on the Layer 2" and "settled on Ethereum" are not always the same event.

Takeaway: Finality is network-specific and recipient-specific. The correct threshold depends on the chain, transaction value, adversary model and whether another settlement layer is involved.

Where does crypto security actually fail?

The source article framed the protocol as essentially unbroken and the key layer as the location of nearly every loss. That is too absolute. Major signature schemes have resisted practical forgery under their intended assumptions, and Bitcoin and Ethereum have strong production records. But blockchain software has contained serious consensus and inflation vulnerabilities, applications have lost assets through contract and bridge failures, custodians have failed, and users have authorised malicious transactions.

Where ordinary users are most exposed

For plain self-custody, the signing path is often the decisive operational risk: a stolen recovery phrase or malicious signature can authorise a valid transfer that the blockchain executes exactly as designed. Across the wider ecosystem, however, losses also arise from exchanges, custodians, smart contracts, bridges, oracles, governance and operational compromise. Security effort should match the actual system being used, not one slogan.

Robustness is conditional, not magical

A network can be difficult to rewrite and still host a fraudulent token. A transaction can be final and still be sent to the wrong address. A hardware wallet can keep the key secret and still sign a malicious permit. A decentralised protocol can depend on a centralised front end or bridge. The correct question is always: which property is protected against which adversary, under which assumptions?

What does cryptocurrency not guarantee?

Takeaway: Blockchains are specialised verification systems. Their strength comes from narrow, explicit rules; treating them as universal truth machines creates the very misunderstandings that attackers exploit.

How can keys and wallets be held?

Recovery phrases and deterministic wallets

Many self-custody wallets use a hierarchical deterministic design. A BIP39-style phrase encodes entropy and, together with an optional passphrase, derives a binary seed from which a wallet can generate many private keys and addresses. It is therefore not literally "one private key written as words". Wallet standards, derivation paths and passphrase use must match during restoration.

Single-key software and hardware wallets

A software wallet keeps signing material on an internet-connected device or protected operating-system enclave. A hardware wallet isolates signing in a dedicated device and can reduce extraction risk. Both can fail through bad backups, malicious firmware or software, weak transaction review, physical compromise or user error.

On-chain multisignature and smart accounts

Multisig scripts and smart-contract accounts can require several approvals, enforce spending limits, add timelocks or support recovery roles. Their rules are visible and enforced on-chain, but security depends on code, signer independence, upgrade authority and the recovery process. Ethereum's EIP-7702 expands the ability of EOAs to use delegated wallet code without changing address, which increases both capability and policy complexity.

Threshold cryptography and MPC

Threshold signing distributes the ability to produce one signature across key shares. In a properly designed distributed-key-generation lifecycle, the complete private key need never exist in one place. This can reduce single-device failure, but it adds interactive protocol, coordinator, implementation, availability and share-independence assumptions. It is not simply "multisig without fees".

Questions every custody design should answer

• What exact signature, script or contract action can move the assets?
• Which people, devices, services or code paths can satisfy that authority?
• What happens if one device is stolen, one person is unavailable or one provider fails?
• What happens if recovery material leaks but no transaction has yet been signed?
• Can a malicious transaction be limited by value, destination, time delay or policy review?
• How are software updates, signer replacement, share refresh and emergency response governed?
• How will heirs or authorised successors recover access without giving one person a standing theft path?
• Has the recovery process been tested with small amounts before it is needed under pressure?

Takeaway: The key is one component of an authorisation and recovery system. Good custody designs survive foreseeable loss, compromise and human unavailability without creating an easier theft path.

Frequently asked questions

How does cryptocurrency work in simple terms?

A wallet creates and signs a transaction, independent nodes verify it, a miner or validator includes it in a block, and consensus rules determine which valid block history becomes canonical. More blocks or checkpoint votes reduce the chance of reversal until the recipient treats the transaction as settled.

Does a crypto wallet actually hold coins?

Usually no. The blockchain records spendable outputs, account balances or token state. The wallet manages addresses, transaction construction and the keys or policies that can authorise changes to that state.

Is a wallet address the same as a public key?

Not universally. An Ethereum EOA address is derived from a public key; a standard Solana signer address is the public key; Bitcoin addresses can encode key hashes, scripts or Taproot output keys; contract and program-derived addresses can exist without a corresponding private key.

Can someone steal my crypto from my public address alone?

A public address normally grants no spending authority. However, it can reveal balances and transaction history, attract phishing or address-poisoning attacks, and help an attacker identify a valuable target. Theft still requires a valid authority path, such as a stolen key, malicious signature, contract bug or compromised custodian.

Can a blockchain itself be hacked?

Cryptographic forgery and deep consensus attacks are only part of the risk. Major networks have strong security records, but client software has contained critical bugs, applications and bridges have been exploited, and custodians and users have been compromised. "The blockchain was hacked" is often imprecise; identify the actual failed layer.

Are crypto transactions irreversible?

A pending transaction can be replaced or dropped under some conditions, and a shallow confirmed transaction can be removed by a reorganisation. After an appropriate settlement threshold, protocol reversal becomes extremely difficult, but account recovery, recipient cooperation, custodial intervention or legal seizure can still change the practical outcome in some systems.

How long does a crypto transaction take?

It depends on the network, fee, congestion, routing and settlement threshold. Bitcoin targets roughly ten-minute blocks; Ethereum uses 12-second slots and normally reaches checkpoint finality after about two epochs. Layer 2 systems and exchanges add their own clocks.

Do miners or validators control the blockchain?

They influence block production and ordering, but they do not have unilateral authority over validity. Full nodes independently reject blocks that violate the rules they run. Governance over rule changes is distributed across software maintainers, node operators, resource providers, applications, businesses and users.

What happens if I lose my private key?

If no backup, co-signer, custodian or recovery policy can satisfy the account's authority, the assets remain recorded but become unspendable. Smart accounts, multisig and custodial systems can have different recovery paths; a conventional single-key address does not have a network password reset.

Why do crypto fees change?

Demand for scarce block or execution capacity changes. Bitcoin bids for virtual block space; Ethereum prices gas with a protocol base fee and priority fee. Dependencies, nonce order, private order flow, builder strategies and local policy also affect inclusion.

Is cryptocurrency anonymous?

Usually not. Many public chains are pseudonymous: addresses are public and transaction history is permanent, while identity links can be inferred from exchanges, network data, counterparties and behavioural patterns.

What does "not your keys, not your coins" mean?

It means that when a custodian controls the on-chain keys, the customer depends on that custodian to honour withdrawals and remain secure and solvent. It does not mean self-custody is automatically safe; direct key control adds backup, signing and recovery responsibilities.

The bottom line

Cryptocurrency works because several narrow mechanisms cooperate. A signing policy turns authority into verifiable cryptographic evidence. A transaction encodes an exact proposed state change. Nodes verify that proposal against deterministic rules. Block producers order valid proposals, and consensus determines which valid history the network follows. Settlement rules then tell recipients when reorganisation risk is low enough for the value at stake.

The strongest mental model is not "mathematics replaces trust". Trust is redistributed and made more explicit. Users trust cryptographic assumptions, software implementations, hardware, network participation, smart-contract code, wallet interfaces and their own recovery design. Public verification reduces dependence on one record keeper; it does not remove every dependency or every form of governance.

That is also why security advice must name the layer. Protecting a recovery phrase does not audit a bridge. Waiting for finality does not make a token valuable. A hardware wallet does not explain a malicious permit. A decentralised validator set does not guarantee a decentralised front end. Crypto is powerful precisely because its guarantees are specific. Use those guarantees where they apply, and do not silently extend them to problems they were never designed to solve.

Sources and further reading

Key references for this article, current as of July 2026.

• Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf
• Bitcoin Developer Guide - Transactions. https://developer.bitcoin.org/devguide/transactions.html
• Bitcoin Developer Guide - Block Chain. https://developer.bitcoin.org/devguide/block_chain.html
• Bitcoin Developer Guide - Mining. https://developer.bitcoin.org/devguide/mining.html
• BIP 340 - Schnorr Signatures for secp256k1. https://bips.dev/340/
• BIP 341 - Taproot. https://bips.dev/341/
• Ethereum.org - Accounts. https://ethereum.org/developers/docs/accounts/
• Ethereum.org - Transactions. https://ethereum.org/developers/docs/transactions/
• Ethereum.org - Gas and fees. https://ethereum.org/developers/docs/gas/
• Ethereum.org - Consensus mechanisms. https://ethereum.org/developers/docs/consensus-mechanisms/
• Ethereum.org - Proof of stake. https://ethereum.org/developers/docs/consensus-mechanisms/pos/
• Ethereum.org - Gasper. https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/