BSV Technical Standards programme provides a process, tooling, guidance and resources for industry participants who, in response to a perceived need, wish to come together to standardise some aspect of the utility of Bitcoin SV. The standard development process is split into three phases, each made up of a number of activities. The full details of the standardisation process and activities for each stages are presented in this document.

Overview

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:

• Promote technical excellence and improve Bitcoin SV utility by enhancing interoperability through standardisation.
• Facilitate industry participation in the development of global standards.
• Ensure that the technical standards are maintained and are freely available.

During a formation workshop, the TSC designed processes for how it runs itself, and how standards progress from inception to recommendation.

TSC processes

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.

Committee member selection

• Participants: Project Coordinator, TSC
• Time limit: 4-6 weeks 
• IT Systems: Decision log, Email 

The TSC is formed of industry representatives. The selection process is designed to ensure representation from across all industries, locations, and skill sets. The TSC was formed with all parties involved agreeing that, in any given year, approximately one third of the TSC members’ tenure would expire, ensuring stability whilst providing an avenue for new participants to step forward. After this initial formation, all the TSC appointments will be fixed for three years, unless a trigger condition is met (see Early Termination of a member’s tenure).

A TSC member whose seat is up for renewal can apply to renew their role for a further three years. However, a member who is considered to have performed poorly, will score lower than a fresh applicant or a high performing member. Appointments are made to individuals; the company that employs the individual has no right to swap this employee with another one.

Anyone who wants to apply to become a member of the committee should meet the desired experience and skills as described in the role description. Applicants should bear in mind that they will be volunteering their time for the good of the wider BSV ecosystem. If they are not able to commit a reasonable amount of time to managing a standard working group if appointed, they should not apply. Although some of the content of these working groups will remain confidential to members for a short time, the overall process (and eventually, the content) will be transparently disclosed. Therefore, the TSC members will be somewhat accountable to the public for their activity, or the lack of it.

Desirable experience and attributes

• Demonstrate at least one of:
  • Strong technical knowledge of blockchain in at least one of the following areas: wallets, mining, node development, application development, data services; and/or 
  • Experience in a strategic role within technology, marketing, communications or governance field; and/or 
  • Experience in standards development associated with a domestically or internationally recognised standards body. 
• Demonstrate a track record in technical delivery. 
• Demonstrate a commitment to building business. 
• Have both time and interest to take one or more standards or governance projects and drive them forward to completion.
• Demonstrate a deep understanding of the latest trends and developments in the Bitcoin SV ecosystem. 
• Able to commit time to attend the TSC governance meetings in person (up to twice a year). 
• Comfortable with the idea of protecting intellectual property generated from the output of these processes. 
• Display a collaborative instead of competitive bent. 
• Strong attention to detail to review the technical elements of the standards documentation. 
• Proficient in the English language. 

Application process

A nominating committee will be formed to oversee the selection process. The committee will be supported by the project coordinator for the administrative aspect of the recruitment process. The nominating committee should be formed of up to 5 persons excluding the administrative support. Current committee members with exception of the members that are up to re-election, support staff and external stakeholders can all be part of the nominating committee.

Annually, a call for application will be published for a one-month period which can be extended by a further-month if no suitable applicant has come forward in the first round.

Following the closure of the window for application, the nominating committee has seven days to review the applications based on the required experience, skill sets and the review criteria. The highest-ranking applicants (2-3 for each position available) will be invited for a short interview with a select panel made up of nominating committee members and administrative staff. The leaving committee member cannot take part in this interview process. The nominating committee and member of the interview panel will meet to agree of the best applicant(s) and make a recommendation to the whole TSC committee on who should be appointed. The nominating committee is not required to recommended applicant to fill all available positions if it does not consider there is enough suitable applicants as long as the minimum number of 9 committee members to operate is reached.

The TSC will vote on the recommendation made by the nominating committee and appoint new member. The nominating committee chair will inform Bitcoin Association executive committee of the recommended appointments.

Review Criteria

• Representation from across the Bitcoin SV industry is important for a body of this nature to be effective. Areas of industry and skill sets that are less represented on the committee will score higher.
• To ensure representation from across all locations, the committee should endeavour to keep an international profile with appointed members based in different countries, ensuring where possible, a representation in key areas for BSV deployment.
• The TSC is made up of representatives from different companies, rather than multiple representatives from a single company. An applicant from a company already represented in the TSC will score lower.
• No preference will be offered to a TSC member whose seat is up for renewal. In addition, a member who is considered to have performed poorly will score lower than a fresh applicant or a high performing member.

Incomplete committee

If, at any given moment and for any given reason, the committee does not have eleven elected active members in place, it should continue its activities as usual as long as there are nine members remaining in the committee. Should the numbers of active elected committee member drop to eight, it should pause its activities until at least one new member is recruited.

Early termination of a member’s tenure

There are several trigger conditions that can cause a member’s tenure to terminate early:

