Bitcoin Whitepaper (Bahasa Indonesia)

·

Bitcoin: A Peer-to-Peer Electronic Cash System

Satoshi Nakamoto
[email protected]
www.bitcoin.org

Translated into Indonesian from bitcoin.org/bitcoin.pdf
by Gregorius Airlangga & K Hendrawan

Abstract. A purely peer-to-peer version of electronic cash allows online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain serves not only as a witness to the sequence of events but also proves that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they will generate the longest chain and outpace potential attackers. The network itself is robustly simple. 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 transpired during their absence.

Introduction

Traditional online commerce relies heavily on financial institutions as trusted intermediaries for processing electronic payments. While this model works adequately for most transactions, it inherits systemic weaknesses rooted in trust dependency. Fully irreversible transactions are unfeasible since intermediaries must mediate disputes, leading to higher transaction costs, minimum transfer thresholds, and the loss of opportunity for small, everyday payments. Reversible transactions also necessitate greater trust, pushing merchants to collect excessive customer data and accept fraud as an inevitable cost.

Although physical cash avoids these issues personally, no mechanism previously enabled trustless digital payments over communication channels. What’s needed is a cryptographic proof-based electronic payment system that allows two parties to transact directly without third-party oversight. Computationally irreversible transactions can protect sellers from fraud, while standard escrow mechanisms can safeguard buyers.

This paper presents a solution to double-spending using a decentralized peer-to-peer timestamp server that establishes a chronological order of transactions. The system remains secure as long as honest nodes collectively control more CPU power than any colluding group of attacking nodes.

👉 Discover how blockchain technology powers modern financial freedom

Transactions

An electronic coin is defined as a chain of digital signatures. Each owner transfers value by digitally signing a hash of the previous transaction and the public key of the next owner, appending both to the coin. The payee verifies these signatures to confirm ownership history.

However, the core challenge lies in verifying that no prior owner has double-spent the coin. Conventional solutions rely on a central authority or mint that checks every transaction for duplication. In such models, each coin must be returned to the mint for reissuance, making only mint-issued coins trustworthy—centralizing financial control akin to banking systems.

Instead, we require a method for payees to confirm that previous owners haven't signed earlier transactions. Since only the earliest transaction counts, subsequent attempts at reuse are irrelevant. The sole way to verify absence is through public transparency: transactions must be broadcast widely, and participants must agree on their chronological order. A payee needs proof that, at the time of transaction, the majority of nodes accepted it first.

Timestamp Server

Our proposed solution begins with a timestamp server. This server takes a block of items to be timestamped, hashes them, and widely publishes the hash—similar to techniques used in newspaper or Usenet announcements [2–5]. The timestamp proves that data existed at that time, as it’s embedded within the hash. Each new timestamp includes the previous one in its hash, forming a chain where each addition strengthens all prior entries.

Proof-of-Work

To implement a decentralized peer-to-peer timestamp system, we adopt Adam Back’s Hashcash [6] proof-of-work mechanism instead of centralized publishing. Proof-of-work involves scanning for a value that, when hashed (e.g., via SHA-256), produces a result starting with a specified number of zero bits. The average effort required grows exponentially with the number of leading zeros, yet verification requires only one hash operation.

In our network, proof-of-work is achieved by incrementing a nonce in a block until the block’s hash meets the required zero-bit threshold. Once computed, altering the block demands repeating the work. If subsequent blocks are built upon it, changing any earlier block requires redoing all following proofs-of-work.

Proof-of-work also resolves the "majority decision" problem. Unlike one-IP-address-one-vote models vulnerable to IP spoofing, proof-of-work operates as one-CPU-one-vote. The longest chain represents consensus because it embodies the greatest cumulative computational effort. As long as honest nodes control most CPU power, they extend the valid chain faster than attackers.

An attacker attempting to alter past blocks must redo the target block’s proof-of-work and all subsequent blocks, then overtake the honest chain—an exponentially improbable feat as more blocks are added.

Difficulty adjusts dynamically based on hardware advancements and node participation, targeting a consistent block rate (e.g., one block every 10 minutes). If blocks are generated too quickly, difficulty increases.

Network Operations

The network functions through these steps:

  1. New transactions are broadcast to all nodes.
  2. Each node collects new transactions into a block.
  3. Nodes compete to find a valid proof-of-work for their block.
  4. Upon success, the node broadcasts the block to all others.
  5. Nodes accept the block only if all transactions are valid and unspent.
  6. Acceptance is signaled by building the next block on top, using the accepted block’s hash as the previous hash.

Nodes always recognize the longest chain as authoritative and strive to extend it. When two versions of a subsequent block are broadcast simultaneously, some nodes may receive one before the other. They work on the first received but retain the alternative branch in case it grows longer. The tie breaks when the next proof-of-work extends one branch; nodes then switch to the longer chain.

Transaction broadcasts don’t require universal delivery—reaching many nodes ensures inclusion in a block soon after. Similarly, occasional dropped block messages are tolerated; missing nodes request updates upon receiving later blocks.

👉 See how secure blockchain networks maintain trustless consensus

Incentive Mechanism

The first transaction in each block is a special transaction that creates new coins owned by the block creator—this serves as an incentive for nodes to support the network and enables initial coin distribution without central issuance.

