You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* DERIVED BIP39 MNEMONIC=puppy ocean match cereal symbol another shed magic wrap hammer bulb intact gadget divorce twin tonight reason outdoor destroy simple truth cigar social volcano
227
227
228
+
===BIP93 (codex32)===
229
+
Application Number: 93'
230
+
231
+
The derivation path format is: <code>m/83696968'/93'/{hrp}'/{threshold}'/{n}'/{byte_length}'/{id0}'/{id1}'/{id2}'/{id3}'/{index}'</code>
232
+
233
+
Use this application to generate fresh codex32 strings (as defined in BIP-0093) for Shamir's Secret Sharing backups of BIP-0032 HD master seeds. Each codex32 string encodes a share or secret with a human-readable prefix (hrp), and a data part consisting of a threshold, identifier, share index, payload, and checksum.
234
+
235
+
Create a BIP85 DRNG whose seed is the derived entropy. Read 1 byte from the DRNG and trim to the 5 most significant bits to obtain an integer (0–31), representing a bech32 character.
Repeat until all required data characters are validly chosen.
240
+
241
+
Example: a codex32 secret with <code>hrp = "ms"</code> (first index), <code>threshold = "0"</code>, <code>n = 1</code>, <code>byte_length = 16</code>, identifier <code>"c0??"</code> would have the path <code>m/83696968'/93'/0'/0'/1'/16'/24'/15'/32'/32'/0'</code>, the next secret would be <code>m/83696968'/93'/0'/0'/1'/16'/24'/15'/32'/32'/1'</code> (identifier <code>"c0zc"</code>) etc.
242
+
243
+
Human-readable Prefix Table
244
+
245
+
{|
246
+
!hrp
247
+
!Code
248
+
|-
249
+
| "ms"
250
+
| 0'
251
+
|-
252
+
| "cl"
253
+
| 1'
254
+
|-
255
+
|}
256
+
257
+
Threshold Table
258
+
259
+
{|
260
+
!Threshold
261
+
!Code
262
+
|-
263
+
| "0"
264
+
| 0'
265
+
|-
266
+
| "2"
267
+
| 2'
268
+
|-
269
+
| "3"
270
+
| 3'
271
+
|-
272
+
| "4"
273
+
| 4'
274
+
|-
275
+
| "5"
276
+
| 5'
277
+
|-
278
+
| "6"
279
+
| 6'
280
+
|-
281
+
| "7"
282
+
| 7'
283
+
|-
284
+
| "8"
285
+
| 8'
286
+
|-
287
+
| "9"
288
+
| 9'
289
+
|-
290
+
|}
291
+
292
+
Share Count Table
293
+
294
+
{|
295
+
!Threshold code
296
+
!Number of Shares
297
+
!Code
298
+
|-
299
+
| 0'
300
+
| n = 1
301
+
| 1'
302
+
|-
303
+
| not 0'
304
+
| n (from 1 to 31)
305
+
| n'
306
+
|}
307
+
308
+
Bytes Length Table
309
+
310
+
{|
311
+
! Bytes
312
+
! Data Length (Characters)
313
+
!Code
314
+
|-
315
+
| 16
316
+
| 45
317
+
| 16'
318
+
|-
319
+
| 32
320
+
| 71
321
+
| 32'
322
+
|-
323
+
| 64
324
+
| 124
325
+
| 64'
326
+
|}
327
+
Note: Other lengths between 16 and 64 are valid but not recommended, using corresponding hardened indices.
328
+
329
+
Identifier Table
330
+
331
+
{|
332
+
! Identifier
333
+
!Code
334
+
|-
335
+
| id0, id1, id2, id3
336
+
| id0'/id1'/id2'/id3'
337
+
|-
338
+
| Default (BIP-0032 fingerprint)
339
+
| 32'/32'/32'/32'
340
+
|}
341
+
The identifier is four bech32 characters converted to four integers using the character table from BIP-0173. Each identifier hardened index (idX) used in the derivation path affects the derived entropy; if idX = 32 then the character emitted at that position in the encoded identifier MUST be the bech32 character for the corresponding 5-bit chunk of the 20 most significant bits of the relevant seed's BIP-0032 fingerprint (master seed, else seed recovered at t = n, else share "a" if n = 1).
342
+
343
+
Rationale: This default assists users in locating the correct codex32 backup for their wallets, should be distinct for hundreds of backups users may need to disambiguate and, as it is widely stored, improves overall error correction.
344
+
345
+
====Unshared Secret====
346
+
347
+
When <code>threshold == "0"</code>, <code>n</code> MUST be ''1'' and the output is a codex32 secret. The payload in a codex32 secret is a direct encoding of a BIP-0032 HD master seed.
348
+
349
+
Examples:
350
+
351
+
Generate a "ms" prefixed codex32 secret, 16-byte payload, with identifier <code>"c0??"</code>.
If we already have a valid set of ''t'' initial codex32 strings, use BIP-0093 to derive ''n'' shares. The BIP85 dice application may be used to randomly select ''n'' share indices.
374
+
375
+
Otherwise, for each initial share needed:
376
+
377
+
1. Take the next available letter from the bech32 alphabet, in alphabetical order, as <code>a</code>, <code>c</code>, <code>d</code>, ..., to be the share index.
2. Generate ceil(''<code>byte_length</code> * 8 / 5'') random payload characters using the BIP85 DRNG.
380
+
* Recover secret at "s", if needed, for the default identifier.
381
+
3. Prepend the <code>threshold</code> and identifier.
382
+
383
+
4. Compute and append the codex32 checksum.
384
+
385
+
5. Translate the data part to characters using the table from BIP-0173 and prepend <code>hrp</code>1.
386
+
{|
387
+
! Fresh master seeds
388
+
!Existing master seeds
389
+
|-
390
+
| ''n'' >= ''t''
391
+
| ''n'' < ''t''
392
+
|}
393
+
There are two ways to create an initial set of ''t'' valid codex32 strings, depending on whether the user is creating a fresh master seed or using an existing master seed.
394
+
The following steps outline the process for each case.
395
+
396
+
=====For a fresh master seed=====
397
+
398
+
Generate ''t'' initial random shares as above, then:
399
+
* Derive the remaining 31 - ''t'' possible shares by interpolating from these initial ''t'' shares.
400
+
* Use the DRNG to deterministically select ''n'' unique indices (excluding "s").
401
+
* Output the shares with these indices.
402
+
* The secret can be recovered by interpolating any ''t'' shares at index "s".
403
+
404
+
Examples:
405
+
406
+
Generate 3 codex32 shares with a threshold of 2 for a 16-byte seed, identifier <code>"c00l"</code>.
Note: The share indices are alphabetized. The default identifier is the fingerprint of payload bytes of "s" had the <code>threshold</code been <code>n</code> (2 in this example).
This specification is not backwards compatible with any other existing specification.
431
662
432
-
This specification relies on BIP32 but is agnostic to how the BIP32 root key is derived. As such, this standard is able to derive wallets with initialization schemes like BIP39 or Electrum wallet style mnemonics.
663
+
This specification relies on BIP32 but is agnostic to how the BIP32 root key is derived. As such, this standard is able to derive wallets with initialization schemes like BIP39, codex32 or Electrum wallet style mnemonics.
0 commit comments