This project welcomes contributions from anyone via peer review, documentation, testing, and patches, regardless of experience, age, or other factors. Cryptocurrency protocol development requires rigor, adversarial thinking, thorough testing, and risk minimization, as bugs can cost users money.
Communication occurs in the #silent-payments channel on the BDK Discord server and on GitHub via issues and pull requests.
No requirements to contribute, but familiarity with BIPs 3521, 3752, 3743, and the light client specification4 helps, as they drive this repository's content.
The codebase uses the contributor workflow, where everyone submits patch proposals via pull requests. This facilitates social contribution, easy testing, and peer review.
To contribute a patch:
- Fork the repository.
- Create a topic branch.
- Commit patches.
Commits should be atomic with easy-to-read diffs. Do not mix formatting fixes or code moves with actual changes. Each commit should compile and pass tests to ensure tools like git bisect work properly.
When adding features, consider long-term technical debt. Cover new features with functional tests where possible.
For refactoring, structure PRs for easy review and split into multiple small, focused PRs if needed.
The minimal supported Rust version is 1.63.0 (enforced by CI).
Commits should describe the issue fixed and the solution's rationale.
Consider cbeams guidelines to write commit messages. Apply "Conventional Commits 1.0.0" for readable commit histories for humans, tools and LLMs.
Sign commits with GPG, SSH, or S/MIME; GitHub enforces this when merging pull requests. Read more about signing commits.
To communicate with contributors, use GitHub's assignee field. Check if assigned, then comment that you're working on it. If assigned, ask if they're still active if it's been awhile.
Use just for the preferred workflow. If not installed, installation page.
Run just fmt to format code.
Run just check to apply linters and ensure signed commits.
Run just pre-push or just p before PRs to verify formatting, no linter warnings, passing tests, and signed commits.
Document all public items. Adhere to Rust API Guidelines for documentation.
Carefully consider using clone, unwrap, or expect.
The library uses safe Rust. Avoid unsafe blocks.
Add dependencies only if strictly necessary and impossible otherwise.
Avoid breaking existing APIs where possible. Add new APIs and use #[deprecated] to discourage old ones.
Maintain deprecated APIs for one release cycle. For example, an API deprecated in 0.10 may be removed in 0.11. This enables smooth upgrades without excessive technical debt.
If you deprecate an API, own it and submit a follow-up PR to remove it in the next cycle.
Anyone can participate in peer review via pull request comments. Reviewers check for obvious errors, test patches, and assess technical merits. Review PRs conceptually first, before code style or grammar fixes.
Security is a high priority for bdk-sp to prevent user fund loss. Since not production-ready, report vulnerabilities via GitHub issues.
bdk-sp developers prioritize testing seriously. The modular structure makes writing functional tests easy, with good codebase coverage as a key goal.
Test all new features. Make tests unique and self-describing. If ignoring a test, provide a reason with the #[ignore] attribute.
Namespace unit tests in an inner module named after the function under test, without test_ prefix or the function name. The test name should explicitly state the case.
As in Coding Conventions, use just to run unit tests, functional tests, integration tests, and doctests:
just testConsider Jon Atack's guides on How to review Bitcoin Core PRs and How to make Bitcoin Core PRs. Despite project differences in context and maturity, many suggestions apply here.