Jeff Garzik

On GitHub, Jeff Garzik uses the name jgarzik. His work can be explored in individual repositories, public stores of code and its history. That is more useful than assigning one person the vague role of “running Bitcoin.” For a program, the questions are what it does and which version you are looking at; for a proposal, what it sought to change. A developer profile alone does not decide which software release other people run. [1]

Garzik’s cpuminer is described in its README introduction as a Bitcoin mining program for a CPU, the computer’s processor. Multithreading lets it divide computational work among several threads running concurrently. The project pooler/cpuminer, for Litecoin and Bitcoin, explicitly identifies itself as a descendant of that program. Taking existing code and developing it separately is called a project fork. That alone does not split the Bitcoin network, and features added to a derivative need not have existed in Garzik’s original. [2] [3]

Picocoin provides another example. It includes libccoin, a library in the C programming language whose functions developers can use to build Bitcoin applications. Its README, however, marks the associated HD wallet and brd node as WIP, meaning work in progress. An HD wallet derives a family of keys from a common starting point; the node is intended to communicate with the Bitcoin network. The repository was archived on 15 February 2024. It remains useful for studying history, but available code alone does not establish a finished, maintained and safe product for your savings. [4]

Imagine a node wanting to discover which unconfirmed transactions its peer knows about. Garzik’s BIP 35 addresses that task: a mempool message requests a list, an inv response carries transaction identifiers, their hashes, and getdata can then request the actual data. A mempool is a local “waiting room” for transactions before confirmation. It is not a single list shared by the whole world. The getrawmempool command in Bitcoin Core’s documentation likewise returns one node’s contents; finding a transaction there does not mean it has been confirmed in a block. [5] [8]

Block size affects both the room for transactions and the resources needed to transmit and verify them. In BIP 100, Garzik, Tom Harding and Dagur Valberg Johannsson proposed adjusting the limit through votes miners recorded in blocks. Recalculation would happen every 2016 blocks, requiring 75% support in blocks and bounding the size of each change. This was not a vote counted by the number of people. The registry marks the proposal Closed; its description is not evidence that the entire Bitcoin network adopted the mechanism. [6]

Consider an ordinary node that still checks the original 1 MB limit. When a larger block arrives, the node rejects it even if its miner supports a higher limit. BIP 100 explicitly warns of this split. A vote in a block is data that new software can interpret, not an instruction that rewrites an old program. A change allowing blocks that older rules reject is a Hard Fork. This use of “fork” differs from simply starting a derivative project on GitHub. [6]

Garzik’s BIP 102 proposed a different approach: raising the limit once, to 2 MB. Activation would require both a specified time condition and support signaled in 95% of the last 1000 blocks. Meeting those conditions would not itself update older validating programs, which would still reject the larger blocks. This proposal is also marked Closed. It records a proposed change; it is not a guide to the block-size rules Bitcoin uses today. [7]

For each BIP, read both its content and its status. BIP 35 is marked Deployed in the Peer Services layer, which concerns services and communication between nodes. BIP 100 and BIP 102 are Closed in the Consensus (hard fork) layer because they concern which blocks nodes accept as valid. One author can work in both areas with different outcomes. Successfully introducing a network message does not mean all of that author’s proposed rule changes were introduced as well. [5] [6] [7]