A valid transaction requires info from the blockchain and a signature from the owner's secret key. Key management - keeping the private key secret and secure - is central.
Store key in a file on computer or phone. Very convenient; as secure as your device.
Device compromised → key leaked → coins stolen. Device lost/wiped → key lost → coins lost.
Best of both: use separate keys for hot and cold. Move coins between them; each side needs the other's addresses. If hot is compromised, cold coins stay safe if keys are separate.
Problem: Want a new address per coin sent to cold. Cold is offline - how can hot learn new addresses?
Generate a big batch of addresses/keys, transfer to hot beforehand. Drawback: hot must reconnect with cold periodically for more.
Instead of single (sk, pk), generate address generation info and private key generation info. From these, derive sequences of addresses and keys such that the ith address pairs with the ith key. Address gen info does not leak private keys. Bitcoin's ECDSA supports this.
Encrypt info under passphrase user remembers
Print on paper; lock it up. Can rot, be lost, torn, stolen.
Signs for you but won't divulge keys
Exchanges accept deposits of Bitcoin and fiat ($, €). Let customers make/receive payments and buy/sell BTC for fiat. Like banks: promise to pay back on demand.
Two parts: (1) Prove you have at least X reserve - publish valid payment-to-self of that amount; sign challenge with same key. (2) Prove customers have at most Y deposited. Reserve fraction ≥ X/Y. No central regulator required.
Binary tree of hash pointers; each node includes total value in its subtree. Root value = total liabilities. Each customer gets O(log n) items to verify inclusion; if every customer checks, every branch is explored.
Two Merkle trees comparable if same hash depth. Same root hashes ⇒ data blocks the same. In a Bitcoin block, Merkle root stored in block header.
Bitcoin addresses = public key hashes (not real identities) → pseudonymity. In CS: anonymity = pseudonymity + unlinkability.
Trivial to create new address; best practice = fresh address per receive. Still linkable:
Identifying users: flows through exchanges (traceable); address–identity links in forums; high centralization in service providers.
Proposed by Greg Maxwell. Each signature is separate; mixing principles apply on top of the protocol. Single transaction mixes coins from a group.
Participants must exchange addresses so even other peers don't know input→output mapping. Need anonymous communication (e.g., Tor) for inputs. Outputs need not be communicated securely.
Goal: Prove knowledge of x at time t (optionally without revealing x). Publishing H(x) is a commitment to x - can reveal later. Applications: proof of knowledge, proof of receipt, hash-based signatures.
Send money to hash of data. Burns coins. Pros: compatible, easy. Cons: unspendable UTXO forever; miners must check forever.
Encode data into private key; exploit ECDSA property (bad randomness leaks key). Avoids burning; miners don't track unspendable. Very complex.
Instruction returns error; data never executed. Encode arbitrary data (e.g., 80 bytes). Preferred since 2014.
Websites collect commitments, combine into Merkle tree, publish one output with tree root - batched timestamping.
Use Bitcoin as append-only log; write overlay currency data via unspendable outputs. No new consensus mechanism needed.
Pros: Smart contracts, user-defined currencies; no new consensus. Cons: Still dependent on Bitcoin; inefficient - overlay must process lots of data (nodes don't filter).