In January 2020, the Bitcoin Association formed the Technical Standards Committee (TSC) to design and oversee the Bitcoin SV Technical Standards program. The mission statement of the TSC is to:
During a formation workshop, the TSC designed processes for how it runs itself, and how standards progress from inception to recommendation.
In addition to the primary standards process, the TSC operates a number of internal processes. These processes are documented below and will be published along with the standards process, to the web, for public awareness. The public form of these processes will also be translated into all the languages in which Bitcoin Association usually publishes content.
Most internal processes are executed by the Project Coordinator, an administrative support staff member supplied by Bitcoin Association, who performs a support and administration role outside of the elected TSC and is provided by Bitcoin Association. The Project Coordinator works in cooperation with the TSC, with communications handled via email.
The TSC is formed from industry representatives. A selection process was discussed and agreed during the Formation Workshop, which was designed to ensure representation from across all areas of industry, all geographies, and all skill sets. The formation TSC was appointed with a variety of terms in order to ensure that in any given year approximately one third of the TSC seats come up for re-selection, ensuring stability whilst providing an avenue for new participants to step forward. After this initial formation, all TSC appointments will be fixed for three years, unless a trigger condition is met.
The exact process for member selection has not been finalised, however the following features were discussed:
There are several trigger conditions that can cause a member’s tenure to terminate early:
A re-election will be held should any of these conditions trigger. Depending on the nature of the trigger, it may be acceptable and even appropriate for the outgoing TSC member to be immediately reappointed back to the TSC. This will be assessed on a case-by-case basis.
TSC membership candidates will be required to declare any potential conflicts of interest, which may exclude them from participating in specific standards, from joining working groups, from proposing their own standards (for example, to further licensing revenue from their own IP), or from participating in the checkpoint review process of outside submissions. Wilful failure to disclose a conflict of interest is grounds for immediate disqualification from the TSC.
The method for amending or defining new processes, is as follows:
The voting phase is timed, with a maximum window of two weeks. A super-minority (33%) may veto a change, in the interests of stability and the highest possible level of support for any change. Any non-response after the time window expires, is considered an approval.
If a proposal is vetoed, it may be further discussed and re-presented for voting. Should a proposal be vetoed three times, it is escalated to the next bi-annual meeting for further discussion.
Twice per year the TSC will meet for a standard-agenda meeting. This meeting will be timed to occur before the TSC reports to the Bitcoin Association Exec Committee are due, and the output of this meeting will be used to feed into that report.
The typical agenda for this meeting is as follows:
TSC provides a process, tooling, guidance and resources for industry use by participants who, in response to a perceived need, wish to come together to standardise some aspects of the utility of Bitcoin SV.
The objectives of the standardisation process are to:
The standardisation process is split into three phases:
Each phase of the standardisation process is made up of a number of activities. An activity involves one or more categories of participants. Each activity is subject to a time limit, after which no progress is often interpreted to mean that either the TSC must intervene to resolve any blockers, or the industry need was not strong enough for those involved, to progress the standard further. Finally, Bitcoin Association will provide IT systems to assist those in the standardisation progress with the task at hand. These processes will be explained as each activity is presented in detail.
The following participants are involved in the standardisation lifecycle:
|Proposer||The individual or group of industry players who collectively identify the need for a standard|
|TSC||The Technical Standards Committee|
|Authors||Individuals from the industry tasked with writing the standard|
|TSC Sponsor||A member of the TSC assigned to each standard’s working group to facilitate the authoring and review process|
|Reviewers||Selected individuals from industry who will confidentially review drafts produced by Authors prior to public review|
|BA Specialists||Individuals working on behalf of Bitcoin Association who provide additional skills, such as legal or regulatory advice|
|Public||Any industry participant|
|Project Coordinator||An administrative support staff member supplied by Bitcoin Association|
|Stakeholders||Businesses and Individuals from the industry that have a need for the standard. The Proposer is, by default, a stakeholder|
A number of IT systems are provided by BA for use during the standardisation process:
|An email system for use by the TSC and the Project Coordinator when communicating with other participants|
|Decision Log||Tracking system capturing the context and justification for any decisions made that materially affect the delivered standard|
|CMS||Content Management System, where Authors work to draft a standard, Reviewers read and review the standard, and ultimately the public may access the published standard|
|Online Form||A structured data capture form system, where the structure can be defined by the TSC|
The submission phase of the standardisation process describes the activities undertaken from initially identifying a business need through to the formation of a Working Group (WG) that will drive the standard forwards to completion.
The entry point to the standards process is the identification of an industry need.
This activity is complete when Proposers are able to articulate that industry need.
During this activity, Proposers elaborate the industry need to more fully understand the success criteria for any standard.
Proposers complete a structured submission form provided by Bitcoin Association, explaining the high-level goal of the standard.
The TSC aim to provide an acknowledgement of receipt within 48 hours of submission.
At the Proposer’s request, the TSC can provide an indicative response to the Proposer(s), earlier into the submission process of facilitating a provisional working group in advance of full checkpoint review approval. This aims to tackle the disconnect between the Proposer’s enthusiasm to work on the standard at the time of the submission and the delay due to the long window of the checkpoint process.
A lighter review of the proposal will be done jointly by the Project Coordinator and one TSC member to find any red flags in the proposal. If there are no major issues, the Proposer(s) will be provided with a limited access to Confluence to start working on the draft while the TSC goes through the Checkpoint Review stage.
The Project Coordinator will designate three committee members to review each submitted standard proposal. The remaining committee members are invited but not required to review the proposal. The following criteria are assessed:
In addition, the Checkpoint Review is used to determine an appropriate time box for the initial drafting process, adoption and response monitoring, as this will be a function of the size/complexity of the standard.
The mechanism for concluding the Checkpoint Review will be a vote by the TSC members, held under the same rules as process amendments:
Proposers are the preferred candidates for Author roles, however, the TSC, together with the Project Coordinator, may help find suitable Authors from the industry if the Proposers are not suitable for the role.
Expressions of interest to join a working group will be sought for every standard going through the standardisation process. Proposers should be encouraged to approach relevant contacts in their network to participate in the standardisation effort. The TSC can identify stakeholders from the industry and invite them to apply to join a working group as Authors or Reviewers. Stakeholders who are not Authors are offered a Reviewer role.
A notice of expression of interest is circulated to fill the Reviewer and Author roles when the Proposer is not suitable for the role, and if they are not filled, additional Authors are sought. The Reviewer and Author selections are made based on the applicant suitability to the desired criteria listed in the notice.
The target number of Authors is low (2-3 preferred), whereas the number of Reviewers may be larger. Authors and Reviewers should sign a Non-Disclosure Agreement (a stock artefact), to protect any intellectual property (IP) generated during the drafting process.
Reviewers should be selected with the following roles:
As needed, the TSC may appoint users, implementers, technical experts and standards experts to supplementary roles within a working group.
The working group is formed when Authors and Reviewers are selected, and when one TSC member agrees to perform the role of a Sponsor. A working group formation document is published on the TSC website listing the review criteria that will be used in future stages to assess if the solution presented solves the stated industry need.
The TSC Sponsor has the following responsibilities within a working group:
If the TSC Sponsor reaches the end of their term of office or have their tenure terminated while their working group is still active, the TSC will designate a replacement to carry on the process. This replacement selection will be decided by the TSC, coordinated by the Project Coordinator, and recorded into the decision log.
The Drafting and Review phase of the standardisation process describes the activities undertaken from the successful formation of a working group through to the completion of a final, reviewed draft.
Authors can request the help of specialist support via their TSC Sponsor for the Draft and subsequent internal reviews.
The TSC have agreed on a common format for standards documents. There are three aspects to a standard:
A standards document is primarily intended to be read by implementers. However, policy/law makers, auditors, insurers, certification bodies and educators may have an interest. Different sections of a standards document will be geared towards one or more of these groups.
|Version||Numeric revision number, used for tracking draft amendments during the internal review cycle|
|Authors||Names of the Authors responsible for the draft|
|Tags / Categories||High level thematic grouping which, once published, can be used to find groups of related standards|
|Publication Date||Blank until public review has completed and the standard is published and promoted for adoption|
|Expiry Date||If a standard is known to have a fixed lifetime and expected redundancy date, it is included here|
|Copyright Notices||A standard notice for the content ownership and licence with respect to the Authors, plus any quoted or otherwise included content used under licence.|
|IP Generation||Contains registration information of any new IP generated during drafting|
|Known Implementations||Links to available products, services, or solutions that implement this standard. May be updated on an on-going basis|
|Applies-to / target||Industry sections for whom this standard is most likely to be useful, for example, miners, wallet providers, data service providers or exchanges|
|BRFC ID||A unique identifier for this standard, generated as a function of title, Authors and version fields|
|Acknowledgements||Direct or indirect contributors, or references to previous work that inspired the standard.|
Must be one of the following:
DRAFT INTERNAL REVIEW
PUBLIC REVIEW PUBLISHED
|Visibility / sensitivity / confidentiality||In the interest of protecting new IP during the drafting process, standards are in-confidence until legal assessment has been completed, which must happen before moving to Public Review|
The long-form textual content of a standard is made up of several templated sections. During the DRAFT process, sections that describe the problem may be visible to all and used to attract external Reviewers during the PUBLIC REVIEW phase, whilst sections describing the solution should be shared only under Non-Disclosure Agreement within the working group until all IP work has been completed.
|Problem Statement / Purpose||All||Public|
|Objectives / Justification||All||Public|
|Background / Context||All||Public|
|Method / Concepts||Implementers||NDA|
|Exceptions / Exclusions / Out-of-scope||All||Public|
|Glossary / Terms and Definitions||Implementers||NDA|
|Errata and Change Log||All||Public|
|IP licences / dependencies||Lists known intellectual property present in this standard, together with licencing terms for implementations of the standard (if known).|
|Version history||List of prior draft versions kept for contextual awareness, together with changes made between revisions|
|Extends||Any existing standards where this standard is strictly additive (adds new features)|
|Modifies||Any existing standards whose meaning is modified by this standard|
|Deprecates||Previous standards replaced or made obsolete by this standard|
|Depends on||Existing standards that an implementer must also deliver, in order to correctly implement this standard|
|Prior art||Known techniques outside of the standards process that this standard builds upon|
|Existing Solutions||Products, services or techniques that attempt to solve a similar problem to this standard|
|References||Additional subject matter pertinent to this standard|
In addition to the standards document, working group should consider delivering the following artefacts when drafting a standard:
The internal review phase attempts to satisfy the following requirements checklist:
The Reviewers should assess the draft using the requirements checklist and provide written feedback. The Authors are invited to review the feedback and provide additional information if needed. These actions can be iterated several times during the time frame defined for Internal Review. At the end of the stage, the Reviewers and Authors will have reached a consensus on the standard being returned to the Authors with feedback for areas to be addressed, or it can be passed, and the process may move to the next stage.
If there is a strong disagreement on the chosen solution between the Reviewers and Authors at the end of the stage, the Stakeholders will be asked to give their recommendation on whether the standard can move to the next stage.
If the standard is reverted to the draft stage, the Reviewers will define a new timebox to work on the draft before the standard is sent back for Internal Review. A standard that is considered unsuitable to progress to the next stage after a second Internal Review will be withdrawn.
This is an optional stage.
The working group can request a Specialist Review if there are specific concerns that they wish to address. During a Specialist Review, BA Specialists work with the working group to assess the standard to ensure that the standard does not recommend something explicitly prohibited by various regulations.
The nature of this phase will depend on the context of the standard and the problem being solved. The working group, the TSC and the Project Coordinator will ensure that suitable specialists are appointed to assist during this time.
If BA Specialists recommend minors changes to pass the Specialist Review stage, the working group will vote to amend the draft or withdraw the proposal if they feel the required changes would prevent them from solving the identified industry need. If the Specialist Review concludes that the standard recommends a solution explicitly prohibited by various regulations, the TSC will review the specialists’ conclusions and vote on whether the standard should revert to drafting stage or be withdrawn.
During this stage, the Project Coordinator will confirm if the Authors have contributed to any IP and if the IP is protected to the satisfaction of their company. They will also confirm if any additional IP was included in the drafting process and if the IP owner has decided on a document for a license/pledge. The Authors can request for a BA Specialist to assess the standard for potential IP issues.
Where the Proposers are not the Authors, the Proposers are consulted to determine if the standard, as presented, provides a solution for the industry need that was identified, prior to the submission being made to the TSC. If there is no consensus at the end of the stage, a vote will take place and the majority of stakeholders must agree it provides a solution for the industry need that was identified for the standard to be sent for Public Review. If it is voted that the standard does not meet the industry needs identified, the working group can revert to drafting stage or withdraw the standard.
If it is decided to return the standard to the draft stage, the working group will define a timebox before the standard is sent back to Internal Review. A standard that is considered unsuitable to progress to Public Review on the second occasion will be withdrawn.
Once Internal Review and specialist review are completed, the standard transitions to Public Review. A two-month time period allows for public comments.
When the public commentary period closes, the working group must review the comments and decide for itself whether they have reason for returning the standard to the drafting phase, publish it or withdraw it altogether.
During the standardisation phase, the standard is published via the TSC website. A period of time is allowed during which the TSC and the working group monitor adoption and/or implementations. This period of time is determined by the scale and scope of the standard. Once elapsed, the TSC make a final decision (through majority vote) on whether to promote the publication of the standard to published, recommended, or withdraw the standard due to lack of interest.
The standard is published to the TSC standards library. At this stage, previous versions, the decision log, Internal and Public Review notes are archived, and they do not form part of the published artefact.
A summary of comments received during both Internal and Public Review is also published. Although comments may be presented as-is, it is expected that a summary of trends in comments compiled by the working group will be presented instead. Individual comment authors may not be named. However, the comment review publication provides a level of transparency for both authors and the TSC, and allows for specific concerns, observations and suggestions to be addressed. This is considered an indicator that the review process is not simply a void into which well-intended feedback disappears.
A period of time is allowed for the industry to digest and subsequently adopt/implement the standard. This period is determined during the Checkpoint Review.
Once the standard is published, the TSC designates two committee members to monitor and report to the working group Sponsor on the industry response to the standard. This acts as the final signal from the industry as to whether the standard solves the industry need that originally led to the standard being proposed.
Once the standard has reached the end of the Adoption and Response monitoring stage, the designated committee member reports to the TSC on the response to the standard. Based on this report, the TSC will vote to recommend or withdraw the standard. If the TSC determines that the standard has received sufficient adoption, it is promoted to a recommendation. The Working Group may be dissolved at this point, subject to any further standards work coming from the original industry need.
If the TSC determines that the standard has not received sufficient adoption, it is withdrawn and archived. This is a final signal from the industry that either the need no longer exists, or the standard failed to meet that need.
The Submission to TSC activity of the standards process calls for proposals to be submitted to the TSC. A proposal should contain the following information:
This section should introduce the TSC members and prospective industry collaborators, to the problem you are trying to solve through the creation of a standard.
It would be helpful if the following questions are addressed directly:
This section is all about explaining the value proposition created by the implementation of the proposed standard. This section focuses on the ‘who’ and ‘what’ of the anticipated benefits.
Please describe who you see as the intended beneficiaries of a successful implementation of the proposed standard. Examples can include the following:
Please describe in what ways the beneficiaries will benefit. Examples can include the following:
Are there any other companies and/or individuals who have expressed interest in collaborating on the creation of the proposed standard, either as an Author or as a Reviewer? If so, please include their contact details.
This section is optional. Are there any other standards/solutions that already solve this problem, either partially or wholly? Why does a new standard need to be created? Please include relevant references to any prior art.
This section is all about the ‘how’ and is optional. If you have a proposed solution, or an idea of how you think it should be solved, you can write the big lines here. This section is for indication only, defining the solution will be done by the parties involved in writing the standard once in development.
At this stage, the solution overview should not be too detailed. The TSC may publish the list of proposals that have been received as part of their activities in securing co-Authors and Reviewers, or in the course of managing multiple proposals attempting to find a solution for the same requirements. As this may be made public, nothing in the solution approach should disclose key inventions that may be part of the proposal, in order to protect any IP that may otherwise become public knowledge (and therefore prior art).
A drafted standards document is a structured document comprising of defined sections, attributes, and external relationships. In addition, a standards document may be accompanied by supplementary material. This appendix describes the model of a standards document.
|UID||A unique identification number|
|Version||A unique revision identifier|
|Authors||The names and companies of the Authors of the document|
|Reviewers||The names and companies of the Reviewers of the document|
|Tags and categories||Keyword-summaries of the standard, selected from a TSC-owned taxonomy|
|Publication date||Referring to the point in time that this version was completed, not necessarily made public|
|Valid until||If this document has an obvious or natural end-of-life, both the expiry date and reason should be listed|
Bitcoin Association standard copyright statement applies:
© (add year) Bitcoin Association. Unless otherwise specified or required in the context of its implementation on BSV Blockchain, no part of this standard may be reproduced or utilised otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission of Bitcoin Association.
|IP generation||A list of all new IP generated during the course of the development of this standard|
|Known implementations||For the case where a standard is a formalisation of a de-facto prior art, reference current implementations|
|Applies To||Market segment(s) to which this standard may be applicable (for example, miners, wallets, data service providers, etc.)|
|BRFC ID||A unique identifier for this standard, generated as a function of title, authors and version fields|
|Acknowledgements||Direct or indirect contributors, or references to previous work that inspired the standard|
|Status||The current step in the standards Process that the proposal described by this document has reached|
|Visibility||A measure of the sensitivity and confidentiality requirements for distribution of this standard (for example, IN-CONFIDENCE prior to any IP being filed for)|
|Background||Contextual setting for the standard||General|
|Problem Statement||The purpose of the standard||General|
|Objectives||Justification for the standard||General|
|Scope||To include exceptions, exclusions, non-goals, out-of-scope||General|
|Method and Concepts||Explication of the methods, specific tools, and procedures for collecting and analysing data approach. Justification of the approach if it is not a standard widely accepted approach. Description of the methods of data collection/selection, if applicable.||Experts|
|Specification||This is where you state your business case and where your request is assessed thoroughly, and a decision is possibly made based on your input in this section. This section is usually quite elaborate, depending on the level of detail and complexity of the information you wish to provide.||Experts|
|Glossary||Definition of industry or technical terms used throughout the document||Experts|
|Limitations||Describe any restrictions or defects that can impede or negatively impact your ‘deliverable’.||Experts|
|Errata||Corrections to previous publications of this standard|
|Change Log||Version history with changes since the previous version (or blank for first draft)|
|Decision Log||The standard itself captures the what and the how, the decision log captures the why which may include alternatives not selected and the reason for preferring what was selected.|
Supplementary material is a collection of optional additional documents that may assist the reader in understanding and implementation.
|Worked Example||Where a standard is highly prescriptive, a worked example may clarify how it actually fits together|
|Diagrams||Flow, sequence, and/or entity diagrams may assist a reader in understanding the standard|
|Code Snippets||Less comprehensive than a worked example but illustrates how a small part of the standard may be implemented|
|Alternative Explanations||Clear and meaningful explanation of the standard for different, discrete, targeted audiences such as regulators, software engineers and other such groups, in such a way that the explanation is beneficial and specific to each group consisting of different roles and skills, for example, the way the standard would be relevant to a software engineer would be very different from how it would be relevant to a regulator.|
|Security Model||Security and trust model, with formal proofs|
|Test Cases||Data sets describing expected outputs for given inputs|
|Reference Implementation||Similar to worked example, a working code implementation of the standard for demonstration purposes|