Our Process
From inception to release

Standard Overview

In January 2020, the Bitcoin Association (BA) formed the Technical Standards Committee (TSC) to design and oversee the Technical Standards Program (TSP). The mission statement of the TSP 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 freely available.

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

TSC Processes

In addition to the primary standards process, the TSC operate a number of internal processes. They are documented here and it is expected these, and the standards process, will be published to the web for public awareness. It is further intended that the public form is translated into all languages in which the BA usually publishes content. Most TSC internal processes are executed by the project coordinator, who performs a support and administration role outside of the elected TSC and is provided by the BA. The project coordinator works in cooperation with the TSC, with communications handled via email.

Governance

Committee Member Selection

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 skillsets. 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:

  • Attempt to define selection criteria that were wholly objective
  • Offer no preference to a TSC member whose seat is up for renewal, 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 switch out their representative mid-term for another employee
  • Prefer for the TSC to be made up of representatives from different companies, rather than multiple representatives from a single company

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

  • A member significantly changing their role within their company
  • A member leaving their employer, with or without a new employer lined up
  • A member’s company realigns itself in such a way as to be incompatible with the goals of the TSC and/ or the BA

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.

Process Amendments

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

  • Originating TSC member emails the project coordinator with a description of the proposal
  • The project coordinator coordinates an enquiry email chain describing the proposal
  • TSC members respond with an Expression of Interest
  • Interested members discuss the proposal via email
  • An approval vote is requested by the project coordinator via email
  • 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

The TSC will meet for a standard-agenda meeting, twice a year. This meeting will be timed to occur before the TSC reports to the BA 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:

  • Update the TSC members on BA activity
  • Discuss external events/ industry news
  • Update the TSC on pertinent advancements from industry
  • Manage any escalations from process votes
  • Status report (Red/ Amber/ Green) on in-flight standards, working group
  • Summary of recently published standards
  • If required, execute the TSC Member Selection process
  • Review recent regulatory changes that impact on both currently recommended and future standards
  • Measure TSC performance against objectives e.g. engagement, performance for TSC activities in the standards process
    • Define metrics
    • Review metrics
    • Actions based on metrics
  • Address feedback on the TSC
  • Review market priorities as understood from standards submissions
  • Review common dependencies across standards and working groups
  • Any other business

Standards

The BA 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 aspect of the utility of Bitcoin SV. The objectives of the standardisation process are:

  • 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
  • To encourage the development of certification schemes
  • Foster business growth and infer market signalling from proposals
  • To 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 category of participant. Each activity be subject to a time limit, after which no progress is often interpreted to mean 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, the BA will provide IT systems to assist those in the standardisation progress with the task at hand. These are all explained as each activity is presented in detail. The following participants are involved in the standardisation lifecycle:

ParticipantDescription
ProposerThe individual or group of industry players who collectively identify the need for a standard
TSCThe Technical Standards Committee
AuthorsIndividuals from industry tasked with writing the standard
TSC SponsorA member of the TSC assigned to each standard’s working group to facilitate the authoring and review process
ReviewersSelected individuals from industry who will confidentially review drafts produced by Authors prior to public review
BA SpecialistsIndividuals working on behalf of the BA who provide additional skills, such as legal or regulatory advice
PublicAny industry participant
Project CoordinatorAn administrative support staff member supplied by the BA

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

SystemDescription
EmailAn email system for use by the TSC and project coordinator when communicating with other participants
Decision LogTracking system capturing the context and justification for any decisions made that materially affect the delivered standard
CMSContent 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 FormA structured data capture form system, where the structure can be defined by the TSC

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. 

Parallel Gateway is represented as a diamond with a ‘+‘ sign in it. This means activities take place in parallel.
When such parallel events come together again, a diamond with an ‘x‘ sign in it represents an Exclusive Gateway / singular flow.

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.

Requirements Capture

  • 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 hour window)
  • IT Systems: Online form, decision log

Proposers complete a structured submission form provided by the BA, explaining the high-level goal of the standard. The TSC aim to provide an acknowledgement of receipt within 48 hours of submission.

Checkpoint Review

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

The TSC reviews the submitted standards 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, as this will be a function of the size/ complexity of the standard. The mechanism for concluding the checkpoint review will be an email ballot of TSC members, held under the same rules as process amendments:

  • A timed vote
  • A minimum of seven committee members must cast a vote
  • A super-minority (33%) may veto the proposal
  • A non-response is considered as an approval
  • The vote will be coordinated by the project coordinator and conducted via email

