Bitcoin code: the repository, live
Live activity of Bitcoin Core on GitHub: commits, merged pull requests, releases, maintainers and contributors. Plus BIPs, Bitcoin Knots, Lightning implementations, where developers talk, how to contribute and how to verify a download.
🌱 Who writes Bitcoin's code, and how changes get in
- Bitcoin has no company or CEO. The most-used software, Bitcoin Core, is open source on GitHub: anyone can read every line and propose a change (a "pull request").
- Hundreds of volunteers and funded developers review each proposal publicly. Only after enough experienced reviewers agree ("ACK") does one of a handful of maintainers press merge. Maintainers don't decide what Bitcoin is; they apply what review agreed on.
- Big rule changes (soft forks) are written up as BIPs, debated for months or years on the mailing list and Delving Bitcoin, and only activate if node operators run the new software. Nobody can force an upgrade.
bitcoin/bitcoin right now
What it means: dozens of changes land every week, almost all tests, refactors and small fixes. Each one was reviewed in public before merging; consensus rules change very rarely.
GitHub data checked 22 Oct, 20:05 London · github.com/bitcoin/bitcoin · public GitHub REST API, refreshed every 3 hours.
Latest Bitcoin Core releases
Bitcoin Core ships a new major version roughly every six months and keeps releasing fixes for older branches for a while (see the release lifecycle on bitcoincore.org). Always verify a download (see below). Which versions nodes run →
Maintainers and top contributors
Maintainers are the people who press merge. Derived live from merge commits since 28 Sept 2026; the repo's contrib/verify-commits/trusted-keys lists 5 signing keys allowed to merge.
- 1.laanwj7,406
- 2.fanquake5,669
- 3.achow1012,578
- 4.sipa2,399
- 5.hebasto2,327
- 6.gavinandresen1,101
- 7.ryanofsky939
- 8.glozow795
- 9.jnewbery794
- 10.jonasschnelli774
- 11.theuni758
- 12.practicalswift715
Recently merged pull requests
- #35395doc: Improve test suite dependencies documentationfanquake · 22 Oct, 16:53 London
- #36581subprocess: fix command line memory leak on Windowsfanquake · 22 Oct, 16:34 London
- #36599test: Fix intermittent timeout waiting for ibd_wtxid getdatafanquake · 22 Oct, 11:50 London
- #36456Test: Cover malformed and truncated tx encodingsfanquake · 22 Oct, 10:35 London
- #36590doc: archive release notes for v32.0fanquake · 22 Oct, 08:33 London
- #36465Test: Add P2SH scriptSig stack-size boundary testsfanquake · 21 Oct, 20:16 London
- #36457Test: Cover malformed merkle trees and nBitsfanquake · 21 Oct, 19:46 London
- #36287build: Bump Xcode CLT minimum supported version to 26.3fanquake · 21 Oct, 16:46 London
- #35919p2p: cap maxconnections at 2,000 to reduce crash risksedited · 21 Oct, 15:02 London
- #36279test: non-inbound version message promotes address to tried tablesedited · 21 Oct, 14:09 London
- #36579refactor: Enable some string performance tidy rulessedited · 21 Oct, 13:45 London
- #36453util, cli: name the Sock wait timeout cap and use it for -rpcclienttimeout=0sedited · 21 Oct, 13:00 London
- #36509refactor: remove more dead codesedited · 21 Oct, 12:13 London
- #36449addrman: use uniform sampling inside bucketsfanquake · 21 Oct, 11:25 London
- #36531guix: use `--load-path` for local modulesfanquake · 21 Oct, 10:50 London
BIPs: latest proposals and BIP-110
Consensus (soft fork) · by Dathon Ohm · number assigned 2025-12-03. Proposes temporarily limiting arbitrary data at the consensus level for one year. Status in the BIPs repository: Closed. Mailing-list thread ↗ · Node signalling share →
- BIP 332Stale Tip RelayPeer Services · Draft · 2026-08-21
- BIP 461Deterministic ECDSA SignaturesApplications · Draft · 2026-08-12
- BIP 95Testnet 5Applications · Draft · 2026-06-22
- BIP 450Formosa—Seed encoding by themed mnemonic storiesApplications · Draft · 2026-05-15
- BIP 138Compact Encryption Scheme for Non-seed Wallet DataApplications · Draft · 2026-05-11
- BIP 451Dust UTXO Disposal ProtocolApplications · Draft · 2026-04-28
- BIP 440Varops Budget For Script Runtime ConstraintConsensus (soft fork) · Draft · 2026-03-25
- BIP 441Restoration of disabled script (Tapleaf 0xC2)Consensus (soft fork) · Draft · 2026-03-25
- BIP 393Output Script Descriptor AnnotationsApplications · Draft · 2026-03-17
- BIP 448Taproot-native (Re)bindable TransactionsConsensus (soft fork) · Draft · 2026-03-11
192 BIPs in github.com/bitcoin/bips README; statuses per BIP 3. Checked 22 Oct, 20:05 London.
Bitcoin Knots, GUI and BIPs repositories
Bitcoin Core derivative maintained by Luke Dashjr with extra options and stricter default relay policy.
Where pull requests for the Qt graphical interface of Bitcoin Core are opened and reviewed.
Bitcoin Improvement Proposals: design documents for protocol, P2P and wallet standards.
Lightning implementations
Lightning node by Lightning Labs (Go).
Lightning node by Blockstream (C).
Lightning node by ACINQ (Scala), powers Phoenix's LSP.
Lightning Dev Kit: a library to build Lightning into apps (Rust).
Where developers discuss
- TCP hole punching for Bitcoin nodes behind home NATs? · 22 Oct
- Cost-Bounded Transaction Filtering Language · 22 Oct
- Several projects to make merchant adoption easier and cheaper · 22 Oct
- Softfork before GTA VI? · 22 Oct
- Bounds on chain length with BIP-54 timewarp fixes · 21 Oct
- Evaluating Deterministic BFT Finality within a Confidential UTXO State Machine · 20 Oct
The main list for protocol proposals and BIP announcements (hosted on Google Groups since 2024).
- Testing Bitcoin Core 31.0 Release Candidates · 08 Apr 2026 · svanstaa
- #33300 Compact block harness · 08 Oct 2025 · marcofleon
- #32489 wallet: Add exportwatchonlywallet RPC · 06 Aug 2025 · ryanofsky
- #31829 Improve TxOrphanage denial of service bounds · 18 Jun 2025 · glozow
How to contribute
CONTRIBUTING.md explains the PR workflow, commit style and how review (ACK/NACK) works. GUI changes go to bitcoin-core/gui.
Testing and reviewing open PRs is the most useful first contribution. The PR Review Club walks through one PR at a time.
Coding style, testing and debugging conventions for Bitcoin Core.
BIP 3 describes how BIPs are written, numbered and move through statuses (Draft → Complete → Deployed, or Closed).
- 5. Discuss
bitcoindev mailing list (Google Groups) for protocol proposals; Delving Bitcoin for technical research threads.
- 6. Get funded
bitcoincore.org lists ways to contribute, including funding organisations for open-source Bitcoin work.
Verify a Bitcoin Core release (GPG + Guix hashes)
- Download the release file and, from the same release folder, SHA256SUMS and SHA256SUMS.asc.
- Check the hash of your file is listed:
sha256sum --ignore-missing --check SHA256SUMS
- Import the builder keys from the guix.sigs repository (builder-keys folder) and verify the signatures:
gpg --verify SHA256SUMS.asc
- Look for several "Good signature" lines from builders you recognise. Releases are built reproducibly with Guix: independent builders get byte-identical binaries and publish their hashes in guix.sigs.
For v31.1: SHA256SUMS · SHA256SUMS.asc
Sources and method
- GitHub public REST API (unauthenticated): repository stats, commit counts, search for open/merged PRs, releases, contributors, weekly commit activity.
- Maintainers: GitHub accounts behind recent Merge bitcoin/bitcoin#… commits, cross-checked against the number of keys in contrib/verify-commits/trusted-keys.
- BIPs: README and BIP files from github.com/bitcoin/bips; Delving Bitcoin latest.json; bitcoincore.reviews.
- Refresh every 3 hours on our server. If a source fails, its last good data stays with a mark.
core ok · activity ok · repos ok · bips ok · delving ok · review_club ok · updated 22 Oct, 20:05 London