This reward mirrors gold mining: just as miners expend resources to introduce gold into circulation, here CPU time and electricity are expended to generate new coins.

Transaction fees also contribute to incentives. When output values are less than inputs, the difference becomes a fee added to the block’s incentive. Once a predetermined coin supply is reached, incentives will transition entirely to fees—creating an inflation-free monetary system.

This structure discourages attacks: even a powerful attacker with superior CPU resources faces better returns by playing by the rules—earning new coins—than undermining the system and devaluing their own wealth.

Storage Space Recovery

Once a coin’s final transaction is buried under sufficient blocks, earlier transactions can be discarded to save space. Using Merkle Trees [7][2][5], transactions are hashed into a tree structure where only the root is included in the block hash—enabling old blocks to be pruned by trimming branches without breaking integrity.

A block header without transactions is about 80 bytes. At one block every 10 minutes, this amounts to roughly 4.2MB per year—well within manageable limits even if stored in memory, especially considering 2008-era computers with 2GB RAM and projected annual storage growth.

Simplified Payment Verification

Users can verify payments without running full nodes. By keeping only the block headers of the longest proof-of-work chain—and confirming its length via network queries—they can obtain Merkle branches linking their transaction to its timestamped block.

While users can’t validate transactions independently, linking them into the chain shows network acceptance. Subsequent blocks further confirm validity.

This method is reliable under honest majority control but vulnerable if attackers dominate. Full nodes remain immune; simplified methods may accept fake transactions during attacks. One mitigation is client alerts upon detecting invalid blocks, prompting full downloads for verification.

Frequent payment receivers may prefer running their own nodes for enhanced security and faster confirmation.

👉 Learn how decentralized networks empower user sovereignty

Value Splitting and Combining

Though possible to handle coins individually, managing micro-transactions per unit would be inefficient. Transactions support multiple inputs and outputs: typically one input from prior larger transaction(s), or several smaller ones combined; outputs include payment and optional change back to sender.

The “fan-out” effect—where transactions depend on others recursively—is not problematic. There's no need to extract standalone transaction histories.

Privacy

Traditional banking ensures privacy by restricting data access to involved parties and trusted intermediaries. Public transaction broadcasting prevents this model—but privacy persists through public key anonymity.

Observers see transfers between keys but cannot link them to real-world identities—similar to stock market data ("the tape") revealing trade times and sizes without participant names.

For stronger privacy, new key pairs should be used per transaction to avoid linkage. Multi-input transactions may reveal common ownership of inputs, potentially exposing other transactions by the same owner if identity is compromised.

Probability Analysis

We analyze an attacker attempting to outpace the honest chain. Success would allow reversing their own transaction—e.g., double-spending—but not creating money or stealing funds outright, as invalid transactions would be rejected by honest nodes.

The race between chains resembles a Binomial Random Walk:

The attacker’s chance of catching up mirrors the Gambler’s Ruin problem: probability drops exponentially with each additional block they trail behind.

Let:

Assuming _p > q_, catching up becomes increasingly improbable over time.

When receiving a new transaction, how long should a recipient wait before being confident it can’t be reversed? Suppose the sender plans to double-spend after some delay.

To prevent pre-mining attacks (where an attacker pre-builds a chain), recipients generate fresh keys and provide public keys only just before signing. Once sent, attackers begin secretly building an alternate chain.

Recipients wait until z confirmations (blocks added after). Assuming honest nodes follow expected timing, attacker progress follows a Poisson distribution with mean λ = z(q/p).

Final probability calculations show exponential decline in risk with increasing _z_. For instance:

Thus, six confirmations offer strong assurance against realistic attack scenarios.

Conclusion

We have proposed a trustless electronic transaction system built on digital signatures and decentralized consensus via proof-of-work. This network records transaction history publicly in an immutable ledger secured by computational majority rule.

Its strength lies in simplicity: minimal coordination, no identity requirements, best-effort message propagation, and dynamic node participation governed by CPU voting—validating blocks via extension and rejecting invalid ones passively.

All necessary rules and incentives are enforced organically through this consensus mechanism—establishing a resilient foundation for digital currency independent of institutional trust.

Frequently Asked Questions

Q: What is proof-of-work in Bitcoin?
A: Proof-of-work is a consensus mechanism requiring miners to solve computationally difficult puzzles to validate blocks and secure the network against manipulation.

Q: How does Bitcoin prevent double-spending?
A: By timestamping transactions into an immutable blockchain using cryptographic hashing and proof-of-work—ensuring only one valid transaction history exists.

Q: Can Bitcoin be used anonymously?
A: Bitcoin offers pseudonymity through public key addresses; while transactions are public, identities aren’t directly linked unless revealed through usage patterns or external data.

Q: What happens after all Bitcoins are mined?
A: Miners will continue earning rewards through transaction fees instead of block subsidies—maintaining economic incentives without inflation.

Q: Is simplified payment verification safe?
A: It’s secure under honest majority conditions but vulnerable if attackers control most hash power; full node verification offers stronger security guarantees.

Q: How many confirmations are enough for high-value transactions?
A: For large transfers, six or more confirmations are standard; higher values may warrant additional waiting depending on risk tolerance and network conditions.

Core Keywords