What this is
Bitcoin Untangled is not a fork, not a competitor to Bitcoin Core, and not aligned against any single implementation. On the contrary it's main mission is node software decentralization, where no no node software is running more than 50% of the nodes. It's an effort to shift how the Bitcoin community thinks about its own software — away from “development,” and toward maintenance.
Bitcoin Untangled is separate from Knots Untangled, a specific technical fork — a non-RDTS continuation of Bitcoin Knots, tracking Bitcoin Core. Knots Untangled is one small, concrete example of the argument this page makes, not the argument itself.
The core position
Bitcoin is not a software development project. It's settled, working infrastructure that people trust with real value. Treating it primarily as something to keep developing — adding features, expanding scope, continuously evolving — creates exactly the kind of concentration risk a decentralized system is supposed to avoid: one dominant codebase, one small group of maintainers, one point of failure for the software the entire network relies on.
The right frame is maintenance: keep it running, keep it secure, change it only when genuinely necessary.
What actually needs solving
In this view, there are two real open technical problems — not a long backlog of features:
- The timestamp issue — Bitcoin's block header stores the timestamp as a 32-bit unsigned integer, which rolls over on February 7, 2106. Fixing it means every piece of node software agreeing on a coordinated change well in advance — another reason node diversity matters now, not just in a crisis.
- Quantum readiness — a real future requirement, but likely not urgent for years yet
Nearly everything else is optional scope, not necessity.
Why implementation diversity matters
A single reference implementation, however well-run, concentrates decision-making in a way that doesn't match Bitcoin's own premise. This site hosts an overview of Bitcoin node implementations — Core, Knots, btcd, and others — not to rank them, but to make the current landscape visible: what's actively maintained, what's specialized for what use case, and where real diversity exists versus where it's mostly nominal.
What this is not
- Not anti-Core. Core's engineering discipline and conservatism are real strengths worth preserving.
- Not a call for more features, more experimentation, or faster change.
- Not a single fork trying to replace anything.
What this is for
To make the case, in public, that Bitcoin's long-term health depends on:
- Multiple independently maintained implementations, resourced seriously — not as rivals, but as a check against single-point-of-failure governance.
- A shift in framing from “what should we build next” to “what must we maintain, and how do we do that safely, together.”