Lazy Consensus

Lazy consensus is the informal decision-making model used by the Bitcoin Core project and, in varying forms, by many long-lived open-source efforts. There is no formal voting, no board, and no committee that ratifies code changes. Instead, a proposed change accumulates public peer review, and a merge maintainer assesses whether it has rough consensus among contributors before merging. The word "lazy" is a term of art borrowed from open-source governance, and it cuts the opposite way from how it sounds: silence is not assent. A change advances because reviewers actively support it and no one raises an unrebutted technical objection — not because nobody happened to comment.

How review is expressed

Reviewers signal positions in a shared vocabulary that has hardened over years of practice. A Concept ACK agrees with the goal of a change without vouching for the implementation; an Approach ACK agrees with the method; a plain ACK or tested ACK (tACK) means the reviewer examined and, in the tested case, actually exercised the code and supports merging it. A NACK is an objection, and to carry weight it must include a sound technical rationale — NACKs without reasoning may be disregarded. This vocabulary matters because it separates "I like this idea" from "I have verified this code," two very different contributions that a naive thumbs-up count would flatten together.

Why the friction is deliberate

This model intentionally makes changes to consensus-critical software slow and hard to push through. Bitcoin Core is not an ordinary application: a subtle bug or an ill-considered rule change could split the network or destroy value at scale, so the cost of moving slowly is far lower than the cost of moving wrongly. Lazy consensus resists capture — no single actor, including a maintainer, can unilaterally approve a controversial change, because merging over standing technical objections would be visible to everyone and would burn the project's most important asset, credibility. It also weights arguments over identities: a well-reasoned objection from a newcomer outranks social pressure from a veteran, at least in principle, and review reputation is earned slowly, by a track record of demonstrated correctness over time rather than by title, tenure, or volume of commentary.

Consensus about code versus consensus about rules

It is worth keeping two layers distinct. Lazy consensus governs what code gets merged into one implementation. What rules the network runs is decided by the economic majority — node operators choosing what software to run, as users did during past activation debates. Maintainers cannot force a rule on users who refuse to run it, which is precisely the property that makes running your own node meaningful: development consensus proposes, but sovereign node runners dispose.

How a change actually lands

The lifecycle is public end to end. A contributor opens a pull request; reviewers pick it apart in the open, from concept to line-by-line; the author revises, sometimes across months or years; and only when review has converged does a maintainer merge — an act that reflects consensus rather than creating it. Changes to the protocol itself take the longer road of a Bitcoin Improvement Proposal, where the design is argued before any implementation is considered, and contentious proposals can circulate for years without resolution. Frustrating as that pace looks from outside, it is the review process doing its job: in software that secures other people's money, a change that cannot survive scrutiny should not survive at all. The process optimizes for the errors it never lets happen, which by definition nobody ever sees or credits.

Maintainers weigh review according to demonstrated expertise; see the Bitcoin Core maintainer role and the broader code review culture that makes the whole model function.