1. Should a member change to a professional role or company that no longer aligns with the goals of the TSC, the individual should step down from the committee. To continue without proper alignment would be considered to be acting in bad faith.
2. A member’s company realigning itself in such a way as to be incompatible with the goals of the TSC and/ or Bitcoin Association.

Wilful failure to disclose a conflict of interest is grounds for immediate disqualification from the TSC. TSC membership candidates will be required to declare any potential conflicts of interest, which may exclude them from:

• participating in specific standards
• joining working groups
• proposing their own standards (for example, to further license revenue from their own IP)
• participating in the Checkpoint Review process of external submissions.

A re-election following the Committee member selection process will be held should any of these conditions be triggered. 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 by the committee with the decision recorded by vote.

If a member displays unethical or unprofessional behaviour that falls short of the ethical or professional standards, guides, or codes of conduct while representing the TSC and/or Bitcoin Association, their tenure could be terminated early. The TSC, excluding the member suspected of displaying professional misconduct, will meet to decide if the member’s tenure should be terminated early. This will be done via a special meeting where a vote will be recorded. The Committee member selection process will begin to replace the committee member whose tenure was terminated early.

Process amendments

The method for amending or defining new processes, is as follows:

Email:

• Initiating TSC member emails the Project Coordinator with a description of the proposal
• The Project Coordinator coordinates an enquiry email chain describing the proposal
• The TSC members respond with an Expression of interest
• Interested members discuss the proposal via email
• An approval vote is requested by the Project Coordinator
• If passed, the process amendment/creation is enacted and published to the TSC processes repository (web property)

Monthly meeting:

• Initiating TSC member emails the Project Coordinator with a description of the proposal and desire to bring the matter at the next TSC meeting.
• The Project Coordinator circulate the proposal in advance of the meeting to give time to TSC members to review it.
• Interested members discuss the proposal during at the meeting.
• An approval vote is requested by the Project Coordinator.
• If passed, the process amendment/creation is enacted and published to the TSC processes repository (web property)

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.

Bi-annual meetings

Once per year the TSC will meet for a standard-agenda meeting. The 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 meeting will also serve as a strategical planning session for the following year and to input in the longer strategic plan.

The typical agenda for this meeting is as follows:

Standards progresses update

• Summary of recently published standards
• Manage any escalations from process votes
• Review common dependencies across standards and working groups
• Address feedback on the TSC

Industry news

• Update the TSC members on Bitcoin Association activity
• Discuss external events/industry news
• Review recent regulatory changes that impact both currently recommended and future standards
• Update the TSC on pertinent advancements from industry

Strategical planning

• Review market priorities as understood from standards submissions
• Review and realignment of the roadmap
• Measure the TSC performance against objectives such as engagement and performance for the TSC activities in the standards process
  • Define metrics
  • Review metrics
  • Actions based on metrics
• Discuss following year strategy and input in the longer strategic plan.
• Define next year objectives to measure TSC performance.
• Any other business

Standards

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:

• Encourage growth of the Bitcoin SV ecosystem
• Promote interoperability between systems
• Enhance credibility of solutions built on Bitcoin SV from the perspective of:
  • Auditors
  • Regulators
  • Insurers
  • Clients
• Encourage the development of certification schemes
• Foster business growth and infer market signalling from proposals
• Have international reach (i18n)

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:

A number of IT systems are provided by BA for use during the standardisation process:

Submission

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. 

Articulate industry need

• Participants: Proposers
• Time Limit: Unlimited
• IT Systems: None

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.

Capture requirements

• Participants: Proposers
• Time Limit: Unlimited
• IT Systems: None

During this activity, Proposers elaborate the industry need to more fully understand the success criteria for any standard.

Submission to TSC

• Participants: Proposers, TSC
• Time Limit: “Instant” response (48 hours window)
• IT Systems: Online form, decision log

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.

Provisional working group

• Participants: Project Coordinator, TSC
• Time Limit: 2 weeks
• IT Systems: Email, decision log

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 Notion to start working on the draft while the TSC goes through the Checkpoint Review stage.

Checkpoint review

• Participants: TSC
• Time Limit: 1 month
• IT Systems: Email, decision log

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:

• Alignment with the TSP objectives
• Does not conflict or overlap with existing standards, active working groups or the existing standards roadmap
• Feasibility
• Resourcing
• Impact on existing standards
• Value to Bitcoin SV

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:

• A timed vote
• A super-minority (33%) may veto the proposal
• A minimum of 70% of the total of active committee members must cast a vote.
• A non-response is considered as an approval
• The vote will be coordinated by the Project Coordinator and conducted via email or poll.

Working group formation

• Participants: Project Coordinator, TSC, Authors, Reviewers
• Time Limit: 4 weeks
• IT Systems: Email, decision log

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 will be asked to sign a Patent License Pledge and Copyright Agreement (a stock artefact) as default At the Working Group or Author(s) request, the work can be protected under a Non-Disclosure Agreement (NDA), to protect any intellectual property (IP) generated during the drafting process.

Reviewers should be selected with the following roles:

