How to Start Contributing to Bitcoin Open Source
Start where you can verify something. A precise bug reproduction or careful documentation fix can be more useful than an ambitious patch nobody can review.
1. Choose a project you can run.
Pick a project whose purpose you understand and whose development environment you can reproduce. Wallet developers might explore BDK; integration developers might start with BTCPay Server documentation; designers can explore the Bitcoin Design community.
Read the project’s contribution guide, issue templates and recent discussions. Look for evidence of how maintainers want help. Check whether somebody already owns the task before investing heavily in the same change.
2. Start with a bounded question.
Examples: Can a fresh installation follow this setup guide? Does this error message explain the next action? Can you reproduce a reported problem on the current version? Each question has an observable result and a small scope.
Keep a local notebook with the repository, commit, environment, commands and result. A failure to reproduce can still be useful if the conditions are clear. Do not turn uncertainty into an assertion that the report is wrong.
3. Learn how review works.
Bitcoin Core PR Review Club and LDK PR Review Club offer past discussions and prepared material. Choose an archived review near your skill level. Inspect the change, run the relevant test and compare your understanding with the discussion.
For Bitcoin Core itself, follow the current contribution instructions. A review should say what you checked: a particular commit, an execution path or a test result. Avoid generic approval comments that add no evidence.
4. Make the contribution easy to assess.
- Explain the concrete problem and how to reproduce it.
- Keep the change focused and avoid unrelated formatting.
- Describe the resulting behavior and relevant tradeoffs.
- Include appropriate tests or a before/after demonstration.
- Respond to feedback with updated evidence.
For a documentation change, run the documented steps. For a design contribution, connect the proposed change to a task and explain its states. For a code patch, understand the modified behavior well enough to answer a reviewer’s questions.
5. Keep a truthful contribution record.
Distinguish proposed, reviewed, merged and released work. Those states mean different things. A useful record includes the public link, your role, the date, what you verified and the outcome. An unmerged contribution can still demonstrate learning, but should be labeled accurately.
When a tool helps produce code or writing, you remain responsible for understanding the submitted work and following the project’s policies. Submit evidence you have checked, and use the project’s disclosure process for sensitive security findings.
Two exercises to make your first review concrete
The Bitcoin Core Onboarding guide covers the codebase, development workflow and testing. Use its build and review chapters to prepare this small practice exercise:
- Choose an archived review or a narrowly scoped change you can understand. Record the base and proposed commit IDs.
- Build the relevant version using its current instructions. Record the operating system, build options and any setup problems.
- Run the relevant test on the base and proposed versions. Describe what differs, or why the result is unchanged.
- Write a short review note with the commands, observations and limits of your check. Treat an archived exercise as portfolio practice; do not post a redundant comment to a closed pull request.
If Rust is the gap, The Bitcoiner’s Intro to Rust uses a transaction decoder to teach the language. After a lesson, make your own test fixtures for valid input, truncated input and malformed input. Explain how errors reach the caller and compare a valid decoding with the library you used. Label this as a learning implementation and credit course material.
These are Bitcoin CV practice suggestions, not assignments from a hiring team. A useful result is a small repository and an honest account of what you verified.
A realistic first contribution plan
Use your first sessions to set up the project and reproduce a documented example. Next, investigate one bounded issue or review exercise. Then prepare a small contribution with its evidence. Leave room for maintainers’ response times; a merge is not something a newcomer can schedule unilaterally.
Once you have a body of useful public work, compare the funding programs with your actual experience and intended contribution.
Keep the evidence.
Download a worksheet to record what you tried, what happened and what you would improve.
Download evidence worksheet ↓