You Are Ready
You've learned Bitcoin's protocol, built applications, and studied the codebase. Now it's time for the most important step: contributing to Bitcoin itself.
This module is different. It's not just learning—it's doing. By the end, you'll have made your first real contribution to the Bitcoin ecosystem.
Remember: Every Bitcoin Contributor Started Exactly Where You Are
The developers who built SegWit, Taproot, and the Lightning Network all started with their first PR. Many were nervous, made mistakes, and learned through feedback. That's not just normal—it's expected and welcomed.
"The best time to start contributing to Bitcoin was yesterday. The second best time is today."
Step 1: Set Up Your Development Environment
Before contributing, you need a proper development setup. This is a one-time investment that will serve you for all future contributions.
1Fork Bitcoin Core
- Go to github.com/bitcoin/bitcoin
- Click "Fork" in the top right
- This creates your own copy of Bitcoin Core
2Clone Your Fork
# Clone your fork (replace YOUR_USERNAME)
git clone https://github.com/YOUR_USERNAME/bitcoin.git
cd bitcoin
# Add upstream remote (official Bitcoin repo)
git remote add upstream https://github.com/bitcoin/bitcoin.git
# Verify remotes
git remote -v
# origin -> your fork
# upstream -> bitcoin/bitcoin
3Install Dependencies
# macOS
brew install automake libtool boost pkg-config libevent
# Ubuntu/Debian
sudo apt-get update
sudo apt-get install build-essential libtool autotools-dev automake \
pkg-config bsdmainutils python3 libssl-dev libevent-dev \
libboost-dev libsqlite3-dev
# Check you have required tools
python3 --version # Should be 3.7+
git --version # Should be 2.0+
4Build Bitcoin Core
# Generate build files
./autogen.sh
# Configure (adjust for your system)
./configure --without-gui --with-incompatible-bdb
# Build (use all CPU cores)
make -j$(nproc) # Linux
make -j$(sysctl -n hw.ncpu) # macOS
# This will take 10-30 minutes on first build
5Run Tests to Verify
# Run unit tests
make check
# Run a quick functional test
test/functional/wallet_basic.py
# If these pass, your environment is ready!
Build Problems?
If you encounter build issues:
- Check
doc/build-*.mdfor OS-specific instructions - Search existing GitHub issues for your error message
- Ask in Bitcoin Core IRC/Slack (be specific about your error)
- Make sure all dependencies are installed
Step 2: Find Your First Issue
The hardest part of contributing is often finding the right issue to work on. Here's a curated guide to finding good first contributions.
Where to Find Issues
GitHub label specifically for newcomers. Usually documentation, tests, or minor fixes.
Fix typos, improve clarity, add examples. Non-consensus, safe to start with.
Add test coverage, improve existing tests, fix flaky tests.
Code cleanup, removing deprecated code, improving variable names.
Improve RPC commands, add helpful fields, better error messages.
Example Good First Issues
Why it's good: Clear scope, existing code to reference, non-consensus, helps you learn testing framework.
What you'd do: Write a functional test that creates a wallet, backs it up, deletes it, and restores from backup.
Why it's good: Documentation improvement, helps other users, low risk of bugs.
What you'd do: Add clearer descriptions, examples, and edge case warnings to RPC help.
Why it's good: Easiest possible first PR, gets you familiar with the contribution process.
What you'd do: Fix spelling/grammar error, learn git workflow, create PR.
⚠️ What to Avoid as First Contribution
- Consensus code: Too critical for beginners (e.g., validation, script interpreter)
- Large refactors: Requires deep codebase knowledge
- New features: Requires extensive discussion and consensus
- Performance optimizations: Need benchmarks and deep understanding
- Closed/controversial issues: Likely there's a reason they're stalled
Step 3: Create Your Pull Request
You've found an issue. Now let's walk through creating a quality PR that will get merged.
1Sync with Latest Master
# Fetch latest changes
git fetch upstream
# Update your local master
git checkout master
git merge upstream/master
# Push to your fork
git push origin master
2Create Feature Branch
# Create descriptive branch name
git checkout -b fix-wallet-backup-test
# Good branch names:
# - add-rpc-example-to-docs
# - test-wallet-restore
# - fix-typo-developer-notes
# - refactor-net-logging
# Bad branch names:
# - fix
# - changes
# - my-branch
3Make Your Changes
Follow the coding standards in doc/developer-notes.md:
- Use consistent formatting
- Write clear variable names
- Add comments for complex logic
- Keep changes focused (one issue per PR)
4Test Your Changes
# Rebuild
make -j$(nproc)
# Run affected tests
make check
test/functional/test_runner.py
# Run linter
test/lint/lint-all.sh
# Test manually if needed
./src/bitcoind -regtest
./src/bitcoin-cli -regtest [your command]
5Commit with Good Message
# Stage your changes
git add [files]
# Write descriptive commit message
git commit
# Commit message format:
# component: Short description (max 50 chars)
#
# Longer explanation of what changed and why.
# Wrap at 72 characters.
#
# Fixes #12345
Example good commit message:
test: Add coverage for wallet backup restoration
Adds functional test that verifies wallet can be restored
from backup file. Tests both with and without encryption.
This increases test coverage for wallet backup functionality
and catches potential regressions in backup/restore flow.
6Push and Create PR
# Push to your fork
git push origin fix-wallet-backup-test
# Go to GitHub - you'll see "Compare & pull request" button
# Or manually: github.com/bitcoin/bitcoin/compare/master...YOUR_USERNAME:fix-wallet-backup-test
PR Description Template
## Summary
Brief description of what this PR does.
## Motivation
Why is this change needed? What problem does it solve?
## Changes
- Bullet point list of changes
- Be specific but concise
- Mention any files significantly changed
## Testing
How did you test this?
- [ ] Unit tests pass
- [ ] Functional tests pass
- [ ] Manual testing performed
- [ ] Linter passes
## Notes for Reviewers
Anything reviewers should pay attention to?
Any specific areas where you want feedback?
## Checklist
- [ ] I have read the developer-notes.md
- [ ] I have added tests for my changes
- [ ] I have updated documentation if needed
- [ ] My code follows the project style
- [ ] All tests pass locally
Fixes #[issue number]
Step 4: Navigate the Review Process
Your PR is open! Now comes the most important part: responding to review feedback professionally and learning from the process.
What to Expect
Reviewers are volunteers. Be patient. If no response after a week, politely ping on IRC or add a comment asking for review.
CI will run tests automatically. Fix any failures immediately.
Reviewers will leave comments. Some will be questions, some suggestions, some requests for changes.
Address feedback, push updates, explain your reasoning when you disagree.
Expect 2-5+ rounds of feedback. This is normal! Each iteration improves the code.
Reviewers leave "ACK" when they approve. Need multiple ACKs for merge.
A maintainer merges your PR. Congratulations - you're a Bitcoin contributor! 🎉
How to Respond to Feedback
✅ Good Response Examples:
// When accepting feedback:
"Good catch! I'll update to use std::optional here."
// When explaining your approach:
"I chose this approach because X, but I can see the benefit
of your suggestion. Let me try that and see if it's clearer."
// When disagreeing respectfully:
"I see your point about performance. However, in this case
I think readability is more important because [reason].
What do you think?"
// Asking for clarification:
"Could you elaborate on the edge case you mentioned?
I want to make sure I understand the concern."
❌ Bad Response Examples:
// Defensive:
"That's how I always do it and it works fine."
// Dismissive:
"This is just a small change, it doesn't matter."
// Demanding:
"Can someone review this? It's been 2 days."
// Vague:
"Fixed." (without explanation)
Updating Your PR
# Make changes based on feedback
# ... edit files ...
# Commit changes
git add [files]
git commit -m "address review feedback: improve error handling"
# Push update
git push origin fix-wallet-backup-test
# PR updates automatically!
# If asked to squash commits:
git rebase -i HEAD~3 # Combine last 3 commits
git push --force-with-lease origin fix-wallet-backup-test
⚠️ Common Mistakes to Avoid
- Force pushing without --force-with-lease: Can lose commits if branch was updated
- Adding unrelated changes: Keep PR focused on one issue
- Not running tests: Always test before pushing updates
- Getting discouraged: First PRs often need many revisions - that's learning!
- Arguing extensively: If 2+ reviewers agree, they're probably right
Step 5: Build Your Contribution History
One PR is great. But becoming a trusted Bitcoin contributor takes consistency and breadth. Here's how to build your contribution history strategically.
Contribution Paths
Documentation Path
- Fix typos and grammar
- Add missing documentation
- Improve code examples
- Write guides for new features
- Update outdated docs
Timeline: 5-10 PRs over 2-3 months
Testing Path
- Add missing test coverage
- Fix flaky tests
- Improve test readability
- Add edge case tests
- Write fuzzing harnesses
Timeline: 10-15 PRs over 3-6 months
Code Quality Path
- Refactor duplicated code
- Improve variable naming
- Remove deprecated code
- Add helpful logging
- Fix compiler warnings
Timeline: 8-12 PRs over 4-6 months
Feature Path
- Review and test open PRs
- Improve RPC interfaces
- Add wallet features
- Optimize performance
- Eventually: consensus code
Timeline: 6-12 months of consistent contributions
Non-Code Contributions (Equally Important!)
Review others' PRs thoroughly. Test their code, provide feedback, learn from their approach. Many maintainers spend more time reviewing than writing code.
Help triage new issues: reproduce bugs, ask clarifying questions, suggest workarounds, tag with appropriate labels.
Answer questions on Bitcoin Stack Exchange, IRC, GitHub discussions. Help newcomers get started. Share your learning journey.
Contribute to Bitcoin-related projects: LND, BDK, rust-bitcoin, btcd, libbitcoin, wallets, explorers, libraries. Builds skills applicable to Core.
Step 6: Stay Involved and Keep Learning
Bitcoin development is a marathon, not a sprint. Here's how to stay engaged and continue growing.
Regular Activities
Every Wednesday: bitcoincore.reviews - Review a PR together with other contributors. Ask questions, learn review process.
bitcoinops.org - Stay current on protocol developments, new BIPs, notable PRs.
Watch the repository, read new PRs, follow discussions. You learn as much from reading others' code as writing your own.
#bitcoin-core-dev on Libera.Chat - Ask questions, discuss ideas, help others.
Example: "1 PR per month" or "Review 2 PRs per week" or "Complete one good first issue per quarter"
Deepening Your Knowledge
- Study merged PRs: Read the discussion, understand why changes were made
- Read the codebase: Pick a component (wallet, net, consensus) and study it deeply
- Implement features locally: Build things that won't be merged, just to learn
- Follow mailing lists: Bitcoin-dev mailing list for protocol discussions
- Attend conferences: Bitcoin developers meetups, conferences, workshops
Your Journey Begins Now
You have everything you need to make your first Bitcoin contribution. The knowledge, the tools, the roadmap. All that's left is to take the first step.
Start small. Fix a typo. Add a test. Review a PR. Each contribution, no matter how small, makes Bitcoin better and makes you a better developer.
Bitcoin needs you. The network needs you. The world needs you.
Parting Wisdom from Bitcoin Contributors
"Don't be intimidated. Everyone started somewhere. Your perspective as a newcomer is valuable—you see things experienced developers overlook."
"The best way to learn Bitcoin is to contribute to Bitcoin. Nothing else comes close."
"Start with review. You learn the codebase, the culture, and the standards. Then your own PRs will be much better."
Key Takeaways
- Set up development environment: fork, clone, build, test
- Start with good first issues: documentation, tests, small fixes
- Follow the contribution workflow: branch, commit, test, PR
- Write clear PR descriptions and commit messages
- Respond to review feedback professionally and promptly
- Code review is as valuable as writing code
- Build contribution history through consistent, quality work
- Engage with community: PR Review Club, IRC, mailing lists
- Every Bitcoin contributor started exactly where you are
- Your first contribution is the beginning, not the end
Essential Resources
Getting Started
Learning & Review
- PR Review Club - Weekly PR reviews
- Bitcoin Optech - Technical newsletter
- Bitcoin Stack Exchange - Q&A
- Chaincode Bitcoin Curriculum
Community
- IRC: #bitcoin-core-dev on Libera.Chat
- Mailing List: bitcoin-dev
- Meetings: Weekly Core dev meetings (check IRC logs)
Related Projects to Contribute To
- LND - Lightning Network implementation
- BDK - Bitcoin Dev Kit
- rust-bitcoin - Rust Bitcoin library
- BIPs Repository - Propose improvements