This document was last updated on 23rd December 2019.  Previous versions of the Responsible Disclosure Policy can be found here.


Security is core to our values, and we value the input of security researchers acting in good faith to help us maintain high standards of security and privacy for our users and the Bitcoin SV blockchain. This includes encouraging responsible vulnerability research and disclosure. This policy sets out our definition of good faith in the context of finding and reporting vulnerabilities, as well as what you can expect from us in return.

We may modify the terms of this policy or terminate this policy at any time. We won’t apply any changes we make to these policy terms retroactively.


When working with us according to this policy, you can expect us to:

  • Extend Safe Harbor for your vulnerability research that is related to this policy;
  • Work with you to understand and validate your report, including an initial response to the report within 72 hours of submission;
  • Work to remediate discovered vulnerabilities in a timely manner; and
  • Recognize your contribution to improving our security if you are the first to report a unique vulnerability, and your report triggers a code or configuration change.

Safe Harbor

When conducting vulnerability research according to this policy, we consider this research to be:

  • Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) (and/or similar state laws), and we will not initiate or support legal action against you for accidental, good faith violations of this policy;
  • Exempt from the Digital Millennium Copyright Act (DMCA), and we will not bring a claim against you for circumvention of technology controls;
  • Exempt from restrictions in our Terms & Conditions that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy;
  • Lawful, helpful to the overall security of the Internet, and conducted in good faith.

You are expected, as always, to comply with all applicable laws.

If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further.

Ground Rules

To encourage vulnerability research and to avoid any confusion between good-faith research and malicious attack, we ask that you:

  • Play by the rules. This includes following this policy, as well as any other relevant agreements. If there is any inconsistency between this policy and any other relevant terms, the terms of this policy will prevail.
  • Report any vulnerability you’ve discovered promptly.
  • Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience.
  • Use only the Official Channels to discuss vulnerability information with us.
  • Keep the details of any discovered vulnerabilities confidential until they are fixed, according to the Disclosure Terms in this policy.
  • Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope.
  • If a vulnerability provides unintended access to data: Limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept; and cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), or proprietary information.
  • You should only interact with test accounts you own or with explicit permission from the account holder.
  • Do not engage in extortion.

Official Channels

To help us receive vulnerability submissions we use the following official reporting channel:

If you think you’ve found a vulnerability, please include the following details with your report and be as descriptive as possible:

  • The location and nature of the vulnerability,
  • A detailed description of the steps required to reproduce the vulnerability (screenshots, compressed screen recordings, and proof-of-concept scripts are all helpful), and
  • Your name/handle and a link for recognition.

Please encrypt all information that you send to us using our PGP key ([email protected]). This key is available from Public PGP Key Servers such as the MIT PGP Public Key Server. The PGP key has ID 7A20AB62 and fingerprint E8EB 970A 1C60 7DF0 822E 1388 F969 76FD 7A20 AB62. The PGP key is included in its entirety at the bottom of this page for your convenience.


A ‘bounty’ or reward may be payable for the responsible disclosure of vulnerabilities in accordance with our policy and ground rules, and provided that the Bitcoin SV security team is one of the original recipients of the disclosure.

The final amount is always chosen at the discretion of the reward panel, but the general guidelines below provides examples of the maximum rewards that may be payable based on the severity of the vulnerability that has been found. It should be noted that only vulnerabilities that are economically feasible will be considered e.g. 51% attacks on the network will be considered economically unviable.

DescriptionCatastrophic impact on the network as a whole; network availability compromised; loss of fundsImpacts individual nodes; individual node crashes; potential for a loss of fundsNot easily exploitable; medium impact; no loss of fundsNot easily exploitable; low impact
Reward*$100,000 USD$50,000 USD$10,000 USD$1,000 USD

*All rewards will be paid out in Bitcoin SV from CoinGeek Mining’s open source budget.


Our bug bounty policy focuses on the code base for Bitcoin SV and spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.), protocol implementation and compliance to network security and consensus integrity. Classical client security as well as security of cryptographic primitives are also part of the policy.

Scope is limited to code contained in specified branches of the repository located at: Branches in and out of scope are specified by the branch name:

Branches in scope:

  • master branch
  • most recently updated branch with prefix: rc-*
  • branches prefixed with: review-*

Branches out of scope:

  • branches prefixed with: dev-*, exp-* or research-*
  • branches suffixed with: *-beta
  • all other branches not specified as in scopeThe scope of this policy is limited to those

Disclaimer: the scope of this policy is limited to those Operating Systems & hardware platforms for which binaries are released by the Bitcoin SV Node implementation team.


  • Findings from physical testing such as office access (e.g. open doors, tailgating)
  • Findings derived primarily from social engineering (e.g. phishing, vishing)
  • Findings from applications or systems not listed in the ‘Scope’ section
  • Findings that have already been reported
  • UI bugs and spelling mistakes on this or any associated website
  • Network level Denial of Service (DoS/DDoS) vulnerabilities
  • website
  • Resource exhaustion attacks subject to further caveats detailed below

Resource exhaustion attacks out of scope

We define “resource exhaustion attack” as an exploit designed to consume large amounts of CPU, memory, bandwidth or storage resources whether by normal operation of the Bitcoin SV protocol or by intentionally crafting blocks or transactions with unusual behavioural characteristics.Bitcoin by design requires that miners competitively push the boundaries of resource limits to ensure ongoing growth in network capacity. As such default settings of various resource limiting features are intentionally defaulted to values which may not be considered safe under unusual situations. It is intended for operators of the Bitcoin SV software to choose and set these limits. Various other mechanisms, both technical and economic, are in place to discourage such attacks either by making them expensive to execute, by minimising their impact on the majority of network operations or by limiting resource usage with configurable consensus or policy limits.Resource exhaustion attacks, as defined, are out of scope for the bug bounty program.However, we acknowledge that there is value in documenting all possible attack vectors and will consider disclosures of such attacks for rewards in the “low” category and in exceptional cases in the “medium” category. Awarding of bounties in this category are subject to the following conditions:

  • The award is completely discretionary
  • The attack much not be previously known to us
  • The attack must be demonstrably executable on a version of the software that would otherwise be deemed in scope if not for the resource exhaustion attack exclusion

For obvious security reasons it would not responsible for the Bitcoin SV team to publicly document known attack vectors. This necessarily requires a degree of good faith however it is strongly in the interest of the Bitcoin SV team to encourage such disclosures and build trust with the security research community through building a track record of making such bounty awards.

Sensitive data

Please note, we do not want to receive any sensitive data during any disclosure, such as personally identifiable information (PII) or any data associated with private/public keys.

If in any doubt, send an email to [email protected]

Bitcoin SV Security Team PGP Key

Version: SKS 1.1.6

September 25, 2020