Module 3: Your First Contribution

Ongoing journey - start here, continue forever

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

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-*.md for 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

Good First Issues
Easiest

GitHub label specifically for newcomers. Usually documentation, tests, or minor fixes.

🔗 github.com/bitcoin/bitcoin/labels/good first issue

Documentation
Low Risk

Fix typos, improve clarity, add examples. Non-consensus, safe to start with.

📁 Files: doc/*.md, code comments, help text

Tests
Low Risk

Add test coverage, improve existing tests, fix flaky tests.

📁 Files: src/test/*.cpp, test/functional/*.py

Refactoring
Medium

Code cleanup, removing deprecated code, improving variable names.

🏷️ Label: Refactoring

RPC/Interface Improvements
Medium

Improve RPC commands, add helpful fields, better error messages.

📁 Files: src/rpc/*.cpp

Example Good First Issues

Example: "Add missing test for wallet backup restoration"

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.

Example: "Improve help text for 'createwallet' RPC command"

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.

Example: "Fix typo in developer-notes.md"

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

Initial silence (1-7 days)

Reviewers are volunteers. Be patient. If no response after a week, politely ping on IRC or add a comment asking for review.

Automated checks run

CI will run tests automatically. Fix any failures immediately.

First reviews come in

Reviewers will leave comments. Some will be questions, some suggestions, some requests for changes.

You respond and iterate

Address feedback, push updates, explain your reasoning when you disagree.

Multiple rounds of review

Expect 2-5+ rounds of feedback. This is normal! Each iteration improves the code.

ACKs accumulate

Reviewers leave "ACK" when they approve. Need multiple ACKs for merge.

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!)

Code Review
High Impact

Review others' PRs thoroughly. Test their code, provide feedback, learn from their approach. Many maintainers spend more time reviewing than writing code.

Start with "Concept ACK" comments, work up to full technical reviews

Issue Triage
Helpful

Help triage new issues: reproduce bugs, ask clarifying questions, suggest workarounds, tag with appropriate labels.

Community Support
Valuable

Answer questions on Bitcoin Stack Exchange, IRC, GitHub discussions. Help newcomers get started. Share your learning journey.

Related Projects
Ecosystem

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

Attend PR Review Club (Weekly)

Every Wednesday: bitcoincore.reviews - Review a PR together with other contributors. Ask questions, learn review process.

Read Bitcoin Optech Newsletter (Weekly)

bitcoinops.org - Stay current on protocol developments, new BIPs, notable PRs.

Monitor Bitcoin Core Development (Daily/Weekly)

Watch the repository, read new PRs, follow discussions. You learn as much from reading others' code as writing your own.

Join Bitcoin Dev IRC/Slack

#bitcoin-core-dev on Libera.Chat - Ask questions, discuss ideas, help others.

Set Goals for Contributions

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."
- Bitcoin Core Contributor
"The best way to learn Bitcoin is to contribute to Bitcoin. Nothing else comes close."
- Bitcoin Core Contributor
"Start with review. You learn the codebase, the culture, and the standards. Then your own PRs will be much better."
- Bitcoin Core Contributor

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

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