48 |
49 | ### Coming Soon
50 |
51 | _We are planning one more UR article in the near future, detailing how to use URs with PSBTs._
52 |
53 | _Please feel free to file an issue if there's more Crypto Commons specifications that you'd like to see with more extensive documents._
54 |
55 | ## #SmartCustody
56 |
57 | #SmartCustody is an initiative meant to help users to safely manage their cryptocurrency and is focused on responsible key management.
58 |
59 | 1. [SmartCustody Book 1.01](https://www.smartcustody.com/)
60 | 1. [Designing Multisig for Independence & Resilience](https://github.com/BlockchainCommons/SmartCustody/blob/master/README.md#the-smartcustody-book)
61 | 1. [Using Timelocks to Protect Digital Assets](https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Timelocks.md)
62 | 1. [Designing SSKR Share Scenarios](https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Sharing.md)
63 | 1. [The Dangers of Secret-Sharing Schemes](https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Dangers.md)
64 |
65 | See [the SmartCustody repo](https://github.com/BlockchainCommons/SmartCustody/blob/master/README.md#the-smartcustody-book) for the most up-to-date listing of docs.
66 |
67 | ## Learning Bitcoin from the Command Line
68 |
69 | Learning Bitcoin is our classic course that introduce Bitcoin concepts and programming beginning with Bitcoin Core's command-line tools and its RPC interface.
70 |
71 | 1. [Learning Bitcoin from the Command Line 2.0](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/README.md)
72 |
--------------------------------------------------------------------------------
/Docs/crypto-request-or-crypto-psbt.md:
--------------------------------------------------------------------------------
1 | # `crypto-request` and `crypto-response` vs Signing via `crypto-psbt`
2 |
3 | ## by Wolf McNally, Christopher Allen, and Shannon Applecline for Blockchain Commons
4 |
5 | ### Introduction
6 |
7 | The Blockchain Commons [Uniform Resource (UR)](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md) technology is designed to make it easy to transmit structured binary data via several methods, including text and QR codes. It addresses the inherent size limits of QR codes by supporting streaming message fragments using fountain codes.
8 |
9 | Blockchain Commons, in cooperation with members of the [airgapped wallet community](https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions), has expanded URs by developing a proposed standard for a UR-based message architecture that can be used as a standard design pattern to request various actions from network-isolated devices (`crypto-request`), and for those devices to respond to those requests (`crypto-response`).
10 |
11 | For the purpose of signing [Partially Signed Bitcoin Transactions (PSBTs)](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki), some developers have chosen to use a bare UR-encoded PSBT (`crypto-psbt`) as a way to request a signature instead of using `crypto-request` and `crypto-response`. This approach, while straightforward, has a number of distinct disadvantages over the request-response pattern that Blockchain Commons has proposed. The purpose of this document is to explain the motivation for the request-response architecture, in order to encourage its universal adoption by the airgapped wallet community.
12 |
13 | ### The Purpose and Limits of PSBTs
14 |
15 | As a tool for handing structured data, each top-level UR has a type. The bare UR-encoded `crypto-psbt`, which represents a single PSBT, is one of those. The intention with PSBTs is that they be generated by one party, and then passed around to one or more other parties for co-signing. The co-signed PSBTs are then passed to another party (which could be the originating party) who finalizes the transaction and produces a fully-signed transaction ready to be transmitted to the Bitcoin network.
16 |
17 | The PSBT specification allows for the inclusion of additional metadata about the transaction such as the identity and derivation paths of the [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) HD keys that must be used to sign the transaction's inputs. PSBTs can also contain user-specified data, but this usage can become problematic if a user attempts to convey complex policies that PSBTs themselves were never designed to handle, such as the creator of the transaction, the intention for the transaction's use, the business rules that are being enforced or that must be enforced by the co-signers, or the motivation that signers should have to actually sign the transaction.
18 |
19 | PSBTs were never meant to convey general business rules of this sort: they are not a mechanism of coordination between parties. Instead, in order to convey higher-level communications between parties, a PSBT may need to be used in conjunction with other structures. That's where the `crypto-request` and `crypto-response` URs come in.
20 |
21 | ### The Need for Higher-Level Conversations
22 |
23 | Any UR type that can be conveyed as a top-level UR (such as `crypto-psbt`) can also be embedded as a CBOR object within a larger object (such as `crypto-request` or `crypto-response`). While Blockchain Commons produced the spec for a `crypto-psbt` type, which presents only a raw PSBT, we also recognized the need to more generally facilitate higher-level conversations between participants. The `crypto-psbt` spec does nothing more than present a transaction that may or may not have some of its inputs signed; it does not carry any semantics about what the recipient should actually *do* with the transaction it receives. While the recipient of a PSBT might assume that its mere receipt implies a request to sign the transaction, we can easily imagine scenarios where the intent of transmitting a PSBT is *not* for it to be signed, but for it to be stored for later retrieval, relayed to another party, validated against some set of business rules, or finalized and transmitted to the network.
24 |
25 | Therefore as a best practice, requests for actions should be explicit between participants. This is similar in nature to other established protocols like HTTP, where a request consists of a both verb and a noun, e.g., `GET https://blockchaincommons.com`. A URL by itself is just a pointer, and as such is ambiguous. PSBTs are similar: by itself, a PSBT is *not* actually a request to sign a transaction; it is merely a transaction in a possibly unsigned and unfinalized state.
26 |
27 | ### The Request-Response Architecture
28 |
29 | This need for clarity was the motivation for Blockchain Commons to create the `crypto-request` and `crypto-response` specifications. These URs are messages designed to facilitate participants' understanding of what they are being asked to do, in workflows that vary in complexity.
30 |
31 | **NOTE:** To avoid terminology confusion with PSBTs and finalized Bitcoin "transactions", in the present document we will resist the urge to call the sending of requests and receiving of responses "transactions between the parties" and shall instead simply refer to them as requests and responses.
32 |
33 | The initial specification for `crypto-request` and `crypto-response` supports three scenarios:
34 |
35 | 1. The requester provides a seed digest, and wishes the responder to reply with the corresponding `crypto-seed`.
36 | 2. The requester provides an HD key fingerprint, derivation path, and type of desired key (private or public), and wishes the responder to reply with the corresponding derived HD key. The fingerprint may also be omitted, in which case the respondant can choose the seed or key from which to perform the specified derivation.
37 | 3. The requester provides a `crypto-psbt`, and wishes the responder to reply with another `crypto-psbt` containing as many output signatures as it can perform.
38 |
39 | The `crypto-request` CBOR object is [currently defined](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2021-001-request.md#cddl-for-request) as follows:
40 |
41 | ```
42 | crypto-request = {
43 | transaction-id: uuid,
44 | body: request-seed / request-hdkey-derivation / request-psbt-signature,
45 | ? description: text ; Text to be displayed to the approving user.
46 | }
47 | ```
48 |
49 | The `crypto-request` structure includes a `transaction-id` field and an optional `description` field. Fields at this level are intended to help facilitate all sorts of requests.
50 |
51 | The purpose of the `transaction-id` is so that transaction producer/coordinators can receive responses to their requests and know that these responses have been generated specifically to service their particular requests, and are not responses to some other request. In general, the sender of a request must not accept a response that does not contain the same `transaction-id` as the one in the request. This may not be necessary for simple, relatively stateless interactions, but could be crucial for more complex ones.
52 |
53 | The purpose of the optional `description` field is to provide an advisory to the human user receiving the request as to its meaning or purpose.
54 |
55 | In the case of a request for a PSBT signature, the `body` field is defined as follows:
56 |
57 | ```
58 | ;
59 | ; Returns the given PSBT with one or more outputs signed.
60 | ;
61 | request-psbt-signature = #6.502({
62 | psbt: crypto-psbt
63 | })
64 | ```
65 |
66 | As you can see, the `body` of a `crypto-request` is an enumerated type that expresses the nature of the request (e.g., "sign this psbt") and the data needed to perform the action (e.g., the PSBT itself). Because this information is being conveyed as structured CBOR data, it also inheres the possibility for future extension: both in the kind of actions that can be requested, and in what data is included as parameters for particular requests.
67 |
68 | The higher-level `crypto-request` structure may thus be extended with other alternatives for the `body` field, and the nested `request-psbt-signature` structure may be extended with additional fields that specify, for example, additional validations to be performed or additional business rules to be enforced. Extending the existing structures would involve identifying use-case scenarios that the community would find useful, specifying additional fields and/or semantics to be added to the existing specifications, and updating reference implementations to support those extensions, including ensuring backward compatibility.
69 |
70 | ### The Future
71 |
72 | Given the structured nature of CBOR, future request types could even contain sub-requests of their own, enabling multi-level scenarios. The simplest practical use of this capability would be to specify an extension to `crypto-request` that supports the ability to encapsulate several sub-requests to be performed by the receiver and returned in a single `crypto-response`.
73 |
74 | The purpose for this generality is so that Blockchain Commons can work with the larger community to build the extensions needed to work with emergent scenarios, and to standardize on solutions that meet the greatest shared needs. Please consider how this general design pattern might fulfill your own needs for higher-level communications associated with Bitcoin transactions, and talk to us about how the design pattern might best be utilized for your purposes.
75 |
76 | ### The Need to Adopt Now
77 |
78 | Taken together, `crypto-request` and `crypto-response` provide a powerful general architecture for facilitating multi-party, multi-way conversations. It was never the intent of Blockchain Commons that `crypto-psbt` was to be used a signing request, but rather as a more general component in larger scenarios. The present particular need for requesting signatures on PSBTs and returning signed PSBTs is a use-case for early adoption of the request-response framework in the airgapped wallet community. It can and will be extended. Blockchain Commons strongly recommends that airgapped wallet providers support `crypto-request` and `crypto-response` out of the box, and not rely on more ambiguous and less future-proof methods.
79 |
--------------------------------------------------------------------------------
/Docs/crypto-request-test-vectors.md:
--------------------------------------------------------------------------------
1 | # `crypto-request` Test Vectors
2 |
3 | _**Deprecated.** crypto-requests are being replaced with Envelopes in newer reference apps._
4 |
5 | ## `crypto-hdkey` Requests
6 |
7 | ### Requests for Key Derivations from Any Seed
8 |
9 | When requesting a specific HD key derivation from a user-selected seed (tag 501), the body of the `crypto-request` has two elements of note: whether the key is private (1) and what the derivation path is (2).
10 | ```
11 | 2: 501({
12 | 1: false,
13 | 2: 304({
14 | 1: [84, true, 0, true, 0, true]
15 | })
16 | })
17 | ```
18 | The above requests a public key from `84'/0'/0'` (the Segwith single-sig derivation).
19 |
20 | #### Cosigner (`48'/0'/0'/2'`) Public Key
21 |
22 | 
23 |
24 | _AKA Segwit Multsig Public Key_
25 |
26 | ```
27 | {
28 | 1: 37(h'36ED0A7280A04AF98C8030F39871B6EA'),
29 | 2: 501({
30 | 1: false,
31 | 2: 304({
32 | 1: [48, true, 0, true, 0, true, 2, true]
33 | })
34 | })
35 | }
36 | ```
37 |
38 | ```
39 | ur:crypto-request/oeadtpdagdenwebkjplanbgeytlkladywfmkjsrpwdaotaadykoeadwkaotaaddyoyadlocsdyykaeykaeykaoykynurjomh
40 | ```
41 |
42 | #### Cosigner (`48'/0'/0'/2'`) Private Key
43 |
44 | 
45 |
46 | _AKA Segwit Multsig Private Key_
47 |
48 | ```
49 | {
50 | 1: 37(h'36ED0A7280A04AF98C8030F39871B6EA'),
51 | 2: 501({
52 | 1: true,
53 | 2: 304({
54 | 1: [48, true, 0, true, 0, true, 2, true]
55 | })
56 | })
57 | }
58 | ```
59 |
60 | ```
61 | ur:crypto-request/oeadtpdagdenwebkjplanbgeytlkladywfmkjsrpwdaotaadykoeadykaotaaddyoyadlocsdyykaeykaeykaoykjskkrkte
62 | ```
63 |
64 | #### Master Public Key
65 |
66 | 
67 |
68 | ```
69 | {
70 | 1: 37(h'36ED0A7280A04AF98C8030F39871B6EA'),
71 | 2: 501({
72 | 1: false,
73 | 2: 304({
74 | 1: []
75 | })
76 | })
77 | }
78 | ```
79 |
80 | ```
81 | ur:crypto-request/oeadtpdagdenwebkjplanbgeytlkladywfmkjsrpwdaotaadykoeadwkaotaaddyoyadlavdhfhnhp
82 | ```
83 |
84 | #### Master Private Key
85 |
86 | 
87 |
88 |
89 | ```
90 | {
91 | 1: 37(h'36ED0A7280A04AF98C8030F39871B6EA'),
92 | 2: 501({
93 | 1: true,
94 | 2: 304({
95 | 1: []
96 | })
97 | })
98 | }
99 | ```
100 |
101 | ```
102 | ur:crypto-request/oeadtpdagdynlremcyyttdfehdnsctctlomnstrlotaotaadykoeadwkaotaaddyoyadlncsghykaeykaeykaeuolywf
103 | ```
104 |
105 | #### Segwit Single Sig (`84'/0'/0'`) Public Key
106 |
107 | 
108 |
109 | ```
110 | {
111 | 1: 37(h'f684371af9d245589c1f1f888ec7b7a3'),
112 | 2: 501({
113 | 1: false,
114 | 2: 304({
115 | 1: [84, true, 0, true, 0, true]
116 | })
117 | })
118 | }
119 | ```
120 |
121 | ```
122 | ur:crypto-request/oeadtpdagdynlremcyyttdfehdnsctctlomnstrlotaotaadykoeadwkaotaaddyoyadlncsghykaeykaeykaeuolywf
123 | ```
124 |
125 | #### Segwit Single Sig (`84'/0'/0'`) Private Key
126 |
127 | 
128 |
129 | ```
130 | {
131 | 1: 37(h'36ED0A7280A04AF98C8030F39871B6EA'),
132 | 2: 501({
133 | 1: true,
134 | 2: 304({
135 | 1: [84, true, 0, true, 0, true]
136 | })
137 | })
138 | }
139 | ```
140 |
141 | ```
142 | ur:crypto-request/oeadtpdagdenwebkjplanbgeytlkladywfmkjsrpwdaotaadykoeadykaotaaddyoyadlncsghykaeykaeykbkatbncl
143 | ```
144 |
145 | ### Requests for Key Derivations from Any Seed with Comment
146 |
147 | Adding a comment to a request for a general key derivation simply requires adding a description, which is element 3 of the `crypto-request`. It should be displayed by the recipient, but it should not be used in any response
148 | ```
149 | 3: "Watch-only key to create ACME Multisig."
150 | ```
151 | The above adds the listed comment to a `crypto-request`.
152 |
153 | Reviewing a comment can help a user to determine if a request is clearly legitimate (or clearly fradulent).
154 |
155 | #### Cosigner (`48'/0'/0'/2'`) Public Key
156 |
157 | 
158 |
159 | _AKA Segwit Multsig Public Key_
160 |
161 | ```
162 | {
163 | 1: 37(h'F94ADE8D3843486180CC9B4D37F70724'),
164 | 2: 501({
165 | 1: false,
166 | 2: 304({
167 | 1: [48, true, 0, true, 0, true, 2, true]
168 | })
169 | }),
170 | 3: "Watch-only key to create ACME Multisig."
171 | }
172 | ```
173 |
174 | ```
175 | ur:crypto-request/otadtpdagdytgeuelgetfxfdhslasfndgtemylatdkaotaadykoeadwkaotaaddyoyadlocsdyykaeykaeykaoykaxksdihghsjyiaisdpjljtjzkkcxjeihkkcxjyjlcxiajpihhsjyihcxfpfxgtfecxgtkpjzjyinjkiniodmtddydeiy
176 | ```
177 |
178 | #### Cosigner (`48'/0'/0'/2'`) Private Key
179 |
180 | 
181 |
182 | _AKA Segwit Multsig Private Key_
183 |
184 | ```
185 | {
186 | 1: 37(h'03B0CB4C54C143E89E6D137FC56C41D6'),
187 | 2: 501({
188 | 1: true,
189 | 2: 304({
190 | 1: [48, true, 0, true, 0, true, 2, true]
191 | })
192 | }),
193 | 3: "Please give over private key for usage in real multisig."
194 | }
195 | ```
196 | ```
197 | ur:crypto-request/otadtpdagdaxpfsbgsghsefxvsnnjnbwlbskjzfptbaotaadykoeadykaotaaddyoyadlocsdyykaeykaeykaoykaxksetgdjzihhsjkihcxioinkoihcxjlkoihjpcxjojpinkohsjyihcxjeihkkcxiyjljpcxkpjkhsioihcxinjtcxjpihhsjzcxjnkpjzjyinjkiniodmasgefpwf
198 | ```
199 |
200 | #### Master Public Key
201 |
202 | 
203 |
204 | ```
205 | {
206 | 1: 37(h'84D22FD40EA74968993B9BDCF2CC00F3'),
207 | 2: 501({
208 | 1: false,
209 | 2: 304({
210 | 1: []
211 | })
212 | }),
213 | 3: "Master public key for watch-only wallet on Sparrow."
214 | }
215 | ```
216 |
217 | ```
218 | ur:crypto-request/otadtpdagdlrtddltybaosgaisnlfrnduowzsfaewfaotaadykoeadwkaotaaddyoyadlaaxkseogthsjkjyihjpcxjokpidjziniacxjeihkkcxiyjljpcxkthsjyiaisdpjljtjzkkcxkthsjzjzihjycxjljtcxgujohsjpjpjlktdmbgfrdaon
219 | ```
220 |
221 | #### Master Private Key
222 |
223 | 
224 |
225 |
226 | ```
227 | {
228 | 1: 37(h'389C3AA302C14088B21D4425B77B6450'),
229 | 2: 501({
230 | 1: true,
231 | 2: 304({
232 | 1: []
233 | })
234 | }),
235 | 3: "Transfer master key to Electrum for online usage."
236 | }
237 | ```
238 |
239 | ```
240 | ur:crypto-request/otadtpdagdetnsftotaosefzloprcafydarlkgiegdaotaadykoeadykaotaaddyoyadlaaxksehghjphsjtjkiyihjpcxjnhsjkjyihjpcxjeihkkcxjyjlcxfejzihiajyjpkpjncxiyjljpcxjljtjzinjtihcxkpjkhsioihdmkiaamows
241 | ```
242 | #### Segwit Single Sig (`84'/0'/0'`) Public Key
243 |
244 | 
245 |
246 | ```
247 | {
248 | 1: 37(h'601FDC4EE38841898D6DA3CEF9E855CE'),
249 | 2: 501({
250 | 1: false,
251 | 2: 304({
252 | 1: [84, true, 0, true, 0, true]
253 | })
254 | }),
255 | 3: "Creating single-sig watch-only wallet on Sparrow."
256 | }
257 | ```
258 | ```
259 | ur:crypto-request/otadtpdagdhnctuoglvllofpldlgjnottoytvsgotoaotaadykoeadwkaotaaddyoyadlncsghykaeykaeykaxksehfxjpihhsjyinjtiocxjkinjtiojzihdpjkiniocxkthsjyiaisdpjljtjzkkcxkthsjzjzihjycxjljtcxgujohsjpjpjlktdmjyskeshk
260 | ```
261 |
262 | #### Segwit Single Sig (`84'/0'/0'`) Private Key
263 |
264 | 
265 |
266 | ```
267 | {
268 | 1: 37(h'5C99BB444C354B659D58BC2299C47032'),
269 | 2: 501({
270 | 1: true,
271 | 2: 304({
272 | 1: [84, true, 0, true, 0, true]
273 | })
274 | }),
275 | 3: "We are withholding your arrest for one more day. This is your last chance to prove your identity by sending your private key. Police sherriffs will be on their way otherwise. Do naught delay!"
276 | }
277 | ```
278 |
279 | ```
280 | ur:crypto-request/otadtpdagdhhnlrkfygsecgrihnthdrfcpnlssjoeyaotaadykoeadykaotaaddyoyadlncsghykaeykaeykaxksrshgihcxhsjpihcxktinjyisisjljzieinjtiocxkkjlkpjpcxhsjpjpihjkjycxiyjljpcxjljtihcxjnjljpihcxiehskkdmcxghisinjkcxinjkcxkkjlkpjpcxjzhsjkjycxiaishsjtiaihcxjyjlcxjojpjlkoihcxkkjlkpjpcxinieihjtjyinjykkcxidkkcxjkihjtieinjtiocxkkjlkpjpcxjojpinkohsjyihcxjeihkkdmcxgdjljziniaihcxjkisihjpjpiniyiyjkcxktinjzjzcxidihcxjljtcxjyisihinjpcxkthskkcxjljyisihjpktinjkihdmcxfyjlcxjthskpioisjycxieihjzhskkclleskzohd
281 | ```
282 |
283 | ## `crypto-seed` Requests
284 |
285 | ### Sample Seed: Yinmn Blue
286 |
287 | 
288 |
289 | The above seed, Yinmn Blue, or `59f2293a5bce7d4de59e71b4207ac5d2`, is used for the following examples. See [the crypto-seed test vectors](https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/crypto-seed-test-vectors.md).
290 |
291 | `crypto-seeds` can be specifically requested by sending a `crypto-request` body that contains a typed 500 seed-digest for the seeds. This is the SHA256 of the seed, which can be calculated by programs such as `shasum`:
292 | ```
293 | $ echo '59f2293a5bce7d4de59e71b4207ac5d2' | xxd -r -p | shasum -a 256
294 | ffa11a8b90954fc89ae625779ca11b8f0227573a2f8b4ed85d96ddf901a72cea -
295 | ```
296 | This digest would then be listed as the first and only entry of the 500-encoded map:
297 | ```
298 | 2: 500({
299 | 1: 600(h'ffa11a8b90954fc89ae625779ca11b8f0227573a2f8b4ed85d96ddf901a72cea')
300 | })
301 |
302 | ```
303 |
304 | ### Seed-Digest Request for Yinmn Blue
305 |
306 | 
307 |
308 | ```
309 | {
310 | 1: 37(h'3CB81644ADA44ECB9DDFA285C14FA877'),
311 | 2: 500({
312 | 1: 600(h'ffa11a8b90954fc89ae625779ca11b8f0227573a2f8b4ed85d96ddf901a72cea')
313 | })
314 | }
315 | ```
316 |
317 | ```
318 | ur:crypto-request/oeadtpdagdfnrocmfypmoxglsbnturoelpsegwpdktaotaadwkoyadtaaohdhdcxzmoycylumhmdgwspnyvadaktnsoycwmyaodihgftdllugltphlmtutytadosdwwdetjsdwwt
319 | ```
320 |
321 | ### Seed-Digest Request for Yinmn Blue with Comment
322 |
323 | 
324 | ```
325 | {
326 | 1: 37(h'3CB81644ADA44ECB9DDFA285C14FA877'),
327 | 2: 500({
328 | 1: 600(h'ffa11a8b90954fc89ae625779ca11b8f0227573a2f8b4ed85d96ddf901a72cea')
329 | }),
330 | 3: "Seed request by ACME Exchange."
331 | }
332 | ```
333 | ```
334 | ur:crypto-request/oeadtpdagdenwebkjplanbgeytlkladywfmkjsrpwdaotaadykoeadwkaotaaddyoyadlocsdyykaeykaeykaoykynurjomh
335 | ```
336 |
337 | ### Sample Seed: Khaki
338 |
339 | See [the crypto-seed test vectors](https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/crypto-seed-test-vectors.md) for our 256-bit test seed, Khaki.
340 |
341 | ```
342 | $ echo 'e3955cda304771c0031895637f55c3abe45153c87abd81c51ed14e8aafa1af13' | xxd -r -p | shasum -a 256
343 | 8b206fb05be13485e7e39f8fdba045ce01c98cf42b6687b083e71ae9739d3609 -
344 | ```
345 |
346 | ### Seed-Digest Request for Khaki
347 |
348 | 
349 |
350 | ```
351 | {
352 | 1: 37(h'3CB81644ADA44ECB9DDFA285C14FA877'),
353 | 2: 500({
354 | 1: 600(h'8b206fb05be13485e7e39f8fdba045ce01c98cf42b6687b083e71ae9739d3609')
355 | })
356 | }
357 | ```
358 |
359 | ```
360 | ur:crypto-request/oeadtpdagdfnrocmfypmoxglsbnturoelpsegwpdktaotaadwkoyadtaaohdhdcxzmoycylumhmdgwspnyvadaktnsoycwmyaodihgftdllugltphlmtutytadosdwwdetjsdwwt
361 | ``
362 | ## `crypto-psbt` Requests
363 |
364 | To test a PSBT:
365 |
366 | 1. [Add Alice seed](https://github.com/BlockchainCommons/GordianSeedTool-iOS/blob/master/Testing/PSBT%20Signing%20Request/Alice.pdf)
367 | 2. [Add Bob seed](https://github.com/BlockchainCommons/GordianSeedTool-iOS/blob/master/Testing/PSBT%20Signing%20Request/Bob.pdf)
368 | 3. [Test Alice signing](https://raw.githubusercontent.com/BlockchainCommons/GordianSeedTool-iOS/master/Testing/PSBT%20Signing%20Request/PSBT%20Signing%20Request%201%20of%202.png)
369 | 4. [Test Both signing](https://raw.githubusercontent.com/BlockchainCommons/GordianSeedTool-iOS/master/Testing/PSBT%20Signing%20Request/PSBT%20Signing%20Request%201%20of%202.png)
370 |
371 | ## Appendix: Standard Process for Creating Test Vectors:
372 |
373 | The following process, which can be used for all test vector creation, using a `crypto-request` of a `crypto-hdkey` as an example.
374 |
375 | 1. Produce a UUID
376 | ```
377 | $ uuidgen | sed s/-//g
378 | BD4CD51356B248D8A04C3609F5A737FA
379 | ```
380 | 2. Write the JSON vector using [BCR-2021-001](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2021-001-request.md) as reference. Place the UUID in map element #1 and any description in map element #3. Map element #2, the body, will vary based on the type of Request.
381 | ```
382 | {
383 | 1: 37(h'f684371af9d245589c1f1f888ec7b7a3'),
384 | 2: 501({
385 | 1: false,
386 | 2: 304({
387 | 1: [84, true, 0, true, 0, true]
388 | })
389 | })
390 | }
391 | ```
392 | 3. Encode the JSON with [CBOR Playground](https://cbor.me/). First test it with full description, then check "plain text" to just produce the hex.
393 | ```
394 | A201D82550F684371AF9D245589C1F1F888EC7B7A302D901F5A201F402D90130A101861854F500F500F5
395 | ```
396 | 4. Use `bytewords` with `hex` input and `minimal` output to produce the UR body.
397 | ```
398 | bytewords -i hex -o minimal A201D82550F684371AF9D245589C1F1F888EC7B7A302D901F5A201F402D90130A101861854F500F500F5
399 | oeadtpdagdynlremcyyttdfehdnsctctlomnstrlotaotaadykoeadwkaotaaddyoyadlncsghykaeykaeykaeuolywf
400 | ```
401 | 5. Add `ur:crypto-request/` as a prefix.
402 | ```
403 | ur:crypto-request/oeadtpdagdynlremcyyttdfehdnsctctlomnstrlotaotaadykoeadwkaotaaddyoyadlncsghykaeykaeykaeuolywf
404 | ```
405 | 6. Encode the `crypto-request` as a QR. Be sure to capitalize to maximize efficiency of QR.
406 | ```
407 | echo "ur:crypto-request/oeadtpdagdynlremcyyttdfehdnsctctlomnstrlotaotaadykoeadwkaotaaddyoyadlncsghykaeykaeykaeuolywf" | tr '[:lower:]' '[:upper:]' | qrencode -o ~/vector-segwit-single-pubkey.png
408 | ```
409 | ## TODO
410 |
411 | 2. Six (or twelve?) crypto-requests for hdkey from specific seed
412 | 3. Import and Export Yimn Blue
413 | 4. Import and Export Khaki
414 | 5. PSBT Test
415 |
416 |
--------------------------------------------------------------------------------
/Docs/crypto-seed-test-vectors.md:
--------------------------------------------------------------------------------
1 | # `crypto-seed` Test Vectors
2 |
3 | * [128 Bit Examples (Yinmn Blue)](#128-bit-examples-yinmn-blue)
4 | * [256 Bit Examples (Khaki)](#256-bit-examples-khaki)
5 |
6 | ## 128 Bit Examples (Yinmn Blue)
7 |
8 | 
9 |
10 | ### Seed with No Additional Data
11 |
12 | 
13 |
14 | ```
15 | {
16 | 1: h'59f2293a5bce7d4de59e71b4207ac5d2'
17 | }
18 | ```
19 |
20 | ### Seed with Date
21 |
22 | 
23 |
24 | ```
25 | {
26 | 1: h'59f2293a5bce7d4de59e71b4207ac5d2',
27 | 2: 1(1645539742)
28 | }
29 | ```
30 |
31 | ### Seed with Date & Name
32 |
33 | 
34 |
35 | ```
36 | {
37 | 1: h'59f2293a5bce7d4de59e71b4207ac5d2',
38 | 2: 1(1645539742),
39 | 3: "Yinmn Blue Acid Exam"
40 | }
41 | ```
42 |
43 | ### Seed with Date, Name & Note
44 |
45 | 
46 |
47 | ```
48 | {
49 | 1: h'59f2293a5bce7d4de59e71b4207ac5d2',
50 | 2: 1(1645539742),
51 | 3: "Yinmn Blue Acid Exam",
52 | 4: "This is our standard 128-bit test seed."
53 | }
54 | ```
55 |
56 | ### Seed with Date, Name & Long Note
57 |
58 | **Static Version:**
59 |
60 | 
61 |
62 | **Animated Version:**
63 |
64 | [pending]
65 |
66 | ```
67 | {
68 | 1: h'59f2293a5bce7d4de59e71b4207ac5d2',
69 | 2: 1(1645539742),
70 | 3: "Yinmn Blue Acid Exam",
71 | 4: "This is our standard 128-bit test seed. However, this version of it has a very long note. Why? The object is to force the creation of an animated GIF, which demonstrates the power of URs, not just to allow for the self-identification of information, but also to do so in a way the integrates well with QR codes, creating an animated QR when the data would otherwise be too long for a static QR. To force that to happen, this note was made to be over 500 characters long, which is a lot of data for a QR, which maxes out at about 4,000 alphanumeric characters, but which gets very hard to read (especially from a phone) before that."
72 | }
73 | ```
74 |
75 | ## 256 Bit Examples (Khaki)
76 |
77 | 
78 |
79 | ### Seed with No Additional Data
80 |
81 | 
82 |
83 | ```
84 | {
85 | 1: h'e3955cda304771c0031895637f55c3abe45153c87abd81c51ed14e8aafa1af13'
86 | }
87 | ```
88 |
89 | ### Seed with Date
90 |
91 | 
92 |
93 | ```
94 | {
95 | 1: h'e3955cda304771c0031895637f55c3abe45153c87abd81c51ed14e8aafa1af13',
96 | 2: 1(1645539742)
97 | }
98 | ```
99 | ### Seed with Date & Name
100 |
101 | 
102 |
103 | ```
104 | {
105 | 1: h'e3955cda304771c0031895637f55c3abe45153c87abd81c51ed14e8aafa1af13',
106 | 2: 1(1645539742),
107 | 3: "Khaki Gala Jazz"
108 | }
109 | ```
110 |
111 | ### Seed with Date, Name & Note
112 |
113 | 
114 |
115 | ```
116 | {
117 | 1: h'e3955cda304771c0031895637f55c3abe45153c87abd81c51ed14e8aafa1af13',
118 | 2: 1(1645539742),
119 | 3: "Khaki Gala Jazz",
120 | 4: "This is our standard 256-bit test seed."
121 | }
122 | ```
123 |
124 | ### Seed with Date, Name & Long Note
125 |
126 | **Static Version:**
127 |
128 | 
129 |
130 | **Animated Version:**
131 |
132 | [pending]
133 |
134 | ```
135 | {
136 | 1: h'e3955cda304771c0031895637f55c3abe45153c87abd81c51ed14e8aafa1af13',
137 | 2: 1(1645539742),
138 | 3: "Khaki Gala Jazz",
139 | 4: "This is our standard 256-bit test seed. However, this version of it has a very long note. Why? The object is to force the creation of an animated GIF, which demonstrates the power of URs, not just to allow for the self-identification of information, but also to do so in a way the integrates well with QR codes, creating an animated QR when the data would otherwise be too long for a static QR. To force that to happen, this note was made to be over 500 characters long, which is a lot of data for a QR, which maxes out at about 4,000 alphanumeric characters, but which gets very hard to read (especially from a phone) before that."
140 | }
141 | ```
142 |
143 | ## Crypto-Seed Requests
144 |
145 | For example requests for these seeds, see the [crypto-requests test vectors](https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/crypto-request-test-vectors.md#crypto-seed-requests).
146 |
147 | ## Appendix: Standard Process for Creating Test Vectors:
148 |
149 | The following process, which can be used for all test vector creation, using a detailed `crypto-seed` as an example.
150 |
151 | 1. Write the JSON vector using [BCR-2020-006](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-006-urtypes.md#cryptographic-seed-crypto-seed) as reference. Place the hex seed in map element #1, and then optionally place a creation date in element #2, a name in element #3, and a note in element #4.
152 | ```
153 | {
154 | 1: h'59f2293a5bce7d4de59e71b4207ac5d2',
155 | 2: 1(1645539742),
156 | 3: "Yinmn Blue Acid Exam",
157 | 4: "This is our standard 128-bit test seed."
158 | }
159 | ```
160 | 2. Encode the JSON with [CBOR Playground](https://cbor.me/). First test it with full description, then check "plain text" to just produce the hex.
161 | ```
162 | A4015059F2293A5BCE7D4DE59E71B4207AC5D202C11A6214F19E037459696E6D6E20426C75652041636964204578616D04782754686973206973206F7572207374616E64617264203132382D626974207465737420736565642E
163 | ```
164 | 3. Use `bytewords` with `hex` input and `minimal` output to produce the UR body.
165 | ```
166 | bytewords -i hex -o minimal A4015059F2293A5BCE7D4DE59E71B4207AC5D202C11A6214F19E037459696E6D6E20426C75652041636964204578616D04782754686973206973206F7572207374616E64617264203132382D626974207465737420736565642E
167 | oxadgdhkwzdtfthptokigtvwnnjsqzcxknsktdaosecyidbbwnnnaxjyhkinjtjnjtcxfwjzkpihcxfpiainiecxfekshsjnaaksdighisinjkcxinjkcxjlkpjpcxjkjyhsjtiehsjpiecxeheyetdpidinjycxjyihjkjycxjkihihiedmksjpaate
168 | ```
169 | 4. Add `ur:crypto-seed/` as a prefix.
170 | ```
171 | ur:crypto-seed/oxadgdhkwzdtfthptokigtvwnnjsqzcxknsktdaosecyidbbwnnnaxjyhkinjtjnjtcxfwjzkpihcxfpiainiecxfekshsjnaaksdighisinjkcxinjkcxjlkpjpcxjkjyhsjtiehsjpiecxeheyetdpidinjycxjyihjkjycxjkihihiedmksjpaate
172 | ```
173 | 5. Encode the `crypto-request` as a QR.
174 | ```
175 | echo "ur:crypto-seed/oxadgdhkwzdtfthptokigtvwnnjsqzcxknsktdaosecyidbbwnnnaxjyhkinjtjnjtcxfwjzkpihcxfpiainiecxfekshsjnaaksdighisinjkcxinjkcxjlkpjpcxjkjyhsjtiehsjpiecxeheyetdpidinjycxjyihjkjycxjkihihiedmksjpaate" | qrencode -o ~/vector-seed-yinmn-note.png
176 | ```
177 |
178 |
--------------------------------------------------------------------------------
/Docs/key-derivations.md:
--------------------------------------------------------------------------------
1 | # Key Derivations
2 |
3 | We use the following names for common key derivations:
4 |
5 | ```
6 | Native Segwit Single Key
7 | wpkh(84'/0'/0')
8 |
9 | Native Segwit Multisig
10 | wsh(cosigner(48'/0'/0'/2'))
11 |
12 | Nested Segwit Single Key
13 | sh(wpkh(49'/0'/0'))
14 |
15 | Nested Segwit Multisig
16 | sh(wsh(cosigner(48'/0'/0'/1')))
17 |
18 | Legacy Single Key
19 | pkh(44'/0'/0')
20 |
21 | Legacy Multisig
22 | sh(cosigner(45'))
23 |
24 | Taproot Single Key
25 | tr(86'/0'/0')
26 | ```
27 |
--------------------------------------------------------------------------------
/Docs/sskr-cold-storage.md:
--------------------------------------------------------------------------------
1 | # SSKR Cold Storage
2 |
3 | [Smart Custody](https://www.smartcustody.com/), Blockchain Commons' 2019 guide to best practices for key management, suggests maintaining copies of keys etched in metal. Though SSKR can produced a much larger set of words, it can still be managed. Ken Sedgwick demonstrated one way to do so using dogtags and the [test vector](sskr-test-vector.md).
4 |
5 | His complete method requires the following shopping list (with two different options for the military embossing machine):
6 | https://gist.github.com/ksedgwic/d4d34cab504ac453eaf2a3656f86e2f6#file-dogtag-parts-md
7 |
8 | The overall procedure is simple:
9 |
10 | 1. Print out your SSKR as a guide.
11 | 2. Optionally, print a [new sheet](https://gist.github.com/ksedgwic/ce28cedd58b40fdb6522c905c07655e4) to divide each SSKR into two parts.
12 | 3. Emboss each share onto a pair of tags using the machine.
13 |
14 | 
15 |
16 | You could stop there, but Ken suggests additional security:
17 |
18 | 4. Bolt each pair of tags against a blank tag to make them unreadable.
19 | 5. Dip each set of bolted tags in black plasti dip to bind them together.
20 | 6. Cover the edges of the dip with glitter to form a unique pattern that can't be replicated.
21 | 7. Photograph the patterns so that you can later test if the tags have been opened up.
22 |
23 | 
24 |
25 | Ken [has more photographs](https://photos.google.com/share/AF1QipMdrblk43sLJQeeMAcrT6AH9r9Peb9kENyAF6aflZbQD5Bqbyi8zSLegHg5akUYYg?key=WlJVd3ZLakI2Y0NoSnFiRkE1RjFCWks5Zjl0U1BB) of the entire procedure.
26 |
--------------------------------------------------------------------------------
/Docs/sskr-developers.md:
--------------------------------------------------------------------------------
1 | # SSKR for Developers
2 |
3 | SSKR is Sharded Secret Key Reconstruction. It's a methodology for secret sharing
4 | that allows for the sharding of a master seed into multiple shares, which may then be combined with a certain threshold to reconstruct that secret. Major expansions of the SSKR specification over previous standards include:
5 |
6 | 1. Compatibility with BIP-39.
7 | 2. Implementation of two-level shares.
8 | 3. Encoding of shares as ByteWords.
9 | 4. Integration with URs.
10 |
11 | Currently, SSKR supports one secret-sharing algorithm: Shamir's Secret Sharing, which is version `0` of SSKR types. As such, it's intended to replace SLIP-39 as a specification for Shamir's Secret Sharing.
12 |
13 | ## Where Can I Find SSKR?
14 |
15 | **Specification:**
16 |
17 | SSKR is described in a Blockchain Commons research paper.
18 |
19 | * [BCR-0011: UR Type Definition for Sharded Secret Key Reconstruction (SSKR)](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-011-sskr.md)
20 |
21 | **Code Libraries:**
22 |
23 | The core of SSKR is in the `bc-sskr` library:
24 |
25 | * [bc-sskr](https://github.com/blockchaincommons/bc-sskr) (C library)
26 |
27 | However, SSKR was built with a modular design allowing developers to choose both the underlying secret sharing and the encoding that they use.
28 |
29 | The Shamir's Secret Sharing used by default with SSKR is found in the `bc-shamir` library, which is supported by the `bc-crypto-base` library:
30 |
31 | * [bc-crypto-base](https://github.com/blockchaincommons/bc-crypto-base) (C library)
32 | * [bc-shamir](https://github.com/blockchaincommons/bc-shamir) (C library)
33 |
34 | SSKR's default encoding method is ByteWords, which is available in the `bc-bytewords` library:
35 |
36 | * [bc-bytewords](https://github.com/BlockchainCommons/bc-bytewords) (C library)
37 |
38 | Many of these libraries are available in the following conversions:
39 |
40 | * [bc-libs-java](https://github.com/BlockchainCommons/bc-libs-java) (Java library for crypto-base, shamir, sskr, and bytewords)
41 | * [BCLibsSwift](https://github.com/BlockchainCommons/BCLibsSwift) (Swift library for crypto-base, shamir, and sskr)
42 |
43 | **Sample Code:**
44 |
45 | The following applications demonstrate the usage of SSKR:
46 |
47 | * [Gordian SeedTool](https://github.com/BlockchainCommons/GordianSeedTool-iOS) (app implementation)
48 | * [LetheKit](https://github.com/BlockchainCommons/bc-lethekit) (hardware implementation)
49 | * [SeedTool CLI](https://github.com/BlockchainCommons/bc-seedtool-cli) (CLI implementation)
50 |
51 | ## How Do I Use SSKR?
52 |
53 | SSKR allows you to protect a 32-byte seed. You will also need to think about a few other things when utilizing SSKR:
54 |
55 | * The seed being encrypted must be truly random, with high entropy.
56 | * The shares are non-deterministic due to a random factor in their creation. This means that shares will look different every time you generate them.
57 | * If you need to protect more than 32 bytes, you will need to either create muktiple SSKR objects or else encrypt the additional data using the 32-byte value being protected by SSKR as an encryption key.
58 |
59 | The last point is particularly notable because multilayered encryption of this type is required to protect a standard BIP-32 HD wallet, which is typically built with a 32-byte private key and its 32-byte chain code; it is also necessary to preserve metadata related to any 32-byte key. It may also be required in other situations where more than 32 bytes are being preserved for later reconstruction.
60 |
61 | ## Why Use Shamir's Secret Sharing?
62 |
63 | Shamir's Secret Sharing (SSS) is built on an old, well-respected cryptographic proof, and so we have faith in its foundational concepts.
64 |
65 | Though we believe that [the usage of multisig](https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Multisig.md) is superior to SSS, because Shamir's Secret Sharing can expose the user to vulnerability on the machine where a key is reconstructed, we nonetheless acknowledge that many users prefer Shamir's Secret Sharing, in large part for compatibility with last-generation single-signature addresses.
66 |
67 | So, while we're leading the way in using multisig to better protect our digital wealth, we're also interested in improving the interoperability of resilient, single-signature addresses, and that primarily means improving the interoperability of Shamir's Secret Sharing.
68 |
69 | ## What are Two-Level Shares?
70 |
71 | Using SSKR, you can implement Shamir's Secret Sharing as normal, using a group of shares with a threshold for reconstruction. However, you can also implement a two-level hierarchy with multiple groups, each of which contain some shares. You can then specify a threshold for both groups and shares.
72 |
73 | For example, you could create shares for 2 groups: the first group might require 2 of 3 shares and the second group might require 3 of 5 shares. With a group threshold of 2, individual thresholds from both groups must be met.
74 |
75 | ## What are ByteWords?
76 |
77 | SSKR shares can be output as [Bytewords](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-012-bytewords.md), which is a specification for outputting encoded binary data as English words. We purposefully differentiated it from the BIP-39 mnemonics to avoid confusion: we wanted to make it obvious that the shares were SSKR, as evidenced by the ByteWords encoding, as opposed to SLIP-39, which would use BIP-39 encoding.
78 |
79 | ByteWords also has several advantages. It's as efficient as hex, the words are all a uniform four letters, there are no homophones, and the first and last characters of each word differ from other words. Words were also specifically chosen to either be concrete or else to have valence. All around, the goal was to make ByteWords very easy to distinguish.
80 |
81 | ## What are URs?
82 |
83 | URs are [Uniform Resources](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md), another Blockchain Commons specification. They describe a methodology for efficient, self-describing resources, and are easily interoperable with ByteWords. We choose them as another output format for SSKR.
84 |
85 | See [A Guide to Using URs for SSKRs](ur-3-sskrs.md) for how ByteWord SSKRs and UR SSKRs are encoded, and how they slightly differ.
86 |
87 | ## Why Did We Create a New Standard?
88 |
89 | We are well aware of the problems of creating yet more standards, as depicted by the ever-insightful Randall Munroe:
90 |
91 | 
92 |
93 | In the case of SSKR we felt that the creation of a new specification for Shamir's Secret Sharing was critical due to problems that we identified with the previous implementations, primarily SLIP-39, which we discovered [did not round trip with BIP-39](https://github.com/BlockchainCommons/bc-lethekit/issues/38).
94 |
95 | The result is SSKR, which is similar to SLIP-39, but not compatible. It includes the same Shamir's Secret Sharing technology, but uses a different key-derivation methodology, for compatibility with BIP-39.
96 |
97 | Seeing the need for a new specification that roundtripped with BIP-39 also allowed the possibility for expansion, which permitted us to introduce two-level shares as a major new feature.
98 |
99 | ## Why Did We Create New Libraries?
100 |
101 | Obviously, with a new specification, we also needed libraries for that specification. We created C reference libraries for SSS and SSKR and modularizing the contents to allow a developer to pick and choose how they were put together. These libraries were later converted to Java, then our [contributing sponsor Bitmark](https://bitmark.com/) converted them to Swift.
102 |
103 | Our new libraries also resolve one of our long-standing problems with SSS: we've always felt that Shamir's Secret Sharing looked deceptively easy to code, which has resulted in more than one implementation incorporating fundamental problems, from the lack of round-tripping in SLIP-39, to incorrect use of entropy in other implementations. Thus, we were happy to offer our own implementation, building on the cryptographic expertise of Blockchain Commons members and other experts in the field such as Daan Sprenkels.
104 |
105 | ## What is the Foundation of SSKR?
106 |
107 | SSKR is the end-result of over two years of effort. It most immediately grew out of workgroups at the Rebooting the Web of Trust design workshops. At [RWOT8 in Barcelona](https://github.com/WebOfTrustInfo/rwot8-barcelona), a group of experts worked on "Shamir's Secret Sharing Best Practices" and the foundation of a new library, while at [RWOT9 in Prague](https://github.com/WebOfTrustInfo/rwot9-prague), a new cohort further discussed use cases, formats, and the two-level scheme. These workgroups included experts such as Christopher Allen, Bryan Bishop, Laurence Chen, Hank Chiu, Mark Friedenbach, Chris Howe, Yancy Ribbens, Daan Sprenkels, ChiaWei Tang, and others. Initial work on Blockchain Common's `bc-shamir` library grew from Daan's work on his own [SSS library](https://github.com/dsprenkels/sss). Further encouragement to produce the new SSKR specification came from Ken Sedgwick, who identified the round-tripping problems between BIP-39 and SLIP-39.
108 |
109 | ## What is the Future of SSKR?
110 |
111 | SSKR was designed from the beginning to work with different types of secret sharing. The first expansion is likely to be into VSS.
112 |
113 | _Also see the [SSKR Example & Test Vector](sskr-test-vector.md) for a ready-to-use seed and [A Guide to Using URs for SSKRs](https://github.com/BlockchainCommons/crypto-commons/blob/shannona-docs-sskr-request-response/Docs/ur-3-sskrs.md) for discussions of a variety of SSKR formatting._
114 |
115 | _For a higher level discussion of secret-sharing designs and dangers, see our #SmartCustody articles on [Designing SSKR Share Scenarios](https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Sharing.md) and [The Dangers of Secret-Sharing Schemes](https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Dangers.md)._
116 |
117 | _For a discussion of using SSKR for storing more data than just seeds, such as descriptors, transaction details, etc. see the [CSR - Collaborative Seed Recovery Project](https://github.com/BlockchainCommons/Gordian/blob/master/CSR/README.md)
118 |
119 |
--------------------------------------------------------------------------------
/Docs/sskr-overview.md:
--------------------------------------------------------------------------------
1 | # SSKR Docs
2 |
3 | SSKR stands for Sharded Secret Key Reconstruction. It's a specification that allows you to securely create a backup of your cryptoseeds by sharding those secrets. It uses the mature Shamir’s Secret Sharing functionality, but with more choices of output and options for advanced two-tiered shards.
4 |
5 | Users can use SSKR to easily shard a seed. Our reference tools for iOS, macOS, and UNIX demo the functionality, but we expect more cryptocurrency wallet manufacturers to soon be incorporating SSKRs as well.
6 |
7 | Seedtool, our iOS and macOS reference tool, allows you to print your sares and distribute them as coupons, which include QRs of the shares that can be stored in a QR vault. If you run the Mac version of Seedtool, you can instead print them directly to a PDF!
8 |
9 | But you can also secure shares in other ways, such as etching the words into steel to ensure you never lose your cryptocurrency seed. We have a demo on how to do it with steel dog tags!
10 |
11 | There are other advantages as well, including BIP-39 roundtripping and the usage of words that are less-likely to be confused. Take a look, we talk about it all in our docs!
12 |
13 | Developers of all sorts should find it easy to incorporate the functionality, thanks to libraries available in multiple programming languages, plus a large collection of documents.
14 |
15 | If you’d like to see more #SmartCustody work to support responsible key management, including more specifications and references for creating wallet interoperability. Support Blockchain Commons by [becoming a patron](https://github.com/sponsors/BlockchainCommons)!
16 |
17 | ## Intro
18 |
19 | The following overviews SSKR.
20 |
21 | * [SSKR for Users](https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/sskr-users.md)
22 | * [SSKR in Technology Overview Video](https://www.youtube.com/watch?v=RYgOFSdUqWY&t=1612s)
23 | * [Early Demo Video](https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/sskr-video.md)
24 |
25 | ## For Users
26 |
27 | How can you use SSKR? The following describes its usage in [Gordian Seed Tool](https://apps.apple.com/us/app/gordian-seed-tool/id1545088229).
28 |
29 | * [Sharding a Seed (from Gordian Seed Tool Manual)](https://github.com/BlockchainCommons/GordianSeedTool-iOS/blob/master/Docs/MANUAL.md#sharding-a-seed)
30 | * [Importing SSKR Shards (from Gordian Seed Tool Manual)](https://github.com/BlockchainCommons/GordianSeedTool-iOS/blob/master/Docs/MANUAL.md#importing-sskr-shares)
31 |
32 |
36 | 
37 | SSKR Export
38 | |
39 |
40 | 
41 | SSKR Coupons
42 | |
43 |
44 | 
45 | SSKR Import
46 | |
47 |
79 |
80 | The ByteWords for `59f2293a5bce7d4de59e71b4207ac5d2` are:
81 | ```
82 | vial mild high twin duty fuel jugs rust apex cats
83 | mild idea lamb gyro scar play vibe gray guru soap
84 | kiln ruby lazy silk cook tent girl love pose obey
85 | pose brew exit gray king iced
86 | ```
87 | The BIP39 words are:
88 | ```
89 | toe priority custom gauge jacket theme arrest bargain gloom wide ill fit eagle prepare capable fish limb cigar reform other priority speak rough imitate
90 | ```
91 | If you'd like to test the seed yourself, download [Gordian SeedTool for iOS](https://apps.apple.com/us/app/gordian-seed-tool/id1545088229) and click the "QR" icon at the top to scan a QR code. Point it to the QR code above and you'll load this Test Vector into your own phone!
92 |
93 | #### Two-of-Three SSKR
94 |
95 | A traditional use of Shamir's Secret Sharing might shard a secret into three shares, and then allow the secret to be restored from two of those shares.
96 |
97 | The following shows a set of 2-of-3 shares generated by Gordian SeedTool and exported as ByteWords:
98 | ```
99 | tuna acid epic hard data love wolf able acid able
100 | duty surf belt task judo legs ruby cost belt pose
101 | ruby logo iron vows luck bald user lazy tuna belt
102 | guru buzz limp exam obey kept task cash saga pool
103 | love brag roof owls news junk
104 |
105 | tuna acid epic hard data love wolf able acid acid
106 | barn peck luau keys each duty waxy quad open bias
107 | what cusp zaps math kick dark join nail legs oboe
108 | also twin yank road very blue gray saga oboe city
109 | gear beta quad draw knob main
110 |
111 | tuna acid epic hard data love wolf able acid also
112 | fund able city road whiz zone claw high frog work
113 | deli slot gush cats kiwi gyro numb puma join fund
114 | when math inch even curl rich vows oval also unit
115 | brew door atom love gyro figs
116 | ```
117 | The following shows that same 2-of-3 share exported as a [Uniform Resource (UR)](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md):
118 | ```
119 | ur:crypto-sskr/hddalewfaeadaedysfbttkjolsryctbtperyloinvslkbdurlytabtgubzlpemoykttkchsapllebgvdgleedp
120 | ur:crypto-sskr/hddalewfaeadadbnpkluksehdywyqdonbswtcpzsmhkkdkjnnllsoeaotnykrdvybegysaoecygrbavssktbti
121 | ur:crypto-sskr/hddalewfaeadaofdaecyrdwzzecwhhfgwkdistghcskigonbpajnfdwnmhihenclrhvsolaoutbwdrhliazcia
122 | ```
123 | A UR uses the minimal bytewords form, meaning that it shows only the first and last letter of each word. This means that "go" is "gyro", "jy" is "jury", "jp" is "jump", "ae" is "able", etc. You can see that the "UR" form of the three shares thus precisely matches the ByteWords except that the first three words ("tune acid epic"), identifying it as an SSKR, has been omitted, and this changes the checksum, which is the last four words.
124 |
125 | > :warning: **WARNING.** SSKR is non-deterministic. There is a random factor introduced when the shares are created, which means that every time you generate shares, they will be different. This is an expected and correct result.
126 |
127 | #### The Two-of-Three Two-of-Three SSKR
128 |
129 | One of the advantages of SSKR is that it can support arbitrary groups, where you can then reconstruct a secret by using some number of shares from some number of groups.
130 |
131 | One example is a two-of-three two-of-three (grouped four-of-nine) SSKR. Three groups are created, each of which has three shares. Reconstructing the secret requires a threshold of two shares from a threshold of two groups. In other words, the secret can be reconstructed from four of the nine shares, provided that they are two each from two of the groups.
132 |
133 | For a more complex SSKR such as this, you might want to use Gordian SeedTool's print function, rather than cutting and pasting SSKRs or URs:
134 |
135 | 
136 | 
137 | 
138 |
139 |
140 | ## Final Notes
141 |
142 | SSKR is a powerful way to back up digital secrets. This example demonstrates a specific seed and how it can be used to generate SSKR shares using two different groupings.
143 |
144 | See [SSKR Cold Storage](sskr-cold-storage.md) for an example of how to store this test vector by etching it in metal.
145 |
146 |
147 |
--------------------------------------------------------------------------------
/Docs/sskr-users.md:
--------------------------------------------------------------------------------
1 | # SSKR for Users
2 |
3 | SSKR is Sharded Secret Key Reconstruction. It's a way that you can divide ("shard") the master seed underlying a Bitcoin HD wallet into "shares", which you can then distribute to friends, family, or fiduciaries. If you ever lose your seed, you can then "reconstruct" it by collecting sufficient of your shares (the "threshold").
4 |
5 | ## How Does SSKR Work?
6 |
7 | The basic level of SSKR allows you to create a single group of shares, with a threshold for how many of those must be collected to reconstruct your seed. The following shows an example from [Gordian SeedTool](https://github.com/BlockchainCommons/GordianSeedTool-iOS) of creating three shares, of which two must be recovered.
8 |
9 |
12 | 
13 | |
14 |
15 | 
16 | |
17 |
40 | 
41 | |
42 |
43 | 
44 | |
45 |
66 | 
67 | |
68 |
35 | 
36 | QR Tool (deprecated) Recognition
37 | |
38 |
39 | 
40 | Seed Tool Exports
41 | |
42 |
43 | 
44 | Seed Tool SSKR
45 | |
46 |
48 |
49 | ## Gordian Tools & Demos
50 |
51 | _Blockchain Commons has released a number of kits and CLI tools that exercise the Gordian reference libraries._
52 |
53 | * **[Bytewords](https://github.com/BlockchainCommons/bc-bytewords-cli) \(CLI\).** A tool for testing bytewords.
54 | * _Exercises [bc-crypto-base](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-crypto-base) and [bc-bytewords](https://github.com/blockchaincommons/bc-bytewords)._
55 | * **[dCBOR](https://github.com/BlockchainCommons/dcbor-cli) \(CLI\).** A tool for parsing & validating deterministic CBOR.
56 | * _Exercises [bc-dcbor-rust](https://github.com/BlockchainCommons/bc-dcbor-rust)._
57 | * **[Keytool](https://github.com/BlockchainCommons/bc-keytool-cli) \(CLI\).** A tool for deriving keys and addresses from seeds.
58 | * _Uses [bc-crypto-base](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-crypto-base)._
59 | * **[LetheKit](https://github.com/BlockchainCommons/bc-lethekit) \(Hardware Kit\).** A do-it-yourself hardware kit for generating and translating seeds in an airgapped manner. Cotains its own version of seedtool built using the Arduino IDE.
60 | * _LetheKit's Seedtool exercises [bc-crypto-base](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-crypto-base), [bc-bip-39](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-bip-39), [bc-bytewords](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-bytewords), [bc-shamir](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-shamir), [bc-sskr](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-sskr), and [bc-ur](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-ur) (the last through a bc-ur-arduino port)._
61 | * **[LifeHashTool](https://github.com/BlockchainCommons/LifeHashTool) \(Swift CLI\).** A tool for generating Lifehash PNGs from the command line.
62 | * _LifeHashTool uses [LifeHash](https://github.com/BlockchainCommons/LifeHash)._
63 | * **[Seedtool](https://github.com/BlockchainCommons/bc-seedtool-cli) \(CLI\).** A tool for generating seeds from a variety of random inputs and for translating seeds among formats like BIP39, [SSKR](https://github.com/blockchaincommons/bc-sskr), hex, and [Bytewords](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-012-bytewords.md).
64 | * _Exercises [bc-crypto-base](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-crypto-base), [bc-bip-39](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-bip-39), [bc-shamir](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-shamir), [bc-sskr](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-sskr), and [bc-ur](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-ur)._
65 | * **[URDemo](https://github.com/BlockchainCommons/URDemo) \(iOS Demo\).** A demonstration of the [URKit](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-ur) that can be compiled and run in Xcode using Swift. It demonstrates multi-part animated QRs.
66 |
67 | See also our [Gordian repo](https://github.com/BlockchainCommons/Gordian/blob/master/README.md#quick-links-for-reference-apps) for our complete list of reference apps, including other CLIs, mobile apps, and web servers.
68 |
69 | ## Gordian Reference Libraries
70 |
71 | _The Crypto Commons libraries are reference implementations, meant to be examples of how to standardly implement these various crypto functions._
72 |
73 | ### *bc-crypto-base*
74 |
75 | _Well-reviewed, audited, and optimized crypto functions. Includes CRC32, HMAC-SHA-256, HMAC-SHA-512, PBKDF2-SHA-256, PBKDF2-SHA-512, SHA-256, and SHA-512 algorithms, and memzero functions._
76 |
77 | | Language | Repo | Contributor | Status |
78 | |----------|------|-------------|--------|
79 | | C | [bc-crypto-base](https://github.com/BlockchainCommons/bc-crypto-base) | Blockchain Commons |
80 | | Java | [bc-libs-java](https://github.com/BlockchainCommons/bc-libs-java) | Bitmark |
81 | | Rust | [bc-crypto-rust](https://github.com/BlockchainCommons/bc-crypto-rust) | Blockchain Commons |
82 | | Swift | [BCLibsSwift](https://github.com/BlockchainCommons/BCLibsSwift) | Blockchain Commons |
83 |
84 | ### *bc-bech32*
85 |
86 | **Specification:** [BIP-173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)
87 |
88 | _Implementation of Bech32 address format. No longer being actively supported._
89 |
90 | | Language | Repo | Contributor | Status |
91 | |----------|------|-------------|--------|
92 | | C | [bc-bech32](https://github.com/BlockchainCommons/bc-bech32) | Blockchain Commons | Unsupported |
93 |
94 | ### *bc-bip-39*
95 |
96 | **Specification:** [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)
97 |
98 | _Implementation of BIP-39 mnemonic codes._
99 |
100 | | Language | Repo | Contributor | Status |
101 | |----------|------|-------------|--------|
102 | | C | [bc-bip39](https://github.com/blockchaincommons/bc-bip39) | Blockchain Commons | |
103 | | Java | [bc-libs-java](https://github.com/BlockchainCommons/bc-libs-java) | Bitmark |
104 |
105 | ### *bc-bytewords*
106 |
107 | **Specification:** [bcr-2020-012](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-012-bytewords.md)
108 |
109 | _The Bytewords methodology encodes binary data as English words, using a set of 256 four-letter words, each of which can be recovering using just the first two letters. Bytewords are also used in [bc-sskr](https://github.com/blockchaincommons/bc-sskr) and [bc-ur](https://github.com/BlockchainCommons/bc-ur)._
110 |
111 | | Language | Repo | Contributor | Status |
112 | |----------|------|-------------|--------|
113 | | C | [bc-bytewords](https://github.com/BlockchainCommons/bc-bytewords) | Blockchain Commons | |
114 | | Java | [bc-libs-java](https://github.com/BlockchainCommons/bc-libs-java) | Bitmark |
115 |
116 |
117 | ### *bc-dcbor*
118 |
119 | **Specification:** [RFC8949](https://www.rfc-editor.org/rfc/rfc8949.html) / [dCBOR I-D](https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/)
120 |
121 | _Libraries for CBOR compliant with the [deterministic options](https://www.rfc-editor.org/rfc/rfc8949.html#name-deterministically-encoded-c). For more, see our [dCBOR page](dcbor.md)._
122 |
123 | | Language | Repo | Contributor | Status |
124 | |----------|------|-------------|--------|
125 | | Rust | [bc-dcbor-rust](https://github.com/BlockchainCommons/bc-dcbor-rust) | Blockchain Commons | |
126 | | Swift | [BCSwiftDCBOR](https://github.com/BlockchainCommons/BCSwiftDCBOR) | Blockchain Commons | |
127 |
128 |
129 | ### *bc-envelope*
130 |
131 | **Specification:** [Envelope Structured Data Format I-D](https://datatracker.ietf.org/doc/draft-mcnally-envelope/)
132 |
133 | _Libraries for [Gordian Envelope](https://www.blockchaincommons.com/introduction/Envelope-Intro/)._
134 |
135 | | Language | Repo | Contributor | Status |
136 | |----------|------|-------------|--------|
137 | | Rust | [bc-envelope-rust](https://github.com/BlockchainCommons/bc-envelope-rust) | Blockchain Commons | |
138 | | Swift | [BCSwiftEnvelope](https://github.com/BlockchainCommons/BCSwiftEnvelope) | Blockchain Commons | |
139 |
140 |
141 | ### *bc-lifehash*
142 |
143 | **Overview:** [Lifehash.info](https://github.com/BlockchainCommons/lifehash.info)
144 |
145 | _A library for creating LifeHash visual hashes._
146 |
147 | | Language | Repo | Contributor | Status |
148 | |----------|------|-------------|--------|
149 | | C/C++ | [bc-lifehash](https://github.com/BlockchainCommons/bc-lifehash) | Blockchain Commons |
150 | | Python | [bc-lifehash-python](https://github.com/BlockchainCommons/bc-lifehash-python) | CrossBar |
151 | | Swift | [LifeHash](https://github.com/BlockchainCommons/LifeHash) | Blockchain Commons |
152 |
153 | ### *bc-shamir*
154 |
155 | **Specification:** ["How to Share a Secret"](https://dl.acm.org/doi/pdf/10.1145/359168.359176)
156 |
157 | _Implementation of Shamir's Secret Sharing._
158 |
159 | | Language | Repo | Contributor | Status |
160 | |----------|------|-------------|--------|
161 | | C | [bc-shamir](https://github.com/BlockchainCommons/bc-shamir) | Blockchain Commons | [Security Reviewed](https://github.com/BlockchainCommons/bc-shamir/blob/master/SECURITY-REVIEW.md) |
162 | | Java | [bc-libs-java](https://github.com/BlockchainCommons/bc-libs-java) | Bitmark |
163 | | Rust | [bc-shamir-rust](https://github.com/BlockchainCommons/bc-shamir-rust) | Blockchain Commons |
164 | | Swift | [BCLibsSwift](https://github.com/BlockchainCommons/BCLibsSwift) | Blockchain Commons |
165 |
166 | ### *bc-slip39*
167 |
168 | **Specification:** [SLIP-39](https://github.com/satoshilabs/slips/blob/master/slip-0039.md).
169 |
170 | _Implementation of Satoshi Labs' SLIP-39. Largely deprected due to discovery of [round-trip failure with BIP-39](https://github.com/BlockchainCommons/bc-lethekit/issues/38). Blockchain Commons projects use [bc-sskr](https://github.com/blockchaincommons/bc-sskr) instead._
171 |
172 | | Language | Repo | Contributor | Status |
173 | |----------|------|-------------|--------|
174 | | C | [bc-slip39](https://github.com/BlockchainCommons/bc-slip39) | Blockchain Commons | Deprecated |
175 |
176 | ### *bc-sskr*
177 |
178 | **Specification:** [bcr-2020-011](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-011-sskr.md)
179 |
180 | _The SSKR (Sharded Secret Key Reconstruction) methodology is an alternative to SLIP-39 that converts Shamir shares to [URs](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-012-bytewords.md) or [bytewords](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-012-bytewords.md). Its main improvement over SLIP-39 is that it round trips with BIP-39, whereas [SLIP-39 does not](https://github.com/BlockchainCommons/bc-lethekit/issues/38)._
181 |
182 | | Language | Repo | Contributor | Status |
183 | |----------|------|-------------|--------|
184 | | C | [bc-sskr](https://github.com/blockchaincommons/bc-sskr) | Blockchain Commons | [Security Reviewed](https://github.com/BlockchainCommons/bc-sskr/blob/master/SECURITY-REVIEW.md) |
185 | | Java | [bc-libs-java](https://github.com/BlockchainCommons/bc-libs-java) | Bitmark |
186 | | JavaCard | [jc-sskr](https://github.com/proxyco/jc-sskr) | Proxy |
187 | | Rust | [bc-sskr-rust](https://github.com/BlockchainCommons/bc-sskr-rust) | Blockchain Commons |
188 | | Swift | [BCLibsSwift](https://github.com/BlockchainCommons/BCLibsSwift) | Blockchain Commons |
189 |
190 | ### *bc-ur*
191 |
192 | **Specification:** [bcr-2020-005](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md)
193 |
194 | _The UR methodology allows the encoding of binary data of arbitrary content and length and their transportation using one or more URIs or QR codes (or alternatively animated QR codes). It also integrates with [bytewords](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-012-bytewords.md)._
195 |
196 | | Language | Repo | Contributor | Status |
197 | |----------|------|-------------|--------|
198 | | C++ | [bc-ur](https://github.com/BlockchainCommons/bc-ur) | Blockchain Commons |
199 | | Java | [bc-ur-java](https://github.com/BlockchainCommons/bc-ur-java) | Bitmark |
200 | | Java | [Hummingbird](https://github.com/sparrowwallet/hummingbird) | Craig Raw |
201 | | Python | [foundation-ur-py](https://github.com/Foundation-Devices/foundation-ur-py) | Foundation |
202 | | Rust | [bc-ur-rust](https://github.com/BlockchainCommons/bc-ur-rust) | Blockchain Commons |
203 | | Rust | [ur-rust](https://github.com/dspicher/ur-rs) | Dominik Spicher |
204 | | Swift | [URKit](https://github.com/BlockchainCommons/URKit) + [URUI](https://github.com/BlockchainCommons/URUI) | Blockchain Commons |
205 |
206 | ## Third-Party Libraries
207 |
208 | Blockchain Commons also uses well-supported libraries from third parties. In particular, we make strong usage of The Elements Project [libwally wallet library](https://github.com/ElementsProject/libwally-core). We are further supporting it with wrappers for [Swift](https://github.com/BlockchainCommons/BCLibwallySwift) and [Java](https://github.com/BlockchainCommons/bc-bclibwally-java).
209 |
210 | ## Status - Varied
211 |
212 | Please see individual projects for their exact status. The C libraries are largely in feature-complete beta status.
213 |
214 | ## Origin, Authors, Copyright & Licenses
215 |
216 | Unless otherwise noted (either in this [/README.md](./README.md) or in the file's header comments) the contents of this repository are Copyright © 2020 by Blockchain Commons, LLC, and are [licensed](./LICENSE) under the [spdx:BSD-2-Clause Plus Patent License](https://spdx.org/licenses/BSD-2-Clause-Patent.html).
217 |
218 | In most cases, the authors, copyright, and license for each file reside in header comments in the source code. When it does not, we have attempted to attribute it accurately in the table below.
219 |
220 | ## Financial Support
221 |
222 | Crypto Commons is a project of [Blockchain Commons](https://www.blockchaincommons.com/). 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.
223 |
224 | To financially support further development of Crypto Commons and other projects, please consider becoming a Patron of Blockchain Commons through ongoing monthly patronage as a [GitHub Sponsor](https://github.com/sponsors/BlockchainCommons). You can also support Blockchain Commons with bitcoins at our [BTCPay Server](https://btcpay.blockchaincommons.com/).
225 |
226 | ## Contributing
227 |
228 | We encourage public contributions through issues and pull requests! Please review [CONTRIBUTING.md](./CONTRIBUTING.md) for details on our development process. All contributions to this repository require a GPG signed [Contributor License Agreement](./CLA.md).
229 |
230 | ### Discussions
231 |
232 | The best place to talk about Blockchain Commons and its projects is in our GitHub Discussions areas.
233 |
234 | [**Gordian Developer Community**](https://github.com/BlockchainCommons/Gordian-Developer-Community/discussions). 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](https://github.com/BlockchainCommons/Gordian-Developer-Community/discussions). This is where you talk about Gordian specifications such as [Gordian Envelope](https://github.com/BlockchainCommons/Gordian/tree/master/Envelope#articles), [bc-shamir](https://github.com/BlockchainCommons/bc-shamir), [Sharded Secret Key Reconstruction](https://github.com/BlockchainCommons/bc-sskr), and [bc-ur](https://github.com/BlockchainCommons/bc-ur) as well as the larger [Gordian Architecture](https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Overview-Architecture.md), its [Principles](https://github.com/BlockchainCommons/Gordian#gordian-principles) of independence, privacy, resilience, and openness, and its macro-architectural ideas such as functional partition (including airgapping, the original name of this community).
235 |
236 | [**Blockchain Commons Discussions**](https://github.com/BlockchainCommons/Community/discussions). For developers, interns, and patrons of Blockchain Commons, please use the discussions area of the [Community repo](https://github.com/BlockchainCommons/Community) to talk about general Blockchain Commons issues, the intern program, or topics other than those covered by the [Gordian Developer Community](https://github.com/BlockchainCommons/Gordian-Developer-Community/discussions) or the
237 | [Gordian User Community](https://github.com/BlockchainCommons/Gordian/discussions).### Other Questions & Problems
238 |
239 | 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](./issues) feature. Unfortunately, we can not make any promises on response time.
240 |
241 | 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.
242 |
243 | ### Credits
244 |
245 | 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](./CONTRIBUTING.md) documentation.
246 |
247 | | Name | Role | Github | Email | GPG Fingerprint |
248 | | ----------------- | ------------------- | ------------------------------------------------- | ------------------------------------- | -------------------------------------------------- |
249 | | Christopher Allen | Principal Architect | [@ChristopherA](https://github.com/ChristopherA) | \
17 | Why CBOR?
18 | 
19 | |
20 |
21 | dCBOR Library from Blockchain Commons
22 | 
23 | |
24 |