Technical standards form the basis for product development by establishing consistent protocols that can be universally understood and adopted.
Technical Standards are:
Using technical standards alleviates the need for multiple organisations to repeatedly solve the same problems. History has repeatedly demonstrated the value of seeking consensus on technical standards to fuel industry growth through compatibility and interoperability between different businesses. They enable technology to work seamlessly and establish trust so that the wider ecosystem can develop and operate smoothly.
Standards are sometimes used by regulators and cited in regulations as a tool to demonstrate compliance. They can also serve as a catalyst for innovation and help in anchoring solutions more quickly on the market. Innovations that extend across industries and value chains are becoming increasingly important. Incorporating innovative aspects into standards can prove crucial for market success since the market is then best prepared for the product.
The Technical Standards Committee (TSC) oversees the development of Bitcoin SV techincal standards. They serve as facilitators for the standards development process, offering the platforms, rules, governance, methodologies and access to specialists such as technical writers to objectively address the standards development lifecycle.
Each standard is developed by a working group that is assigned a TSC sponsor. The sponsors independently oversee the working group and ensures policies and processes are maintained to guarantee high-quality outputs and reinforce the relevance of industry and technology standards.
There are three ways to get involved in developing Bitcoin SV technical standards:
More details can be found in the Get involved section of the TSC website.
No. Everyone with subject matter knowledge can propose a standard, join a working group and participate in public review. We strive to have a balance of stakeholder views in our working groups and our participants can include (but are not limited to):
The technical programme provides access to processes, tooling, guidance, and resources for industry use by participants who, in response to a perceived need, wish to come together to standardise ways in which applications built on top of Bitcoin SVcan interoperate. This includes access to:
The first step for a proposer is to elaborate on the industry need they wish to solve and to understand the success criteria more fully. When capturing the standard requirements, you must ensure that the problem you wish to solve is in line with TSC criteria of enhancing interoperability through standardisation. When identifying the industry needs, proposers should also consult the standard library and look into the purpose of published standards and those in development, their working groups, their members and their activities. Your proposed working group may be different enough to justify the creation of a new group, or you may want to consider ways to work with existing groups to address your defined problem.
The submission of a proposal to develop a standard is the next point in the standards process. At this stage, the solution overview should not be too detailed. The solution will be defined by the parties involved in writing the standard once in development if the submission is successful. The TSC will review the submission and if successful, a Working Group will be created to drive the standard forwards to completion. As this will be made public, nothing in this form should disclose key inventions that may be part of the proposal – in order to protect any intellectual property that may otherwise become public knowledge (and therefore prior art).
Getting involved in this process can bring significant advantages to you and to your business:
When joining a working group, participant (or a legally authorized representative of the company they are employed by) will be asked to sign a Patent License Pledge and Copyright Assignment. Under this agreement, the participants retain their patent rights and/or claims in their inventions. However, they authorize the other participants (the licensees) to use that IP to the extent necessary to implement the required portions (including the required elements of optional portions) of the standard that are described in the standard documentation.
Proposer(s) and author(s) can request for the working group to sign a non-disclosure agreement (NDA) to ensures that information exchanged between parties is kept confidential. This means that all participants can feel comfortable having open discussions with other parties to develop a standard. It also means that if participants have generated IP or are generating IP during the working group process, they will have some reassurance that they can protect that IP themselves, should they want to.
Before the standard is released publicly, we will confirm if the author(s) have contributed to any IP and if the IP is protected to the satisfaction of their company.
Time commitment is influenced by the participant role, the complexity of the industry needs the working group tries to solve and of the proposed solution. The time listed below are for indication.
Time commitment – Authors
The time that it takes to create technical documentation directly correlates with the length of the documents. As a rule of thumb for estimating the creation of technical documentation, it takes about 2 hours per page to write a new document for a non-professional writer. Like any writing project, authors must also allow time for research, outlining, review and coming up with diagrams/images. As a guideline, a typical technical document can take between 24 and 50 hours to complete usually across 3-4 months.
Time commitment – Reviewers
The review cycle will vary depending on the complexity of the technical standard. A common process follows a first draft, revised draft, and final draft/version of the document. Each review will refine and improve the document. Therefore, a lengthier or more critical document will require additional rounds of review. As a guideline, the time commitment to the review process over the expected lifetime of the workgroup are expected to be in the range of 2-3 months and would typically require 5-10 hours of review work split across 2-3 iterations of a draft standard.
There are several benefits to joining a working group and helping shape the standard for topics that are important to you. By taking part in the standard development process, you contribute to building a highly professional BSV ecosystem.
Being a member of a working group will provide the opportunity to shape the technical content of the standard based on your own interests, knowledge and ideas, ensuring that the standard being recommended integrates with your companies long-term technical needs.
Joining a working group presents a fantastic opportunity to expand your network and meet other experts in the fields. It provides access to information about worthwhile technologies and regulations at an early stage, helping you keep up to date.
The public review is an important stage that can influence the technical decisions made by the working group. It represents an opportunity for industry experts to review and comment on the draft. Providing their opinion on the standard will help shape its outcome and ensure it solves the need of the wider industry. Public reviewer comments on the standard are published in the standard catalogue under public review and do not require you to join the working group or take part in the writing process. This offers participants a chance to provide feedback on a standard of interest and impact its final content with a minimal time commitment.
The Patent License Pledge is based on Sections 2 and 3 of the Community Specification License 1.0, which is widely recognized as a standard in open source-inspired collaboration methods.
Under these, the participants retain their patent rights and/or claims in their inventions. However, they authorize the other participants (the licensees) to use that IP to the extent necessary to implement the required portions (including the required elements of optional portions) of the standard that are described in the standard documentation.
The participant may exclude certain patent rights and/or claims from the license pledge. The licensing terms are clearly listed in the heading of the standard document with details of the patent pledge – if applicable- under the relationship section of the same document. You should carefully read the patent pledge before implementing the standard to ensure compliance with the licensing terms.
All Copyrights to text of draft standards and published standards belongs to the Bitcoin Association.
The Copyright licence requires BA to allow the technical standard to be copied, modified, published and distributed for free, provided certain conditions are met. These conditions include that any commercial use of the copyrighted material in a software product be limited to the BSV blockchain only.
The licence also requires that any copies of the specification (or substantial parts thereof) include the copyright notice, i.e., © 2023 Bitcoin Association, and the text of the licence.
Any modifications or derivative works must be identified clearly and offered under the same licence. For example, a third party is free to expand on the standard further and even commercialise the improvement into a product, provided that product is for use with the BSV blockchain only. If the third party wanted to use a different blockchain, they would need to seek a commercial licence from BA.