The Double Spending Problem

Unlike physical cash, which can’t be in two places at once, digital information can be duplicated easily. This opens up the risk that someone could copy a digital coin and try to spend it in multiple transactions, essentially creating fake money. Digital signatures provide a solution to prevent it, but again this requires a trusted authority / third party. The paper proposes a solution to eliminate the mediatories and create a purely pure-to-peer version of electronic cash while addressing the Double Spending Problem.

For more detailed information read the Whitepaper.

I tried to compress the paper as small as possible and this mostly contains my inferences and idea on reading the paper.

The Proof

The trust factor has many problems, so replace it with cryptographic proof. A peer-to-peer distributed timestamp server is created, which is the computational proof of the chronological order of all the transactions.

The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power.

Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.

The system is secure until and unless the majority CPU power is controlled by honest nodes which collectively controls more CPU power than any cooperating group of attacker nodes.

What is an electronic coin?

We define an electronic coin as a chain of digital signatures.

Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.

Again we face the problem of double spending here. We could have created a mint (or trusted authority) but the entire fait of the coin would depend upon the authority. Instead, what do we need? We need to know the history of the coin to understand whether the user has already done a transaction on this or not. That’s what the mint does, it has all the records and verifies that for double spending. But, we could make all the transaction history of the coin public and create a system for participants to agree on a single history of the order in which they were received.

The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received

The Timestamp Server

This is where the solution to our electronic coin begins. The Timestamp Server records the exact time when a transaction happened.

The Proof of Work System

It is a method in which computers must perform a computationally hard task to prove they did some work.

In bitcoin, the Proof of Work is to find a number (called a nonce) that when hashed together with block’s data using SHA-256, gives a result that starts with a bunch of zeros. Because hashes can’t be predicted, the only way to complete this task is by trail and error. To change the difficulty of computation to find the hash, the number of leading zeros can be changed. Although, it is hard to find the hash, verifying it is quick.

  • Bitcoin miners keep incrementing a number (nonce) inside the block and hash it repeatedly until they find a valid hash.

Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.

The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.

The Network

The steps involved in running the network ob a transaction are:

broadcast transaction to all nodes -> collect transactions into a block -> find difficult proof of work for its block -> if found, broadcast the block to all nodes -> nodes accept if all transactions are valid in it and are not already spent -> nodes create next block in the chain using the hash of the accepted block as the previous hash.

Nodes always consider the longest chain to be the correct one and will keep working on extending it.

The Incentive System

The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.

The first transaction in a block is a special transaction (called coinbase transaction) and it starts a new coin. This offers as a reward for doing the work (validating transactions and securing the blockchain). Besides the block reward, miners also get fees from transactions.

  • If an attacker controls more computing power, they could try to double spend or rewrite history but doing so is hard, expensive, and undermines trust in the system, which reduces the value of their own coins.

He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.

The Deflationary Model

Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.

Bitcoin has a hard cap of 21 million coins. Over time, block rewards halve roughly every 4 years (halving events). Eventually, rewards will become zero, and miners will rely entirely on transaction fees. This makes Bitcoin non-inflationary — it won’t keep creating new coins forever.

Reclaiming Disk Space

Once a coin has moved and its spending is buried deeply, we no longer need to share the old transactions that created or moved it before, because we can trust the chain at this point. To facilitate this, a Merkle Tree (also known as Hash Tree) data structure is used. You don’t need to store the entire tree, you can just store the Merkle Root and enough hashes to reconstruct the proof when needed. This reduces storage needs significantly.

…with only the root included in the block’s hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored.

Simplified Payment Verification

It is possible to verify payments without running a full network node. By linking the transaction in a place in the chain, he can check that the network nodes have accepted it and the blocks added after confirm that the network accepted it.

… Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.

One more Problem

In theory, Bitcoin could have been designed like cash with fixed denominations (e.g., 1 BTC, 0.01 BTC, etc.), and you’d use many small “coins” to make a payment. But that would be very inefficient, especially for small transactions like paying 0.005 BTC — you’d need thousands of tiny units.

In real life, let’s say you’re buying something for ₹170 and you only have 2 ₹100 note, 1 ₹50 note, and 1 ₹20 note. You can either give 1 of each to total ₹170 or you can give 2 ₹100 notes to total ₹200 and the shopkeeper returns ₹30 back to you. The same idea is applied here.

Combining and Splitting Value

This gives the solution to the above problem.

Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.

UTXO: previous unspent transaction output

  • If you have a single large UTXO (e.g., 1 BTC), you use that as one input.
  • If your wallet has many small UTXOs (e.g., 0.2 BTC + 0.3 BTC + 0.5 BTC), you can combine them as multiple inputs.
  • One output goes to the recipient.
  • One output returns leftover BTC (change) to your own address.

Bitcoin doesn’t require to extract the entire transaction history of a coin. The only two things it requires is that the coin is valid and it is unspent to complete the transaction.

Basic Idea

In Bitcoin, when you create a wallet, it generates a key pair:

  • A private key (secret, used to sign transactions).
  • A public key (used to generate your Bitcoin address, visible on the blockchain).

Anyone can send Bitcoin to your address (public key), but only you can spend it using your private key.

Privacy

If the blockchain is public, everyone can see every transaction. The privacy is maintained by maintaining anonymity. This is done by keeping the public keys anonymous.

The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone.

Firewall

As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner.

If you reuse the same public key over and over: Public can see all your incoming and outgoing transactions. An attacker could potentially link your identity to your address. This is called address clustering — a technique used in blockchain forensics.

Many modern wallets (e.g., Electrum, Ledger, BlueWallet) automatically create a new address for each payment.

The Security Model

The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. … The probability of an attacker catching up from a given deficit is analogous to a Gambler’s Ruin problem.

Doing some mathematical calculations that I didn’t understand a shit, The probability that an attacker with less hashing power (q) can catch up with the honest blockchain after falling z blocks behind drops exponentially with each additional block (z) of confirmation.

A transaction is considered confirmed when it is included in a block on the Bitcoin blockchain. But that’s just the first confirmation. Each new block added to the chain after that increases the number of confirmations.

For low attacker power (e.g., q = 0.1 or 10%), even just 5-6 confirmations are enough to make the chance of success less than 0.1%.

As the attacker’s hash power increases, more confirmations are required to achieve the same level of security:

  • q = 0.2 → need z = 11 blocks
  • q = 0.3 → need z = 24 blocks
  • q = 0.4 → need z = 89 blocks
  • q = 0.45 → need z = 340 blocks

This exponential decay of success probability ensures that as long as the attacker has less than 50% of the hash power, the cost and time to overtake the honest chain becomes infeasible very quickly.

Conclusion

Electronic transactions with digital signatures were incomplete without a way to prevent double spending. Thus, bitcoin proposed a peer-to-peer network using proof-of-work to record a public history of transactions. The network is robust in its unstructured simplicity.