• Subject matter experts (SMEs), to assess the standard against the requirements
• Key stakeholders (businesses that will use the standard)
• Standards experts, to assist in the construction of clear, concise and legible documents

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:

• act as a process guide for the group members
• ensure quality control during the drafting process
• provide coherence across a body of standards
• be the point of contact for any escalations that may arise from the 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.

Drafting and review

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.

Drafting

• Participants: Authors, BA Specialists (optional)
• Time Limit: Determined during Checkpoint Review
• IT Systems: CMS (wiki, GDocs, etc)

Structure of a Standards Document

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:

• Attributes describing properties of the standard
• Sections (or long-form textual content) containing the body of the standard
• Relationships which describe interactions to other standards, IP, and other known works

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.

Attributes

Sections/Template Structure

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. The sections describing the solution should be shared within the Working Group unless prior approval to share the DRAFT prior to PUBLIC REVIEW to external audience has been agreed by Working Group participants. Where the working group asked for the worked to be protected under a NDA, the work will be considered as commercial-in-confidence and should be shared only within the working group until all IP work has been completed.

Relationships

Artefacts

In addition to the standards document, working group should consider delivering the following artefacts when drafting a standard:

• Motivation, goals, benefits
• Flow/sequence/entity diagrams
• Test cases
• Security model, proofs
• Implementation guides
• Worked examples
• Code samples/snippets
• Open implementation
• Adaptations for specific audiences, suitable for different roles and skills.

Internal review

• Participants: Reviewers, Authors
• Time Limit: 1 Month
• IT Systems: CMS, decision log

The internal review phase attempts to satisfy the following requirements checklist:

• Suitable for intended needs (actually solves the problem stated in the working group document)
• Appropriate in content and language for intended audience
• Clear and unambiguous
• Sufficiently accurate and precise
• Capable of supporting legitimate claims of compliance and conformity
• Not unduly restrictive (does not stifle competition)
• Comprehensive within intended scope
• Legal status of content, IP

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.

Specialist review

• Participants: TSC, Project Coordinator, BA Specialists
• Time Limit: 1 month, runs concurrently with Internal Review and IP Review
• IT Systems: Decision log, email, online form

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.

IP review

• Participants: Authors, BA Specialists, Project Coordinator
• Time Limit: 1 month (plus IP lead time, if required), runs concurrently with Internal Review and IP Review
• IT Systems: Decision log, email, online form

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.

Stakeholder canvas

• Participants: Proposer(s) and Stakeholders as defined in the workgroup formation document
• Time Limit: 2 weeks
• IT Systems: Decision log, email, online form

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.

Public review

• Participants: Public
• Time Limit: 2 months
• IT Systems: Comments/forum/discourse/online form

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.

Standardisation

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.

Publication

• Participants: TSC, Working group
• Time Limit: 2 weeks
• IT Systems: CMS (BA standards library)

The standard is published to the TSC standards library. The Working Group may be dissolved at this point, subject to any further standards work coming from the original industry need. 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.

Adoption

• Participants: Public
• Time Limit: Unlimited
• IT Systems: Decision log

A period of time is allowed for the industry to digest and subsequently adopt/implement 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. A standard will remain in the published stage until it reaches these two triggers to move to the recommended stage:

• recorded a minimum of three implementations verified by the designated committee member
• has been a minimum of 12 months in publish stage.

There is no time limit for adoption.

Recommendation

• Participants: TSC
• Time Limit: 2 weeks
• IT Systems: Decision log, CMS

Once the standard has reached the minimal adoption level of three implementations, the designated committee member reports to the TSC on the response to the standard. Based on this report, the TSC will vote to recommend the standard. If the TSC determines that the standard has received sufficient adoption, it is promoted to a recommendation.

Withdrawal

• Participants: Public & TSC
• Time Limit: 2 weeks
• IT Systems: Decision log, CMS

TSC members and the public can request that the TSC review a published or recommended standard if they feel it as become obsolete. If the TSC determines that the standard as become obsolete after review, the standard will be withdrawn.

Appendix A: submission form

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:

Purpose

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:

• What is the problem you are trying to solve?
• What are you hoping to achieve with the standard?
• Is there an industry need? Has this industry need been validated by other companies?

Value Proposition

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:

• types of companies
• types of products/services
• types of customers

Please describe in what ways the beneficiaries will benefit. Examples can include the following:

• greater interoperability between companies
• an improved user experience
• lower operating costs

Collaborators

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.

Prior Art

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.

Proposed Solution

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

Appendix B: standard document model

A drafted standards document is a structured document comprising 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.

Attributes

Document Sections

History

Relationships

• IP licences and dependencies
• Previous versions
• Extends (existing standards extended by this standard)
• Modifies (existing standards changed by this standard)
• Deprecates (existing standards obsoleted by this standard)
• Depends On (existing standards that are foundational or prerequisite to this standard)
• Prior Art
• Existing Solution
• References (input required is this a catch-all or does it have a specific meaning?)

Supplementary Material

Supplementary material is a collection of optional additional documents that may assist the reader in understanding and implementation.