in , , ,

Bitcoin SV Node Official EN

Bitcoin SV Node
Bitcoin SV Node


Four fundamental pillars form the basis of Bitcoin SV’s roadmap to create the one blockchain for the world: stability, scalability, security, and safe instant transactions (a.k.a 0-confirmation).

The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. It never really hits a scale ceiling.” – Satoshi Nakamoto (April 2009)

1 – Stability

Businesses, especially the biggest enterprises, require stability before they will operate on a technology platform. Repeated, unnecessary, and unproven changes to the Bitcoin protocol can be detrimental to the economic incentive structure and security of the blockchain. They can also cause significant uncertainties for large scale businesses that need to plan years in advance and commit significant resources before deciding to build applications and projects on Bitcoin SV.

The Bitcoin SV vision is to provide assured stability with only a limited and well known set of changes planned to restore the Bitcoin protocol to its original design, and enable innovation to occur on top of a stable base protocol.

Part of this is restoring the Satoshi op_codes to enable businesses and development teams around the world to create the many solutions possible on the BSV blockchain, such as smart contracts, tokenisation, atomic swaps, and many more.

2 – Scalability

In order for Bitcoin SV to truly act as a global money platform, it is necessary to demonstrate that the platform is ready to process transaction volume at the required scale. The Bitcoin SV roadmap is primarily focussed on delivering capacity increases, through bigger default or miner configurable block sizes and performance improvements. Out of the nine test environments in use by the project, the SV Gigablock Testnet (SV-GBTN) is specifically dedicated to identifying bottlenecks and performance measurement of proposed changes. The SV-GBTN is running on a continuous cycle of performance tests and the results of those are for public consumption so that miners and other industry participants will be able to make informed scaling decisions.

By enabling massive scaling, Bitcoin SV will pave the way for the BSV blockchain to support significantly higher transaction volumes and more transaction fees for miners. This is important for miners to maintain profitability as the block reward will halve again in the year 2020 (reducing from 12 BSV to 6.25 BSV for each block), and halve again in later years.

Massive scaling is also important to convince enterprises to use BSV for their blockchain applications – which will require big blocks and large throughput capacity.

3 – Security

Bitcoin SV will be a global currency. To enable such a future, we need to be prepared to ensure a level of security commensurate with a global money system. To do this, the Bitcoin SV project has focused on rigorous Quality Assurance for mining node software.

This is achieved by implementing a rigid set of test phases with full traceability throughout the test pipeline, to assure users that changes pass through a formal and rigorous validation process before they are accepted. In this respect, Bitcoin SV aspires to levels of Quality Assurance exemplified by mission critical industries such as aerospace, medicine and national security.

First, the team will use best practice change management processes and engage external QA expertise from other security-sensitive industries to monitor and audit its QA processes.

Second, the project will engage the services of an industry-leading blockchain security audit firm.

Third, the project will offer a lucrative bug bounty program matching the likes of Google and Microsoft to motivate and mobilize security researchers around the world to find and responsibly report security vulnerabilities. The team has engaged expert service providers in the field to develop an industry best practice “Responsible Disclosure Program.”

4 – Safe instant transactions (a.k.a. 0-conf)

Instant transactions are key to unlocking the brick and mortar merchant market for Bitcoin SV payments. Security improvements can be made to better secure instant transactions for the future, and the Bitcoin SV roadmap treats safe instant transactions as a key priority.

Bitcoin SV Node

Quality Program

The Bitcoin SV project assures its commitment to stringent quality with several measures.

First, the team has implemented best practice change management processes, and has engaged external QA expertise from security-sensitive industries to monitor and audit these processes. Furthermore, the Bitcoin SV project has commissioned a dedicated QA team consisting of a QA manager and three dedicated QA Engineers responsible for the development and maintenance of test environments as well as performing, documenting and approving all changes.

Second, the project has engaged the services of an industry-leading blockchain security audit firm. This outside team will serve two purposes:

1. Complete a full security audit of the Bitcoin SV code base.  This audit will cover not only the code itself but also development practices and processes to assist in building the most robust node development team in the industry.

2. Provide ongoing review and threat analysis of all code changes as and when they are submitted as candidates.

Third, the Bitcoin SV project will offer a generous bug bounty program (funded by CoinGeek) to motivate and mobilize security researchers around the world to find and report security vulnerabilities.  With input from expert service providers in the field, the Bitcoin SV team is developing an industry best practice “Responsible Disclosure Program.” Bounties are dependent on bug criticality with the highest severity attracting a bounty of USD $100,000 (payable in BSV).

The Responsible disclosure policy can be found here along with PGP key details.

Bitcoin SV uses CppDepend as part of our extensive QA process.

Bitcoin SV uses CppDepend for QA


Bitcoin SV Node


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:

  • email:

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 ( 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.

Severity Critical High Medium Low
Description Catastrophic impact on the network as a whole; network availability compromised; loss of funds Impacts individual nodes; individual node crashes; potential for a loss of funds Not easily exploitable; medium impact; no loss of funds Not 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

Bitcoin SV Security Team PGP Key

Bitcoin SV Node

Select a service category:

What do you think?

Written by Ramon Quesada

Passionate about Blockchain & Bitcoin technology since 2013, Co- Founder of, Team Manager in the CoinTelegraph Spain franchise (2016-2017 years) Co. Organizer of the Blockchain Boot camp Valencia 2018, Co. Organizer of the mini Hackathon BitcoinSV Barcelona, in August 2019, current coordinator of the BSV Valencia Meetup.


Leave a Reply

Your email address will not be published. Required fields are marked *


Bitcoin Wiki


Bitcoin SV Node

BitcoinSV Coin Splitting Guide