Workgroup Formation

  • Participants: Project coordinator, TSC, Authors, Reviewers
  • Time Limit: 2 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 industry if the proposers are not suitable for the role. The TSC, together with the project coordinator, identify stakeholders from industry. Stakeholders are offered a reviewer role. The target number of authors is low (2-3 preferred), whereas the number of reviewers may be larger. Authors and reviewers should sign an NDA (a stock artefact), to protect any intellectual property generated during the drafting process. 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 sponsor. The sponsor has a number of 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

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 completion of a final, reviewed draft. 

Parallel Gateway is represented as a diamond with a ‘+‘ sign in it. This means activities take place in parallel.
When such parallel events come together again, a diamond with an ‘x‘ sign in it represents an Exclusive Gateway / singular flow.

Drafting

  • Participants: Authors
  • Time Limit: Determined during checkpoint review
  • IT Systems: CMS (wiki, GDocs, etc)

Structure of a Standards Document

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 all have an interest. Different sections of a standards document will be geared towards one or more of these groups.

Attributes
AttributeDescription
VersionNumeric revision number, used for tracking draft amendments during the internal review cycle
AuthorsNames of the authors responsible for the draft
Tags/ CategoriesHigh level thematic grouping which, once published, can be used to find groups of related standards
Publication DateBlank until public review has completed and the standard is published and promoted for adoption
Expiry DateIf a standard is known to have a fixed lifetime and expected redundancy date, it is included here
Risk categories
Copyright noticesStandard notice for the content ownership and licence with respect to the authors, plus any quoted or otherwise included content used under licence
IP GenerationContains registration information of any new IP generated during drafting
Known ImplementationsLinks to available products, services, or solutions that implement this standard. May be updated on an on-going basis
Applies-to/ targetIndustry sections for whom this standard is most likely to be useful, for example Minerswallet providersdata service providers or exchanges
BRFC IDA unique identifier for this standard, generated as a function of title, authors and version fields
Acknowledgements
StatusMust be one of the following: draft | internal review | public review | published | recommended | withdrawn
Visibility/ sensitivity/ confidentialityIn 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

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, whilst sections describing the solution should be shared only under NDA within the Working Group until all IP work has completed.

SectionTarget AudienceVisibility
TitleAllPublic
Problem Statement/ PurposeAllPublic
Objectives/ JustificationAllPublic
ScopeAllPublic
Background/ ContextAllPublic
Method/ ConceptsImplementersNDA
SpecificationImplementersNDA
Exceptions/ Exclusions/ Out-of-scopeAllPublic
Glossary/ Terms and DefinitionsImplementersNDA
LimitationsImplementersNDA
RisksAllPublic
Errata and Change LogAllPublic
Decision LogAllPublic

Relationships

RelationshipDescription
IP licences/ dependenciesIf a standard builds on top of IP, reference the IP, owner, and licence status, together with information for implementers who wish to acquire a licence
Version historyList of prior draft versions, kept for contextual awareness together with changes made between revisions
ExtendsAny existing standards where this standard is strictly additive (adds new features)
ModifiesAny existing standards whose meaning is modified by this standard
DeprecatesPrevious standards replaced or made obsolete by this standard
Depends onExisting standards that an implementer must also deliver, in order to correctly implement this standard
Prior artKnown techniques outside of the standards process that this standard builds upon
Existing SolutionsProducts, services or techniques that attempt to solve a similar problem to this standard
ReferencesAdditional subject matter pertinent to this standard

Artefacts

In addition to the standards document, the 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
  • “Translations” by target audience, role, skill

Internal Review

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

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

  • Suitable for intended needs
  • 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 internal review can result in a standard being returned to the authors with feedback for areas to be addressed, or can be passed and the process may move to the next stage.

Specialist Review

  • Participants: WG (Authors, Reviewers, TSC Sponsor), BA specialists
  • Time Limit: 1 month (plus IP lead time, if required), runs concurrently with internal review
  • IT Systems: Decision log, email, online form

During specialist review, BA specialists work with the Working Group to assess the standard for potential IP issues, and 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 WG, the TSC and the project coordinator will ensure that suitable specialists are appointed to assist during this time.

Stakeholder Canvas

  • Participants: Workgroup (Authors, Reviewers, TSC Sponsor)
  • Time Limit: 2 weeks
  • IT Systems: Decision log, email, online form

The stakeholders, as identified during submission by the TSC, are consulted to determine if the standard, as presented, solves for the industry need identified – prior to the submission being made to the TSC.

Public Review

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

Once internal review and specialist review are completed, the standard transitions to public review. A two month time period allows for public comments. Upon the public commentary period closing, the WG must review the comments and decide for itself whether they show cause for returning to the drafting phase, proceeding to be published, or even to withdraw the standard.

Standardisation

During the standardisation phase, the standard is published via the BA website. A period of time is allowed for during which the TSC (and the WG) 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 to published, recommended, or withdraw the standard due to lack of interest. 

