This repository contains early-stage research of interest to the blockchain community.
Blockchain Commons Research papers (BCRs) are not standards. They are fluid specifications, typically based on our own libraries or other coding. Because of their fluidity, BCRs might change without notice. If you decide to adopt a Blockchain Commons Research paper, you are becoming a Research Partner, examining how the specification might work in the real world. We look forward to working with you!
If you are using the specifications from a BCR, please let us know. Having a BCR in usage by at least two parties other than Blockchain Commons is one of our criteria for advancing a BCR to a Blockchain Commons Proposal (BCP), increasing its stability. If you can only use a specification if it is advanced to the BCP stage, sldo let us know that, as we sometimes advance BCRs on our own if they have achieved sufficient maturity.
Generally, it's only if a BCR advances to the BCP stage that we more deeply involve community in its continued maturation and focus on it becoming an actual standard.
Each BCR has a status which is indicated by a symbol.
| Symbol | Title | Description |
|---|---|---|
| ❌❌ | Withdrawn | Of historic interest only. Withdrawn either because never came into use or proved sufficiently problematic that we do not recommend its usage in any way. |
| ❌ | Superseded | Superseded by a newer BCR. We do not suggest implementing as an output format, but you may still wish to implement as an input format to maintain backward compatibility. |
| 📙 | Research | Contains original research or proposes specifications that have not yet been implemented by us. Offered to the community for consideration. |
| ⭐️ | Reference Implementation | At least one reference implementation has been released, usually as a library, and may include demos or other supporting tools. This specification still remains very open to change because it has not yet (to our knowledge) been implemented by additional parties. |
| ⭐️⭐️ | Multiple Implementations | At least two (known) implementations exist, at least one not by the owner of the reference implementation. Has demonstrable community support. May still change due to the needs of the community, but community feedback will be sought. |
| ⭐️⭐️⭐️ | Standards Track | Typically at least two implementations, and is considered stable and ready for standardization. Being proposed as a BIP, IETF Internet Draft, or some other standardization draft format. Will typically be moved to the BCP repo. Though changes may still be made to the specification, these changes will exclusively be to allow for standardization, and will be conducted with community feedback. |
| ⭐️⭐️⭐️⭐️ | Standardized | A specification has been standardized as a an IETF RFC, BIP, or approved by some other standards body. |
| 📖 | Implementation Guide | A developer's guide to implementating a specification that may also double as the specification itself. |
❌❌ after another status symbol is read, "...but withdrawn" and ❌ is read, "...but superseded".
| Number | Title | Owner | Status |
|---|---|---|---|
| BCR-2020-001 | Uniformly Translating Entropy into Cryptographic Seeds | Wolf McNally | 📙 |
| BCR-2020-002 | Bech32 Encoding for Cryptographic Seeds | Wolf McNally | ❌❌ |
| BCR-2020-003 | Encoding Binary Compatibly with URI Reserved Characters | Wolf McNally | 📙 |
| BCR-2020-004 | The BC32 Data Encoding Format | Wolf McNally | ⭐️❌❌ |
| BCR-2020-005 | Uniform Resources (UR): Encoding Structured Binary Data for Transport in URIs and QR Codes (Version 2) | Wolf McNally | ⭐️⭐️ |
| BCR-2020-006 | Registry of Uniform Resource (UR) Types | Wolf McNally | ⭐️⭐️ |
| BCR-2020-007 | UR Type Definition for Hierarchical Deterministic (HD) Keys | Wolf McNally | ⭐️⭐️ |
| BCR-2020-008 | UR Type Definition for Elliptic Curve (EC) Keys | Wolf McNally | ⭐️ |
| BCR-2020-009 | UR Type Definition for Cryptocurrency Addresses | Wolf McNally | ⭐️⭐️ |
| BCR-2020-010 | UR Type Definition for Bitcoin Output Descriptors (Version 1) | Wolf McNally | ⭐️⭐️❌ |
| BCR-2020-011 | UR Type Definition for Sharded Secret Key Reconstruction (SSKR) | Wolf McNally | ⭐️ |
| BCR-2020-012 | Bytewords: Encoding binary data as English words | Wolf McNally | ⭐️⭐️ |
| BCR-2020-013 | CRC-32 Checksums in CBOR | Wolf McNally | ❌❌ |
| BCR-2020-014 | URs on E-paper display | Gorazd Kovacic | ⭐️ |
| BCR-2020-015 | UR Type Definition for BIP44 Accounts (version 1) | Craig Raw | ⭐️⭐️❌ |
| BCR-2021-001 | UR Type Definitions for Transactions Between Airgapped Devices | Wolf McNally | ⭐️❌ |
| BCR-2021-002 | Digests for Digital Objects | Wolf McNally | ⭐️ |
| BCR-2022-001 | Encrypted Message | Wolf McNally | ⭐️ |
| BCR-2022-002 | ARID: Apparently Random Identifier | Wolf McNally | ⭐️ |
| BCR-2023-001 | Compressed Message | Wolf McNally | ⭐️ |
| BCR-2023-002 | Known Values: A Compact, Deterministic Representation for Ontological Concepts | Wolf McNally | ⭐️ |
| BCR-2023-003 | Gordian Envelope Extension: Known Values | Wolf McNally | ⭐️ |
| BCR-2023-004 | Gordian Envelope Extension: Symmetric Encryption | Wolf McNally | ⭐️ |
| BCR-2023-005 | Gordian Envelope Extension: Compression | Wolf McNally | ⭐️ |
| BCR-2023-006 | Gordian Envelope: Attachments | Wolf McNally | ⭐️ |
| BCR-2023-007 | Gordian Envelope: Bitcoin Output Descriptors (Version 2) | Wolf McNally | ⭐️❌❌ |
| BCR-2023-008 | dCBOR: Preferred Encoding of Dates | Wolf McNally | ⭐️ |
| BCR-2023-009 | Gordian Envelope: Cryptographic Seeds | Wolf McNally | ⭐️ |
| BCR-2023-010 | Bitcoin Output Descriptor (Version 3) | Wolf McNally | ⭐️⭐️ |
| BCR-2023-011 | UR Type Definitions for Public Key Cryptography | Wolf McNally | ⭐️ |
| BCR-2023-012 | Gordian Envelope Expressions | Wolf McNally | ⭐️ |
| BCR-2023-013 | Gordian Envelope Cryptography | Wolf McNally | ⭐️ |
| BCR-2023-014 | Gordian Sealed Transaction Protocol (GSTP) | Wolf McNally | ⭐️ |
| BCR-2023-015 | UR Type Definition for Cryptographic Nonce | Wolf McNally | ⭐️ |
| BCR-2023-016 | UR Type Definition for Scrypt-Hashed Password | Wolf McNally | ⭐️ |
| BCR-2023-017 | UR Type Definition for Random Salt | Wolf McNally | ⭐️ |
| BCR-2023-018 | Gordian Depository API | Wolf McNally | ⭐️ |
| BCR-2023-019 | UR Type Definition for BIP44 Accounts (Version 2) | Craig Raw | ⭐️⭐️ |
| BCR-2024-001 | Multipart UR (MUR) Implementation Guide | Wolf McNally | 📖⭐️⭐️ |
| BCR-2024-002 | dCBOR: A Deterministic CBOR Application Profile | Wolf McNally | ⭐️⭐️⭐️ |
| BCR-2024-003 | The Gordian Envelope Structured Data Format | Wolf McNally | ⭐️ |
| BCR-2024-004 | Gordian Transport Protocol Implementation Guide Envelope Request & Response Implementation Guide |
Shannon Appelcline | 📖⭐️ |
| BCR-2024-005 | CBOR Encodings for Cryptographic Keys and Signatures | Wolf McNally | 📙 |
| BCR-2024-006 | Representing Graphs using Gordian Envelope | Wolf McNally | 📙 |
| BCR-2024-007 | Decorrelation of Gordian Envelopes | Wolf McNally | ⭐️ |
Also see our Testimony and our Blockchain Commons Proposals.
Please feel free to submit your own Drafts of BCRs for specifications that support the creation of open, interoperable, secure & compassionate digital infrastructure to this repo as PRs, as follows.
All contributions to this repo require a Signed Contributor License Agreement (which will be needed if we submit to other organizations like IETF, W3C, Linux Foundation, etc.).
Please number all Bitcoin Research BCRs with a four-digit number representing the current year (YYYY) followed by a three-digit sequence number for that year (SSS). For example: bcr-2020-001 is the first BCR for 2020, bcr-2020-017 is the 17th, and bcr-2021-001 is the first BCR for 2021.
Note that the sequence number reverts to 001 at the start of each year.
Please be sure that your title is concise, yet informative.
When updating BCRs, please use semantic versioning for your version number.
Most briefly: your version number should be of the form X.Y.Z, where X is the major number ("0" for a BCR Draft; "1" for something ready to become a BCR Work Product; and "2" or higher for a new version that has introduced a backward-incompatible change), Y is the minor number (for a backward-compatible new feature), and Z is the patch number (for fixing typos and making other clarifications that don't fundamentally change what the BCR means).
But please consult the semantic versioning document for more information and adjust appropriately for the fact that these are textual BCRs, not software.
Please list the person primarily responsible for the BCR, and moving it forward, as the owner. If there are multiple authors, they should be listed on the BCR itself, not on this overview.
Unless otherwise noted (either in this /README.md or in the file's header comments) the contents of this repository are Copyright © by Blockchain Commons, LLC, and are licensed under the spdx:BSD-2-Clause Plus Patent License.
This research is a project of Blockchain Commons. We are proudly a "not-for-profit" social benefit corporation committed to open source & open development. Our work is funded entirely by donations and collaborative partnerships with people like you. Every contribution will be spent on building open tools, technologies, and techniques that sustain and advance blockchain and internet security infrastructure and promote an open web.
To financially support further development of this research and other projects, please consider becoming a Patron of Blockchain Commons through ongoing monthly patronage as a GitHub Sponsor. You can also support Blockchain Commons with bitcoins at our BTCPay Server.
We encourage public contributions through issues and pull requests! Please review CONTRIBUTING.md for details on our development process. All contributions to this repository require a GPG signed Contributor License Agreement.
The best place to talk about Blockchain Commons and its projects is in our GitHub Discussions areas.
Gordian Developer Community. For standards and open-source developers who want to talk about interoperable wallet specifications, please use the Discussions area of the Gordian Developer Community repo. This is where you talk about Gordian specifications such as Gordian Envelope, bc-shamir, Sharded Secret Key Reconstruction, and bc-ur as well as the larger Gordian Architecture, its Principles of independence, privacy, resilience, and openness, and its macro-architectural ideas such as functional partition (including airgapping, the original name of this community).
Blockchain Commons Discussions. For developers, interns, and patrons of Blockchain Commons, please use the discussions area of the Community repo to talk about general Blockchain Commons issues, the intern program, or topics other than those covered by the Gordian Developer Community or the Gordian User Community.
As an open-source, open-development community, Blockchain Commons does not have the resources to provide direct support of our projects. Please consider the discussions area as a locale where you might get answers to questions. Alternatively, please use this repository's issues feature. Unfortunately, we can not make any promises on response time.
If your company requires support to use our projects, please feel free to contact us directly about options. We may be able to offer you a contract for support from one of our contributors, or we might be able to point you to another entity who can offer the contractual support that you need.
The following people directly contributed to this repository. You can add your name here by getting involved. The first step is learning how to contribute from our CONTRIBUTING.md documentation.
| Name | Role | Github | GPG Fingerprint | |
|---|---|---|---|---|
| Christopher Allen | Principal Architect | @ChristopherA | <[email protected]> | FDFE 14A5 4ECB 30FC 5D22 74EF F8D3 6C91 3574 05ED |
| Wolf McNally | Contributor | @WolfMcNally | <[email protected]> | 9436 52EE 3844 1760 C3DC 3536 4B6C 2FCF 8947 80AE |
We want to keep all of our software safe for everyone. If you have discovered a security vulnerability, we appreciate your help in disclosing it to us in a responsible manner. We are unfortunately not able to offer bug bounties at this time.
We do ask that you offer us good faith and use best efforts not to leak information or harm any user, their data, or our developer community. Please give us a reasonable amount of time to fix the issue before you publish it. Do not defraud our users or us in the process of discovery. We promise not to bring legal action against researchers who point out a problem provided they do their best to follow the these guidelines.
Please report suspected security vulnerabilities in private via email to [email protected] (do not use this email for support). Please do NOT create publicly viewable issues for suspected security vulnerabilities.
The following keys may be used to communicate sensitive information to developers:
| Name | Fingerprint |
|---|---|
| Christopher Allen | FDFE 14A5 4ECB 30FC 5D22 74EF F8D3 6C91 3574 05ED |
You can import a key by running the following command with that individual’s fingerprint: gpg --recv-keys "<fingerprint>" Ensure that you put quotes around fingerprints that contain spaces.