Skip to content
This repository has been archived by the owner on May 8, 2020. It is now read-only.

Latest commit

 

History

History
67 lines (41 loc) · 2.99 KB

CONTRIBUTING.md

File metadata and controls

67 lines (41 loc) · 2.99 KB
Raw

Contributing to bitcoinjs-lib

Firstly in terms of structure, there is no particular concept of "bitcoinjs developers" in a sense of privileged people. Open source revolves around a meritocracy where contributors who help gain trust from the community.

For practical purpose, there are repository "maintainers" who are responsible for merging pull requests.

We are always accepting of pull requests, but we do adhere to specific standards in regards to coding style, test driven development and commit messages.

Communication Channels

GitHub is the preferred method of communication between members.

Otherwise, in order of preference:

  • bitcoinjs.slack.com
  • #bitcoinjs-dev on Freenode IRC

Workflow

The codebase is maintained using the "contributor workflow" where everyone without exception contributes patch proposals using "pull requests". This facilitates social contribution, easy testing and peer review.

To contribute a patch, the workflow is as follows:

  1. Fork repository
  2. Create topic branch
  3. Commit patches
  4. Push changes to your fork
  5. Submit a pull request to https://github.com/bitcoinjs/bitcoinjs-lib

Commits should be atomic and diffs easy to read.

If your pull request is accepted for merging, you may be asked by a maintainer to squash and or rebase your commits before it is merged.

Please refrain from creating several pull requests for the same change.

Patchsets should be focused:

* Adding a feature, or
* Fixing a bug, or
* Refactoring code.

If you combine these, the PR may be rejected or asked to be split up.

The length of time required for peer review is unpredictable and will vary from pull request to pull request.

Refer to the Git manual for any information about git.

We adhere to Bitcoin-Core policy

Bitcoin script payment/script templates are based on community consensus, but typically adhere to bitcoin-core node policy by default.

  • bitcoinjs.script.decompile is consensus bound only, it does not reject based on policy.
  • bitcoinjs.script.compile will try to adhere to bitcoin-core IsStandard policies rules. (eg. minimalpush in bitcoinjs#638)

Any elliptic curve sign operations should adhere to IsStandard policies, like LOW_S, but verify should not reject them [by default].

If you need non-standard rejecting decoding, you should use an external module, not this library.

TLDR

Where "standards compliant" refers to the default policies of bitcoin-core, we adhere to the following:

  • Any "creation" event must create standards-compliant data (standards bound)
  • Any "validation" event must allow for non-standards compliant data (consensus bound)

For stricter validation, use an external module which we [may have] provided.