The Timechain, or Bitcoin Blockchain, is the connected chain of valid blocks from the Genesis Block to the network's current tip. Each subsequent block points to its predecessor’s hash, its digital fingerprint, and adds its own Proof of Work, evidence of the computational work required to create the block. Nodes can therefore verify independently which history follows the rules and has the greatest accumulated work. Here, “time” does not mean an exact clock for every transaction; it primarily means a demonstrable order of events.
Imagine a public accounting history in which thousands of computers can independently check every new page. One page is a block. It contains a set of transactions and a reference to the previous block, so the pages have a defined order and cannot be shuffled at will. The Timechain is this entire connected sequence, from the first block to today's tip. It does not say how much bitcoin each named person owns; it records transaction history from which nodes derive the outputs that remain unspent. Nor is it one company's server. Any Full Node (a node that independently verifies transactions and network rules) can download and verify a copy. [1] [3]
In the Bitcoin context, both names refer to the same block history. Surviving pre-release code from November 2008 used timechain in comments and variable or function names. The whitepaper instead speaks of timestamping, a chain of blocks and a Proof of Work chain; the exact word timechain does not appear in it. Blockchain later became the globally common term. Today it is also a broad label for other networks and databases, while the Bitcoin Timechain is Bitcoin's specific chain. The two words in the title therefore do not name two protocols. They preserve the historical name alongside the present-day common term. [2] [1] [8]
A digital signature can prove that a transaction was authorized by the holder of the required key. By itself, it cannot stop someone from signing two conflicting transactions that try to spend the same unspent output of an earlier transaction, called a UTXO. One node may first receive a payment to a merchant while another first receives a transfer of the same value back to the sender. The network therefore needs a shared history that determines which spend was confirmed and which can no longer be valid. Blocks give transactions a verifiable place in that order. They do not prove which message was created first in human or network time; nodes may have seen unconfirmed transactions in different orders. [1]
A Block Header contains a block’s essential summary data. Among its fields are the previous header’s hash and the Merkle Root, which combines the block’s transaction identifiers into one hash. A hash is like a digital fingerprint: even a small change in the input creates a different result. Changing an old transaction would change the Merkle Root, that block's hash and the reference stored by the next block. The edit would not remain one altered line of history; it would break the whole following sequence. A hash alone does not prove that transactions follow the rules. Nodes must also validate the transactions, and every block must satisfy the required Proof of Work. [3] [1]
A node does not accept a branch merely because it is longer or promoted by a large miner. It first checks the rules: Proof of Work, links to earlier blocks, the permitted reward, transactions, spending conditions and whether inputs refer to funds that have already been spent. An invalid branch remains invalid regardless of its author's computing power. Only among valid candidates does the node choose the chain with the greatest accumulated work. It is therefore more precise to speak of the most-work valid branch than simply the “longest chain.” The chainwork field estimates the expected number of hashes required to produce the chain at each block's difficulty; it is not a counter of the attempts miners actually performed. [4] [5] [6]
Proof of Work costs time, electricity and computing power, while its result is quick to verify. Someone changing an old block would need to produce new valid Proof of Work for it, reconnect every later block and keep catching up with the work the honest branch continues to add. The deeper a block sits below the tip, the larger the ordinary history's lead. This is not a mathematical promise that the past can never change. It is an economic and probabilistic defense: additional blocks usually make a successful rewrite rapidly more expensive. An attacker also cannot place an arbitrary invalid payment or excess bitcoin into the replacement branch, because other nodes would reject the block. [1] [4]
A miner places a timestamp in the Block Header. Consensus rules allow some latitude, so the time value is not exact proof of when a block or a particular transaction was created. One block's timestamp need not even be higher than its immediate predecessor's. For some rules Bitcoin therefore uses Median Time Past: the median timestamp of the previous 11 blocks. The median is found by sorting these timestamps and selecting the middle value. It advances more steadily than individual timestamps. The average ten-minute block interval is not a timetable either. Two blocks may arrive close together, while another gap may be much longer. Block height gives an exact position in the chain, not an exact time on a calendar. [4] [7]
Two miners can find different valid blocks at nearly the same time and at the same height. Some nodes may see one branch first and other nodes the other. When later Proof of Work creates a difference between the valid branches, nodes move to the one with more accumulated work. This switch is called a Reorg. Transactions from the disconnected block may confirm in the new branch, return to the Mempool or become invalid if the new history confirms a conflicting spend. Inclusion in a block is the first confirmation; every later block above it adds another. There is no universal magic number for every payment. Appropriate confidence depends on value, risk and the ability to wait. [1] [3]
Bitcoin can create a transaction that may only be confirmed from a certain block height or after a specified time. A Timelock is not an instruction to execute the transaction automatically at that minute. It only establishes the earliest point from which a valid block may include it. For time-based nLockTime, BIP 113 uses the previous block's Median Time Past instead of the easily shifted timestamp of the block being created. The condition therefore rests on the history of several blocks. Even after it is satisfied, the transaction must be broadcast, accepted by nodes and selected by a miner; inclusion in a particular block is not guaranteed. [7] [4]
RPC is an interface for sending commands to a node and reading its responses. A Full Node need not trust a public explorer's claim that a block or transaction belongs to the current history. For a particular hash, the getblock RPC can show height, confirmation count, Merkle Root, time, mediantime, the previous hash, difficulty and chainwork. Each field answers a different question: height gives position; previousblockhash shows ancestry; confirmations show depth below the current tip; time is the header value; mediantime is a median; and chainwork represents accumulated expected work. No single number is enough. The point of the Timechain is that a node checks their relationship and every consensus rule as one whole. [6] [4]
For the clearest picture, read this entry together with Genesis Block, Proof of Work, Transaction, Full Node, Difficulty Adjustment. The reverse links also lead from Bitcoin Whitepaper, Genesis Block, Proof of Work, Full Node.