Parallel Gateway is represented as a diamond with a ‘+‘ sign in it. This means activities take place in parallel.
When such parallel events come together again, a diamond with an ‘x‘ sign in it represents an Exclusive Gateway / singular flow.

Publication

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

The standard is published to the BA standards library. At this stage, previous versions, the decision log, internal and public review notes are archived; these 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 be presented instead. It is not expected that individual comment authors are 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 intention-ed feedback disappears.

Adoption

  • Participants: Public
  • Time Limit: determined during checkpoint review
  • IT Systems: Decision log

A period of time is allowed for industry to digest and subsequently adopt/ implement the standard. This period is determined during checkpoint review.

Response Monitoring

  • Participants: TSC
  • Time Limit: determined during checkpoint review
  • IT Systems: Decision log

The TSC monitor industry response to the standard. This acts as the final signal from industry as to whether the standard solves the industry need that originally led to the standard being proposed.

Recommendation

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

If the TSC determine 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.

Withdrawal

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

If the TSC determine that the standard has not received sufficient adoption, it is withdrawn and archived. This is a final signal from industry that either the need is no longer required, or that the standard failed to meet that need.

Appendix A: Submission Form

The Submission to TSC step of the standards process calls for proposals to be submitted to the TSC.

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 solve 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 intellectual property that may otherwise become public knowledge (and therefore prior art).

A proposal should contain the following information:

Purpose

This section should introduce the members of the TSC, and prospective industry collaborators, to the problem you are trying to solve through the creation of a standard. This section is all about answering the ‘why’.

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, etc.
  • 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, etc.

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’, but this section is optional. If you have a proposed solution, or an idea of how you think it should be solved, please explain in as much detail as possible. If you don’t have a proposed solution, that is okay, a working group can still be formed to find a solution to the problem.

Appendix B: Standard Document Model

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.

Attributes

AttributeDescription
VersionA unique revision identifier
AuthorsLists the names and companies of the authors of the document
ReviewersLists the names and companies of the reviewers of the document
Tags and CategoriesKeyword-summaries of the standard, selected from a TSC-owned taxonomy
Publication DateReferring to the point in time that this version was completed, not necessarily made public
Valid UntilIf this document has an obvious or natural end-of-life, both the expiry date and reason should be listed
Risk Categoriesinput required unknowns – does this specification potentially mandate something that is against some applicable regulation?
Copyrightinput required lists the holders of the copyright to this document, and under what terms they licence it to the TSC and the public
IP Generationinput required lists any IP generated as a result of this document, together with the rights holder and licensing information
Known Implementationsinput required for the case where a standard is a formalisation of a de-facto prior art, reference current implementations
Applies ToMarket segment(s) to which this standard may be applicable (e.g. Miners, wallets, data service providers, etc.)
BRFC IDA unique reference to this version of this standard to-do: link to canonical BRFC definition
Acknowledgementsinput required snappy definition needed
StatusThe current step in the standards Process that the proposal described by this document has reached
VisibilityA measure of the sensitivity and confidentiality requirements for distribution of this standard (for example, IN-CONFIDENCE prior to any IP being filed for)

Document Sections

SectionDescriptionAudience
TitleGeneral
BackgroundContextual setting for the standardGeneral
Problem StatementThe purpose of the standardGeneral
ObjectivesJustification for the standardGeneral
ScopeTo include exceptions, exclusions, non-goals, out-of-scopeGeneral
Method and Conceptsinput requiredExperts
Specificationinput requiredExperts
Glossaryinput requiredExperts
Limitationsinput requiredExperts
Risksinput requiredGeneral

History

ArtefactDescription
ErrataCorrections to previous publications of this standard
Change LogVersion history with changes since the previous version (or blank for first draft)
Decision LogThe 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

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

SupplementDescription
Worked ExampleWhere a standard is highly prescriptive, a worked example may clarify how it actually fits together
DiagramsFlow, sequence, and/or entity diagrams may assist a reader in understanding the standard
Code SnippetsLess comprehensive than a worked example but illustrates how a small part of the standard may be implemented
Alternative Explanations“Translations” of the standard by target audience – what is meaningful to a regulator will differ to what is meaningful to a software engineer, materials to each appropriate audience may aid in conveying the standard and its benefits to those with differing roles and skills
Security ModelSecurity and trust model, with formal proofs
Methodsinput required Describe the intention — there was discussion around the difference between “standard”, “method” and “implementation”, a clarifying statement here would be useful
Test CasesData sets describing expected outputs for given inputs
Reference ImplementationSimilar to worked example, a working code implementation of the standard for demonstration purposes
Overview