diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 00000000..a252d3d7 --- /dev/null +++ b/.gitattributes @@ -0,0 +1 @@ +*.md linguist-detectable diff --git a/.travis.yml b/.travis.yml index a84ebc9e..8b798ca9 100644 --- a/.travis.yml +++ b/.travis.yml @@ -8,3 +8,4 @@ before_script: script: - markdownlint -c markdownlint.json *.md + - ./check.sh diff --git a/README.md b/README.md index 7b0dfecb..98264579 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,5 @@ # SatoshiLabs Improvement Proposals -[![Build Status](https://travis-ci.org/satoshilabs/slips.svg?branch=master)](https://travis-ci.org/satoshilabs/slips) - SatoshiLabs projects need a way how to document their technical decisions and features. For some of them Bitcoin Improvement Proposal (BIP) is not a right place because their range and implications are outside of the scope of Bitcoin and cryptocurrencies. @@ -14,21 +12,30 @@ Each SLIP should provide a concise technical specification of the feature and a | Number | Title | Type | Status | |---------------------------|-----------------------------------------------------------------------|---------------|----------| | [SLIP-0000](slip-0000.md) | SLIP Template | Informational | Accepted | -| [SLIP-0010](slip-0010.md) | Universal private key derivation from master private key | Standard | Draft | -| [SLIP-0011](slip-0011.md) | Symmetric encryption of key-value pairs using deterministic hierarchy | Standard | Draft | +| [SLIP-0010](slip-0010.md) | Universal private key derivation from master private key | Standard | Final | +| [SLIP-0011](slip-0011.md) | Symmetric encryption of key-value pairs using deterministic hierarchy | Standard | Final | | [SLIP-0012](slip-0012.md) | Public key encryption using deterministic hierarchy | Standard | Draft | -| [SLIP-0013](slip-0013.md) | Authentication using deterministic hierarchy | Standard | Draft | -| [SLIP-0014](slip-0014.md) | Stress Test Deterministic Wallet | Informational | Draft | -| [SLIP-0015](slip-0015.md) | Format for Bitcoin metadata and its encryption in HD wallets | Standard | Draft | -| [SLIP-0016](slip-0016.md) | Format for password storage and its encryption | Standard | Draft | -| [SLIP-0017](slip-0017.md) | Elliptic Curve Diffie-Hellman using deterministic hierarchy | Standard | Draft | -| [SLIP-0018](slip-0018.md) | reserved | Standard | Draft | +| [SLIP-0013](slip-0013.md) | Authentication using deterministic hierarchy | Standard | Final | +| [SLIP-0014](slip-0014.md) | Stress Test Deterministic Wallet | Informational | Active | +| [SLIP-0015](slip-0015.md) | Format for Bitcoin metadata and its encryption in HD wallets | Standard | Final | +| [SLIP-0016](slip-0016.md) | Format for password storage and its encryption | Standard | Final | +| [SLIP-0017](slip-0017.md) | Elliptic Curve Diffie-Hellman using deterministic hierarchy | Standard | Final | +| SLIP-0018 | reserved (CoSi) | Standard | Draft | +| [SLIP-0019](slip-0019.md) | Proof of Ownership | Standard | Accepted | +| [SLIP-0020](slip-0020.md) | Proof of User Confirmation | Standard | Draft | +| [SLIP-0021](slip-0021.md) | Hierarchical derivation of symmetric keys | Standard | Final | +| [SLIP-0022](slip-0022.md) | FIDO2 Credential ID format for HD wallets | Standard | Final | +| [SLIP-0023](slip-0023.md) | Cardano HD master node derivation from a master seed | Standard | Final | +| [SLIP-0024](slip-0024.md) | Trezor payment request format | Standard | Draft | +| [SLIP-0025](slip-0025.md) | Key derivation for CoinJoin accounts | Standard | Draft | +| SLIP-0026 | reserved (CoSi) | Standard | Draft | | [SLIP-0032](slip-0032.md) | Extended serialization format for BIP-32 wallets | Standard | Draft | -| [SLIP-0039](slip-0039.md) | Shamir's Secret-Sharing for Mnemonic Codes | Standard | Draft | -| [SLIP-0044](slip-0044.md) | Registered coin types for BIP-0044 | Standard | Draft | -| [SLIP-0048](slip-0048.md) | Deterministic key hierarchy for Graphene-based networks | Informational | Draft | -| [SLIP-0132](slip-0132.md) | Registered HD version bytes for BIP-0032 | Standard | Draft | -| [SLIP-0173](slip-0173.md) | Registered human-readable parts for BIP-0173 | Standard | Draft | +| [SLIP-0039](slip-0039.md) | Shamir's Secret-Sharing for Mnemonic Codes | Standard | Final | +| [SLIP-0044](slip-0044.md) | Registered coin types for BIP-0044 | Standard | Active | +| [SLIP-0048](slip-0048.md) | Deterministic key hierarchy for Graphene-based networks | Standard | Active | +| [SLIP-0077](slip-0077.md) | Deterministic blinding key derivation for Confidential Transactions | Standard | Draft | +| [SLIP-0132](slip-0132.md) | Registered HD version bytes for BIP-0032 | Standard | Active | +| [SLIP-0173](slip-0173.md) | Registered human-readable parts for BIP-0173 | Standard | Active | --- diff --git a/check.sh b/check.sh new file mode 100755 index 00000000..4ab2034e --- /dev/null +++ b/check.sh @@ -0,0 +1,5 @@ +echo "SLIP-0044 duplicates:" +grep '^| [0-9]' slip-0044.md | cut -f 4 -d '|' | tr -d ' ' | sort | uniq -d + +echo "SLIP-0044 uppercase:" +grep '0x80[^ ]*[A-F]' slip-0044.md diff --git a/slip-0010.md b/slip-0010.md index 91ee388c..9cd6638b 100644 --- a/slip-0010.md +++ b/slip-0010.md @@ -4,7 +4,7 @@ Number: SLIP-0010 Title: Universal private key derivation from master private key Type: Standard -Status: Draft +Status: Final Authors: Jochen Hoenicke Pavol Rusnak Created: 2016-04-26 @@ -12,24 +12,27 @@ Created: 2016-04-26 ## Abstract -SLIP-0010 describes how to derive private and public key pairs for curve -types different from secp256k1. +SLIP-0010 describes a generalized derivation scheme for private and public key +pairs in hierarchical deterministic wallets for the curves secp256k1, +NIST P-256, ed25519 and curve25519. ## Motivation Some Trezor applications, in particular SSH and GPG, need different curve types, e.g., NIST P-256 and ed25519. For security reasons different private and public key pairs should be used for these curves. This SLIP -describes how to derive a master private/public key for these curves and -how a BIP-0032 like derivation is used. +describes how to derive a master private/public key for these curves by +generalizing the derivation scheme used in +[BIP-0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). ## Body -Trezor generates all keys from a 12 to 24 word mnemonic sequence and -optionally a passphrase. The BIP-0039 standard describes the procedure -to compute a 512 bit seed from this passphrase. From this seed Trezor -can create several master keys, one for each curve. It uses a process -similar and compatible to BIP-0032. For other curves it uses a +Trezor generates all keys from a [BIP-0039](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) +mnemonic or from a set of [SLIP-0039](https://github.com/satoshilabs/slips/blob/master/slip-0039.md) +mnemonic shares and optionally a passphrase. Each of these standards specifies +how to compute a seed from the mnemonic(s) and passphrase. From this +seed Trezor can create several master keys, one for each curve. It uses a +process similar and practically compatible with BIP-0032. For other curves it uses a different salt than BIP-0032. This avoids using the same private key for different elliptic curves with different orders. @@ -38,39 +41,60 @@ for different elliptic curves with different orders. We adapt the master key generation from BIP-0032. To use different private keys for different curves we use different keys for the HMAC hash that generates the master key. For the NIST P-256 curve the only -other difference is the different group order. In the algorithm below -we denote the group order of the elliptic curve with n. For ed25519 -curve the private keys are no longer multipliers for the group -generator; instead the hash of the private key is the multiplier. For -this reason, our scheme for ed25519 does not support public key -derivation and uses the produced hashes directly as private keys. +other difference is the curve domain parameters. In the algorithm below +we denote the group order of the elliptic curve by n. point(k) is the +scalar multiplication of the curve generator by the scalar k. +The operation (+) of two elements on the curve is the group point +addition. For ed25519 and curve25519 the private keys are no longer +multipliers for the group generator; instead the hash of the private +key is the multiplier. For this reason, our scheme for ed25519 and curve25519 does +not support public key derivation and uses the produced hashes directly +as private keys. + +For ed25519 public keys we define serP(P): serializes the elliptic +curve point P = (x,y) on a twisted Edwards curve as a byte sequence: +0x00 || ENC(x, y), where ENC is defined in [RFC 8032](https://datatracker.ietf.org/doc/html/rfc8032). + +For curve25519 public keys we define serP(P): serializes the elliptic +curve point P = (u,v) on a Montgomery curve as a byte sequence: +0x00 || encodeUCoordinate(u, 255), where encodeUCoordinate is defined in [RFC 7748](https://datatracker.ietf.org/doc/html/rfc7748). + +For ed25519 and curve25519 private keys we define ser256(p) = p and +parse256(p) = p, since private keys for these two curves are not +integers but byte sequences. To avoid invalid master keys, the algorithm is retried with the intermediate hash as new seed if the key is invalid. -1. Generate a seed byte sequence S of 512 bits according to BIP-0039. -2. Calculate I = HMAC-SHA512(Key = Curve, Data = S) -3. Split I into two 32-byte sequences, IL and IR. -4. Use parse256(IL) as master secret key, and IR as master chain code. -5. If curve is not ed25519 and IL is 0 or ≥ n (invalid key): - * Set S := I and continue at step 2. +Let S be a seed byte sequence of 128 to 512 bits in length. This is the same +as the seed byte sequence used in BIP-0032. The value of S should be the +binary seed obtained from a BIP-0039 mnemonic and optional passphrase or it +should be the master secret obtained from a set of SLIP-0039 mnemonics and +optional passphrase. + +1. Calculate I = HMAC-SHA512(Key = Curve, Data = S) +2. Split I into two 32-byte sequences, IL and IR. +3. Use parse256(IL) as master secret key, and IR as master chain code. +4. If curve is not ed25519 or curve25519 and IL is 0 or ≥ n (invalid key): + * Set S := I and restart at step 1. The supported curves are -* Curve = "Bitcoin seed" for the secp256k1 curve (this is compatible to BIP-0032). +* Curve = "Bitcoin seed" for the secp256k1 curve (this is compatible with BIP-0032). * Curve = "Nist256p1 seed" for the NIST P-256 curve. * Curve = "ed25519 seed" for the ed25519 curve. +* Curve = "curve25519 seed" for curve25519. -For ed25519, the last step always succeeds since every 256-bit number -(even 0) is a valid private key. +For ed25519 and curve25519, the last step always succeeds since every +32-byte sequence (even all zero) is a valid private key. ### Child key derivation (CKD) functions Private and public key derivation for NIST P-256 is identical to the -generation for secp256k1 but uses the order of that curve as modulo. +generation for secp256k1 but uses the domain parameters of that curve. We change BIP-32 to not fail if the resulting key is not valid but -retry hashing until a valid key is found. For ed25519 only hardened -key generation from Private parent key to private child key is supported. +retry hashing until a valid key is found. For ed25519 and curve25519 only hardened +key generation from private parent key to private child key is supported. Given a parent extended key and an index i, it is possible to compute the corresponding child extended key. The algorithm to do so depends @@ -87,20 +111,20 @@ The function CKDpriv((kpar, cpar), i) → (ki31 (whether the child is a hardened key). * If so (hardened child): let I = HMAC-SHA512(Key = cpar, Data = 0x00 || ser256(kpar) || ser32(i)). (Note: The 0x00 pads the private key to make it 33 bytes long.) * If not (normal child): - * If curve is ed25519: return failure. + * If curve is ed25519 or curve25519: return failure. * let I = HMAC-SHA512(Key = cpar, Data = serP(point(kpar)) || ser32(i)). 2. Split I into two 32-byte sequences, IL and IR. 3. The returned chain code ci is IR. -4. If curve is ed25519: The returned child key ki is parse256(IL). -5. If parse256(IL) ≥ n or parse256(IL) + kpar = 0 (resulting key is invalid): +4. If curve is ed25519 or curve25519: The returned child key ki is IL. +5. If parse256(IL) ≥ n or parse256(IL) + kpar (mod n) = 0 (resulting key is invalid): * let I = HMAC-SHA512(Key = cpar, Data = 0x01 || IR || ser32(i) and restart at step 2. 6. Otherwise: The returned child key ki is parse256(IL) + kpar (mod n). -The HMAC-SHA512 function is specified in [RFC 4231](http://tools.ietf.org/html/rfc4231). +The HMAC-SHA512 function is specified in [RFC 4231](https://datatracker.ietf.org/doc/html/rfc4231). #### Public parent key → public child key -This function always fails for ed25519 since normal derivation is not supported. +This function always fails for ed25519 and curve25519 since normal derivation is not supported. The function CKDpub((Kpar, cpar), i) → (Ki, ci) computes a child extended public key from the parent extended public key. It is only defined for non-hardened child keys. @@ -113,6 +137,29 @@ The function CKDpub((Kpar, cpar), i) → (Ki 5. If parse256(IL) ≥ n or Ki is the point at infinity (the resulting key is invalid): * let I = HMAC-SHA512(Key = cpar, Data = 0x01 || IR || ser32(i)) and restart at step 2. +## Compatibility with BIP-0032 + +Master key generation in BIP-0032 may result in an invalid key, in which case +the wallet keys are undefined. Similarly child key derivation may result in an +invalid key, in which case the child key for the given index is undefined and +one should proceed with the next index value. For the secp256k1 curve the +probability of this happening is lower than 2−127, +i.e. practically impossible. For the NIST P-256 curve, on the other hand, the +probability is 2−32, i.e. unlikely but possible. The present +specification extends the BIP-0032 definition of child key derivation so that +the keys for all indices are well defined. The reason for extending the +definition is to avoid problems when dealing with the NIST P-256 curve. However, +the extended definition also applies to the secp256k1 curve. + +For the secp256k1 curve the SLIP-0010 derivation scheme is identical to BIP-0032 +with near certainty (probability greater than 1−2−127 per +derivation operation). Theoretically, if a seed is used in a SLIP-0010 wallet to +receive assets and the seed is ported to a BIP-0032 wallet, then there is an +infinitesimal chance that some assets will not be discovered by the BIP-0032 +wallet. Conversely, if a seed is used in a BIP-0032 wallet to receive assets and +the seed is ported to a SLIP-0010 wallet, then all assets will be discovered by +the SLIP-0010 wallet. + ## Test vectors ### Test vector 1 for secp256k1 @@ -120,246 +167,322 @@ The function CKDpub((Kpar, cpar), i) → (Ki Seed (hex): 000102030405060708090a0b0c0d0e0f * Chain m - * fpr: 00000000 - * chain: 873dff81c02f525623fd1fe5167eac3a55a049de3d314bb42ee227ffed37d508 - * prv: e8f32e723decf4051aefac8e2c93c9c5b214313817cdb01a1494b917c8436b35 - * pub: 0339a36013301597daef41fbe593a02cc513d0b55527ec2df1050e2e8ff49c85c2 + * fingerprint: 00000000 + * chain code: 873dff81c02f525623fd1fe5167eac3a55a049de3d314bb42ee227ffed37d508 + * private: e8f32e723decf4051aefac8e2c93c9c5b214313817cdb01a1494b917c8436b35 + * public: 0339a36013301597daef41fbe593a02cc513d0b55527ec2df1050e2e8ff49c85c2 * Chain m/0H - * fpr: 3442193e - * chain: 47fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae6236141 - * prv: edb2e14f9ee77d26dd93b4ecede8d16ed408ce149b6cd80b0715a2d911a0afea - * pub: 035a784662a4a20a65bf6aab9ae98a6c068a81c52e4b032c0fb5400c706cfccc56 + * fingerprint: 3442193e + * chain code: 47fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae6236141 + * private: edb2e14f9ee77d26dd93b4ecede8d16ed408ce149b6cd80b0715a2d911a0afea + * public: 035a784662a4a20a65bf6aab9ae98a6c068a81c52e4b032c0fb5400c706cfccc56 * Chain m/0H/1 - * fpr: 5c1bd648 - * chain: 2a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19 - * prv: 3c6cb8d0f6a264c91ea8b5030fadaa8e538b020f0a387421a12de9319dc93368 - * pub: 03501e454bf00751f24b1b489aa925215d66af2234e3891c3b21a52bedb3cd711c + * fingerprint: 5c1bd648 + * chain code: 2a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19 + * private: 3c6cb8d0f6a264c91ea8b5030fadaa8e538b020f0a387421a12de9319dc93368 + * public: 03501e454bf00751f24b1b489aa925215d66af2234e3891c3b21a52bedb3cd711c * Chain m/0H/1/2H - * fpr: bef5a2f9 - * chain: 04466b9cc8e161e966409ca52986c584f07e9dc81f735db683c3ff6ec7b1503f - * prv: cbce0d719ecf7431d88e6a89fa1483e02e35092af60c042b1df2ff59fa424dca - * pub: 0357bfe1e341d01c69fe5654309956cbea516822fba8a601743a012a7896ee8dc2 + * fingerprint: bef5a2f9 + * chain code: 04466b9cc8e161e966409ca52986c584f07e9dc81f735db683c3ff6ec7b1503f + * private: cbce0d719ecf7431d88e6a89fa1483e02e35092af60c042b1df2ff59fa424dca + * public: 0357bfe1e341d01c69fe5654309956cbea516822fba8a601743a012a7896ee8dc2 * Chain m/0H/1/2H/2 - * fpr: ee7ab90c - * chain: cfb71883f01676f587d023cc53a35bc7f88f724b1f8c2892ac1275ac822a3edd - * prv: 0f479245fb19a38a1954c5c7c0ebab2f9bdfd96a17563ef28a6a4b1a2a764ef4 - * pub: 02e8445082a72f29b75ca48748a914df60622a609cacfce8ed0e35804560741d29 + * fingerprint: ee7ab90c + * chain code: cfb71883f01676f587d023cc53a35bc7f88f724b1f8c2892ac1275ac822a3edd + * private: 0f479245fb19a38a1954c5c7c0ebab2f9bdfd96a17563ef28a6a4b1a2a764ef4 + * public: 02e8445082a72f29b75ca48748a914df60622a609cacfce8ed0e35804560741d29 * Chain m/0H/1/2H/2/1000000000 - * fpr: d880d7d8 - * chain: c783e67b921d2beb8f6b389cc646d7263b4145701dadd2161548a8b078e65e9e - * prv: 471b76e389e528d6de6d816857e012c5455051cad6660850e58372a6c3e6e7c8 - * pub: 022a471424da5e657499d1ff51cb43c47481a03b1e77f951fe64cec9f5a48f7011 + * fingerprint: d880d7d8 + * chain code: c783e67b921d2beb8f6b389cc646d7263b4145701dadd2161548a8b078e65e9e + * private: 471b76e389e528d6de6d816857e012c5455051cad6660850e58372a6c3e6e7c8 + * public: 022a471424da5e657499d1ff51cb43c47481a03b1e77f951fe64cec9f5a48f7011 ### Test vector 1 for nist256p1 Seed (hex): 000102030405060708090a0b0c0d0e0f * Chain m - * fpr: 00000000 - * chain: beeb672fe4621673f722f38529c07392fecaa61015c80c34f29ce8b41b3cb6ea - * prv: 612091aaa12e22dd2abef664f8a01a82cae99ad7441b7ef8110424915c268bc2 - * pub: 0266874dc6ade47b3ecd096745ca09bcd29638dd52c2c12117b11ed3e458cfa9e8 + * fingerprint: 00000000 + * chain code: beeb672fe4621673f722f38529c07392fecaa61015c80c34f29ce8b41b3cb6ea + * private: 612091aaa12e22dd2abef664f8a01a82cae99ad7441b7ef8110424915c268bc2 + * public: 0266874dc6ade47b3ecd096745ca09bcd29638dd52c2c12117b11ed3e458cfa9e8 * Chain m/0H - * fpr: be6105b5 - * chain: 3460cea53e6a6bb5fb391eeef3237ffd8724bf0a40e94943c98b83825342ee11 - * prv: 6939694369114c67917a182c59ddb8cafc3004e63ca5d3b84403ba8613debc0c - * pub: 0384610f5ecffe8fda089363a41f56a5c7ffc1d81b59a612d0d649b2d22355590c + * fingerprint: be6105b5 + * chain code: 3460cea53e6a6bb5fb391eeef3237ffd8724bf0a40e94943c98b83825342ee11 + * private: 6939694369114c67917a182c59ddb8cafc3004e63ca5d3b84403ba8613debc0c + * public: 0384610f5ecffe8fda089363a41f56a5c7ffc1d81b59a612d0d649b2d22355590c * Chain m/0H/1 - * fpr: 9b02312f - * chain: 4187afff1aafa8445010097fb99d23aee9f599450c7bd140b6826ac22ba21d0c - * prv: 284e9d38d07d21e4e281b645089a94f4cf5a5a81369acf151a1c3a57f18b2129 - * pub: 03526c63f8d0b4bbbf9c80df553fe66742df4676b241dabefdef67733e070f6844 + * fingerprint: 9b02312f + * chain code: 4187afff1aafa8445010097fb99d23aee9f599450c7bd140b6826ac22ba21d0c + * private: 284e9d38d07d21e4e281b645089a94f4cf5a5a81369acf151a1c3a57f18b2129 + * public: 03526c63f8d0b4bbbf9c80df553fe66742df4676b241dabefdef67733e070f6844 * Chain m/0H/1/2H - * fpr: b98005c1 - * chain: 98c7514f562e64e74170cc3cf304ee1ce54d6b6da4f880f313e8204c2a185318 - * prv: 694596e8a54f252c960eb771a3c41e7e32496d03b954aeb90f61635b8e092aa7 - * pub: 0359cf160040778a4b14c5f4d7b76e327ccc8c4a6086dd9451b7482b5a4972dda0 + * fingerprint: b98005c1 + * chain code: 98c7514f562e64e74170cc3cf304ee1ce54d6b6da4f880f313e8204c2a185318 + * private: 694596e8a54f252c960eb771a3c41e7e32496d03b954aeb90f61635b8e092aa7 + * public: 0359cf160040778a4b14c5f4d7b76e327ccc8c4a6086dd9451b7482b5a4972dda0 * Chain m/0H/1/2H/2 - * fpr: 0e9f3274 - * chain: ba96f776a5c3907d7fd48bde5620ee374d4acfd540378476019eab70790c63a0 - * prv: 5996c37fd3dd2679039b23ed6f70b506c6b56b3cb5e424681fb0fa64caf82aaa - * pub: 029f871f4cb9e1c97f9f4de9ccd0d4a2f2a171110c61178f84430062230833ff20 + * fingerprint: 0e9f3274 + * chain code: ba96f776a5c3907d7fd48bde5620ee374d4acfd540378476019eab70790c63a0 + * private: 5996c37fd3dd2679039b23ed6f70b506c6b56b3cb5e424681fb0fa64caf82aaa + * public: 029f871f4cb9e1c97f9f4de9ccd0d4a2f2a171110c61178f84430062230833ff20 * Chain m/0H/1/2H/2/1000000000 - * fpr: 8b2b5c4b - * chain: b9b7b82d326bb9cb5b5b121066feea4eb93d5241103c9e7a18aad40f1dde8059 - * prv: 21c4f269ef0a5fd1badf47eeacebeeaa3de22eb8e5b0adcd0f27dd99d34d0119 - * pub: 02216cd26d31147f72427a453c443ed2cde8a1e53c9cc44e5ddf739725413fe3f4 + * fingerprint: 8b2b5c4b + * chain code: b9b7b82d326bb9cb5b5b121066feea4eb93d5241103c9e7a18aad40f1dde8059 + * private: 21c4f269ef0a5fd1badf47eeacebeeaa3de22eb8e5b0adcd0f27dd99d34d0119 + * public: 02216cd26d31147f72427a453c443ed2cde8a1e53c9cc44e5ddf739725413fe3f4 ### Test vector 1 for ed25519 Seed (hex): 000102030405060708090a0b0c0d0e0f * Chain m - * fpr: 00000000 - * chain: 90046a93de5380a72b5e45010748567d5ea02bbf6522f979e05c0d8d8ca9fffb - * prv: 2b4be7f19ee27bbf30c667b642d5f4aa69fd169872f8fc3059c08ebae2eb19e7 - * pub: 00a4b2856bfec510abab89753fac1ac0e1112364e7d250545963f135f2a33188ed + * fingerprint: 00000000 + * chain code: 90046a93de5380a72b5e45010748567d5ea02bbf6522f979e05c0d8d8ca9fffb + * private: 2b4be7f19ee27bbf30c667b642d5f4aa69fd169872f8fc3059c08ebae2eb19e7 + * public: 00a4b2856bfec510abab89753fac1ac0e1112364e7d250545963f135f2a33188ed * Chain m/0H - * fpr: ddebc675 - * chain: 8b59aa11380b624e81507a27fedda59fea6d0b779a778918a2fd3590e16e9c69 - * prv: 68e0fe46dfb67e368c75379acec591dad19df3cde26e63b93a8e704f1dade7a3 - * pub: 008c8a13df77a28f3445213a0f432fde644acaa215fc72dcdf300d5efaa85d350c + * fingerprint: ddebc675 + * chain code: 8b59aa11380b624e81507a27fedda59fea6d0b779a778918a2fd3590e16e9c69 + * private: 68e0fe46dfb67e368c75379acec591dad19df3cde26e63b93a8e704f1dade7a3 + * public: 008c8a13df77a28f3445213a0f432fde644acaa215fc72dcdf300d5efaa85d350c * Chain m/0H/1H - * fpr: 13dab143 - * chain: a320425f77d1b5c2505a6b1b27382b37368ee640e3557c315416801243552f14 - * prv: b1d0bad404bf35da785a64ca1ac54b2617211d2777696fbffaf208f746ae84f2 - * pub: 001932a5270f335bed617d5b935c80aedb1a35bd9fc1e31acafd5372c30f5c1187 + * fingerprint: 13dab143 + * chain code: a320425f77d1b5c2505a6b1b27382b37368ee640e3557c315416801243552f14 + * private: b1d0bad404bf35da785a64ca1ac54b2617211d2777696fbffaf208f746ae84f2 + * public: 001932a5270f335bed617d5b935c80aedb1a35bd9fc1e31acafd5372c30f5c1187 * Chain m/0H/1H/2H - * fpr: ebe4cb29 - * chain: 2e69929e00b5ab250f49c3fb1c12f252de4fed2c1db88387094a0f8c4c9ccd6c - * prv: 92a5b23c0b8a99e37d07df3fb9966917f5d06e02ddbd909c7e184371463e9fc9 - * pub: 00ae98736566d30ed0e9d2f4486a64bc95740d89c7db33f52121f8ea8f76ff0fc1 + * fingerprint: ebe4cb29 + * chain code: 2e69929e00b5ab250f49c3fb1c12f252de4fed2c1db88387094a0f8c4c9ccd6c + * private: 92a5b23c0b8a99e37d07df3fb9966917f5d06e02ddbd909c7e184371463e9fc9 + * public: 00ae98736566d30ed0e9d2f4486a64bc95740d89c7db33f52121f8ea8f76ff0fc1 * Chain m/0H/1H/2H/2H - * fpr: 316ec1c6 - * chain: 8f6d87f93d750e0efccda017d662a1b31a266e4a6f5993b15f5c1f07f74dd5cc - * prv: 30d1dc7e5fc04c31219ab25a27ae00b50f6fd66622f6e9c913253d6511d1e662 - * pub: 008abae2d66361c879b900d204ad2cc4984fa2aa344dd7ddc46007329ac76c429c + * fingerprint: 316ec1c6 + * chain code: 8f6d87f93d750e0efccda017d662a1b31a266e4a6f5993b15f5c1f07f74dd5cc + * private: 30d1dc7e5fc04c31219ab25a27ae00b50f6fd66622f6e9c913253d6511d1e662 + * public: 008abae2d66361c879b900d204ad2cc4984fa2aa344dd7ddc46007329ac76c429c * Chain m/0H/1H/2H/2H/1000000000H - * fpr: d6322ccd - * chain: 68789923a0cac2cd5a29172a475fe9e0fb14cd6adb5ad98a3fa70333e7afa230 - * prv: 8f94d394a8e8fd6b1bc2f3f49f5c47e385281d5c17e65324b0f62483e37e8793 - * pub: 003c24da049451555d51a7014a37337aa4e12d41e485abccfa46b47dfb2af54b7a + * fingerprint: d6322ccd + * chain code: 68789923a0cac2cd5a29172a475fe9e0fb14cd6adb5ad98a3fa70333e7afa230 + * private: 8f94d394a8e8fd6b1bc2f3f49f5c47e385281d5c17e65324b0f62483e37e8793 + * public: 003c24da049451555d51a7014a37337aa4e12d41e485abccfa46b47dfb2af54b7a + +### Test vector 1 for curve25519 + +Seed (hex): 000102030405060708090a0b0c0d0e0f + +* Chain m + * fingerprint: 00000000 + * chain code: 77997ca3588a1a34f3589279ea2962247abfe5277d52770a44c706378c710768 + * private: d70a59c2e68b836cc4bbe8bcae425169b9e2384f3905091e3d60b890e90cd92c + * public: 005c7289dc9f7f3ea1c8c2de7323b9fb0781f69c9ecd6de4f095ac89a02dc80577 +* Chain m/0H + * fingerprint: 6f5a9c0d + * chain code: 349a3973aad771c628bf1f1b4d5e071f18eff2e492e4aa7972a7e43895d6597f + * private: cd7630d7513cbe80515f7317cdb9a47ad4a56b63c3f1dc29583ab8d4cc25a9b2 + * public: 00cb8be6b256ce509008b43ae0dccd69960ad4f7ff2e2868c1fbc9e19ec3ad544b +* Chain m/0H/1H + * fingerprint: fde474d7 + * chain code: 2ee5ba14faf2fe9d7ab532451c2be3a0a5375c5e8c44fb31d9ad7edc25cda000 + * private: a95f97cfc1a61dd833b882c89d36a78a030ea6b2fbe3ae2a70e4f1fc9008d6b1 + * public: 00e9506455dce2526df42e5e4eb5585eaef712e5f9c6a28bf9fb175d96595ea872 +* Chain m/0H/1H/2H + * fingerprint: 6569dde7 + * chain code: e1897d5a96459ce2a3d294cb2a6a59050ee61255818c50e03ac4263ef17af084 + * private: 3d6cce04a9175929da907a90b02176077b9ae050dcef9b959fed978bb2200cdc + * public: 0018f008fcbc6d1cd8b4fe7a9eba00f6570a9da02a9b0005028cb2731b12ee4118 +* Chain m/0H/1H/2H/2H + * fingerprint: 1b7cce71 + * chain code: 1cccc84e2737cfe81b51fbe4c97bbdb000f6a76eddffb9ed03108fbff3ff7e4f + * private: 7ae7437efe0a3018999e6f00d72e810ebc50578dbf6728bfa1c7fe73501081a7 + * public: 00512e288a8ef4d869620dc4b06bb06ad2524b350dee5a39fcfeb708dbac65c25c +* Chain m/0H/1H/2H/2H/1000000000H + * fingerprint: de5dcb65 + * chain code: 8ccf15d55b1dda246b0c1bf3e979a471a82524c1bd0c1eaecccf00dde72168bb + * private: 7a59954d387abde3bc703f531f67d659ec2b8a12597ae82824547d7e27991e26 + * public: 00a077fcf5af53d210257d44a86eb2031233ac7237da220434ac01a0bebccc1919 ### Test vector 2 for secp256k1 Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542 * Chain m - * fpr: 00000000 - * chain: 60499f801b896d83179a4374aeb7822aaeaceaa0db1f85ee3e904c4defbd9689 - * prv: 4b03d6fc340455b363f51020ad3ecca4f0850280cf436c70c727923f6db46c3e - * pub: 03cbcaa9c98c877a26977d00825c956a238e8dddfbd322cce4f74b0b5bd6ace4a7 + * fingerprint: 00000000 + * chain code: 60499f801b896d83179a4374aeb7822aaeaceaa0db1f85ee3e904c4defbd9689 + * private: 4b03d6fc340455b363f51020ad3ecca4f0850280cf436c70c727923f6db46c3e + * public: 03cbcaa9c98c877a26977d00825c956a238e8dddfbd322cce4f74b0b5bd6ace4a7 * Chain m/0 - * fpr: bd16bee5 - * chain: f0909affaa7ee7abe5dd4e100598d4dc53cd709d5a5c2cac40e7412f232f7c9c - * prv: abe74a98f6c7eabee0428f53798f0ab8aa1bd37873999041703c742f15ac7e1e - * pub: 02fc9e5af0ac8d9b3cecfe2a888e2117ba3d089d8585886c9c826b6b22a98d12ea + * fingerprint: bd16bee5 + * chain code: f0909affaa7ee7abe5dd4e100598d4dc53cd709d5a5c2cac40e7412f232f7c9c + * private: abe74a98f6c7eabee0428f53798f0ab8aa1bd37873999041703c742f15ac7e1e + * public: 02fc9e5af0ac8d9b3cecfe2a888e2117ba3d089d8585886c9c826b6b22a98d12ea * Chain m/0/2147483647H - * fpr: 5a61ff8e - * chain: be17a268474a6bb9c61e1d720cf6215e2a88c5406c4aee7b38547f585c9a37d9 - * prv: 877c779ad9687164e9c2f4f0f4ff0340814392330693ce95a58fe18fd52e6e93 - * pub: 03c01e7425647bdefa82b12d9bad5e3e6865bee0502694b94ca58b666abc0a5c3b + * fingerprint: 5a61ff8e + * chain code: be17a268474a6bb9c61e1d720cf6215e2a88c5406c4aee7b38547f585c9a37d9 + * private: 877c779ad9687164e9c2f4f0f4ff0340814392330693ce95a58fe18fd52e6e93 + * public: 03c01e7425647bdefa82b12d9bad5e3e6865bee0502694b94ca58b666abc0a5c3b * Chain m/0/2147483647H/1 - * fpr: d8ab4937 - * chain: f366f48f1ea9f2d1d3fe958c95ca84ea18e4c4ddb9366c336c927eb246fb38cb - * prv: 704addf544a06e5ee4bea37098463c23613da32020d604506da8c0518e1da4b7 - * pub: 03a7d1d856deb74c508e05031f9895dab54626251b3806e16b4bd12e781a7df5b9 + * fingerprint: d8ab4937 + * chain code: f366f48f1ea9f2d1d3fe958c95ca84ea18e4c4ddb9366c336c927eb246fb38cb + * private: 704addf544a06e5ee4bea37098463c23613da32020d604506da8c0518e1da4b7 + * public: 03a7d1d856deb74c508e05031f9895dab54626251b3806e16b4bd12e781a7df5b9 * Chain m/0/2147483647H/1/2147483646H - * fpr: 78412e3a - * chain: 637807030d55d01f9a0cb3a7839515d796bd07706386a6eddf06cc29a65a0e29 - * prv: f1c7c871a54a804afe328b4c83a1c33b8e5ff48f5087273f04efa83b247d6a2d - * pub: 02d2b36900396c9282fa14628566582f206a5dd0bcc8d5e892611806cafb0301f0 + * fingerprint: 78412e3a + * chain code: 637807030d55d01f9a0cb3a7839515d796bd07706386a6eddf06cc29a65a0e29 + * private: f1c7c871a54a804afe328b4c83a1c33b8e5ff48f5087273f04efa83b247d6a2d + * public: 02d2b36900396c9282fa14628566582f206a5dd0bcc8d5e892611806cafb0301f0 * Chain m/0/2147483647H/1/2147483646H/2 - * fpr: 31a507b8 - * chain: 9452b549be8cea3ecb7a84bec10dcfd94afe4d129ebfd3b3cb58eedf394ed271 - * prv: bb7d39bdb83ecf58f2fd82b6d918341cbef428661ef01ab97c28a4842125ac23 - * pub: 024d902e1a2fc7a8755ab5b694c575fce742c48d9ff192e63df5193e4c7afe1f9c + * fingerprint: 31a507b8 + * chain code: 9452b549be8cea3ecb7a84bec10dcfd94afe4d129ebfd3b3cb58eedf394ed271 + * private: bb7d39bdb83ecf58f2fd82b6d918341cbef428661ef01ab97c28a4842125ac23 + * public: 024d902e1a2fc7a8755ab5b694c575fce742c48d9ff192e63df5193e4c7afe1f9c ### Test vector 2 for nist256p1 Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542 * Chain m - * fpr: 00000000 - * chain: 96cd4465a9644e31528eda3592aa35eb39a9527769ce1855beafc1b81055e75d - * prv: eaa31c2e46ca2962227cf21d73a7ef0ce8b31c756897521eb6c7b39796633357 - * pub: 02c9e16154474b3ed5b38218bb0463e008f89ee03e62d22fdcc8014beab25b48fa + * fingerprint: 00000000 + * chain code: 96cd4465a9644e31528eda3592aa35eb39a9527769ce1855beafc1b81055e75d + * private: eaa31c2e46ca2962227cf21d73a7ef0ce8b31c756897521eb6c7b39796633357 + * public: 02c9e16154474b3ed5b38218bb0463e008f89ee03e62d22fdcc8014beab25b48fa * Chain m/0 - * fpr: 607f628f - * chain: 84e9c258bb8557a40e0d041115b376dd55eda99c0042ce29e81ebe4efed9b86a - * prv: d7d065f63a62624888500cdb4f88b6d59c2927fee9e6d0cdff9cad555884df6e - * pub: 039b6df4bece7b6c81e2adfeea4bcf5c8c8a6e40ea7ffa3cf6e8494c61a1fc82cc + * fingerprint: 607f628f + * chain code: 84e9c258bb8557a40e0d041115b376dd55eda99c0042ce29e81ebe4efed9b86a + * private: d7d065f63a62624888500cdb4f88b6d59c2927fee9e6d0cdff9cad555884df6e + * public: 039b6df4bece7b6c81e2adfeea4bcf5c8c8a6e40ea7ffa3cf6e8494c61a1fc82cc * Chain m/0/2147483647H - * fpr: 946d2a54 - * chain: f235b2bc5c04606ca9c30027a84f353acf4e4683edbd11f635d0dcc1cd106ea6 - * prv: 96d2ec9316746a75e7793684ed01e3d51194d81a42a3276858a5b7376d4b94b9 - * pub: 02f89c5deb1cae4fedc9905f98ae6cbf6cbab120d8cb85d5bd9a91a72f4c068c76 + * fingerprint: 946d2a54 + * chain code: f235b2bc5c04606ca9c30027a84f353acf4e4683edbd11f635d0dcc1cd106ea6 + * private: 96d2ec9316746a75e7793684ed01e3d51194d81a42a3276858a5b7376d4b94b9 + * public: 02f89c5deb1cae4fedc9905f98ae6cbf6cbab120d8cb85d5bd9a91a72f4c068c76 * Chain m/0/2147483647H/1 - * fpr: 218182d8 - * chain: 7c0b833106235e452eba79d2bdd58d4086e663bc8cc55e9773d2b5eeda313f3b - * prv: 974f9096ea6873a915910e82b29d7c338542ccde39d2064d1cc228f371542bbc - * pub: 03abe0ad54c97c1d654c1852dfdc32d6d3e487e75fa16f0fd6304b9ceae4220c64 + * fingerprint: 218182d8 + * chain code: 7c0b833106235e452eba79d2bdd58d4086e663bc8cc55e9773d2b5eeda313f3b + * private: 974f9096ea6873a915910e82b29d7c338542ccde39d2064d1cc228f371542bbc + * public: 03abe0ad54c97c1d654c1852dfdc32d6d3e487e75fa16f0fd6304b9ceae4220c64 * Chain m/0/2147483647H/1/2147483646H - * fpr: 931223e4 - * chain: 5794e616eadaf33413aa309318a26ee0fd5163b70466de7a4512fd4b1a5c9e6a - * prv: da29649bbfaff095cd43819eda9a7be74236539a29094cd8336b07ed8d4eff63 - * pub: 03cb8cb067d248691808cd6b5a5a06b48e34ebac4d965cba33e6dc46fe13d9b933 + * fingerprint: 931223e4 + * chain code: 5794e616eadaf33413aa309318a26ee0fd5163b70466de7a4512fd4b1a5c9e6a + * private: da29649bbfaff095cd43819eda9a7be74236539a29094cd8336b07ed8d4eff63 + * public: 03cb8cb067d248691808cd6b5a5a06b48e34ebac4d965cba33e6dc46fe13d9b933 * Chain m/0/2147483647H/1/2147483646H/2 - * fpr: 956c4629 - * chain: 3bfb29ee8ac4484f09db09c2079b520ea5616df7820f071a20320366fbe226a7 - * prv: bb0a77ba01cc31d77205d51d08bd313b979a71ef4de9b062f8958297e746bd67 - * pub: 020ee02e18967237cf62672983b253ee62fa4dd431f8243bfeccdf39dbe181387f + * fingerprint: 956c4629 + * chain code: 3bfb29ee8ac4484f09db09c2079b520ea5616df7820f071a20320366fbe226a7 + * private: bb0a77ba01cc31d77205d51d08bd313b979a71ef4de9b062f8958297e746bd67 + * public: 020ee02e18967237cf62672983b253ee62fa4dd431f8243bfeccdf39dbe181387f ### Test vector 2 for ed25519 Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542 * Chain m - * fpr: 00000000 - * chain: ef70a74db9c3a5af931b5fe73ed8e1a53464133654fd55e7a66f8570b8e33c3b - * prv: 171cb88b1b3c1db25add599712e36245d75bc65a1a5c9e18d76f9f2b1eab4012 - * pub: 008fe9693f8fa62a4305a140b9764c5ee01e455963744fe18204b4fb948249308a + * fingerprint: 00000000 + * chain code: ef70a74db9c3a5af931b5fe73ed8e1a53464133654fd55e7a66f8570b8e33c3b + * private: 171cb88b1b3c1db25add599712e36245d75bc65a1a5c9e18d76f9f2b1eab4012 + * public: 008fe9693f8fa62a4305a140b9764c5ee01e455963744fe18204b4fb948249308a +* Chain m/0H + * fingerprint: 31981b50 + * chain code: 0b78a3226f915c082bf118f83618a618ab6dec793752624cbeb622acb562862d + * private: 1559eb2bbec5790b0c65d8693e4d0875b1747f4970ae8b650486ed7470845635 + * public: 0086fab68dcb57aa196c77c5f264f215a112c22a912c10d123b0d03c3c28ef1037 +* Chain m/0H/2147483647H + * fingerprint: 1e9411b1 + * chain code: 138f0b2551bcafeca6ff2aa88ba8ed0ed8de070841f0c4ef0165df8181eaad7f + * private: ea4f5bfe8694d8bb74b7b59404632fd5968b774ed545e810de9c32a4fb4192f4 + * public: 005ba3b9ac6e90e83effcd25ac4e58a1365a9e35a3d3ae5eb07b9e4d90bcf7506d +* Chain m/0H/2147483647H/1H + * fingerprint: fcadf38c + * chain code: 73bd9fff1cfbde33a1b846c27085f711c0fe2d66fd32e139d3ebc28e5a4a6b90 + * private: 3757c7577170179c7868353ada796c839135b3d30554bbb74a4b1e4a5a58505c + * public: 002e66aa57069c86cc18249aecf5cb5a9cebbfd6fadeab056254763874a9352b45 +* Chain m/0H/2147483647H/1H/2147483646H + * fingerprint: aca70953 + * chain code: 0902fe8a29f9140480a00ef244bd183e8a13288e4412d8389d140aac1794825a + * private: 5837736c89570de861ebc173b1086da4f505d4adb387c6a1b1342d5e4ac9ec72 + * public: 00e33c0f7d81d843c572275f287498e8d408654fdf0d1e065b84e2e6f157aab09b +* Chain m/0H/2147483647H/1H/2147483646H/2H + * fingerprint: 422c654b + * chain code: 5d70af781f3a37b829f0d060924d5e960bdc02e85423494afc0b1a41bbe196d4 + * private: 551d333177df541ad876a60ea71f00447931c0a9da16f227c11ea080d7391b8d + * public: 0047150c75db263559a70d5778bf36abbab30fb061ad69f69ece61a72b0cfa4fc0 + +### Test vector 2 for curve25519 + +Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542 + +* Chain m + * fingerprint: 00000000 + * chain code: b62c0c81a80a0ee16b977abb3677eb47549d0eef090f7a6c2b2010e739875e34 + * private: 088491f5b4dfafbe956de471f3db10e02d784bc76050ee3b7c3f11b9706d3730 + * public: 0060cc3b40567729af08757e1efe62536dc864a57ec582f98b96f484201a260c7a * Chain m/0H - * fpr: 31981b50 - * chain: 0b78a3226f915c082bf118f83618a618ab6dec793752624cbeb622acb562862d - * prv: 1559eb2bbec5790b0c65d8693e4d0875b1747f4970ae8b650486ed7470845635 - * pub: 0086fab68dcb57aa196c77c5f264f215a112c22a912c10d123b0d03c3c28ef1037 + * fingerprint: 75edaf13 + * chain code: 341f386e571229e8adc52b82e824532817a31a35ba49ae334424e7228d020eed + * private: 8e73218a1ba5c7b95e94b6e7cf7b37fb6240fb3b2ecd801402a4439da7067ee2 + * public: 007992b3f270ef15f266785fffb73246ad7f40d1fe8679b737fed0970d92cc5f39 * Chain m/0H/2147483647H - * fpr: 1e9411b1 - * chain: 138f0b2551bcafeca6ff2aa88ba8ed0ed8de070841f0c4ef0165df8181eaad7f - * prv: ea4f5bfe8694d8bb74b7b59404632fd5968b774ed545e810de9c32a4fb4192f4 - * pub: 005ba3b9ac6e90e83effcd25ac4e58a1365a9e35a3d3ae5eb07b9e4d90bcf7506d + * fingerprint: 5b26da66 + * chain code: 942cbec088b4ae92e8db9336025e9185fec0985a3da89d7a408bc2a4e18a8134 + * private: 29262b215c961bae20274588b33955c36f265c1f626df9feebb51034ce63c19d + * public: 002372feac417c38b833e1aba75f2420278122d698605b995cafc2fed7bb453d41 * Chain m/0H/2147483647H/1H - * fpr: fcadf38c - * chain: 73bd9fff1cfbde33a1b846c27085f711c0fe2d66fd32e139d3ebc28e5a4a6b90 - * prv: 3757c7577170179c7868353ada796c839135b3d30554bbb74a4b1e4a5a58505c - * pub: 002e66aa57069c86cc18249aecf5cb5a9cebbfd6fadeab056254763874a9352b45 + * fingerprint: f701c832 + * chain code: fe02397ae2ca71efe455f470fb23928baf026360a9e9090e21958f6fba9efc30 + * private: a4d2474bd98c5e9ff416f536697b89949627d6d2c384b81a86d29f1136f4c2d1 + * public: 00eca4fd0458d3f729b6218eda871b350fa8870a744caf6d30cd84dad2b9dd9c2d * Chain m/0H/2147483647H/1H/2147483646H - * fpr: aca70953 - * chain: 0902fe8a29f9140480a00ef244bd183e8a13288e4412d8389d140aac1794825a - * prv: 5837736c89570de861ebc173b1086da4f505d4adb387c6a1b1342d5e4ac9ec72 - * pub: 00e33c0f7d81d843c572275f287498e8d408654fdf0d1e065b84e2e6f157aab09b + * fingerprint: 6063347b + * chain code: b3b49d550e732ee629f4aeb4bf7213c3ae0f239fd10add513253cddbb8efb868 + * private: d3500d9b30529c51d92497eded1d68d29f60c630c45c61a481c185e574c6e5cf + * public: 00edaa3d381a2b02f40a80d69b2ce7ba7c3c4a9421744808857cd48c50d29b5868 * Chain m/0H/2147483647H/1H/2147483646H/2H - * fpr: 422c654b - * chain: 5d70af781f3a37b829f0d060924d5e960bdc02e85423494afc0b1a41bbe196d4 - * prv: 551d333177df541ad876a60ea71f00447931c0a9da16f227c11ea080d7391b8d - * pub: 0047150c75db263559a70d5778bf36abbab30fb061ad69f69ece61a72b0cfa4fc0 + * fingerprint: 86bf4fed + * chain code: f6ded904046e9758b9388dbf95ea5db837ab98b03b00e4db7009a8e3ac077685 + * private: e20fecd59312b63b37eee27714465aae1caa1c87840abd0d685ea88b3d598fdf + * public: 00aa705de68066e9534a238af35ea77c48016462a8aff358d22eaa6c7d5b034354 ### Test derivation retry for nist256p1 Seed (hex): 000102030405060708090a0b0c0d0e0f * Chain m - * fpr: 00000000 - * chain: beeb672fe4621673f722f38529c07392fecaa61015c80c34f29ce8b41b3cb6ea - * prv: 612091aaa12e22dd2abef664f8a01a82cae99ad7441b7ef8110424915c268bc2 - * pub: 0266874dc6ade47b3ecd096745ca09bcd29638dd52c2c12117b11ed3e458cfa9e8 + * fingerprint: 00000000 + * chain code: beeb672fe4621673f722f38529c07392fecaa61015c80c34f29ce8b41b3cb6ea + * private: 612091aaa12e22dd2abef664f8a01a82cae99ad7441b7ef8110424915c268bc2 + * public: 0266874dc6ade47b3ecd096745ca09bcd29638dd52c2c12117b11ed3e458cfa9e8 * Chain m/28578H - * fpr: be6105b5 - * chain: e94c8ebe30c2250a14713212f6449b20f3329105ea15b652ca5bdfc68f6c65c2 - * prv: 06f0db126f023755d0b8d86d4591718a5210dd8d024e3e14b6159d63f53aa669 - * pub: 02519b5554a4872e8c9c1c847115363051ec43e93400e030ba3c36b52a3e70a5b7 + * fingerprint: be6105b5 + * chain code: e94c8ebe30c2250a14713212f6449b20f3329105ea15b652ca5bdfc68f6c65c2 + * private: 06f0db126f023755d0b8d86d4591718a5210dd8d024e3e14b6159d63f53aa669 + * public: 02519b5554a4872e8c9c1c847115363051ec43e93400e030ba3c36b52a3e70a5b7 * Chain m/28578H/33941 - * fpr: 3e2b7bc6 - * chain: 9e87fe95031f14736774cd82f25fd885065cb7c358c1edf813c72af535e83071 - * prv: 092154eed4af83e078ff9b84322015aefe5769e31270f62c3f66c33888335f3a - * pub: 0235bfee614c0d5b2cae260000bb1d0d84b270099ad790022c1ae0b2e782efe120 + * fingerprint: 3e2b7bc6 + * chain code: 9e87fe95031f14736774cd82f25fd885065cb7c358c1edf813c72af535e83071 + * private: 092154eed4af83e078ff9b84322015aefe5769e31270f62c3f66c33888335f3a + * public: 0235bfee614c0d5b2cae260000bb1d0d84b270099ad790022c1ae0b2e782efe120 ### Test seed retry for nist256p1 Seed (hex): a7305bc8df8d0951f0cb224c0e95d7707cbdf2c6ce7e8d481fec69c7ff5e9446 * Chain m - * fpr: 00000000 - * chain: 7762f9729fed06121fd13f326884c82f59aa95c57ac492ce8c9654e60efd130c - * prv: 3b8c18469a4634517d6d0b65448f8e6c62091b45540a1743c5846be55d47d88f - * pub: 0383619fadcde31063d8c5cb00dbfe1713f3e6fa169d8541a798752a1c1ca0cb20 + * fingerprint: 00000000 + * chain code: 7762f9729fed06121fd13f326884c82f59aa95c57ac492ce8c9654e60efd130c + * private: 3b8c18469a4634517d6d0b65448f8e6c62091b45540a1743c5846be55d47d88f + * public: 0383619fadcde31063d8c5cb00dbfe1713f3e6fa169d8541a798752a1c1ca0cb20 ## Implementation * [Python implementation to generate test vectors](slip-0010/testvectors.py) +* [.NET Standard 2.0 Implementation](https://github.com/elucidsoft/dotnetstandard-bip32) +* [Swift implementation](https://github.com/radixdlt/babylon-wallet-ios/tree/main/RadixWallet/Cryptography/SLIP10) +* [Kotlin implementation](https://github.com/radixdlt/SLIP10-Android) ## References * [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) * [BIP-0039: Mnemonic code for generating deterministic keys](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) +* [SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes](https://github.com/satoshilabs/slips/blob/master/slip-0039.md) +* [RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)](https://datatracker.ietf.org/doc/html/rfc8032) +* [RFC 7748: Elliptic Curves for Security](https://datatracker.ietf.org/doc/html/rfc7748) diff --git a/slip-0010/testvectors.py b/slip-0010/testvectors.py index 97a92e03..ee0ac796 100644 --- a/slip-0010/testvectors.py +++ b/slip-0010/testvectors.py @@ -1,45 +1,30 @@ -#!/usr/bin/env python2 +#!/usr/bin/env python3 -import binascii import hashlib import hmac -import struct -import ecdsa -import ed25519 +from cryptography.hazmat.primitives import serialization +from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey +from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey +from cryptography.hazmat.primitives.asymmetric import ec from base58 import b58encode_check +SECP256K1_ORDER = int("FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141", 16) +SECP256R1_ORDER = int("FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551", 16) privdev = 0x80000000 -def int_to_string(x, pad): - result = ['\x00'] * pad - while x > 0: - pad -= 1 - ordinal = x & 0xFF - result[pad] = (chr(ordinal)) - x >>= 8 - return ''.join(result) - -def string_to_int(s): - result = 0 - for c in s: - if not isinstance(c, int): - c = ord(c) - result = (result << 8) + c - return result - # mode 0 - compatible with BIP32 private derivation -def seed2hdnode(seed, modifier, curve): +def seed2hdnode(seed, curve, modifier, curve_order): k = seed while True: h = hmac.new(modifier, seed, hashlib.sha512).digest() key, chaincode = h[:32], h[32:] - a = string_to_int(key) - if (curve == 'ed25519'): + a = int.from_bytes(key, 'big') + if (curve in ('ed25519', 'curve25519')): break - if (a < curve.order and a != 0): + if (a < curve_order and a != 0): break seed = h - #print 'RETRY seed: ' + binascii.hexlify(seed) + #print('RETRY seed: ' + seed.hex()) return (key, chaincode) def fingerprint(publickey): @@ -47,103 +32,115 @@ def fingerprint(publickey): return h[:4] def b58xprv(parent_fingerprint, private_key, chain, depth, childnr): - raw = ('\x04\x88\xad\xe4' + - chr(depth) + parent_fingerprint + int_to_string(childnr, 4) + - chain + '\x00' + private_key) - return b58encode_check(raw) + raw = (b'\x04\x88\xad\xe4' + + bytes([depth]) + parent_fingerprint + childnr.to_bytes(4, 'big') + + chain + b'\x00' + private_key) + return b58encode_check(raw).decode() def b58xpub(parent_fingerprint, public_key, chain, depth, childnr): - raw = ('\x04\x88\xb2\x1e' + - chr(depth) + parent_fingerprint + int_to_string(childnr, 4) + + raw = (b'\x04\x88\xb2\x1e' + + bytes([depth]) + parent_fingerprint + childnr.to_bytes(4, 'big') + chain + public_key) - return b58encode_check(raw) + return b58encode_check(raw).decode() def publickey(private_key, curve): if curve == 'ed25519': - sk = ed25519.SigningKey(private_key) - return '\x00' + sk.get_verifying_key().to_bytes() + sk = Ed25519PrivateKey.from_private_bytes(private_key) + key_encoding = serialization.Encoding.Raw + key_format = serialization.PublicFormat.Raw + prefix = b'\x00' + elif curve == 'curve25519': + sk = X25519PrivateKey.from_private_bytes(private_key) + key_encoding = serialization.Encoding.Raw + key_format = serialization.PublicFormat.Raw + prefix = b'\x00' else: - Q = string_to_int(private_key) * curve.generator - xstr = int_to_string(Q.x(), 32) - parity = Q.y() & 1 - return chr(2 + parity) + xstr + sk = ec.derive_private_key(int.from_bytes(private_key, 'big'), curve) + key_encoding = serialization.Encoding.X962 + key_format = serialization.PublicFormat.CompressedPoint + prefix = b'' + return prefix + sk.public_key().public_bytes(key_encoding, key_format) -def derive(parent_key, parent_chaincode, i, curve): +def derive(parent_key, parent_chaincode, i, curve, curve_order): assert len(parent_key) == 32 assert len(parent_chaincode) == 32 k = parent_chaincode if ((i & privdev) != 0): - key = '\x00' + parent_key + key = b'\x00' + parent_key else: key = publickey(parent_key, curve) - d = key + struct.pack('>L', i) + d = key + i.to_bytes(4, 'big') while True: h = hmac.new(k, d, hashlib.sha512).digest() key, chaincode = h[:32], h[32:] - if curve == 'ed25519': + if curve in ('ed25519', 'curve25519'): break - #print 'I: ' + binascii.hexlify(h) - a = string_to_int(key) - key = (a + string_to_int(parent_key)) % curve.order - if (a < curve.order and key != 0): - key = int_to_string(key, 32) + #print('I: ' + h.hex()) + a = int.from_bytes(key, 'big') + key = (a + int.from_bytes(parent_key, 'big')) % curve_order + if (a < curve_order and key != 0): + key = key.to_bytes(32, 'big') break - d = '\x01' + h[32:] + struct.pack('>L', i) - #print 'a failed: ' + binascii.hexlify(h[:32]) - #print 'RETRY: ' + binascii.hexlify(d) + d = b'\x01' + h[32:] + i.to_bytes(4, 'big') + #print('a failed: ' + h[:32].hex()) + #print('RETRY: ' + d.hex()) return (key, chaincode) def get_curve_info(curvename): if curvename == 'secp256k1': - return (ecdsa.curves.SECP256k1, 'Bitcoin seed') + return (ec.SECP256K1(), b'Bitcoin seed', SECP256K1_ORDER) if curvename == 'nist256p1': - return (ecdsa.curves.NIST256p, 'Nist256p1 seed') + return (ec.SECP256R1(), b'Nist256p1 seed', SECP256R1_ORDER) if curvename == 'ed25519': - return ('ed25519', 'ed25519 seed') + return ('ed25519', b'ed25519 seed', None) + if curvename == 'curve25519': + return ('curve25519', b'curve25519 seed', None) raise BaseException('unsupported curve: '+curvename) def show_testvector(name, curvename, seedhex, derivationpath): - curve, seedmodifier = get_curve_info(curvename) - master_seed = binascii.unhexlify(seedhex) - k,c = seed2hdnode(master_seed, seedmodifier, curve) + curve, seedmodifier, curve_order = get_curve_info(curvename) + master_seed = bytes.fromhex(seedhex) + k,c = seed2hdnode(master_seed, curve, seedmodifier, curve_order) p = publickey(k, curve) - fpr = '\x00\x00\x00\x00' + fpr = b'\x00\x00\x00\x00' path = 'm' - print "### "+name+" for "+curvename - print "Seed (hex): " + seedhex - print '* Chain ' + path - print ' * fpr: ' + binascii.hexlify(fpr) - print ' * chain: ' + binascii.hexlify(c) - print ' * prv: ' + binascii.hexlify(k) - print ' * pub: ' + binascii.hexlify(p) + print("### "+name+" for "+curvename) + print() + print("Seed (hex): " + seedhex) + print() + print('* Chain ' + path) + print(' * fingerprint: ' + fpr.hex()) + print(' * chain code: ' + c.hex()) + print(' * private: ' + k.hex()) + print(' * public: ' + p.hex()) depth = 0 for i in derivationpath: - if curve == 'ed25519': - # no public derivation for ed25519 + if curve in ('ed25519', 'curve25519'): + # no public derivation for ed25519 and curve25519 i = i | privdev fpr = fingerprint(p) depth = depth + 1 path = path + "/" + str(i & (privdev-1)) if ((i & privdev) != 0): path = path + "H" - k,c = derive(k, c, i, curve) + k,c = derive(k, c, i, curve, curve_order) p = publickey(k, curve) - print '* Chain ' + path - print ' * fpr: ' + binascii.hexlify(fpr) - print ' * chain: ' + binascii.hexlify(c) - print ' * prv: ' + binascii.hexlify(k) - print ' * pub: ' + binascii.hexlify(p) - #print b58xprv(fpr, kc, cc, depth, i) - #print b58xpub(fpr, pc, cc, depth, i) - print + print('* Chain ' + path) + print(' * fingerprint: ' + fpr.hex()) + print(' * chain code: ' + c.hex()) + print(' * private: ' + k.hex()) + print(' * public: ' + p.hex()) + #print(b58xprv(fpr, k, c, depth, i)) + #print(b58xpub(fpr, p, c, depth, i)) + print() def show_testvectors(name, curvenames, seedhex, derivationpath): for curvename in curvenames: show_testvector(name, curvename, seedhex, derivationpath) -curvenames = ['secp256k1', 'nist256p1', 'ed25519']; +curvenames = ['secp256k1', 'nist256p1', 'ed25519', 'curve25519']; show_testvectors("Test vector 1", curvenames, '000102030405060708090a0b0c0d0e0f', diff --git a/slip-0011.md b/slip-0011.md index fb8f6a6c..cbcd91a3 100644 --- a/slip-0011.md +++ b/slip-0011.md @@ -4,7 +4,7 @@ Number: SLIP-0011 Title: Symmetric encryption of key-value pairs using deterministic hierarchy Type: Standard -Status: Draft +Status: Final Authors: Pavol Rusnak Marek Palatinus Karel Bilek @@ -111,6 +111,10 @@ else: The result are the encrypted/decrypted blocks, concatenated together. +## Test Vectors + +Check [test_msg_cipherkeyvalue.py](https://github.com/trezor/python-trezor/blob/master/trezorlib/tests/device_tests/test_msg_cipherkeyvalue.py) for the test vectors. + ## References The algorithm is implemented in [TREZOR firmware](https://github.com/trezor/trezor-mcu/blob/master/firmware/fsm.c) (function `fsm_msgCipherKeyValue`) and its [emulator](https://github.com/trezor/trezor-emu/blob/master/trezor/machine.py#L781) (function `_cipher_keyvalue`). diff --git a/slip-0013.md b/slip-0013.md index 3e94ab08..d14063f6 100644 --- a/slip-0013.md +++ b/slip-0013.md @@ -4,7 +4,7 @@ Number: SLIP-0013 Title: Authentication using deterministic hierarchy Type: Standard -Status: Draft +Status: Final Authors: Pavol Rusnak Created: 2015-03-12 ``` @@ -49,7 +49,7 @@ The index is used so one can generate more keys corresponding to the same URI. 5. Set highest bits of numbers `A`, `B`, `C`, `D` to 1 (e.g. logical OR with 0x80000000) to harden -6. Derive the HD node `m/13'/A'/B'/C'/D'` according to BIP32. +6. Derive the HD node `m/13'/A'/B'/C'/D'` according to SLIP-0010. ### Worked example @@ -59,11 +59,11 @@ The index is used so one can generate more keys corresponding to the same URI. 3. `hash128` = `d0e2389d4c8394a9f3e32de01104bf6e` -4. `A` = 221831888, `B` = 160727884, `C` = 3007475, `D` = 247399441 +4. `A` = 2637750992, `B` = 2845082444, `C` = 3761103859, `D` = 1858012177 5. `A'` = 2637750992, `B'` = 2845082444, `C'` = 3761103859, `D'` = 4005495825 -6. `bip32 node path` = `m/2147483661/2637750992/2845082444/3761103859/4005495825` +6. `HD node path` = `m/2147483661/2637750992/2845082444/3761103859/4005495825` See a [Python example](https://github.com/trezor/python-trezor/blob/ca45019918bc4c54f1ace899a9acf397c8f4d92f/tests/test_msg_signidentity.py#L27). @@ -96,6 +96,6 @@ It's up to service operator to take this message and react in three possible way ## References -* [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) * [BIP-0043: Purpose Field for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) * [RFC 3986: Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986) +* [SLIP-0010: Universal private key derivation from master private key](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) diff --git a/slip-0014-addresses.md b/slip-0014-addresses.md deleted file mode 100644 index 87778084..00000000 --- a/slip-0014-addresses.md +++ /dev/null @@ -1,88 +0,0 @@ -# SLIP-0014: Addresses for various Coins and Chains - -Generated using [https://iancoleman.github.io/bip39/](https://iancoleman.github.io/bip39/) - -## Bitcoin - -`m/44'/0'/0'/0/i` - -index | address | public key | private key -------|------------------------------------|--------------------------------------------------------------------|------------ - 0 | 1JAd7XCBzGudGpJQSDSfpmJhiygtLQWaGL | 03c6d9cc725bb7e19c026df03bf693ee1171371a8eaf25f04b7a58f6befabcd38c | L1KjqxZkUwdXaKNL15F2jJZVZpgi2HkHPHGyqTrQNNegyZez3A7Z - 1 | 1GWFxtwWmNVqotUPXLcKVL2mUKpshuJYo | 02c651a011009e2c7e7b3ed2068857ca0a47cba35b73e06c32e3c06ef3aa67621d | KyBcuurcaJw6NqnZsmtpDqjbsS67PTXEZAK9QyFEDsyYjmNJJozj - 2 | 1Eni8JFS4yA2wJkicc3yx3QzCNzopLybCM | 03330236b68aa6fdcaca0ea72e11b360c84ed19a338509aa527b678a7ec9076882 | L3yYwqub7bYq6qKkPf9UAE7uuZYV8adAHvEaceXY9fKX8G7FDCoZ - 3 | 124dT55Jqpj9AKTyJnTX6G8RkUs7ReTzun | 03e6c684d1e5edffe2fc43d260eb19fea91754b92e90627df7f87e06fc12c6a485 | L2SNnZeTNHwgr9mayyHLZxmpyQN4SNbrxjBf9Rwq5Fvu2wwTm476 - 4 | 15T9DSqc6wjkPxcr2MNVSzF9JAePdvS3n1 | 03f54094da6a0b2e0799286268bb59ca7c83538e81c78e64f6333f40f9e0e222c0 | L4jzKXRhQXesPeUSUNi7EMHAEBFzwJuAkZsNi5tja9rLxgGajwPv - 5 | 1GA9u9TfCG7SWmKCveBumdA1TZpfom6ZdJ | 02a7a079c1ef9916b289c2ff21a992c808d0de3dfcf8a9f163205c5c9e21f55d5c | L1N67rzEMn6fqvhkFeDnt11LMxYdGZtGQgdYVuASNpmQRawgbJEN - 6 | 1PogPE3bXc84abzEuM2rJEZf2vCbCEZzXz | 0369cb2f81b3ec4f0132cf1ac88f09332439773b3f1579bb6557717d0b720c7226 | L3Y5pgT2ewKqdqh6kcGDQ7YHFoW5Vh4xErrPqb4Yjb5re9QYZw7D - 7 | 176U2WABbj4h5PCrxE963wmxzXd2Mw6bP4 | 03dca76f16e6dd87396c5cdae1af1515b60d104fba881cd7591fe6fa60ef3aeabd | L2RpVajejxusxUXqLHTFJAyp1nzJnT2xuJpfm7Uah4GGUHz7XD58 - 8 | 1HRZDR7CmLnq59w6mtzNa7SHtVWPSxdgKA | 0346978a895e75eb498dbf4aff8fa334e6994db1b34a4f2576adc9225415eb9548 | Kx8nBDjAkXkykD62AF8XjP8W5Z4a79iZC8Z7axyDWXsZTcn5agzM - 9 | 1MPdvYLzcekvEzAB7DmiHa1oU8Foh4KUw8 | 02c3ffb6e3456bda85d17845a764f23a54aad4fd39260d5c8da6493134713862ca | L1xWyxmCkjsB2Z9wnjoZ5TGabeg8KbpZt1PjgVsKA9pn3L7JCiTs - -## Bitcoin Testnet - -`m/44'/1'/0'/0/i` - -index | address | public key | private key -------|------------------------------------|--------------------------------------------------------------------|------------ - 0 | mvbu1Gdy8SUjTenqerxUaZyYjmveZvt33q | 030e669acac1f280d1ddf441cd2ba5e97417bf2689e4bbec86df4f831bf9f7ffd0 | cPigoY3hubxpXad1t5WmxpcQpmezLeCcbpA7EpyhDofFnein2wF5 - 1 | mopZWqZZyQc3F2Sy33cvDtJchSAMsnLi7b | 0294e3e5e77e22eea0e4c0d30d89beb4db7f69b4bf1ae709e411d6a06618b8f852 | cVN8eHRQh8r9THM2Mu5HCSjx6cfVdssqGL1KeiCKBwUouyf6K5F5 - 2 | mgswWyysmViMqYmn5XEj1pVz7rVUftVEBP | 03f5008445568548bd745a3dedccc6048969436bf1a49411f60938ff1938941f14 | cUCiXe6qNE43rEJkSR9e1Tt37W5gQmmGeBiSmXzDbZgxbs5Z5nvK - 3 | momtnzR3XqXgDSsFmd8gkGxUiHZLde3RmA | 029ad0b9519779c540b34fa8d11d24d14a5475546bfa28c7de50573d22a503ce21 | cTAi8RAF2htyUn3F921npbuJLSVdYfpfwqjwLEAPkqvFxLAF716k - 4 | moE1dVYvebvtaMuNdXQKvu4UxUftLmS1Gt | 0313a443e806f25052ac7363adc689fcfa72893f2a51a35ab5e096ed5e6cd8517e | cUmGFJMq5Vkh4rjKHe4J4S5adJH1E8xFJJ2ZARBSZNBVzYwj1RvH - 5 | muXZYKRJFJ2qPegzV2GEzLqHxngJpzMrmT | 02e35cca50cb2626212bce8fdfb988bb33f303b15536e9f84f018e63045dbb84ac | cRHMG1RjgVWTdUNEgDD5oNEvQvBAha5N3YntnT7rC8yekePLGQwR - 6 | mnY26FLTzfC94mDoUcyDJh1GVE3LuAUMbs | 0344e14b3da8f5fe77a5465d0f8fe089d64ed5517d1f1f989edd00f530938a2c22 | cS9rFFu8douRgweuQKLdF4QXpS3H1UeoNxZWTt6K874nt4sy56HX - 7 | mgV9Z3YuSbxGb2b2Y1T6VCqtU2osui7vhG | 035169c4d6a36b6c4f3e210f46d329efa1cb7a67ffce7d62062d4a8a17c23756e1 | cQ1Uh9vXLhaoEgPGUEGMoWACpzrVesmB8G4KdK5vZBnLBifyB29Q - 8 | miLqfMwzis98J5vkjjhTiXVsrkAYwuxmts | 03260dc4925b14addb52b4e62c698b99d2318f3d909477a081ae8e5d94dc3c66d8 | cPwi3WVwjgr422fBeLa22UHwRkQEMZqoJBjevuosqd25yyYekEkF - 9 | mhAacBq3SnXEpoxzEwKqfnQz1iYjxmGg9V | 02b3397d76b093624981b3c3a279c79496d16820f821528b9e403bdfc162b34c3c | cRkkmKXgTmq3Je2B71Rn4HQxeo2hEqvtUeQ5r4Q7eKr5qtq6vzu4 - -## Dash - -`m/44'/5'/0'/0/i` - -index | address | public key | private key -------|------------------------------------|--------------------------------------------------------------------|------------ - 0 | XdTw4G5AWW4cogGd7ayybyBNDbuB45UpgH | 02936f80cac2ba719ddb238646eb6b78a170a55a52a9b9f08c43523a4a6bd5c896 | XFiosCguxccAvHDasUYWU4mmx4PABR4dDQhk99k8D2N9cKeTRnYq - 1 | XbDjZajDR6Y9uB23GBrMUKX4Lci3PqPXT1 | 027e1c93904ae880921decff4042cee3901c984fb89f33b39e9cf1db544002e6ba | XKCAE7yNMpRyczUehbX1aMQabUqd8g5Hx2FobmkZ2QVUmoRFiKGJ - 2 | XimA3jRAgsksN937ibHrMny6gYy3RChjFs | 0233e06386e60f9f02fcd2b73f1868cdf5a6dfdcebcd6ddc2b337b25feb1053532 | XBscYDmgeg6xuK9tUZk5itHGYRqs5VqpUcu4Yn5An3TJrfz7xfgb - 3 | Xhxyt3pKQKa2HkePA8tP3NSjkWXFgdsjzH | 02012cf694423b0bba8a54596f4923c1c8d74458f884f8d611c7305ca6d25320d1 | XEkU65os4QjrLYy8HKxfEYtFyuy7RqMAGpHDEgSdMjFWtDFDRPid - 4 | XfcGasDgKu2JvVS38b9pWUcfY8yfCaH9dF | 029aaeefff9ae8ea408de41747ac634b49cb90e111b1ac623c3c742dc5ebe42737 | XFaR8NpQjY8wWrUPNmedwvXyFQTJyj75k1jfYh4Bs2sfBzmfTRFz - 5 | XuBYWmRi7q2KrajtXxpmWC5vKMyqCeKMAj | 0211311f13a287ad81adf710cc837f66b2ce432070752c376861d08c7b91eda67e | XEBxR4AExnhCEBXLvQGX9KYg1TwSfngN4CgnzMeY6zeAgLQYxnYH - 6 | XvYXR1LCedCJBXDVuye7wevrmR5ASaQdEq | 03a526d4aa1bd23e3a4d21646b25901d30734b09413eb6462f9251707db0da0f0a | XEo8Haet4xLXrPiEbmRogGXjs8UyeowRUXHrfKkF45m32w18u7hK - 7 | XgrVDtp8X2C3hEPcwcNY31UPvWGfHSBytG | 02c13197de985aff1847a0b0b6fa41d750cdcf3dee03b3e209729ea4a5c99341a7 | XBdQ7YnpdKqyuA5RH2RzwfWnACKgpTJg9STbxrGFmgoKG7URhYGN - 8 | XteBgFFTpGz2NNedqsZEcqPz5m31AQBBYz | 0260ec3beb9f51b4de98fe7f4c13814077603b6211c9e6acdd1c7b0cc796450d79 | XK13VgxcbF3h9Hr9g5bn1uuhtuaNsfEbcFzQxUsowVVeV7LKGQRy - 9 | XpkAwbPzQFdLmuAeYs7BLJfHfXL163QatG | 027df3bcb58f397d99ec944ae74b15f15bf6ab24190e11e7d3fc164107eb36258b | XEq1Rvq4AQKNm52pqiaeUnyG6DZ9Zf6EvrmaZ23Xx2aVrUPYkq6b - -## Litecoin - -`m/44'/2'/0'/0/i` - -index | address | public key | private key -------|------------------------------------|--------------------------------------------------------------------|------------ - 0 | LcubERmHD31PWup1fbozpKuiqjHZ4anxcL | 021239d8b20ad1f83d34383e82075d0e11f7a98d06f9e015b56cff61db1e4f8c25 | T5wTndHdQ1sDnQhApMnDrbQV56PEnjZeRMq9ao2aRJALyUdjdExP - 1 | LVWBmHBkCGNjSPHucvL2PmnuRAJnucmRE6 | 02c88e3d1c97fe3ff8eb2f51c37ca66cbfabb6404ddf8158478fae3b8a90e98035 | TAZnJTHBjN7UoXV6v1aGhVkgq7kBbtXe9h1oKND7LHGS4FC5wnKQ - 2 | LUQ91iCfoayy3G3rrFtmF6eVzKQyFSdi2T | 02df4513e0faae40c6e1dbca606c4fe6c3e22d00a30024ea2b01b7da0097a97f82 | T3bxs7ZtsnCrXn1dhYJeRBu2FkLFLf8oyhiahMkhdJwxiDVAUP1e - 3 | LNk7cQvGW5LPgkii3RUX7YQWtX6HjmLbB4 | 03a69bec3139474eec35f7c87d59f8b6ec37423dbcfce5c5d090bd26de604a2b70 | T3SQgQ4byehx5ayT98PE7ZDPr68taysoW2Hm6FyDNWuyKiBpWa3L - 4 | Laz1nYzJwrGcaZDEERENpNVbgte1n3vWLJ | 03ed59a1f1b1e2af17ae00ff373a3cedd8b7bd3c4723a76d469e52ec8caba09337 | T5HGaZgAs35kWheKDFDhdHz1sqNgo3FitUaeBegugamfFxRSjYga - 5 | LcBMCi1mQ71LLvFqN2TMgEgomoc9yqEFzg | 0279224038c76ffcfd1a95ca5d93bcb15c426e18776362fcddd76ff7cc60b9a25d | TAdPGc81ANgVhvEVyK5K5DQee4DEv1dDeXAUCBqn6ocPx5Wdi7qc - 6 | LfyFtx6XekFZ54gATTjrgeFFmMqAboZwvi | 0284b369982fba3be2ef729a96b13806b2372c6f3b5209c44fd5ce29c0a1eca976 | T8WecZVp58aYSvtaw8PAhhx2hxMRBUuvT25dtDyk4x6vE97PHnAY - 7 | Le2twPHqkDEiPrY4uZw6Ufes3e7t4VUZ68 | 032e030b64a7de06fc972b7fb82ca4392c4e5a535ce942f32d6b660b1d58b5176c | T5ojDJgMa3QYZkst9po2B6P5SXyP4vFuBFZBhvyp8E9Ek74yCzoE - 8 | LViaNcv7TTQv8yFFvBnjC63dwVNL3e21c1 | 026b9d73e88ecbcd55a68e0a8e6c651e2543075b85fc6e85386e1a8009e9a55abe | T7YQp9UidMzNSRJHPpCVWeANPpDK5Nz1MhfWuP5sy6YFUB5VJiat - 9 | LfritJSaLhmsRDaZwYSnfpUMNTA8kTweHa | 030ad428a32f117f21cbf581630858b28baa957cb475ac43b7536b1a1da3d00293 | T3WSZzJmXPZB7Mr5vAQ5qmi2b9zFww5oLHqUcyy7371d9ujZb8Kb - -## Ethereum - -`m/44'/60'/0'/0/i` - -index | address | public key | private key -------|--------------------------------------------|--------------------------------------------------------------------|------------ - 0 | 0x73d0385F4d8E00C5e6504C6030F47BF6212736A8 | 03ad8e7eb4f3a7d1a409fa7bdc7b79d8840fe746d3fa9ee17fee4f84631ec1430b | 759e46263f1505994d11142d70027975c9b9fef15489b09bd987eb8a31aba0db - 1 | 0xFA01a39f8Abaeb660c3137f14A310d0b414b2A15 | 03ddeae7da4e54757d3f3038315344709971849a971d2619797d9b8574e373ae9b | 616883a861adaab932634c283e294bcfdc9797757984bc4a15a9484ada947177 - 2 | 0x574BbB36871bA6b78E27f4B4dCFb76eA0091880B | 039d09121b995a1f7fe5d30996f6a66fff4688f8eee096faea2957e1fe53923860 | 4f74b7bb78734476e41caa28a397493260103f4ccf0b8a14fe340da5a8a7e22c - 3 | 0xba98D6a5ac827632E3457De7512d211e4ff7e8bD | 0307b32cc46360c9acf750da7acf7dce918aee97dd383236248c9c79b8efbd98fc | a02122e1ac06fb63da2fd293706c91b5839108de765dc9ce3e2d3fb1573bafd4 - 4 | 0x1f815D67006163E502b8eD4947C91ad0A62De24e | 03d26a9f183bbb531e140ab3d87bca361706b4c4be7c731e29160cab833e7a9282 | f686b6033ef11ad995ff93b240bd28b04c6dc3a24cb35861b642f7ba969564e0 - 5 | 0xf69619a3dCAA63757A6BA0AF3628f5F6C42c50d2 | 02ae8cef29ef6d2ad9b98af746589743c510e4b49784ec1181a079b4b1df3c5211 | 945f0973cd011048b56bb87887ad782c72b09ff181f4af97ad033581ea009a74 - 6 | 0xA8664Df3D5E74BE57c19fC7005BBcd0F5328041e | 023ed2881ee76991dafd40e33df96a88a5e929869635cdfc261e947d1e9ca31be9 | 7226389c1de87a3498234ad49e00e48060609b839616de313b341c6245142993 - 7 | 0xf2252f414e727d652d5a488fE4BFf7e64478737F | 03b765e9b8ba13ffb45e69f038bf1506aa2ecf1f1824c88551f98e93026c06e6b4 | 640dfbf3d433c548d0a1b9d0d5dc824f72d631cdfca0902ad16788b6b3081067 - 8 | 0x5708Ae081b48ad7bA8c50ca3D4fa0238d544D6FA | 031acf557e85d59e0305b8b79d4a5cc5077d09811206be208c00c4e457e7017ac1 | 728a3bd762ac7a25d58eafcd3240bb783304cd323e78b5967a8ecdb4c1e1a982 - 9 | 0x12eF7dfb86f6D5E3e0521b72472ca02D2a3814F4 | 02c9f2bf6bbf6244eec9866ad6eb6dec628cbf71f2e2cb77c25d72baeca2c32f61 | 9ee5234da5069eede6135c0f684fd0b633504a04614c740aef47a57a28c0384d diff --git a/slip-0014.md b/slip-0014.md index 6fbc8865..e2938d68 100644 --- a/slip-0014.md +++ b/slip-0014.md @@ -4,7 +4,7 @@ Number: SLIP-0014 Title: Stress Test Deterministic Wallet Type: Informational -Status: Draft +Status: Active Authors: Pavol Rusnak Created: 2015-01-12 ``` @@ -21,72 +21,293 @@ are quite a lot of different types of transactions in the network. In order to simplify testing of transaction history we came up with the idea to create a special xpub that will contain these various types of transactions. -For more coins and their addresses (not listed in this document) see [slip-0014-addresses.md](slip-0014-addresses.md) +For more coins and their addresses (not listed in this document) see [addresses.md](slip-0014/addresses.md) -## Wallet +## Bitcoin Wallets -### Bitcoin Legacy P2PKH (BIP44) +root node: ``` mnemonic: all all all all all all all all all all all all -m/0/i account: +xprv9s21ZrQH143K2rbkN6QpF6ZB3QQcyJA6aYbagMp6i8y831VVvpfcWNWqg5DM6GxSn66UDQUrgRgQEsLPZJC3APkPsQjxB7ndNMgj5R5HLmo +``` + +### Bitcoin: Legacy / P2PKH / BIP44 + +``` +m/44'/0'/0' + xprv9xj9UhHNKHr6kJKJBVj82ZxFrbfhczBDUHyVj7kHGAiZqAeUenz2JhrphnMMYVKcWcVPFJESngtKsVa4FYEvFfWUTtZThCoZdwDeS9qQnqm xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy -m/i account: -xprvA1xn6h6qAwinYq5P37sJsEY39ntjzDpueQPAX9dBQcU81dqZrfBJBVMVuyqnVrMRViPxriZkdLd2vTtpnJaoaomJ67JBk3G1xMagp89w2XX -xpub6Ex8WCdj1KH5mK9r99QKENUmhpjEPgYm1dJmKY2nxx16tSAiQCVYjHfymFdzfpYDAHGtWYTif7WkUKLMULRJFPeV1hvEbeXqrM11K85yPjp +pkh([5c9e228d/44'/0'/0']xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy/0/*)#vzuemqzv +pkh([5c9e228d/44'/0'/0']xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy/1/*)#akecx4j5 + +pkh([5c9e228d/44'/0'/0']xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy/<0;1>/*)#t3pfpx6p ``` -[link to blockchain.info](https://blockchain.info/xpub/xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy) +[link to btc1.trezor.io](https://btc1.trezor.io/xpub/xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy) #### Addresses -index | address | private key -------|------------------------------------|----------------------------------------------------- - 0 | 1JAd7XCBzGudGpJQSDSfpmJhiygtLQWaGL | L1KjqxZkUwdXaKNL15F2jJZVZpgi2HkHPHGyqTrQNNegyZez3A7Z - 1 | 1GWFxtwWmNVqotUPXLcKVL2mUKpshuJYo | KyBcuurcaJw6NqnZsmtpDqjbsS67PTXEZAK9QyFEDsyYjmNJJozj - 2 | 1Eni8JFS4yA2wJkicc3yx3QzCNzopLybCM | L3yYwqub7bYq6qKkPf9UAE7uuZYV8adAHvEaceXY9fKX8G7FDCoZ - 3 | 124dT55Jqpj9AKTyJnTX6G8RkUs7ReTzun | L2SNnZeTNHwgr9mayyHLZxmpyQN4SNbrxjBf9Rwq5Fvu2wwTm476 - 4 | 15T9DSqc6wjkPxcr2MNVSzF9JAePdvS3n1 | L4jzKXRhQXesPeUSUNi7EMHAEBFzwJuAkZsNi5tja9rLxgGajwPv - 5 | 1GA9u9TfCG7SWmKCveBumdA1TZpfom6ZdJ | L1N67rzEMn6fqvhkFeDnt11LMxYdGZtGQgdYVuASNpmQRawgbJEN - 6 | 1PogPE3bXc84abzEuM2rJEZf2vCbCEZzXz | L3Y5pgT2ewKqdqh6kcGDQ7YHFoW5Vh4xErrPqb4Yjb5re9QYZw7D - 7 | 176U2WABbj4h5PCrxE963wmxzXd2Mw6bP4 | L2RpVajejxusxUXqLHTFJAyp1nzJnT2xuJpfm7Uah4GGUHz7XD58 - 8 | 1HRZDR7CmLnq59w6mtzNa7SHtVWPSxdgKA | Kx8nBDjAkXkykD62AF8XjP8W5Z4a79iZC8Z7axyDWXsZTcn5agzM - 9 | 1MPdvYLzcekvEzAB7DmiHa1oU8Foh4KUw8 | L1xWyxmCkjsB2Z9wnjoZ5TGabeg8KbpZt1PjgVsKA9pn3L7JCiTs +index | address | private key +------|--------------------------------------|------------ + 0 | `1JAd7XCBzGudGpJQSDSfpmJhiygtLQWaGL` | `L1KjqxZkUwdXaKNL15F2jJZVZpgi2HkHPHGyqTrQNNegyZez3A7Z` + 1 | `1GWFxtwWmNVqotUPXLcKVL2mUKpshuJYo` | `KyBcuurcaJw6NqnZsmtpDqjbsS67PTXEZAK9QyFEDsyYjmNJJozj` + 2 | `1Eni8JFS4yA2wJkicc3yx3QzCNzopLybCM` | `L3yYwqub7bYq6qKkPf9UAE7uuZYV8adAHvEaceXY9fKX8G7FDCoZ` + 3 | `124dT55Jqpj9AKTyJnTX6G8RkUs7ReTzun` | `L2SNnZeTNHwgr9mayyHLZxmpyQN4SNbrxjBf9Rwq5Fvu2wwTm476` + 4 | `15T9DSqc6wjkPxcr2MNVSzF9JAePdvS3n1` | `L4jzKXRhQXesPeUSUNi7EMHAEBFzwJuAkZsNi5tja9rLxgGajwPv` + 5 | `1GA9u9TfCG7SWmKCveBumdA1TZpfom6ZdJ` | `L1N67rzEMn6fqvhkFeDnt11LMxYdGZtGQgdYVuASNpmQRawgbJEN` + 6 | `1PogPE3bXc84abzEuM2rJEZf2vCbCEZzXz` | `L3Y5pgT2ewKqdqh6kcGDQ7YHFoW5Vh4xErrPqb4Yjb5re9QYZw7D` + 7 | `176U2WABbj4h5PCrxE963wmxzXd2Mw6bP4` | `L2RpVajejxusxUXqLHTFJAyp1nzJnT2xuJpfm7Uah4GGUHz7XD58` + 8 | `1HRZDR7CmLnq59w6mtzNa7SHtVWPSxdgKA` | `Kx8nBDjAkXkykD62AF8XjP8W5Z4a79iZC8Z7axyDWXsZTcn5agzM` + 9 | `1MPdvYLzcekvEzAB7DmiHa1oU8Foh4KUw8` | `L1xWyxmCkjsB2Z9wnjoZ5TGabeg8KbpZt1PjgVsKA9pn3L7JCiTs` -### Bitcoin Segwit P2SH (BIP49) +### Bitcoin: Legacy SegWit / P2SH-P2WPKH / BIP49 ``` -mnemonic: all all all all all all all all all all all all +m/49'/0'/0' -m/0/i account: xprv9yVyTu1dmn2ekCQYnV4FhXrVNbnJKBbAwXgDaqmhcjyxHaz31UTdLYGqdwFCBv8LA1BafJUWeiQ6J1uUSU5ebGK6GmcFiJsb3bYfpfpLyva xpub6CVKsQYXc9awxgV1tWbG4foDvdcnieK2JkbpPEBKB5WwAPKBZ1mstLbKVB4ov7QzxzjaxNK6EfmNY5Jsk2cG26EVcEkycGW4tchT2dyUhrx -m/i account: -xprvA1o8joUTA2L813mNWCDBP1DAeDx9tFZZfzFpA9CzMBTRvfwC7mQ36SjRNFrpvK9qnbXaxX2iohqztZsFaq5qNCRvMmRUSr3dWxoNq8pNtmz -xpub6EnV9K1LzPtRDXqqcDkBk99uCFneHiHR3DBQxXcbuWzQoUGLfJiHeF3uDW1JZH3ZG7mr4TuNtPbgLYwEibEkcDcnQkQksZi7jm3eY8PqKFv +yprvAJLEmZgYvTa8bVbfcqqsucwzYZvkFoafreCSNEfazkMqLgoGG8dBxbvyf9CnBpnFZeJPQn557NkeBJX3AAVfPVzh97JgJDh5KKcKDCEbbzm +ypub6XKbB5DSkq8Royg8isNtGktj6bmEfGJXDs83Ad5CZ5tpDV8QofwSWQFTWP2Pv24vNdrPhquehL7vRMvSTj2GpKv6UaTQCBKZALm6RJAmxG6 + +sh(wpkh([5c9e228d/49'/0'/0']xpub6CVKsQYXc9awxgV1tWbG4foDvdcnieK2JkbpPEBKB5WwAPKBZ1mstLbKVB4ov7QzxzjaxNK6EfmNY5Jsk2cG26EVcEkycGW4tchT2dyUhrx/0/*))#jkfqtdfw +sh(wpkh([5c9e228d/49'/0'/0']xpub6CVKsQYXc9awxgV1tWbG4foDvdcnieK2JkbpPEBKB5WwAPKBZ1mstLbKVB4ov7QzxzjaxNK6EfmNY5Jsk2cG26EVcEkycGW4tchT2dyUhrx/1/*))#8h8knju3 + +sh(wpkh([5c9e228d/49'/0'/0']xpub6CVKsQYXc9awxgV1tWbG4foDvdcnieK2JkbpPEBKB5WwAPKBZ1mstLbKVB4ov7QzxzjaxNK6EfmNY5Jsk2cG26EVcEkycGW4tchT2dyUhrx/<0;1>/*))#a49xle58 +``` + +[link to btc1.trezor.io](https://btc1.trezor.io/xpub/ypub6XKbB5DSkq8Royg8isNtGktj6bmEfGJXDs83Ad5CZ5tpDV8QofwSWQFTWP2Pv24vNdrPhquehL7vRMvSTj2GpKv6UaTQCBKZALm6RJAmxG6) + +#### Addresses + +index | address | private key +------|--------------------------------------|------------ + 0 | `3L6TyTisPBmrDAj6RoKmDzNnj4eQi54gD2` | `L1xY6RmpnGn7r5bhQCrDXFTqVGFY7e1p62Rw5yw6bNzKUzRLD1tw` + 1 | `3GMMgFUQiYTYQhuHQuZfQoXPvW3GPqfGmD` | `Kx2KfpCa6Aewb1zxPBt5ex8MFNKk3SrJaeYRVjNRCUg7zALXDy8w` + 2 | `3BKbtvJtLSjnSoGUYTeQ17tMKTuyqbUV7P` | `L3L1oYXQbPmgpgvyB6BzM5PihfAvZfi3pFMZfppVQscM1zQokdtg` + 3 | `3Dyf1D6pVR6ZAQYN1th6ehgS1uqgGk1TGh` | `L3w2TxQpwJCkEhM96o3DTFTC1Pv67kpQ4Nwp4jD9n8oHvFQ7KsSB` + 4 | `33wLRyxHFtrXLF7Aun38Dctw5QyiBdruK2` | `L1K9dsgY46AgcGsNYdqJCEQbKBvvSuRz1MrWu3ATgyRaq3vVprtn` + 5 | `32pKKUD5TKyqb4kzPorJnY8XhiLaHBKni1` | `L2ET81wAcxm4vU22w7mEU2EC9bf5aNr1XaMNA1B9GkMHr5YT99a5` + 6 | `3NCRi181wMB1v9gPyms9WDruKemBfrE9rQ` | `KzyfHMxPYBmwgy3pJtqj2UK6xbqzA8TDZUdapXMCQidk2zLg1zVC` + 7 | `32d6ze9Be4J45ERomziXxGWXxLobAAQq85` | `L3i75zyVQKi5ZBjHMghQSgCx1HYQnYjZh1N2Y6gBLciEa7mqYqvN` + 8 | `3FNTNKoAcXDUTUSNAtVTcvAehwQLyJSmP9` | `L5SXQN7L1KNFTVurn4xaevP494RYRWNSqVUE2cUFMFnpQTSPHNYG` + 9 | `3L55P4LZsyKYUw5Aqy6DPky6ySw3g34TQS` | `Kzi8YhDogNJKVis8r5z4Lq8M6rSNudAG5p63pF45i9fQQb3KCAeC` + +### Bitcoin: SegWit / P2WPKH / BIP84 + +``` +m/84'/0'/0' + +xprv9zE7ynHaxhGKkZyFCd2jEJYmiZ5X2tdvYHhkVKsHBybspXSX4GTeD9BcR2b4PmvKShEQtFh6L8pRyu8SxPdumPhaQiBUQQiCSsEhnaadaYm +xpub6DDUPHpUo4pcy43iJeZjbSVWGav1SMMmuWdMHiGtkK8rhKmfbomtkwW6GKs1GGAKehT6QRocrmda3WWxXawpjmwaUHfFRXuKrXSapdckEYF + +zprvAdteb7dRG4MHTAMUsLbyeUjn4VNQv8cvNWkC47f3wzMdvj4yZanmTGVtTSWEPbEAFyU2PCtDFTXXkUMaPnTwMs4n9PaKaEMAzKMzZguzwHG +zpub6rszzdAK6RuafeRwyN8z1cgWcXCuKbLmjjfnrW4fWKtcoXQ8787214pNJjnBG5UATyghuNzjn6Lfp5k5xymrLFJnCy46bMYJPyZsbpFGagT + +wpkh([5c9e228d/84'/0'/0']xpub6DDUPHpUo4pcy43iJeZjbSVWGav1SMMmuWdMHiGtkK8rhKmfbomtkwW6GKs1GGAKehT6QRocrmda3WWxXawpjmwaUHfFRXuKrXSapdckEYF/0/*)#l4dc6ccr +wpkh([5c9e228d/84'/0'/0']xpub6DDUPHpUo4pcy43iJeZjbSVWGav1SMMmuWdMHiGtkK8rhKmfbomtkwW6GKs1GGAKehT6QRocrmda3WWxXawpjmwaUHfFRXuKrXSapdckEYF/1/*)#wpge8dgm + +wpkh([5c9e228d/84'/0'/0']xpub6DDUPHpUo4pcy43iJeZjbSVWGav1SMMmuWdMHiGtkK8rhKmfbomtkwW6GKs1GGAKehT6QRocrmda3WWxXawpjmwaUHfFRXuKrXSapdckEYF/<0;1>/*)#tdqj4vr6 +``` + +[link to btc1.trezor.io](https://btc1.trezor.io/xpub/zpub6rszzdAK6RuafeRwyN8z1cgWcXCuKbLmjjfnrW4fWKtcoXQ8787214pNJjnBG5UATyghuNzjn6Lfp5k5xymrLFJnCy46bMYJPyZsbpFGagT) + +#### Addresses + +index | address | private key +------|----------------------------------------------|------------ +0 | `bc1qannfxke2tfd4l7vhepehpvt05y83v3qsf6nfkk` | `Kycvq5CiKukoBWJjN3WEduoHnE6pKWrQPM7XuiLEkbgLuQgEzZPu` +1 | `bc1q7e6qu5smalrpgqrx9k2gnf0hgjyref5p36ru2m` | `Kz4p2JcERCPT6LADX5pDmV1XNtnskABTaCFQb1hyNuWDqY43HuwE` +2 | `bc1q5f2lvs7t29wv8nwssse6a4f6099sc3nagchqyc` | `KxXM7XXwK8G1yZpw5o8tqaA5Ria5R3WxX78zbdPdg3Ncp9mgHiur` +3 | `bc1q6hr68ewf72l6r7cj6ut286x0xkwg5706jq450u` | `KyGV2ApxE2gLmCukQbjKAKKrcGKBCGSRy2itnyXDoxcdjsdd9vXH` +4 | `bc1q7zql632newlfv9rt269jyxdn30370rh4kp23pd` | `L5gUrfBMftHbbn6tUaHNHkNcPxpz6niJsdCubAMHTaxU759RDY6N` +5 | `bc1qfcjv620stvtzjeelg26ncgww8ks49zy8lracjz` | `L3YbRwxjxLx9SwcKYyaKXWPtR3pqbPdzMjaTHv6oi62jETv6VNvC` +6 | `bc1quqgq44wq0zjh6d920zs42nsy4n4ev5vt8nxke4` | `L1i1MqdvaTpcaPaHXfgMkxLU7Mq6DZHRzs54AmdAYNstE4vRRT2i` +7 | `bc1qunyzxr3gfcg7ggxp5vpxwm3q7t3xc52rcaupu4` | `KzkvQCu5ERcFcd6HBicdcDEom3MEaP3ptRLeHqnG6X1LU3jj7vjh` +8 | `bc1q2glg28yag4rdgrd0hj5ntdvva8cgrjdsku5prc` | `KyQf4uHNM1eskde2jJ7XwrXDe8TD9DAML5UTp3uxA7uzbWSY1NzZ` +9 | `bc1q9z4cdmrgtfjsp34dmtvha98shje83jjn2t27z5` | `L5o7HpPciFxK9QrJu2tWg6aVTK89KjLHizHPwwAfqVX2qyzxqmrB` + +### Bitcoin: Taproot / P2TR / BIP86 + +``` +m/86'/0'/0' + +xprv9xwmiZmq343K7HjUZAPMQ51qhFy8vKHeTYWApWMgkTp9LFtrRqkam7p5mwDVcXiaK97CMumfGTqmSgxpWE2yb9LTxmbT1Cnrvq4dYthBjxm +xpub6Bw885JisRbcKmowfBvMmCxaFHodKn1VpmRmctmJJoM8D4DzyP4qJv8ZdD9V9r3SSGjmK2KJEDnvLH6f1Q4HrobEvnCeKydNvf1eir3RHZk + +tr([5c9e228d/86'/0'/0']xpub6Bw885JisRbcKmowfBvMmCxaFHodKn1VpmRmctmJJoM8D4DzyP4qJv8ZdD9V9r3SSGjmK2KJEDnvLH6f1Q4HrobEvnCeKydNvf1eir3RHZk/0/*)#d8jj22qr +tr([5c9e228d/86'/0'/0']xpub6Bw885JisRbcKmowfBvMmCxaFHodKn1VpmRmctmJJoM8D4DzyP4qJv8ZdD9V9r3SSGjmK2KJEDnvLH6f1Q4HrobEvnCeKydNvf1eir3RHZk/1/*)#unhnhlsm + +tr([5c9e228d/86'/0'/0']xpub6Bw885JisRbcKmowfBvMmCxaFHodKn1VpmRmctmJJoM8D4DzyP4qJv8ZdD9V9r3SSGjmK2KJEDnvLH6f1Q4HrobEvnCeKydNvf1eir3RHZk/<0;1>/*)#4swej4wz +``` + +[link to btc1.trezor.io](https://btc1.trezor.io/xpub/tr(xpub6Bw885JisRbcKmowfBvMmCxaFHodKn1VpmRmctmJJoM8D4DzyP4qJv8ZdD9V9r3SSGjmK2KJEDnvLH6f1Q4HrobEvnCeKydNvf1eir3RHZk)) + +#### Addresses + +index | address | private key +------|------------------------------------------------------------------|------------ +0 | `bc1ptxs597p3fnpd8gwut5p467ulsydae3rp9z75hd99w8k3ljr9g9rqx6ynaw` | TBD +1 | `bc1plca7n9vs7d906nwlqyvk0d0jxnxss6x7w3x2y879quuvj8xn3p3s7vrrl2` | TBD +2 | `bc1pks4em3l8vg4zyk5xpcmgygh7elkhu03z3fqj48a2a2lv948cn4hsyltl3h` | TBD +3 | `bc1pvlme5mvcme0mqvfxknqr4mmcajthd9c9vqwknfghgvnsdt0ghtyquf66nq` | TBD +4 | `bc1pu4kdwq4jvpk3psqt6tw38fax7l20xj8y6gtzdgm9dj2amgy6t77sn420ak` | TBD +5 | `bc1p4w7pr3hx7ufuwpl7wj8z70kcdgu3uz5rnunhqv242629xskngyhstt8kny` | TBD +6 | `bc1p6rna8q8jpqj88pc0na5y4c2t574xrr6r4vfl7pw3zfmt0fyvyweskhh52w` | TBD +7 | `bc1pfqpkg5evfvqu0yjczwrm8vr8dzxmg8cpr8t5fw0whcv8r68tvx0swws8nt` | TBD +8 | `bc1pqveghnerewvk8frrs9s4ha5ta8yzycu5zfdmez4jp4dxkdvpaspqenr5dy` | TBD +9 | `bc1pkef3scnk7prtlpklpk586u3n3fvhe4hv2lvmggf8dx7sdwk6l6pq7j6u8q` | TBD + +## Bitcoin Testnet Wallets + +root node: + +``` +mnemonic: all all all all all all all all all all all all + +tprv8ZgxMBicQKsPdfqH2fGKQkBAMXpqCpC6v6WhYnEZC7TbpcEavC1N27tHbFP16eLm9XdFDW6cqnGChit8gWXyyT1zQ3xFqUWgHTS9XBQw3j5 ``` +### Bitcoin Testnet: Legacy / P2PKH / BIP44 + +``` +m/44'/1'/0' + +tprv8gdjtqr3TjNXgxpdi4LurDeG1Z8rQR2cGXYbaifKAPypiaF8hG5k5XxT7bTsjdkN9ERUkLVb47tvJ7sYRsJrkbbFf2UTRqAkkGRcaWEhRuY +tpubDDKn3FtHc74CaRrRbi1WFdJNaaenZkDWqq9NsEhcafnDZ4VuKeuLG2aKHm5SuwuLgAhRkkfHqcCxpnVNSrs5kJYZXwa6Ud431VnevzzzK3U + +pkh([5c9e228d/44'/1'/0']tpubDDKn3FtHc74CaRrRbi1WFdJNaaenZkDWqq9NsEhcafnDZ4VuKeuLG2aKHm5SuwuLgAhRkkfHqcCxpnVNSrs5kJYZXwa6Ud431VnevzzzK3U/0/*)#k65gljcw +pkh([5c9e228d/44'/1'/0']tpubDDKn3FtHc74CaRrRbi1WFdJNaaenZkDWqq9NsEhcafnDZ4VuKeuLG2aKHm5SuwuLgAhRkkfHqcCxpnVNSrs5kJYZXwa6Ud431VnevzzzK3U/1/*)#8w3fz8gk + +pkh([5c9e228d/44'/1'/0']tpubDDKn3FtHc74CaRrRbi1WFdJNaaenZkDWqq9NsEhcafnDZ4VuKeuLG2aKHm5SuwuLgAhRkkfHqcCxpnVNSrs5kJYZXwa6Ud431VnevzzzK3U/<0;1>/*)#jlq3k5tw +``` + +[link to tbtc1.trezor.io](https://tbtc1.trezor.io/xpub/tpubDDKn3FtHc74CaRrRbi1WFdJNaaenZkDWqq9NsEhcafnDZ4VuKeuLG2aKHm5SuwuLgAhRkkfHqcCxpnVNSrs5kJYZXwa6Ud431VnevzzzK3U) + +#### Addresses + +index | address | private key +------|--------------------------------------|------------ + 0 | `mvbu1Gdy8SUjTenqerxUaZyYjmveZvt33q` | `cPigoY3hubxpXad1t5WmxpcQpmezLeCcbpA7EpyhDofFnein2wF5` + 1 | `mopZWqZZyQc3F2Sy33cvDtJchSAMsnLi7b` | `cVN8eHRQh8r9THM2Mu5HCSjx6cfVdssqGL1KeiCKBwUouyf6K5F5` + 2 | `mgswWyysmViMqYmn5XEj1pVz7rVUftVEBP` | `cUCiXe6qNE43rEJkSR9e1Tt37W5gQmmGeBiSmXzDbZgxbs5Z5nvK` + 3 | `momtnzR3XqXgDSsFmd8gkGxUiHZLde3RmA` | `cTAi8RAF2htyUn3F921npbuJLSVdYfpfwqjwLEAPkqvFxLAF716k` + 4 | `moE1dVYvebvtaMuNdXQKvu4UxUftLmS1Gt` | `cUmGFJMq5Vkh4rjKHe4J4S5adJH1E8xFJJ2ZARBSZNBVzYwj1RvH` + 5 | `muXZYKRJFJ2qPegzV2GEzLqHxngJpzMrmT` | `cRHMG1RjgVWTdUNEgDD5oNEvQvBAha5N3YntnT7rC8yekePLGQwR` + 6 | `mnY26FLTzfC94mDoUcyDJh1GVE3LuAUMbs` | `cS9rFFu8douRgweuQKLdF4QXpS3H1UeoNxZWTt6K874nt4sy56HX` + 7 | `mgV9Z3YuSbxGb2b2Y1T6VCqtU2osui7vhG` | `cQ1Uh9vXLhaoEgPGUEGMoWACpzrVesmB8G4KdK5vZBnLBifyB29Q` + 8 | `miLqfMwzis98J5vkjjhTiXVsrkAYwuxmts` | `cPwi3WVwjgr422fBeLa22UHwRkQEMZqoJBjevuosqd25yyYekEkF` + 9 | `mhAacBq3SnXEpoxzEwKqfnQz1iYjxmGg9V` | `cRkkmKXgTmq3Je2B71Rn4HQxeo2hEqvtUeQ5r4Q7eKr5qtq6vzu4` + +### Bitcoin Testnet: Legacy SegWit / P2SH-P2WPKH / BIP49 + +``` +m/49'/1'/0' + +tprv8fbPeVsyzhdBvmTfb8BShTevk7eHVig91hJ3FUHqCXPFMxyMytfYDFLZvLc6C6xvbFRsa26tZXFLDLHigKKwZ1wbHMX9cFfQ2HHQh63C3k3 +tpubDCHRnuvE95JrpEVTUmr36sK3K9ADf3s3aztpXzL8coBeCTE8cHV8PjxS6SjWJM3GfPn798gyEa3dRPgjoUDSuNfuC9xz4PHznwKEk2XL7X1 + +uprv8zRexAYu9PAfn4enRUy4uYkRv5njSLfdvopG2sBiaXm8R4nbEYq6qJzhwYZgC1cqztYgKVhT2Bbt6cuHQ1jxMFdC9hDaCAUtJ1M45hTgJAA +upub5DR1Mg5nykixzYjFXWW5GghAU7dDqoPVJ2jrqFbL8sJ7Hs7jn69MP7KBnnmxn88GeZtnH8PRKV9w5MMSFX8AdEAoXY8Qd8BJPoXtpMeHMxJ + +sh(wpkh([5c9e228d/49'/1'/0']tpubDCHRnuvE95JrpEVTUmr36sK3K9ADf3s3aztpXzL8coBeCTE8cHV8PjxS6SjWJM3GfPn798gyEa3dRPgjoUDSuNfuC9xz4PHznwKEk2XL7X1/0/*))#qfh8hjq8 +sh(wpkh([5c9e228d/49'/1'/0']tpubDCHRnuvE95JrpEVTUmr36sK3K9ADf3s3aztpXzL8coBeCTE8cHV8PjxS6SjWJM3GfPn798gyEa3dRPgjoUDSuNfuC9xz4PHznwKEk2XL7X1/1/*))#4ge30d4c + +sh(wpkh([5c9e228d/49'/1'/0']tpubDCHRnuvE95JrpEVTUmr36sK3K9ADf3s3aztpXzL8coBeCTE8cHV8PjxS6SjWJM3GfPn798gyEa3dRPgjoUDSuNfuC9xz4PHznwKEk2XL7X1/<0;1>/*))#egxlxhl0 +``` + +[link to tbtc1.trezor.io](https://tbtc1.trezor.io/xpub/upub5DR1Mg5nykixzYjFXWW5GghAU7dDqoPVJ2jrqFbL8sJ7Hs7jn69MP7KBnnmxn88GeZtnH8PRKV9w5MMSFX8AdEAoXY8Qd8BJPoXtpMeHMxJ) + +#### Addresses + +index | address | private key +------|---------------------------------------|------------ + 0 | `2N4Q5FhU2497BryFfUgbqkAJE87aKHUhXMp` | `cRgRJFubBbGF7mrYxbtVfYvRTw7nTuwAgCxQxW8sz7J3GUaFDpXy` + 1 | `2Mt7P2BAfE922zmfXrdcYTLyR7GUvbwSEns` | `cNzuaocakTkP3uTfFeyxJaatdFFEi3eEXSeckjrPubeEtLc6LgKN` + 2 | `2N6aUMgQk8y1zvoq6FeWFyotyj75WY9BGsu` | `cRFggMzpii7ZyrnvBaqyq1DE3Aw7yxeT2ZjaJ48GRzcWZYegWaxE` + 3 | `2NA7tbZWM9BcRwBuebKSQe2xbhhF1paJwBM` | `cQEuKiCruVH89JimwRT7LkjPTJKDPRU5FLrzEoEUQqRDJbvVeEaV` + 4 | `2N8RZMzvrUUnpLmvACX9ysmJ2MX3GK5jcQM` | `cUBFS7oSvLg5Lt3jx148obE4dPc3EU8hiwta11LXJipYHE1xD79m` + 5 | `2MvUUSiQZDSqyeSdofKX9KrSCio1nANPDTe` | `cUfaGYiJKGBNawCzm7q4xbCzr3dwpTckdaMLxiNrEHoxQZWCGA6h` + 6 | `2NBXaWu1HazjoUVgrXgcKNoBLhtkkD9Gmet` | `cNzV3JvVCSPsyh34NveJ5YCSE65QWyJNSTGr5LsMtEzgXmsncos5` + 7 | `2N791Ttf89tMVw2maj86E1Y3VgxD9Mc7PU7` | `cNu1yCSQZuUo3qweP73EUu1peVh29xchhwbyBuqWgcAoho2AX9sE` + 8 | `2NCJmwEq8GJm8t8GWWyBXAfpw7F2qZEVP5Y` | `cQjPz5n3UMGY6f2ZTY4EfC5mF7qpcrBXQfFW23xNNxTsUCc4pAse` + 9 | `2NEgW71hWKer2XCSA8ZCC2VnWpB77L6bk68` | `cPb7wNHh9eQqECVdGFCLGTKkmdUjyk2FRdJspBAbKaNAvstZzNzZ` + +### Bitcoin Testnet: SegWit / P2WPKH / BIP84 + +``` +m/84'/1'/0' + +tprv8fs8xTNozVNnBjpLwdox39a8dNqR86VDbVtYDFtJk7HCbSrQDpW4ctKSz9f7J6MTYiHhRANPjvknG2RN5XtxaKmMdW18WUvZiQhHX1s8jmt +tpubDCZB6sR48s4T5Cr8qHUYSZEFCQMMHRg8AoVKVmvcAP5bRw7ArDKeoNwKAJujV3xCPkBvXH5ejSgbgyN6kREmF7sMd41NdbuHa8n1DZNxSMg + +vprv9KXfZnieHrTjtLCacMPCTKm8yK8K1LUDRivyn3g5W82xheUrj8qBs1dj2ZaHHufJMzXJv7ZWfFTt2beVWvizAo8ZNBPygJZYFrpaJAwg3nA +vpub5YX1yJFY8E236pH3iNvCpThsXLxoQoC4nwraaS5h4TZwaSp1Gg9SQoxCsrumxjh7nZRQQkNfH29TEDeMvAZVmD3rpmsDnFc5Sj4JgJG6m4b + +wpkh([5c9e228d/84'/1'/0']tpubDCZB6sR48s4T5Cr8qHUYSZEFCQMMHRg8AoVKVmvcAP5bRw7ArDKeoNwKAJujV3xCPkBvXH5ejSgbgyN6kREmF7sMd41NdbuHa8n1DZNxSMg/0/*)#rn0zejch +wpkh([5c9e228d/84'/1'/0']tpubDCZB6sR48s4T5Cr8qHUYSZEFCQMMHRg8AoVKVmvcAP5bRw7ArDKeoNwKAJujV3xCPkBvXH5ejSgbgyN6kREmF7sMd41NdbuHa8n1DZNxSMg/1/*)#j82ry8g0 + +wpkh([5c9e228d/84'/1'/0']tpubDCZB6sR48s4T5Cr8qHUYSZEFCQMMHRg8AoVKVmvcAP5bRw7ArDKeoNwKAJujV3xCPkBvXH5ejSgbgyN6kREmF7sMd41NdbuHa8n1DZNxSMg/<0;1>/*)#egs8kz3g +``` + +[link to tbtc1.trezor.io](https://tbtc1.trezor.io/xpub/vpub5YX1yJFY8E236pH3iNvCpThsXLxoQoC4nwraaS5h4TZwaSp1Gg9SQoxCsrumxjh7nZRQQkNfH29TEDeMvAZVmD3rpmsDnFc5Sj4JgJG6m4b) + +#### Addresses + +index | address | private key +------|----------------------------------------------|------------ +0 | `tb1qkvwu9g3k2pdxewfqr7syz89r3gj557l3uuf9r9` | `cPSW1uTU2dmrJTgFoiAoZva3iZfyhjdT5y8agNzpMKa4c7qFPgrG` +1 | `tb1qldlynaqp0hy4zc2aag3pkenzvxy65saesxw3wd` | `cRyA1t3w1ytsAiDKsvdeePqESnQBKk8TbftWUPkAGQ4utCZ3Dg42` +2 | `tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu` | `cSskN3UgpZpMSc828a3EZYocJt1XBdEuPaCqkGh6WFa9yxRxN3vs` +3 | `tb1qtxe2hdle9he8hc2xds7yl2m8zutjksv02jf0er` | `cSGF69RZV9Q3kMRRmruArTHr21eSGZ1N1NJAFR7bx29PQLhYq22v` +4 | `tb1qglrv8xrtf68udd5pxj2pxyq5s7lynq20h9nq2w` | `cQjQZvK1kGQBTRMs7Ei5UybGM28qWTUMUrPy41NovrvC6BbcqqK4` +5 | `tb1qds6ygc07t7d8prjs60qnx0nv4gexx9heyx8rek` | `cRJVMp8dUK7ABt6FcxVz3kLLHr2bh4tHeYiZttGibnGSZHsERxDE` +6 | `tb1q86udlgffezp9kgjvqlfah7a6c8dpepamm43yea` | `cW7FNz2pYQchTZHccRQkYZyEEAFB2VyxRBuuwnNGkNoa75jzrRLz` +7 | `tb1q503m8pxyvf7ypurcvwv2kp0ajyjumsjqk55n3f` | `cTX4ewf6JzypdZ4ipLKV4dBCBjyTdHwQ7bgNZDYXduG889te2CoM` +8 | `tb1qg805w4uhsz3sy9stasdx2rkwp4haf446m8ker9` | `cTZX79TBoyzkGjMRAN7AfzUURD7iCjBw6ZPYxHVW4vMSeX8rHyhN` +9 | `tb1qy2f6mkfa3aaecqz2s2xr0utf6edza7qz4h37y6` | `cTpLEpKdrSKsrRjKguU2PKxbKNKPuTvTvFAYGi9X1AMzsoKwiDaH` + +### Bitcoin Testnet: Taproot / P2TR / BIP86 + +``` +m/86'/1'/0' + +tprv8fS6YLYKZhcFQovUKifZpMGn4oGmtS9sNoL4jokEMEYsJWQyZ2s6hTfd1amgKc7PVHdyfkdRgJL7S2DnRtrKczyUq6ZPXWqg5RmFKC51jzh +tpubDC88gkaZi5HvJGxGDNLADkvtdpni3mLmx6vr2KnXmWMG8zfkBRggsxHVBkUpgcwPe2KKpkyvTJCdXHb1UHEWE64vczyyPQfHr1skBcsRedN + +tr([5c9e228d/86'/1'/0']tpubDC88gkaZi5HvJGxGDNLADkvtdpni3mLmx6vr2KnXmWMG8zfkBRggsxHVBkUpgcwPe2KKpkyvTJCdXHb1UHEWE64vczyyPQfHr1skBcsRedN/0/*)#4rqwxvej +tr([5c9e228d/86'/1'/0']tpubDC88gkaZi5HvJGxGDNLADkvtdpni3mLmx6vr2KnXmWMG8zfkBRggsxHVBkUpgcwPe2KKpkyvTJCdXHb1UHEWE64vczyyPQfHr1skBcsRedN/1/*)#yh90mef2 + +tr([5c9e228d/86'/1'/0']tpubDC88gkaZi5HvJGxGDNLADkvtdpni3mLmx6vr2KnXmWMG8zfkBRggsxHVBkUpgcwPe2KKpkyvTJCdXHb1UHEWE64vczyyPQfHr1skBcsRedN/<0;1>/*)#rlla6vx8 +``` + +[link to tbtc1.trezor.io](https://tbtc1.trezor.io/xpub/tr(tpubDC88gkaZi5HvJGxGDNLADkvtdpni3mLmx6vr2KnXmWMG8zfkBRggsxHVBkUpgcwPe2KKpkyvTJCdXHb1UHEWE64vczyyPQfHr1skBcsRedN)) + #### Addresses -index | address | private key -------|------------------------------------|----------------------------------------------------- - 0 | 3L6TyTisPBmrDAj6RoKmDzNnj4eQi54gD2 | L1xY6RmpnGn7r5bhQCrDXFTqVGFY7e1p62Rw5yw6bNzKUzRLD1tw - 1 | 3GMMgFUQiYTYQhuHQuZfQoXPvW3GPqfGmD | Kx2KfpCa6Aewb1zxPBt5ex8MFNKk3SrJaeYRVjNRCUg7zALXDy8w - 2 | 3BKbtvJtLSjnSoGUYTeQ17tMKTuyqbUV7P | L3L1oYXQbPmgpgvyB6BzM5PihfAvZfi3pFMZfppVQscM1zQokdtg - 3 | 3Dyf1D6pVR6ZAQYN1th6ehgS1uqgGk1TGh | L3w2TxQpwJCkEhM96o3DTFTC1Pv67kpQ4Nwp4jD9n8oHvFQ7KsSB - 4 | 33wLRyxHFtrXLF7Aun38Dctw5QyiBdruK2 | L1K9dsgY46AgcGsNYdqJCEQbKBvvSuRz1MrWu3ATgyRaq3vVprtn - 5 | 32pKKUD5TKyqb4kzPorJnY8XhiLaHBKni1 | L2ET81wAcxm4vU22w7mEU2EC9bf5aNr1XaMNA1B9GkMHr5YT99a5 - 6 | 3NCRi181wMB1v9gPyms9WDruKemBfrE9rQ | KzyfHMxPYBmwgy3pJtqj2UK6xbqzA8TDZUdapXMCQidk2zLg1zVC - 7 | 32d6ze9Be4J45ERomziXxGWXxLobAAQq85 | L3i75zyVQKi5ZBjHMghQSgCx1HYQnYjZh1N2Y6gBLciEa7mqYqvN - 8 | 3FNTNKoAcXDUTUSNAtVTcvAehwQLyJSmP9 | L5SXQN7L1KNFTVurn4xaevP494RYRWNSqVUE2cUFMFnpQTSPHNYG - 9 | 3L55P4LZsyKYUw5Aqy6DPky6ySw3g34TQS | Kzi8YhDogNJKVis8r5z4Lq8M6rSNudAG5p63pF45i9fQQb3KCAeC +index | address | private key +------|------------------------------------------------------------------|------------ +0 | `tb1pswrqtykue8r89t9u4rprjs0gt4qzkdfuursfnvqaa3f2yql07zmq8s8a5u` | TBD +1 | `tb1p8tvmvsvhsee73rhym86wt435qrqm92psfsyhy6a3n5gw455znnpqm8wald` | TBD +2 | `tb1p537ddhyuydg5c2v75xxmn6ac64yz4xns2x0gpdcwj5vzzzgrywlqlqwk43` | TBD +3 | `tb1pdsepw2hky9etm9d3yfumyq9g25xwys6d0jysstaaymgc6nheggasgamqts` | TBD +4 | `tb1p7dh7sgd570satc42lfsverp00x97gg7u2xu539ea4xt2mwh2p70q48dg3r` | TBD +5 | `tb1puyst6yj0x3w5z253k5xt0crk2zjy36g0fzhascd4wknxfwv9h9lszyhefk` | TBD +6 | `tb1pz9mehv82d3ujcw3zhqfn2pvlfu6ayzcm936tv9vu32ca0dsymlxs8nhr3m` | TBD +7 | `tb1ppq3xlfze03f0wzp8unyyz4le2fkpx62urz4wppnaty25c2adwljquymj9d` | TBD +8 | `tb1pxveqzq6hgy0dwdehtlhplgrtvu7t83hfr9gkhaxxtjucmwefr2psc49t6a` | TBD +9 | `tb1pwfygp66acq6c3uyuqtjcmmkaahfw543elpyrtfav8dkpv7uy3sxqvkv0j9` | TBD ## References - [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) - [BIP-0039: Mnemonic code for generating deterministic keys](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) - [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) +- [BIP-0049: Derivation scheme for P2WPKH-nested-in-P2SH based accounts](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki) +- [BIP-0084: Derivation scheme for P2WPKH based accounts](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) +- [BIP-0086: Key Derivation for Single Key P2TR Outputs](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki) diff --git a/slip-0014/addresses.md b/slip-0014/addresses.md new file mode 100644 index 00000000..5794f354 --- /dev/null +++ b/slip-0014/addresses.md @@ -0,0 +1,122 @@ +# SLIP-0014: Addresses for various Coins and Chains + +Generated using [https://iancoleman.github.io/bip39/](https://iancoleman.github.io/bip39/) + +## Bitcoin + +`m/44'/0'/0'/0/i` + +index | address | public key | private key +------|--------------------------------------|----------------------------------------------------------------------|------------ + 0 | `1JAd7XCBzGudGpJQSDSfpmJhiygtLQWaGL` | `03c6d9cc725bb7e19c026df03bf693ee1171371a8eaf25f04b7a58f6befabcd38c` | `L1KjqxZkUwdXaKNL15F2jJZVZpgi2HkHPHGyqTrQNNegyZez3A7Z` + 1 | `1GWFxtwWmNVqotUPXLcKVL2mUKpshuJYo` | `02c651a011009e2c7e7b3ed2068857ca0a47cba35b73e06c32e3c06ef3aa67621d` | `KyBcuurcaJw6NqnZsmtpDqjbsS67PTXEZAK9QyFEDsyYjmNJJozj` + 2 | `1Eni8JFS4yA2wJkicc3yx3QzCNzopLybCM` | `03330236b68aa6fdcaca0ea72e11b360c84ed19a338509aa527b678a7ec9076882` | `L3yYwqub7bYq6qKkPf9UAE7uuZYV8adAHvEaceXY9fKX8G7FDCoZ` + 3 | `124dT55Jqpj9AKTyJnTX6G8RkUs7ReTzun` | `03e6c684d1e5edffe2fc43d260eb19fea91754b92e90627df7f87e06fc12c6a485` | `L2SNnZeTNHwgr9mayyHLZxmpyQN4SNbrxjBf9Rwq5Fvu2wwTm476` + 4 | `15T9DSqc6wjkPxcr2MNVSzF9JAePdvS3n1` | `03f54094da6a0b2e0799286268bb59ca7c83538e81c78e64f6333f40f9e0e222c0` | `L4jzKXRhQXesPeUSUNi7EMHAEBFzwJuAkZsNi5tja9rLxgGajwPv` + 5 | `1GA9u9TfCG7SWmKCveBumdA1TZpfom6ZdJ` | `02a7a079c1ef9916b289c2ff21a992c808d0de3dfcf8a9f163205c5c9e21f55d5c` | `L1N67rzEMn6fqvhkFeDnt11LMxYdGZtGQgdYVuASNpmQRawgbJEN` + 6 | `1PogPE3bXc84abzEuM2rJEZf2vCbCEZzXz` | `0369cb2f81b3ec4f0132cf1ac88f09332439773b3f1579bb6557717d0b720c7226` | `L3Y5pgT2ewKqdqh6kcGDQ7YHFoW5Vh4xErrPqb4Yjb5re9QYZw7D` + 7 | `176U2WABbj4h5PCrxE963wmxzXd2Mw6bP4` | `03dca76f16e6dd87396c5cdae1af1515b60d104fba881cd7591fe6fa60ef3aeabd` | `L2RpVajejxusxUXqLHTFJAyp1nzJnT2xuJpfm7Uah4GGUHz7XD58` + 8 | `1HRZDR7CmLnq59w6mtzNa7SHtVWPSxdgKA` | `0346978a895e75eb498dbf4aff8fa334e6994db1b34a4f2576adc9225415eb9548` | `Kx8nBDjAkXkykD62AF8XjP8W5Z4a79iZC8Z7axyDWXsZTcn5agzM` + 9 | `1MPdvYLzcekvEzAB7DmiHa1oU8Foh4KUw8` | `02c3ffb6e3456bda85d17845a764f23a54aad4fd39260d5c8da6493134713862ca` | `L1xWyxmCkjsB2Z9wnjoZ5TGabeg8KbpZt1PjgVsKA9pn3L7JCiTs` + +## Bitcoin Testnet + +`m/44'/1'/0'/0/i` + +index | address | public key | private key +------|--------------------------------------|----------------------------------------------------------------------|------------ + 0 | `mvbu1Gdy8SUjTenqerxUaZyYjmveZvt33q` | `030e669acac1f280d1ddf441cd2ba5e97417bf2689e4bbec86df4f831bf9f7ffd0` | `cPigoY3hubxpXad1t5WmxpcQpmezLeCcbpA7EpyhDofFnein2wF5` + 1 | `mopZWqZZyQc3F2Sy33cvDtJchSAMsnLi7b` | `0294e3e5e77e22eea0e4c0d30d89beb4db7f69b4bf1ae709e411d6a06618b8f852` | `cVN8eHRQh8r9THM2Mu5HCSjx6cfVdssqGL1KeiCKBwUouyf6K5F5` + 2 | `mgswWyysmViMqYmn5XEj1pVz7rVUftVEBP` | `03f5008445568548bd745a3dedccc6048969436bf1a49411f60938ff1938941f14` | `cUCiXe6qNE43rEJkSR9e1Tt37W5gQmmGeBiSmXzDbZgxbs5Z5nvK` + 3 | `momtnzR3XqXgDSsFmd8gkGxUiHZLde3RmA` | `029ad0b9519779c540b34fa8d11d24d14a5475546bfa28c7de50573d22a503ce21` | `cTAi8RAF2htyUn3F921npbuJLSVdYfpfwqjwLEAPkqvFxLAF716k` + 4 | `moE1dVYvebvtaMuNdXQKvu4UxUftLmS1Gt` | `0313a443e806f25052ac7363adc689fcfa72893f2a51a35ab5e096ed5e6cd8517e` | `cUmGFJMq5Vkh4rjKHe4J4S5adJH1E8xFJJ2ZARBSZNBVzYwj1RvH` + 5 | `muXZYKRJFJ2qPegzV2GEzLqHxngJpzMrmT` | `02e35cca50cb2626212bce8fdfb988bb33f303b15536e9f84f018e63045dbb84ac` | `cRHMG1RjgVWTdUNEgDD5oNEvQvBAha5N3YntnT7rC8yekePLGQwR` + 6 | `mnY26FLTzfC94mDoUcyDJh1GVE3LuAUMbs` | `0344e14b3da8f5fe77a5465d0f8fe089d64ed5517d1f1f989edd00f530938a2c22` | `cS9rFFu8douRgweuQKLdF4QXpS3H1UeoNxZWTt6K874nt4sy56HX` + 7 | `mgV9Z3YuSbxGb2b2Y1T6VCqtU2osui7vhG` | `035169c4d6a36b6c4f3e210f46d329efa1cb7a67ffce7d62062d4a8a17c23756e1` | `cQ1Uh9vXLhaoEgPGUEGMoWACpzrVesmB8G4KdK5vZBnLBifyB29Q` + 8 | `miLqfMwzis98J5vkjjhTiXVsrkAYwuxmts` | `03260dc4925b14addb52b4e62c698b99d2318f3d909477a081ae8e5d94dc3c66d8` | `cPwi3WVwjgr422fBeLa22UHwRkQEMZqoJBjevuosqd25yyYekEkF` + 9 | `mhAacBq3SnXEpoxzEwKqfnQz1iYjxmGg9V` | `02b3397d76b093624981b3c3a279c79496d16820f821528b9e403bdfc162b34c3c` | `cRkkmKXgTmq3Je2B71Rn4HQxeo2hEqvtUeQ5r4Q7eKr5qtq6vzu4` + +## Dash + +`m/44'/5'/0'/0/i` + +index | address | public key | private key +------|--------------------------------------|----------------------------------------------------------------------|------------ + 0 | `XdTw4G5AWW4cogGd7ayybyBNDbuB45UpgH` | `02936f80cac2ba719ddb238646eb6b78a170a55a52a9b9f08c43523a4a6bd5c896` | `XFiosCguxccAvHDasUYWU4mmx4PABR4dDQhk99k8D2N9cKeTRnYq` + 1 | `XbDjZajDR6Y9uB23GBrMUKX4Lci3PqPXT1` | `027e1c93904ae880921decff4042cee3901c984fb89f33b39e9cf1db544002e6ba` | `XKCAE7yNMpRyczUehbX1aMQabUqd8g5Hx2FobmkZ2QVUmoRFiKGJ` + 2 | `XimA3jRAgsksN937ibHrMny6gYy3RChjFs` | `0233e06386e60f9f02fcd2b73f1868cdf5a6dfdcebcd6ddc2b337b25feb1053532` | `XBscYDmgeg6xuK9tUZk5itHGYRqs5VqpUcu4Yn5An3TJrfz7xfgb` + 3 | `Xhxyt3pKQKa2HkePA8tP3NSjkWXFgdsjzH` | `02012cf694423b0bba8a54596f4923c1c8d74458f884f8d611c7305ca6d25320d1` | `XEkU65os4QjrLYy8HKxfEYtFyuy7RqMAGpHDEgSdMjFWtDFDRPid` + 4 | `XfcGasDgKu2JvVS38b9pWUcfY8yfCaH9dF` | `029aaeefff9ae8ea408de41747ac634b49cb90e111b1ac623c3c742dc5ebe42737` | `XFaR8NpQjY8wWrUPNmedwvXyFQTJyj75k1jfYh4Bs2sfBzmfTRFz` + 5 | `XuBYWmRi7q2KrajtXxpmWC5vKMyqCeKMAj` | `0211311f13a287ad81adf710cc837f66b2ce432070752c376861d08c7b91eda67e` | `XEBxR4AExnhCEBXLvQGX9KYg1TwSfngN4CgnzMeY6zeAgLQYxnYH` + 6 | `XvYXR1LCedCJBXDVuye7wevrmR5ASaQdEq` | `03a526d4aa1bd23e3a4d21646b25901d30734b09413eb6462f9251707db0da0f0a` | `XEo8Haet4xLXrPiEbmRogGXjs8UyeowRUXHrfKkF45m32w18u7hK` + 7 | `XgrVDtp8X2C3hEPcwcNY31UPvWGfHSBytG` | `02c13197de985aff1847a0b0b6fa41d750cdcf3dee03b3e209729ea4a5c99341a7` | `XBdQ7YnpdKqyuA5RH2RzwfWnACKgpTJg9STbxrGFmgoKG7URhYGN` + 8 | `XteBgFFTpGz2NNedqsZEcqPz5m31AQBBYz` | `0260ec3beb9f51b4de98fe7f4c13814077603b6211c9e6acdd1c7b0cc796450d79` | `XK13VgxcbF3h9Hr9g5bn1uuhtuaNsfEbcFzQxUsowVVeV7LKGQRy` + 9 | `XpkAwbPzQFdLmuAeYs7BLJfHfXL163QatG` | `027df3bcb58f397d99ec944ae74b15f15bf6ab24190e11e7d3fc164107eb36258b` | `XEq1Rvq4AQKNm52pqiaeUnyG6DZ9Zf6EvrmaZ23Xx2aVrUPYkq6b` + +## Groestlcoin + +`m/44'/17'/0'/0/i` + +index | address | public key | private key +------|--------------------------------------|----------------------------------------------------------------------|------------ + 0 | `Fj62rBJi8LvbmWu2jzkaUX1NFXLEqDLoZM` | `03b85cc59b67c35851eb5060cfc3a759a482254553c5857075c9e247d74d412c91` | `KyEjYKtiAqyERxq6f9SMQ29GinrThjVrEmfdUrKZz6ZPnPxr8Hor` + 1 | `FYy3bTDYJiSaNhh4d2ptHGwAPNRc6heKy2` | `02cf5126ff54e38a80a919579d7091cafe24840eab1d30fe2b4d59bdd9d267cad8` | `KyYazbWftZUkCf2k9YFQr6UXtfjAw3vnZXyep6pz9PWATWm6wKaL` + 2 | `FXHDsC5ZqWQHkDmShzgRVZ1MatpWhwxTAA` | `0331693756f749180aeed0a65a0fab0625a2250bd9abca502282a4cf0723152e67` | `L189RB5TvaJX6p3mnjaoJ12R2GGzdxu1iDUvJPdT3d9Wh8c3g9q9` + 3 | `FtM4zAn9aVYgHgxmamWBgWPyZsb6RhvkA9` | `0286b2a6246bfed0f9a3a4e2ccb49b6989fe078177580b763bbe01e3d4fdfecacd` | `KwwoyZrELnXJc1mvuviWCWc3xSZDBUfnpgwee81B6H83myTQ43y9` + 4 | `FjE6TV6jcN12fbrzwn44GFDcmFQvU9driV` | `03c20962ab16f4d97a4f6f8b83f73a05457794ced25debbf8299336e6ac48bf40d` | `L3rGDCVjokG5caEwpxkQSUuDAQc7arsHCzSiFgzqMpJckyVVXAv9` + 5 | `FqN585nhGJGcNohLffk9qc1X6qZjuqxQhQ` | `021283eb77c39b69a4a5920191e884b71d202fe658057b5b2258db357b8731e707` | `KwhgmgqhztPTRKSTwnYz6QpFVQNL9BGfgvfHLxsQrvuAZb4kDhRR` + 6 | `FjuS7xtFhn1KK5jgiTTtVuYiiDivv6heAh` | `03b66c434a1981f85fdb1c8aaa8f6fd2e02dd267b72f832f3fb2a82b25c24c7d41` | `KxtPi5etKLJcF2tzis3ENn8LSCXy36qU6pJqD5J6C9TwYP3qnsFm` + 7 | `Fe9N7LyoTE58PmQ9N2nSAEeeDEbBhS1NLt` | `0344853499594b040ca8c4f605b5f5005d0c4fdf475cd75f158444c6d86b11f3ca` | `Kx4cu3FjSujkjTQVz8LDArXkpScgyMbtJDHEWWaHsrmnTXmtW9M5` + 8 | `FhuvBfBm8gBfhqM93NzPaVXef9Fv95j2rG` | `03331f59b83c3e2274d4b25ca7643f55822e217339132f26e6ce2db82b6e1f8062` | `L3UA7k9U8x5PTc7XQoDtzM5qisNF7XrEkhufF6X73D4iahSMn7t2` + 9 | `Fn5sfR7FifuLYuBjnAtwreGxNqY4bKbS7g` | `03530992c2f712825050f987aa98b2b7cacd4fbd007aef453675afcc1d750c456a` | `KxvLzbDGH6xL92nHVn4kBAHMaEdRJneqhfiF7btgKT5oa6D1KwWx` + +## Groestlcoin Testnet + +`m/44'/1'/0'/0/i` + +index | address | public key | private key +------|--------------------------------------|----------------------------------------------------------------------|------------ + 0 | `mvbu1Gdy8SUjTenqerxUaZyYjmvedc787y` | `030e669acac1f280d1ddf441cd2ba5e97417bf2689e4bbec86df4f831bf9f7ffd0` | `cPigoY3hubxpXad1t5WmxpcQpmezLeCcbpA7EpyhDofFnedLHBaT` + 1 | `mopZWqZZyQc3F2Sy33cvDtJchSAMw6psrt` | `0294e3e5e77e22eea0e4c0d30d89beb4db7f69b4bf1ae709e411d6a06618b8f852` | `cVN8eHRQh8r9THM2Mu5HCSjx6cfVdssqGL1KeiCKBwUouyeX5wXZ` + 2 | `mgswWyysmViMqYmn5XEj1pVz7rVUhwLwmT` | `03f5008445568548bd745a3dedccc6048969436bf1a49411f60938ff1938941f14` | `cUCiXe6qNE43rEJkSR9e1Tt37W5gQmmGeBiSmXzDbZgxbs6qx83w` + 3 | `momtnzR3XqXgDSsFmd8gkGxUiHZLdGuwNb` | `029ad0b9519779c540b34fa8d11d24d14a5475546bfa28c7de50573d22a503ce21` | `cTAi8RAF2htyUn3F921npbuJLSVdYfpfwqjwLEAPkqvFxL9w2gMf` + 4 | `moE1dVYvebvtaMuNdXQKvu4UxUftHrxubx` | `0313a443e806f25052ac7363adc689fcfa72893f2a51a35ab5e096ed5e6cd8517e` | `cUmGFJMq5Vkh4rjKHe4J4S5adJH1E8xFJJ2ZARBSZNBVzYwFUfyE` + 5 | `muXZYKRJFJ2qPegzV2GEzLqHxngJpGE1rY` | `02e35cca50cb2626212bce8fdfb988bb33f303b15536e9f84f018e63045dbb84ac` | `cRHMG1RjgVWTdUNEgDD5oNEvQvBAha5N3YntnT7rC8yekeHrXcuQ` + 6 | `mnY26FLTzfC94mDoUcyDJh1GVE3Lt4iVCd` | `0344e14b3da8f5fe77a5465d0f8fe089d64ed5517d1f1f989edd00f530938a2c22` | `cS9rFFu8douRgweuQKLdF4QXpS3H1UeoNxZWTt6K874nt4vDYQJp` + 7 | `mgV9Z3YuSbxGb2b2Y1T6VCqtU2osx6mqvs` | `035169c4d6a36b6c4f3e210f46d329efa1cb7a67ffce7d62062d4a8a17c23756e1` | `cQ1Uh9vXLhaoEgPGUEGMoWACpzrVesmB8G4KdK5vZBnLBifd1t1d` + 8 | `miLqfMwzis98J5vkjjhTiXVsrkAYyMik61` | `03260dc4925b14addb52b4e62c698b99d2318f3d909477a081ae8e5d94dc3c66d8` | `cPwi3WVwjgr422fBeLa22UHwRkQEMZqoJBjevuosqd25yyZB6Yk5` + 9 | `mhAacBq3SnXEpoxzEwKqfnQz1iYjxvqrcP` | `02b3397d76b093624981b3c3a279c79496d16820f821528b9e403bdfc162b34c3c` | `cRkkmKXgTmq3Je2B71Rn4HQxeo2hEqvtUeQ5r4Q7eKr5qtnuEeMs` + +## Litecoin + +`m/44'/2'/0'/0/i` + +index | address | public key | private key +------|--------------------------------------|----------------------------------------------------------------------|------------ + 0 | `LcubERmHD31PWup1fbozpKuiqjHZ4anxcL` | `021239d8b20ad1f83d34383e82075d0e11f7a98d06f9e015b56cff61db1e4f8c25` | `T5wTndHdQ1sDnQhApMnDrbQV56PEnjZeRMq9ao2aRJALyUdjdExP` + 1 | `LVWBmHBkCGNjSPHucvL2PmnuRAJnucmRE6` | `02c88e3d1c97fe3ff8eb2f51c37ca66cbfabb6404ddf8158478fae3b8a90e98035` | `TAZnJTHBjN7UoXV6v1aGhVkgq7kBbtXe9h1oKND7LHGS4FC5wnKQ` + 2 | `LUQ91iCfoayy3G3rrFtmF6eVzKQyFSdi2T` | `02df4513e0faae40c6e1dbca606c4fe6c3e22d00a30024ea2b01b7da0097a97f82` | `T3bxs7ZtsnCrXn1dhYJeRBu2FkLFLf8oyhiahMkhdJwxiDVAUP1e` + 3 | `LNk7cQvGW5LPgkii3RUX7YQWtX6HjmLbB4` | `03a69bec3139474eec35f7c87d59f8b6ec37423dbcfce5c5d090bd26de604a2b70` | `T3SQgQ4byehx5ayT98PE7ZDPr68taysoW2Hm6FyDNWuyKiBpWa3L` + 4 | `Laz1nYzJwrGcaZDEERENpNVbgte1n3vWLJ` | `03ed59a1f1b1e2af17ae00ff373a3cedd8b7bd3c4723a76d469e52ec8caba09337` | `T5HGaZgAs35kWheKDFDhdHz1sqNgo3FitUaeBegugamfFxRSjYga` + 5 | `LcBMCi1mQ71LLvFqN2TMgEgomoc9yqEFzg` | `0279224038c76ffcfd1a95ca5d93bcb15c426e18776362fcddd76ff7cc60b9a25d` | `TAdPGc81ANgVhvEVyK5K5DQee4DEv1dDeXAUCBqn6ocPx5Wdi7qc` + 6 | `LfyFtx6XekFZ54gATTjrgeFFmMqAboZwvi` | `0284b369982fba3be2ef729a96b13806b2372c6f3b5209c44fd5ce29c0a1eca976` | `T8WecZVp58aYSvtaw8PAhhx2hxMRBUuvT25dtDyk4x6vE97PHnAY` + 7 | `Le2twPHqkDEiPrY4uZw6Ufes3e7t4VUZ68` | `032e030b64a7de06fc972b7fb82ca4392c4e5a535ce942f32d6b660b1d58b5176c` | `T5ojDJgMa3QYZkst9po2B6P5SXyP4vFuBFZBhvyp8E9Ek74yCzoE` + 8 | `LViaNcv7TTQv8yFFvBnjC63dwVNL3e21c1` | `026b9d73e88ecbcd55a68e0a8e6c651e2543075b85fc6e85386e1a8009e9a55abe` | `T7YQp9UidMzNSRJHPpCVWeANPpDK5Nz1MhfWuP5sy6YFUB5VJiat` + 9 | `LfritJSaLhmsRDaZwYSnfpUMNTA8kTweHa` | `030ad428a32f117f21cbf581630858b28baa957cb475ac43b7536b1a1da3d00293` | `T3WSZzJmXPZB7Mr5vAQ5qmi2b9zFww5oLHqUcyy7371d9ujZb8Kb` + +## Ethereum + +`m/44'/60'/0'/0/i` + +index | address | public key | private key +------|----------------------------------------------|----------------------------------------------------------------------|------------ + 0 | `0x73d0385F4d8E00C5e6504C6030F47BF6212736A8` | `03ad8e7eb4f3a7d1a409fa7bdc7b79d8840fe746d3fa9ee17fee4f84631ec1430b` | `759e46263f1505994d11142d70027975c9b9fef15489b09bd987eb8a31aba0db` + 1 | `0xFA01a39f8Abaeb660c3137f14A310d0b414b2A15` | `03ddeae7da4e54757d3f3038315344709971849a971d2619797d9b8574e373ae9b` | `616883a861adaab932634c283e294bcfdc9797757984bc4a15a9484ada947177` + 2 | `0x574BbB36871bA6b78E27f4B4dCFb76eA0091880B` | `039d09121b995a1f7fe5d30996f6a66fff4688f8eee096faea2957e1fe53923860` | `4f74b7bb78734476e41caa28a397493260103f4ccf0b8a14fe340da5a8a7e22c` + 3 | `0xba98D6a5ac827632E3457De7512d211e4ff7e8bD` | `0307b32cc46360c9acf750da7acf7dce918aee97dd383236248c9c79b8efbd98fc` | `a02122e1ac06fb63da2fd293706c91b5839108de765dc9ce3e2d3fb1573bafd4` + 4 | `0x1f815D67006163E502b8eD4947C91ad0A62De24e` | `03d26a9f183bbb531e140ab3d87bca361706b4c4be7c731e29160cab833e7a9282` | `f686b6033ef11ad995ff93b240bd28b04c6dc3a24cb35861b642f7ba969564e0` + 5 | `0xf69619a3dCAA63757A6BA0AF3628f5F6C42c50d2` | `02ae8cef29ef6d2ad9b98af746589743c510e4b49784ec1181a079b4b1df3c5211` | `945f0973cd011048b56bb87887ad782c72b09ff181f4af97ad033581ea009a74` + 6 | `0xA8664Df3D5E74BE57c19fC7005BBcd0F5328041e` | `023ed2881ee76991dafd40e33df96a88a5e929869635cdfc261e947d1e9ca31be9` | `7226389c1de87a3498234ad49e00e48060609b839616de313b341c6245142993` + 7 | `0xf2252f414e727d652d5a488fE4BFf7e64478737F` | `03b765e9b8ba13ffb45e69f038bf1506aa2ecf1f1824c88551f98e93026c06e6b4` | `640dfbf3d433c548d0a1b9d0d5dc824f72d631cdfca0902ad16788b6b3081067` + 8 | `0x5708Ae081b48ad7bA8c50ca3D4fa0238d544D6FA` | `031acf557e85d59e0305b8b79d4a5cc5077d09811206be208c00c4e457e7017ac1` | `728a3bd762ac7a25d58eafcd3240bb783304cd323e78b5967a8ecdb4c1e1a982` + 9 | `0x12eF7dfb86f6D5E3e0521b72472ca02D2a3814F4` | `02c9f2bf6bbf6244eec9866ad6eb6dec628cbf71f2e2cb77c25d72baeca2c32f61` | `9ee5234da5069eede6135c0f684fd0b633504a04614c740aef47a57a28c0384d` diff --git a/slip-0015.md b/slip-0015.md index 1e0df4d2..420f04f1 100644 --- a/slip-0015.md +++ b/slip-0015.md @@ -4,7 +4,7 @@ Number: SLIP-0015 Title: Format for Bitcoin metadata and its encryption in HD wallets Type: Standard -Status: Draft +Status: Final Authors: Karel Bilek Created: 2015-01-12 ``` @@ -39,7 +39,7 @@ We first derive a *master key* from hardware device itself, which is shared for We then derive *account key* for every account. This key is a string -- because of the stated goal 3., we want to be able to import it into third party applications without HD wallets. -From the account key, we derive both a filename and a symmetric encryption key. We then save the metadata to the fiven file, in an encrypted JSON. +From the account key, we derive both a filename and a symmetric encryption key. We then save the metadata to the given file, in an encrypted JSON. ## Design details @@ -159,17 +159,21 @@ All the example code is in Python2. Example code, deriving a master key from a connected TREZOR is in [1_masterkey.py](slip-0015/1_masterkey.py). It requires [python-trezor](https://github.com/trezor/python-trezor) installed and TREZOR connencted -For the "stress test" wallet, defined in SLIP-0014, the master key should be (in hex):: +For the "stress test" wallet, defined in SLIP-0014, the master key should be (in hex): - 20c8bf0701213cdcf4c2f56fd0096c1772322d42fb9c4d0ddf6bb122d713d2f3 +``` +20c8bf0701213cdcf4c2f56fd0096c1772322d42fb9c4d0ddf6bb122d713d2f3 +``` ### Deriving "account" key Example code, deriving an account key for master key, is in [2_accountkey.py](slip-0015/2_accountkey.py). First argument of the script is xpub of the account, the second argument is the master key from previous step (in hexadecimal). -For the "stress test" wallet, defined in SLIP-0014, and its first account (with the xpub `xpub6BiVtCp...`), the key should be:: +For the "stress test" wallet, defined in SLIP-0014, and its first account (with the xpub `xpub6BiVtCp...`), the key should be: - v5kCxSKLTsnwmgPBeaRyFDWeG9zXouF34L72763zjLrS4LWy8 +``` +v5kCxSKLTsnwmgPBeaRyFDWeG9zXouF34L72763zjLrS4LWy8 +``` ### Deriving filename, decoding diff --git a/slip-0016.md b/slip-0016.md index efad4a3e..c3a8d990 100644 --- a/slip-0016.md +++ b/slip-0016.md @@ -4,7 +4,7 @@ Number: SLIP-0016 Title: Format for password storage and its encryption Type: Standard -Status: Draft +Status: Final Authors: Peter Jensen Created: 2016-18-02 ``` @@ -56,8 +56,8 @@ First, we use the HMAC function: where: -- fileKey is the first half of masterKey (`masterKey.substring(0, masterKey.length / 2)`) -- FILENAME_MESS is a constant string `'5f91add3fa1c3c76e90c90a3bd0999e2bd7833d06a483fe884ee60397aca277a'` +* fileKey is the first half of masterKey (`masterKey.substring(0, masterKey.length / 2)`) +* FILENAME_MESS is a constant string `'5f91add3fa1c3c76e90c90a3bd0999e2bd7833d06a483fe884ee60397aca277a'` The output result is digested to HEX string. After, we append extension `'.pswd'` @@ -69,16 +69,16 @@ As an encryption key is used the SECOND half (32 bytes) of master key for the fi For encrypt/decrypt we are using `AES-256-GCM` algorithm. -- Input Vector (IV) is 12 randomly generated bytes -- GCM is used with full 128-bit autentication tag (authTag) +* Input Vector (IV) is 12 randomly generated bytes +* GCM is used with full 128-bit autentication tag (authTag) [more info](https://nodejs.org/api/crypto.html#crypto_crypto_createcipheriv_algorithm_key_iv) The result output stored in file is: -- first 12 bytes of the file is randomly generated IV -- next 16 bytes is the GCM authTag -- the rest is output ciphertext +* first 12 bytes of the file is randomly generated IV +* next 16 bytes is the GCM authTag +* the rest is output ciphertext [more info](https://nodejs.org/api/crypto.html#crypto_crypto_createdecipheriv_algorithm_key_iv) @@ -112,13 +112,13 @@ The result output stored in file is: Every entry contains keys from upper example. -- `title`: title is represented as string. If given string is matching URL, it will be shown on device as domain without protocol prefix. -- `username`: string, will be passed to device, in encryption/decryption process -- `nonce`: hidden generated string which is output of cipherKeyValue over Title + Username key and random values -- `password`: is buffer array output of plain string and nonce (encryption process described later) -- `safe_note`: is also buffer array output of plain string and nonce (also described later) -- `note`: is plain UTF8 string -- `tags`: is array of Tags key values +* `title`: title is represented as string. If given string is matching URL, it will be shown on device as domain without protocol prefix. +* `username`: string, will be passed to device, in encryption/decryption process +* `nonce`: hidden generated string which is output of cipherKeyValue over Title + Username key and random values +* `password`: is buffer array output of plain string and nonce (encryption process described later) +* `safe_note`: is also buffer array output of plain string and nonce (also described later) +* `note`: is plain UTF8 string +* `tags`: is array of Tags key values Step by step entry encryption: @@ -135,7 +135,7 @@ session.cipherKeyValue( '2d650551248d792eabf628f451200d7f51cb63e46aadcbb1038aacb05e8c8aee2d650551248d792eabf628f451200d7f51cb63e46aadcbb1038aacb05e8c8aee', true, //encrypt? - has to be TRUE in encryption false, //askOnEncrypt? is the same in encryption and decryption -true) // askOnDecrypt? we want this becuase otherwise somebody could rob us! +true) // askOnDecrypt? we want this because otherwise somebody could rob us! ``` 4. Then we use our famous `nonce` from the first step in `AES-256-GCM` algorithm encryption for `password` string and `safe_note` string. Process of encryption is the same as in the deriving encryption key and file level encryption. So basically we get some Buffer array output with 12 bytes of IV and 16 bytes of GCM authTag and the rest is cipherText. @@ -154,9 +154,9 @@ session.cipherKeyValue( '8688105887642a3cbb61889d8762432ef864df107e097d2b19e93c8d808c2e21', false, //encrypt? - has to be FALSE in decryption false, //askOnEncrypt? is the same in encryption and decryption -true) // askOnDecrypt? we want this becuase otherwise somebody could rob us! +true) // askOnDecrypt? we want this because otherwise somebody could rob us! ``` -2. Other steps are the same as in entry encryption, we just symetrically decrypt values of `password` and `safe_note` via `AES-256-GCM` algorithm. Size of IV and authTag for AES is the same as in encryption. Beware on cipher Key data type - it must be hex. Output is in JSON. +2. Other steps are the same as in entry encryption, we just symmetrically decrypt values of `password` and `safe_note` via `AES-256-GCM` algorithm. Size of IV and authTag for AES is the same as in encryption. Beware on cipher Key data type - it must be hex. Output is in JSON. Check example of password reader implementation in Python: [pwd_reader.py](https://github.com/trezor/python-trezor/blob/master/tools/pwd_reader.py) - there is an example code for decryption. diff --git a/slip-0017.md b/slip-0017.md index c7d54168..06029e45 100644 --- a/slip-0017.md +++ b/slip-0017.md @@ -4,7 +4,7 @@ Number: SLIP-0017 Title: ECDH using deterministic hierarchy Type: Standard -Status: Draft +Status: Final Authors: Roman Zeyde Created: 2016-05-29 ``` @@ -48,7 +48,7 @@ The index is used so one can generate more keys corresponding to the same URI. 5. Set highest bits of numbers `A`, `B`, `C`, `D` to 1 (e.g. logical OR with 0x80000000) to harden -6. Derive the HD node `m/17'/A'/B'/C'/D'` according to BIP32. +6. Derive the HD node `m/17'/A'/B'/C'/D'` according to SLIP-0010. ## Shared secret generation @@ -65,8 +65,22 @@ by her private key `k1` (as a 256-bit scalar). The result is the elliptic curve point `Q = k1*k2*P`, which can be computed in a similar way by Bob (since `Q = k2*P1`), is used to derive a shared secret. +## Worked example + +1. `index + uri`=`42` + `https://nvsaberhagen@getmonero.org/login` + +2. `sha256(index + uri)` = `f8be2155d1323418dc94a20c74bfdb7ab418eb7b061b38729193870405dd3875` + +3. `hash128` = `f8be2155d1323418dc94a20c74bfdb7a` + +4. `A` = 1428274936 (0x5521bef8), `B` = 406074065 (0x0x183432d1), `C` = 211981532 (0x0ca294dc), `D` = 2061221748 (0x7adbbf74) + +5. `A'` = 3575758584, `B'` = 2553557713, `C'` = 2359465180, `D'` = 4208705396 + +6. `HD node path` = `m/2147483665/3575758584/2553557713/2359465180/4208705396` + ## References -* [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) * [BIP-0043: Purpose Field for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) * [RFC 3986: Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986) +* [SLIP-0010: Universal private key derivation from master private key](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) diff --git a/slip-0019.md b/slip-0019.md new file mode 100644 index 00000000..9f4789c3 --- /dev/null +++ b/slip-0019.md @@ -0,0 +1,349 @@ +# SLIP-0019 : Proof of Ownership + +``` +Number: SLIP-0019 +Title: Proof of Ownership +Type: Standard +Status: Accepted +Authors: Andrew Kozlik + Stepan Snigirev + Ondrej Vejpustek + Pavol Rusnak +Created: 2019-04-25 +``` + +## Abstract + +This specification defines the format for a proof of ownership which can be passed to a hierarchical deterministic wallet together with each input of an unsigned transaction. This proof allows the wallet to determine whether it is able to spend the given input or not. It also allows third parties to verify that a user has the ability to spend the input. + +## Motivation + +In certain applications like CoinJoin or opening a dual-funded channel in the Lightning Network, a wallet has to sign transactions containing external inputs. To calculate the actual amount the user is spending, the wallet needs to reliably determine for each input whether it belongs to the wallet or not. Without such a mechanism an attacker can deceive the wallet into displaying incorrect information about the amount being spent, which can result in theft of user funds. This was first recognized in a bitcoin-dev [mailing list discussion](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html). + +For example, in a CoinJoin transaction an attacker can construct a transaction with inputs `in1` and `in2` of identical value belonging to the user and two outputs of identical value, `user_out` belonging to the user and `attacker_out` belonging to the attacker. If such a transaction is sent to a hardware wallet twice with `in1` marked as external the first time and `in2` marked as external the second time, then the hardware wallet will display two signing requests to the user with a spending amount of `in2 - user_out` and `in1 - user_out`, respectively. The user will think that they are signing two different CoinJoin transactions and spending `in1 + in2 - 2*user_out` for the fees, while in reality they are signing two different inputs to a single transaction and sending half of the amount to the attacker. + +To mitigate such an attack, the hardware wallet needs to ascertain non-ownership of all inputs which are claimed to be external. In case of hierarchical deterministic wallets it is generally not feasible to ascertain this solely based on the scriptPubKey of the UTXO, because it would require searching through billions of BIP32 derivation paths. + +A CoinJoin coordinator can also benefit from such a proof to verify that the CoinJoin participant is able and willing to sign the input. This verification helps to mitigate denial-of-service attacks as the attacker has to use a limited UTXO set that they control and in case of misbehavior this UTXO set gets banned. + +## Proof of ownership format + +A proof of ownership consists of a proof body and a signature. The proof body contains one or more ownership identifiers which allow a wallet to efficiently determine whether or not it is able to spend a UTXO having a given scriptPubKey. The proof signature affirms that the proof body can be trusted to have been generated by the true owner of the UTXO. + +``` +proofOfOwnership = proofBody || proofSignature +``` + +### Ownership identifier + +Let *k* be a secret *ownership identification key* derived from the wallet's master secret using the [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md) method for hierarchical derivation of symmetric keys as: + +``` +k = Key(m/"SLIP-0019"/"Ownership identification key") +``` + +The ownership identifier for a scriptPubKey is computed as: + +``` +id = HMAC-SHA256(key = k, msg = scriptPubKey) +``` + +In case of *m*-of-*n* multi-signature scriptPubKeys the proof of ownership SHOULD contain the ownership identifiers of all *n* co-owners of that scriptPubKey. See [Identifier inclusion](#identifier-inclusion) for further details. + +A wallet MUST NOT produce and reveal an ownership identifier for a scriptPubKey which it does not control. Such a fake ownership identifier can be used to mount a denial-of-service attack. + +### Proof body + +The *proofBody* is a concatenation of the following fields: + +* *versionMagic* (4 bytes): b"\x53\x4c\x00\x19" (this is "SL" followed by 0019 in compressed numeric form as an abbreviation for "SLIP-0019"). +* *flags* (1 byte, bit 0 is the least significant bit): + * Bit 0: User confirmation + * 0 means the proof was generated without user confirmation. + * 1 means the user confirmed the generation of the proof. + * Bits 1 to 7: Reserved for future use (all must be 0). +* *n* (VarInt): the number of ownership identifiers which follow. The VarInt MUST be encoded in the fewest possible number of bytes. +* *id*1 || *id*2 || ... || *id**n* (32 bytes each): concatenation of the ownership identifiers for the given scriptPubKey, one for each co-owner, see [Identifier inclusion](#identifier-inclusion) for further details. + +### Proof footer + +The *proofFooter* is a concatenation of the following fields: + +* *scriptPubKey* (length-prefixed string). +* *commitmentData* (length-prefixed string), any additional data to which the proof should commit, see below. + +The proof footer is included only in the *sighash* computation. It is not part of the proof of ownership, because the verifier of the proof should obtain these fields externally based on the context in which the proof is provided. Namely the *scriptPubKey* should be obtained by looking up the output being spent and the *commitmentData* is given by the application context. Variable-length fields are encoded the same way as in Bitcoin transactions, as a length-prefixed string, where the length is encoded as a variable-length integer (VarInt). + +### Proof signature + +The concatenation of the *proofBody* and *proofFooter* is signed using the Generic Signed Message Format as defined in the [original BIP-0322](https://github.com/bitcoin/bips/blob/f9e95849f337358cd89c83b948fbede3875481c3/bip-0322.mediawiki) until October 2020, when the BIP-0322 specification was rewritten to use the transaction-based approach. +The *proofSignature* is the `SignatureProof` container defined in the original BIP-0322 using the sighash computed as: + +``` +sighash = SHA-256(proofBody || proofFooter) +``` + +### Additional commitment data + +The content of the *commitmentData* field is application-specific. If an application does not define the content of this field, then a zero-length string should be used by default. + +In case of CoinJoin transactions the *commitmentData* SHOULD contain a globally unique PSBT identifier (*psbtId*). The purpose of such an identifier is to prevent an attacker from causing denial of service by registering an input into a different CoinJoin transaction than the one for which the input was intended. The user should explicitly confirm the generation of the proof and the *commitmentData* value to affirm their intent to participate in the given CoinJoin transaction. + +The *psbtId* is not to be confused with TXID, which is the hash of a transaction's data. Since the *psbtId* needs to be known before the transaction is created, it cannot be derived from the transaction data but needs to be generated as a nonce. For example: + +1. The concatenation of a globally unique CoinJoin server identifier (192 bits) with a sequential round identifier (64 bits). +2. A random 256 bit value. + +## Proof construction + +### Single-signature scriptPubKeys + +When constructing a proof of ownership for a single-signature scriptPubKey the inputs to the wallet are the *flags*, *scriptPubKey*, *commitmentData* and the BIP32 derivation path. The wallet takes the following steps: + +1. Ensure that bits 1 through 7 of *flags* are clear. +2. Ensure that the wallet controls the private key to the provided *scriptPubKey*. This is typically done by using the provided BIP32 derivation path. +3. If bit 0 (user confirmation) of *flags* is set, then prompt the user to confirm generation of the ownership proof with the given *commitmentData*. If the user does not confirm, then abort. +4. Compute the ownership identifier for the scriptPubKey. +5. Compile the *proofBody* and *proofFooter*, and generate the *proofSignature*. +6. Return the *proofBody* and *proofSignature*. + +### Multi-signature scriptPubKeys + +The construction of a proof of ownership for a *m*-of-*n* multi-signature scriptPubKey requires a signing coordinator, i.e. a watch-only software wallet. The signing coordinator is assumed to have obtained the ownership identifiers of all *n* co-owners in advance. These ownership identifiers should generally be produced at the time of the creation of the multi-signature address. + +When constructing a proof of ownership, the signing coordinator prepares the *proofBody* and *proofFooter* and sends these to each signer together with any other required metadata, such as the BIP32 derivation path for the input. Each of the *m* signers then takes the following steps: + +1. Parse the *proofBody* and *proofFooter*. If *versionMagic* is not recognized or if any of the bits 1 through 7 of *flags* is set, then abort. +2. Derive the ownership identifier using the *scriptPubKey* provided in the *proofFooter*. +3. If the derived ownership identifier is not listed in the *proofBody*, then abort. +4. If bit 0 (user confirmation) of *flags* is set, then prompt the user to confirm generation of the ownership proof with the given *commitmentData*. If the user does not confirm, then abort. +5. Return the signature for the provided *proofBody* and *proofFooter*. + +The signing coordinator collects all the signatures and combines them into a `SignatureProof` container to finalize the proof. + +## Proof usage + +### Verifying non-ownership of transaction inputs + +When a wallet is requested to sign a transaction, each external input SHOULD be accompanied with a proof of ownership so that the wallet may ascertain non-ownership of such an input in order to correctly inform the user about the amount they are spending in the transaction. For each external input the wallet takes the following steps: + +1. By reliable means obtain the scriptPubKey of the UTXO being spent by that input. Prior to SegWit version 1 witness programs this step involves acquiring the full transaction being spent and verifying its hash against that which is given in the outpoint. +2. Parse the *proofBody*. If *versionMagic* is not recognized or if any of the bits 1 through 7 of *flags* is set, then abort. +3. Verify that the *proofSignature* is valid in accordance with BIP-0322 using the obtained scriptPubKey and the sighash as defined in the [Proof signature](#proof-signature) section. +4. Derive the ownership identifier using the wallet's ownership identification key and the obtained scriptPubKey. +5. Verify that the derived ownership identifier is not included in the *proofBody*. + +### Verifying ability and intent to sign an input + +Each input which is registered to take part in a CoinJoin transaction should be accompanied with a proof of ownership which affirms the owner's intent to take part, so as to mitigate denial-of-service attacks. The CoinJoin coordinator takes the following steps before registering an input: + +1. By reliable means obtain the scriptPubKey of the UTXO being spent by that input. +2. Parse the *proofBody*. If *versionMagic* is not recognized or if any of the bits 1 through 7 of *flags* is set, then abort. +3. Verify that bit 0 (user confirmation) of *flags* is set. +4. Verify that the *proofSignature* is valid using the obtained scriptPubKey. + +A proof of ownership commits to a particular scriptPubKey, which means that the proof is replayable for UTXOs with the same address. Nevertheless, freshness of such a proof is guaranteed if a nonce (such as the *psbtId*) is included in the *commitmentData*. + +## PSBT extension + +This section proposes additional fields for [BIP-0174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) PSBTv0 and [BIP-0370](https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki) PSBTv2 that allow for SLIP-0019 proofs of ownership to be included in a PSBT of any version. + +The following new global type is defined: +Name | `` | `` | `` Description | `` | `` Description | Versions Requiring Inclusion | Versions Requiring Exclusion | Versions Allowing Inclusion +-----|-------------|-------------|-------------------------|---------------|---------------------------|------------------------------|------------------------------|---------------------------- +Proof-of-ownership commitment data | `PSBT_GLOBAL_OWNERSHIP_COMMITMENT = 0x07` | None | No key data | `` | The value used as the *commitmentData* in each input's proof-of-ownership. | | | 0, 2 + +The following new per-input type is defined: +Name | `` | `` | `` Description | `` | `` Description | Versions Requiring Inclusion | Versions Requiring Exclusion | Versions Allowing Inclusion +-----|-------------|-------------|-------------------------|---------------|---------------------------|------------------------------|------------------------------|---------------------------- +Proof-of-ownership | `PSBT_IN_OWNERSHIP_PROOF = 0x19` | None | No key data | `` | A *proofOfOwnership* for this input, as defined above, allowing a wallet to determine whether it is able to spend this input or not. | | | 0, 2 + +## Implementation considerations + +### Script evaluation on hardware wallets + +Currently most hardware wallets do not support complete Bitcoin script verification, so initial deployment of proofs of ownership can be limited to a set of known scripts. In the future hardware wallets may implement [miniscript](http://bitcoin.sipa.be/miniscript/) verification, that will cover most of the use-cases known today. + +### Identifier inclusion + +When generating a proof of ownership for *m*-of-*n* multi-signature scriptPubKeys the proof body SHOULD contain the ownership identifiers of all *n* co-owners of that scriptPubKey. Failing to include all ownership identifiers opens the door to the following attack. + +For simplicity consider two equal-valued UTXOs *A* and *B*, both of which have the same 1-of-2 multi-signature scriptPubKey controlled by Users 1 and 2. The attacker requests a proof of ownership *P1* from User 1 containing only User 1's ownership identifier. Similarly the attacker requests a proof of ownership *P2* from User 2 containing only User 2's ownership identifier. The attacker then creates a CoinJoin transaction with inputs *A* and *B* and equal-valued outputs *out_user* and *out_attacker*, the former of which is a multi-signature scriptPubKey controlled by Users 1 and 2. User 1 is given the transaction to sign with proof *P2* for the input spending *B*, and User 2 is given the same transaction to sign with proof *P1* for the input spending *A*. User 1 perceives *B* as foreign, assumes they are transferring *A* to *out_user* and signs the input spending *A*. User 2 perceives *A* as foreign, assumes they are transferring *B* to *out_user* and signs the input spending *B*. As a result half of the amount from *A* and *B* is transferred to the attacker. This attack is extendable to more complex *m*-of-*n* multi-signatures. + +In some cases there are legitimate reasons not to include the ownership identifier of a co-owner: + +1. The excluded co-owner does not support any kind of proof of ownership format and will never take part in a transaction containing external inputs. An example of this would be a cryptocurrency custody service which is included in the multi-signature setup only as a backup in case the key of one of the co-owners is lost. +2. A co-owner is intentionally excluded to avoid signing failures due to input ownership collisions. Consider a user who is participating in a CoinJoin transaction with their UTXO *A*. At the same time this user happens to be a co-owner of another UTXO *B* being spent as an input in the same transaction. The user is not meant to be cosigning *B*, because this input was registered independently by a group of co-owners who did not expect the user to participate. Thus the user's wallet will recognize *B* as an input it co-owns, but it will not be able to sign because it was not given the corresponding BIP32 derivation path. Even if the path were to be provided, the user might not be willing to cosign due to confusion at the unexpected presence of the input amount supplied by *B*. As a result the CoinJoin transaction will fail to complete. Before excluding an ownership identifier on these grounds, the likelihood of this kind of scenario needs to be carefully weighed against the risk of the attack described above. + +## Test vectors + +### Test vector 1 (P2WPKH) + +#### Input parameters + +Parameter | Value +-----------------------|------ +BIP39 seed | "all all all all all all all all all all all all" +Passphrase | "" +Ownership ID key (hex) | `0a115a171e30f8a740bae6c4144bec5dc1099ffa79b83dfb8aa3501d094de585` +Path | m/84'/0'/0'/1/0 +*scriptPubKey* (hex) | `0014b2f771c370ccf219cd3059cda92bdf7f00cf2103` +User confirmation | False +*commitmentData* | "" +*sighash* (hex) | `850dd556283b49d80fa5501035b4775e62f0c80bf36f62d1adf2f2f9f108c884` + +#### Proof of ownership (hex) + +`534c00190001a122407efc198211c81af4450f40b235d54775efd934d16b9e31c6ce9bad57070002483045022100c0dc28bb563fc5fea76cacff75dba9cb4122412faae01937cdebccfb065f9a7002202e980bfbd8a434a7fc4cd2ca49da476ce98ca097437f8159b1a386b41fcdfac50121032ef68318c8f6aaa0adec0199c69901f0db7d3485eb38d9ad235221dc3d61154b` + +Split into components: + +Name | Value +-------------------|------ +*versionMagic* | `534c0019` +*flags* | `00` +*n* | `01` +*id* | `a122407efc198211c81af4450f40b235d54775efd934d16b9e31c6ce9bad5707` +*scriptSig* length | `00` +*scriptSig* | (empty) +*witness* | `02483045022100c0dc28bb563fc5fea76cacff75dba9cb4122412faae01937cd`
`ebccfb065f9a7002202e980bfbd8a434a7fc4cd2ca49da476ce98ca097437f81`
`59b1a386b41fcdfac50121032ef68318c8f6aaa0adec0199c69901f0db7d3485`
`eb38d9ad235221dc3d61154b` + +### Test vector 2 (P2WPKH nested in BIP16 P2SH) + +#### Input parameters + +Parameter | Value +-----------------------|------ +BIP39 seed | "all all all all all all all all all all all all" +Passphrase | "" +Ownership ID key (hex) | `0a115a171e30f8a740bae6c4144bec5dc1099ffa79b83dfb8aa3501d094de585` +Path | m/49'/0'/0'/1/0 +*scriptPubKey* (hex) | `a914b9ddc52a7d95ad46d474bfc7186d0150e15a499187` +User confirmation | True +*commitmentData* | "TREZOR" +*sighash* (hex) | `709fa3a60709cecefbd7aaaf551ff23421d65d1c046e6a9390abf73cbcd2fc83` + +#### Proof of ownership (hex) + +`534c0019010192caf0b8daf78f1d388dbbceaec34bd2dabc31b217e32343663667f6694a3f4617160014e0cffbee1925a411844f44c3b8d81365ab51d0360247304402207f1003c59661ddf564af2e10d19ad8d6a1a47ad30e7052197d95fd65d186a67802205f0a804509980fec1b063554aadd8fb871d7c9fe934087cba2da09cbeff8531c012103a961687895a78da9aef98eed8e1f2a3e91cfb69d2f3cf11cbd0bb1773d951928` + +Split into components: + +Name | Value +-------------------|------ +*versionMagic* | `534c0019` +*flags* | `01` +*n* | `01` +*id* | `92caf0b8daf78f1d388dbbceaec34bd2dabc31b217e32343663667f6694a3f46` +*scriptSig* length | `17` +*scriptSig* | `160014e0cffbee1925a411844f44c3b8d81365ab51d036` +*witness* | `0247304402207f1003c59661ddf564af2e10d19ad8d6a1a47ad30e7052197d95`
`fd65d186a67802205f0a804509980fec1b063554aadd8fb871d7c9fe934087cb`
`a2da09cbeff8531c012103a961687895a78da9aef98eed8e1f2a3e91cfb69d2f`
`3cf11cbd0bb1773d951928` + +### Test vector 3 (P2PKH) + +#### Input parameters + +Parameter | Value +-----------------------|------ +BIP39 seed | "all all all all all all all all all all all all" +Passphrase | "TREZOR" +Ownership ID key (hex) | `2d773852e0959b3c1bac15bd3a8ad410e2c6720befb4f7f428d74bdd5d6e4f1d` +Path | m/44'/0'/0'/1/0 +*scriptPubKey* (hex) | `76a9145a4deff88ada6705ed70835bc0db56a124b9cdcd88ac` +User confirmation | False +*commitmentData* | "" +*sighash* (hex) | `abf12242bc87f457126373a08775fbeb67ccd5e09c4acbc1d8b310be68a3ac33` + +#### Proof of ownership (hex) + +`534c00190001ccc49ac5fede0efc80725fbda8b763d4e62a221c51cc5425076cffa7722c0bda6b483045022100e818002d0a85438a7f2140503a6aa0a6af6002fa956d0101fd3db24e776e546f0220430fd59dc1498bc96ab6e71a4829b60224828cf1fc35edc98e0973db203ca3f0012102f63159e21fbcb54221ec993def967ad2183a9c243c8bff6e7d60f4d5ed3b386500` + +Split into components: + +Name | Value +-------------------|------ +*versionMagic* | `534c0019` +*flags* | `00` +*n* | `01` +*id* | `ccc49ac5fede0efc80725fbda8b763d4e62a221c51cc5425076cffa7722c0bda` +*scriptSig* length | `6b` +*scriptSig* | `483045022100e818002d0a85438a7f2140503a6aa0a6af6002fa956d0101fd`
`3db24e776e546f0220430fd59dc1498bc96ab6e71a4829b60224828cf1fc35ed`
`c98e0973db203ca3f0012102f63159e21fbcb54221ec993def967ad2183a9c24`
`3c8bff6e7d60f4d5ed3b3865` +*witness* | `00` + +### Test vector 4 (P2WSH 2-of-3 multisig) + +#### Input parameters + +Parameter | Value +-------------------------|------ +BIP39 seed 1 | "all all all all all all all all all all all all" +Passphrase 1 | "" +Ownership ID key 1 (hex) | `0a115a171e30f8a740bae6c4144bec5dc1099ffa79b83dfb8aa3501d094de585` +BIP39 seed 2 | "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about" +Passphrase 2 | "" +Ownership ID key 2 (hex) | `cd50559c65666fd381e823b82fff04763465062c1ff4c93d3e147a306f884130` +BIP39 seed 3 | "zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo wrong" +Passphrase 3 | "" +Ownership ID key 3 (hex) | `64b3e4f003fd7dea4168dd19f85410ac3b1844abd1d7f9f3a74254a7852af725` +Path | m/84'/0'/0'/1/0 +*scriptPubKey* (hex) | `00209149b5bcaae8c876f1997ef6b60ec197475217fd3e736d4c54fcf49fe4f5213a` +User confirmation | False +*commitmentData* | "TREZOR" +*sighash* (hex) | `d2cca14e9ea31a5e4bb36e6e5813adf31f8744bc6da09680e3a0d69e5c8dddb1` + +#### Proof of ownership (hex) + +The proof is signed using the first and the third key. + +`534c00190003309c4ffec5c228cc836b51d572c0a730dbabd39df9f01862502ac9eabcdeb94a46307177b959c48bf2eb516e0463bb651aad388c7f8f597320df7854212fa3443892f9573e08cedff9160b243759520733a980fed45b131a8bba171317ae5d940004004830450221009d8cd2d792633732b3a406ea86072e94c72c0d1ffb5ddde466993ee2142eeef502206fa9c6273ab35400ebf689028ebcf8d2031edb3326106339e92d499652dc43030147304402205fae1218bc4600ad6c28b6093e8f3757603681b024e60f1d92fca579bfce210b022011d6f1c6ef1c7f7601f635ed237dafc774386dd9f4be0aef85e3af3f095d8a9201695221032ef68318c8f6aaa0adec0199c69901f0db7d3485eb38d9ad235221dc3d61154b2103025324888e429ab8e3dbaf1f7802648b9cd01e9b418485c5fa4c1b9b5700e1a621033057150eb57e2b21d69866747f3d377e928f864fa88ecc5ddb1c0e501cce3f8153ae` + +Split into components: + +Name | Value +-------------------|------ +*versionMagic* | `534c0019` +*flags* | `00` +*n* | `03` +*id*1 | `309c4ffec5c228cc836b51d572c0a730dbabd39df9f01862502ac9eabcdeb94a` +*id*2 | `46307177b959c48bf2eb516e0463bb651aad388c7f8f597320df7854212fa344` +*id*3 | `3892f9573e08cedff9160b243759520733a980fed45b131a8bba171317ae5d94` +*scriptSig* length | `00` +*scriptSig* | (empty) +*witness* | `04004830450221009d8cd2d792633732b3a406ea86072e94c72c0d1ffb5ddde4`
`66993ee2142eeef502206fa9c6273ab35400ebf689028ebcf8d2031edb332610`
`6339e92d499652dc43030147304402205fae1218bc4600ad6c28b6093e8f3757`
`603681b024e60f1d92fca579bfce210b022011d6f1c6ef1c7f7601f635ed237d`
`afc774386dd9f4be0aef85e3af3f095d8a9201695221032ef68318c8f6aaa0ad`
`ec0199c69901f0db7d3485eb38d9ad235221dc3d61154b2103025324888e429a`
`b8e3dbaf1f7802648b9cd01e9b418485c5fa4c1b9b5700e1a621033057150eb5`
`7e2b21d69866747f3d377e928f864fa88ecc5ddb1c0e501cce3f8153ae` + +### Test vector 5 (P2TR) + +#### Input parameters + +Parameter | Value +-----------------------|------ +BIP39 seed | "all all all all all all all all all all all all" +Passphrase | "" +Ownership ID key (hex) | `0a115a171e30f8a740bae6c4144bec5dc1099ffa79b83dfb8aa3501d094de585` +Path | m/86'/0'/0'/1/0 +*scriptPubKey* (hex) | `51204102897557de0cafea0a8401ea5b59668eccb753e4b100aebe6a19609f3cc79f` +User confirmation | False +*commitmentData* | "" +*sighash* (hex) | `331a936e0a94d8ec7a105507dbdd445d6cd6a516d53c0bfd83769bdac1950483` + +#### Proof of ownership (hex) + +`534c00190001dc18066224b9e30e306303436dc18ab881c7266c13790350a3fe415e438135ec000140647d6af883107a870417e808abe424882bd28ee04a28ba85a7e99400e1b9485075733695964c2a0fa02d4439ab80830e9566ccbd10f2597f5513eff9f03a0497` + +Split into components: + +Name | Value +-------------------|------ +*versionMagic* | `534c0019` +*flags* | `00` +*n* | `01` +*id* | `dc18066224b9e30e306303436dc18ab881c7266c13790350a3fe415e438135ec` +*scriptSig* length | `00` +*scriptSig* | (empty) +*witness* | `0140647d6af883107a870417e808abe424882bd28ee04a28ba85a7e99400e1b9`
`485075733695964c2a0fa02d4439ab80830e9566ccbd10f2597f5513eff9f03a`
`0497` + +## References + +* [bitcoin-dev](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html): Original mailing list thread +* [BIP-0174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki): Partially Signed Bitcoin Transaction Format +* [BIP-0322](https://github.com/bitcoin/bips/blob/f9e95849f337358cd89c83b948fbede3875481c3/bip-0322.mediawiki): Generic Signed Message Format from March 25th 2020 diff --git a/slip-0020.md b/slip-0020.md new file mode 100644 index 00000000..71ebb290 --- /dev/null +++ b/slip-0020.md @@ -0,0 +1,28 @@ +# SLIP-0020 : Proof of User Confirmation + +``` +Number: SLIP-0020 +Title: Proof of User Confirmation +Type: Standard +Status: Draft +Authors: TBD +Created: 2019-04-25 +``` + +## Abstract + +This is a section for an abstract. + +## Motivation + +This is a section for a motivation. + +## Body + +This is a section for a body. The title of the section should be changed +and the section can be split into multiple sections and subsections. + +## References + +This is a section for references such as links to other documents (BIP or SLIP) +or to reference implementations. diff --git a/slip-0021.md b/slip-0021.md new file mode 100644 index 00000000..92ba394f --- /dev/null +++ b/slip-0021.md @@ -0,0 +1,98 @@ +# SLIP-0021 : Hierarchical derivation of symmetric keys + +``` +Number: SLIP-0021 +Title: Hierarchical derivation of symmetric keys +Type: Standard +Status: Final +Authors: Andrew R. Kozlik + Ondrej Vejpustek + Pavol Rusnak +Created: 2019-06-25 +``` + +## Abstract + +This document describes a method of deriving a hierarchy of symmetric keys from a master secret, such as the recovery seed used in cryptocurrency wallets. + +## Motivation + +The [BIP-0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) and [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) specifications define how to derive a hierarchy of private/public key pairs from a master seed for the elliptic curves secp256k1, NIST P-256 and ed25519. However, there does not exist any similar specification for the derivation of keys for symmetric-key algorithms, which are needed for example in password encryption or encryption of Bitcoin metadata. [SLIP-0011](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) deals with this problem by first using BIP-0032 to derive a secp256k1 private key and then deriving the symmetric key from this private key. However, BIP-0032 was not designed to be used in this way and it also implies that an implementation of SLIP-0011 requires secp256k1 arithmetic, which should not be needed for symmetric key derivation. The purpose of this specification is to lay down a common framework for the deterministic derivation of a hierarchy of symmetric keys from a master seed. + +## Master node generation + +We adapt the master node generation from BIP-0032 and SLIP-0010. To achieve proper domain separation from the secp256k1, NIST P-256 and ed25519 key hierarchies, we use the string “Symmetric key seed” instead of the curve name. Let *S* be the master secret, such as that defined in [SLIP-0039](https://github.com/satoshilabs/slips/blob/master/slip-0039.md) or the binary seed defined in [BIP-0039](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). Then the master node *m* is derived as follows: + +``` +m = HMAC-SHA512(key = b"Symmetric key seed", msg = S) +``` + +The master node is used to derive child nodes, each of which can in turn be used to derive lower-level child nodes of their own and so on. Each node is associated with a 256-bit symmetric key. The master node is thus the root of a key tree. + +## Child node derivation + +The child nodes of a parent node *N* are identified by a variable-length byte string called a *label*. The labels of all nodes which are derived from the master node, i.e., the first-level labels, MUST identify the purpose of the subordinate nodes. The purpose determines the further structure beneath the node. This label must be sufficiently unique to avoid collisions between applications. Examples include the ASCII encoding of the strings "BIP-9999", "SLIP-9999" or "FIDO2 Trezor Credential ID". + +The derivation function is defined as: + +``` +ChildNode(N, label) = HMAC-SHA512(key = N[0:32], msg = b"\x00" + label), +``` + +where *N*[0:32] is the first 32 bytes of node data. The key for a given node is defined as the last 32 bytes of the node data: + +``` +Key(N) = N[32:64] +``` + +## Example + +This example shows several keys derived from the master secret + +``` +S = c76c4ac4f4e4a00d6b274d5c39c700bb4a7ddc04fbc6f78e85ca75007b5b495f74a9043eeb77bdd53aa6fc3a0e31462270316fa04b8c19114c8798706cd02ac8 +``` + +which is the binary seed obtained from the BIP-0039 mnemonic "all all all all all all all all all all all all" with an empty passphrase. + +``` +Key(m) = dbf12b44133eaab506a740f6565cc117228cbf1dd70635cfa8ddfdc9af734756 +Key(m/"SLIP-0021") = 1d065e3ac1bbe5c7fad32cf2305f7d709dc070d672044a19e610c77cdf33de0d +Key(m/"SLIP-0021"/"Master encryption key") = ea163130e35bbafdf5ddee97a17b39cef2be4b4f390180d65b54cf05c6a82fde +Key(m/"SLIP-0021"/"Authentication key") = 47194e938ab24cc82bfa25f6486ed54bebe79c40ae2a5a32ea6db294d81861a6 +``` + +## Design rationale + +This standard is designed in accordance with [NIST SP 800-108](https://doi.org/10.6028/NIST.SP.800-108) Recommendation for Key Derivation Using Pseudorandom Functions. + +### Key length + +Each node is associated with a 256-bit symmetric key. This key length is considered sufficiently secure for a number of years to come, see [keylength.com](https://www.keylength.com/en/compare/). It is also compatible with all major symmetric-key algorithms in use today, such as AES-256, ChaCha20Poly1305 or HMAC. The key derivation functions specified in NIST SP 800-108 allow for the derivation of variable length keys. Nevertheless, since such a feature appears to be of little use, a fixed key length was chosen to keep the implementation of this SLIP as simple as possible. + +### Key separation + +The fact that each node is associated with a key of its own and uses a separate key for the derivation of child nodes is based on the principle that a single key should be used for only one purpose, e.g., encryption, integrity authentication, key derivation. The reasoning behind this principle is well known: + +1. The use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes. +2. Limiting the use of a key limits the damage that could be done if the key is compromised. +3. Some uses of keys interfere with each other. + +Most importantly, the scheme is designed so that the knowledge of Key(*N*) is independent of the ability to derive child nodes of *N*. Thus the compromise of Key(*N*) does not jeopardize any child keys of *N*. + +### Labeling child nodes + +In the BIP-0032 specification child nodes are indexed by a 31-bit integer. This is well suited for hierarchical wallets, but there are instances where it would be more convenient to be able to specify the derived key using a randomly generated value with sufficient entropy to avoid collisions. For such purposes a 31-bit index is insufficient. A variable-length byte string allows maximum flexibility in labeling nodes, for example by using a printable string, an encoded integer index or a 256-bit random value. + +### Child node derivation + +Since this derivation scheme is intended to be fully deterministic once the master secret is known, the context and separator as defined in NIST SP 800-108 are omitted from the HMAC-SHA512 input. The counter and the length of the derived key are also omitted from the input, because they are constant. + +The value of the message entering the HMAC-SHA512 function is a null byte followed by the label of the child node. The reason for this is that the first byte of the message value is reserved for future use. It can be used for domain separation in case support for other types of labels is desired. + +## References + +* [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) +* [SLIP-0010: Universal private key derivation from master private key](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) +* [SLIP-0011: Symmetric encryption of key-value pairs using deterministic hierarchy](https://github.com/satoshilabs/slips/blob/master/slip-0011.md) +* [NIST Special Publication 800-108: Recommendation for Key Derivation Using Pseudorandom Functions](https://doi.org/10.6028/NIST.SP.800-108) diff --git a/slip-0022.md b/slip-0022.md new file mode 100644 index 00000000..d4782f7a --- /dev/null +++ b/slip-0022.md @@ -0,0 +1,198 @@ +# SLIP-0022 : FIDO2 credential ID format for HD wallets + +``` +Number: SLIP-0022 +Title: FIDO2 credential ID format for HD wallets +Type: Standard +Status: Final +Authors: Andrew R. Kozlik + Pavol Rusnak + Ondrej Vejpustek +Created: 2019-07-19 +``` + +## Abstract + +This document describes an interoperable format for FIDO2 credential IDs for use in hierarchical deterministic wallets. + +## Motivation + +A FIDO2 credential ID is a probabilistically-unique byte sequence identifying a public key credential. It is generated by the authenticator during registration and stored by the relying party and optionally by the authenticator itself. One way to generate a credential ID is to encrypt all credential data so that only its managing authenticator can decrypt it. This kind of credential ID allows the authenticator to be nearly stateless, by having the relying party store any necessary state. Currently there is no standardized way of formatting the credential data into this kind of credential ID. This specification defines a format for credential IDs designed for use in hierarchical deterministic wallets, which are distinctive in that they derive a hierarchy of cryptographic keys from a single master secret, such as that defined in [SLIP-0039](https://github.com/satoshilabs/slips/blob/master/slip-0039.md) or the binary seed defined in [BIP-0039](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). This format may also be used for U2F key handles. + +## Credential ID format + +A SLIP-0022 credential ID is a byte string between 33 and 65535 bytes in length of the following form: + +Version | Initialization vector | Encrypted credential data | Authentication tag +--------|-----------------------|---------------------------|------------------- +4 bytes | 12 bytes | variable length | 16 bytes + +The version is the byte string "`\xf1\xd0\x02\x00`" in case of FIDO2 credential IDs and "`\xf1\xd0\x01\x01`" in case of U2F key handles. The initialization vector, which is used as input to the Chacha20Poly1305 cipher, is generated randomly for each new credential ID. The Poly1305 authentication tag is used to verify that the credential ID belongs to the authenticator. + +## Credential data encoding + +Credential data members are encoded using a [CBOR](https://datatracker.ietf.org/doc/html/rfc7049) map (CBOR major type 5) with keys of unsigned integer type, similar to how CTAP2 command parameters and response members are encoded. The CBOR map must be encoded using the definite length variant. Some members are optional, therefore the length of the credential data map may vary. + +The map keys and value types are specified below: + +Member name | Key | Value type | Required | Definition +----------------|-----|---------------------------------------|-----------------------------|------------------------- +rpId | 1 | Text string (CBOR major type 3). | Required for FIDO2. | Relying party identifier. The "id" member of the rp parameter from the authenticatorMakeCredential request. +rpName | 2 | Text string (CBOR major type 3). | Optional. | Relying party name. The "name" member of the rp parameter from the authenticatorMakeCredential request. +userId | 3 | Byte string (CBOR major type 2). | Required for FIDO2. | User account ID. The "id" member of the user parameter from the authenticatorMakeCredential request. +userName | 4 | Text string (CBOR major type 3). | Optional. | User account name. The "name" member of the user parameter from the authenticatorMakeCredential request. +userDisplayName | 5 | Text string (CBOR major type 3). | Optional. | User account display name. The "displayName" member of the user parameter from the authenticatorMakeCredential request. In case of U2F the user may be prompted to enter a custom display name during registration. +creationTime | 6 | Unsigned integer (CBOR major type 0). | Required for FIDO2. | Any value which allows credentials to be sorted by the time of their creation, such as the UNIX timestamp or the value of an incremental counter at the moment of creation. +hmacSecret | 7 | Boolean (CBOR simple value 20 or 21). | Optional. False by default. | Indicates whether the credential was created with the hmac-secret extension set to true. +useSignCount | 8 | Boolean (CBOR simple value 20 or 21). | Optional. False by default for FIDO2. Absent for U2F. | If false, all operations with the credential must use zero as the signature counter value. If true, the credential must use a signature counter which is incremented for each successful authenticatorGetAssertion operation. +algorithm | 9 | Integer (CBOR major type 0 or 1) | Required if the "curve" field is present, otherwise optional. | The COSE identifier of the algorithm to be used for generating assertion signatures, as specified in the IANA COSE Algorithms Registry [IANA-COSE-ALGS-REG](https://www.iana.org/assignments/cose/cose.xhtml#algorithms). +curve | 10 | Integer (CBOR major type 0 or 1) | Required if the "algorithm" field specifies an elliptic curve signature algorithm. | The COSE identifier of the elliptic curve to be used for generating assertion signatures, as specified in the IANA COSE Elliptic Curves Registry [IANA-COSE-EC-REG](https://www.iana.org/assignments/cose/cose.xhtml#elliptic-curves). + +If the "algorithm" field is not present, then the algorithm defaults to ES256 (-7) and the curve defaults to P-256 (1). + +Credential data MUST be encoded using the CTAP2 canonical CBOR encoding form as specified in [Section 6](https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#message-encoding) of the FIDO Client to Authenticator Protocol (CTAP) v2.0. + +### Example of credential data encoding + +A credential data object in CBOR diagnostic notation: + +``` +credentialData = { + 1: "example.com", + 3: h'3082019330820138A0030201023082019330820138A003020102308201933082', + 4: "johnpsmith@example.com", + 6: 2, + 7: true +}; +``` + +would be CBOR encoded as follows: + +``` +a5 # map(5) + 01 # unsigned(1) - rpId + 6b # text(11) + 6578616d706c652e636f6d # "example.com" + 03 # unsigned(3) - userId + 58 20 # bytes(32) + 3082019330820138a003020102 # userid + 3082019330820138a003020102 # ... + 308201933082 # ... + 04 # unsigned(4) - userName + 76 # text(22) + 6a6f686e70736d697468406578616d # "johnpsmith@example.com" + 706c652e636f6d # ... + 06 # unsigned(6) - creationTime + 02 # unsigned(2) - the second credential created + # with this authenticator + 07 # unsigned(7) - hmacSecret + f5 # primitive(21) - true +``` + +## Encryption + +The CBOR encoded credential data is encrypted using Chacha20Poly1305 as defined in [RFC 8439](https://tools.ietf.org/html/rfc8439). In case of FIDO2 the SHA-256 hash of the rpId is used as the AAD input to the cipher. In case of U2F the application parameter (SHA-256 hash of the UTF-8 encoding of the application identity) is used as the AAD input to the cipher. + +The encryption key *k* is the same for all credential IDs of the same version which are generated by an authenticator with a given master secret. The key is derived from the master secret using the [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md) method for hierarchical derivation of symmetric keys as: + +``` +k = Key(m/"SLIP-0022"/version/"Encryption key") +``` + +where *version* is the first four bytes of the credential ID, for example "`\xf1\xd0\x02\x00`" in case of FIDO2 credential IDs. + +## Derivation of the credential key pair + +The credential key pair used for generating assertion signatures is derived from a master secret and from the version and authentication tag of the credential ID using the [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) key derivation scheme. The key path is computed from the authentication tag by splitting it into four 4-byte values A, B, C and D which are interpreted as 32-bit integers in big-endian byte order. The highest bit in each integer is set and the key path is: + +``` +m/10022'/version'/A'/B'/C'/D' +``` + +where *version* is the first four bytes of the credential ID interpreted as a 32-bit integer in big-endian byte order, for example "0xf1d00200" in case of FIDO2 credential IDs. + +## Derivation of hmac-secret CredRandom + +The CredRandom value used in the hmac-secret extension is derived from the master secret and the credential ID using the SLIP-0021 method for hierarchical derivation of symmetric keys as: + +``` +CredRandom = Key(m/"SLIP-0022"/version/"hmac-secret"/credentialId) +``` + +where *version* is the first four bytes of the credential ID. + +## Signature counter + +The purpose of the signature counter is to aid relying parties in detecting cloned authenticators. Hierarchical deterministic wallets use a master secret, which can be backed-up and used for device recovery or legitimately used to create a clone of the device. Implementation of a signature counter impedes these use cases. Fortunately, FIDO2 allows authenticators to choose whether a credential will or will not use a signature counter. In the latter case the value of the signature counter remains constant at zero in all authenticatorMakeCredential responses and authenticatorGetAssertion responses. It is therefore recommended that authenticators do not create FIDO2 credentials with the "useSignCount" field set to true, unless required by the relying party. + +The above does not apply to U2F key handles, because the U2F protocol requires the implementation of a signature counter. In case of U2F key handles the "useSignCount" field MUST NOT be present. + +## Example + +Unless stated otherwise, the values given below are encoded as strings containing two hexadecimal digits for each byte. + +The following is an example of a credential ID and the corresponding keys belonging to an authenticator with the master secret `S`. The credential data stored in the ID is the same as that given in the previous example: + +``` +credentialId = "f1d0020013e65c865634ad8abddf7a66df56ae7d8c3afd356f76426801508b2e579bcb3496fe6396a6002e3cd6d80f6359dfa9961e24c544bfc2f26acec1b8d878ba56727e1f6a7b5176c607552aea63a5abe5d826d69fab3063edfa0201d9a51013d69eddb2eff37acdd5963f" +``` + +``` +S = "c76c4ac4f4e4a00d6b274d5c39c700bb4a7ddc04fbc6f78e85ca75007b5b495f74a9043eeb77bdd53aa6fc3a0e31462270316fa04b8c19114c8798706cd02ac8" +``` + +Note that `S` is the binary seed obtained from the BIP-0039 mnemonic "all all all all all all all all all all all all" with an empty passphrase. + +Credential data encryption key: + +``` +k = "5b60f6c30e5ef87a5f6756242c98f487da0ca7c173282737660e7bc320fad6cf" +``` + +Credential key pair, the private key is encoded as an integer in base 10: + +``` +privateKey = 17028406872725666093318073001284158176462610154049610120643103153631976435873 + +publicKey = "0451f0d4c307bc737c90ac605c6279f7d01e451798aa7b74df550fdb43a7760c7c02b5107fef42094d00f52a9b1e90afb90e1b9decbf15a6f13d4f882de857e2f4" +``` + +CredRandom value used in the hmac-secret extension: + +``` +CredRandom = "36a9b5d71c13ed54594474b54073af1fb03ea91cd056588909dae43ae2f35dbf" +``` + +## Design rationale + +### Choice of encoding + +CBOR encoding is used for serialization throughout the CTAP2 protocol. Therefore any authenticator supporting FIDO2 must support CBOR, making it the natural choice for encoding credential data. Encoding the data as a map allows easy handling of optional members, deprecating old members and introducing new members. + +### Data encryption and authentication + +Generally the data members contained in the credential ID are stored alongside the credential ID or are transmitted on the same channel. Therefore, there does not appear to be a strong reason to encrypt the credential ID content. However, encrypting it allows the credential ID to be separated from the account information so that it is meaningless in isolation. Furthermore, in the future new data members requiring confidentiality may need to be added. In that case it is easier to manage encryption of the entire credential data map rather than its individual members. + +The random 96-bit initialization vector ensures that even if a user were to generate 232 credentials, then the likelihood of a collision occurring would be below 2−32. Since every credential generation requires user consent, this length provides a sufficient guarantee of IV uniqueness. + +The authentication tag is required to prevent an attacker from tampering with credential data and to avoid DOS attacks. + +According to the Web Authentication specification the RP ID is provided by the client to the authenticator for all operations, and the authenticator ensures that credentials created by a relying party can only be used in operations requested by the same RP ID. Using the RP ID as AAD input to the cipher enforces this requirement. + +### Key pair derivation + +The rationale behind using the authentication tag for the SLIP-0010 key path is as follows: + +* The key path is not a confidential piece of information so it does not need to be encrypted or derived with the knowledge of a secret key. +* The key path should depend on the credential information and on the relying party identifier, which is always provided as AAD when computing the authentication tag. +* There should be an element of randomness so that different keys are generated even if the credential information is the same. Consider for example a relying party which insists on rotating the authentication key every three months and keeps track of old keys. The randomness is ensured by the fact that the IV is generated randomly. +* Key path collisions should be near impossible to ensure unlinkability of various online identities of the same user. The likelihood of a collision occurring between authentication tags is even smaller than in the case of initialization vectors. + +## References + +* [Web Authentication](https://www.w3.org/TR/webauthn/): An API for accessing Public Key Credentials Level 1, W3C Recommendation, 4 March 2019 +* [FIDO Client to Authenticator Protocol (CTAP) v2.0](https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#sctn-hmac-secret-extension), Proposed Standard, January 30, 2019 +* [IANA-COSE-REG](https://www.iana.org/assignments/cose/cose.xhtml): IANA CBOR Object Signing and Encryption (COSE) Registries. +* [RFC 7049](https://tools.ietf.org/html/rfc7049): Concise Binary Object Representation (CBOR) +* [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md): Universal private key derivation from master private key +* [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md): Hierarchical derivation of symmetric keys diff --git a/slip-0023.md b/slip-0023.md new file mode 100644 index 00000000..3c8c14f6 --- /dev/null +++ b/slip-0023.md @@ -0,0 +1,122 @@ +# SLIP-0023 : Cardano HD master node derivation from a master seed + +``` +Number: SLIP-0023 +Title: Cardano HD master node derivation from a master seed +Type: Standard +Status: Final +Authors: Andrew R. Kozlik +Created: 2019-07-24 +``` + +## Abstract + +This specification describes how to derive the master node, aka root node, of the key tree in Cardano hierarchical deterministic wallets. + +## Motivation + +Cryptocurrency wallets generally work by combining a [BIP-0039](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) mnemonic or a set of [SLIP-0039](https://github.com/satoshilabs/slips/blob/master/slip-0039.md) mnemonics with a user-entered passphrase to generate a master seed. This master seed is then used to derive a hierarchy of cryptographic keys as defined in [BIP-0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) and [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md). + +Cardano hierarchical deterministic wallets use an extended private key which requires them to implement a custom adaptation of the BIP-0032 child key derivation scheme. The Cardano wallets currently in existence implement several mutually incompatible schemes for the derivation of the master node from a BIP-0039 mnemonic and passphrase. Unfortunately all of these derivation schemes fail to separate the derivation of the seed from the derivation of the key tree, making it impossible to integrate them with new seed derivation schemes. This specification aims to rectify this by defining a new scheme for the derivation of the master node from a seed. The new scheme is primarily intended for use with SLIP-0039 Shamir's Secret-Sharing for Mnemonic Codes. + +## Cardano universal master node derivation + +This scheme adapts the master node derivation used in BIP-0032 and SLIP-0010 by defining a new curve name "ed25519 cardano seed" for the Ed25519 curve with the Cardano deterministic key hierarchy. The curve name is used as salt in BIP-0032 and SLIP-0010 when deriving the master node from the seed. This is necessary to ensure proper domain separation between different elliptic curves or different types of key hierarchies. The root extended private key (*k*L, *k*R) is computed by taking the SHA-512 hash of the root private key *I*L, modifying certain bits to make it a valid EdDSA key and clearing the third highest bit of *k*L to ensure compatibility with Cardano child key derivation. + +1. Let *S* be a seed byte sequence such as the master secret from SLIP-0039. +2. Calculate *I* := HMAC-SHA512(Key = "ed25519 cardano seed", Data = *S*). +3. Split *I* into two 32-byte sequences, *I*L := *I*[0:32] and *I*R := *I*[32:64]. +4. Let *k* := SHA-512(*I*L). +5. Modify *k* by assigning *k*[0] := *k*[0] & 0xf8 and *k*[31] := (*k*[31] & 0x1f) | 0x40. +6. Interpret *k*[0:32] as a 256-bit integer *k*L in little-endian byte order. Let *k*R := *k*[32:64] and use (*k*L, *k*R) as the root extended private key and *c* := *I*R as the root chain code. + +## Cardano Icarus master node derivation + +The Icarus master node derivation scheme, aka V2 derivation scheme, is commonly used with BIP-0039 in Cardano wallets. Since there does not exist any specification of this scheme, its description is included below for completeness. + +1. Let *M* be a BIP-0039 mnemonic and *P* the passphrase entered by the user. +2. Determine the initial entropy *E* that was used to generate *M*. +3. Compute *S* := PBKDF2-HMAC-SHA512(password = *P*, salt = *E*, iterations = 4096, dkLen = 96). +4. Modify *S* by assigning *S*[0] := *S*[0] & 0xf8 and *S*[31] := (*S*[31] & 0x1f) | 0x40. +5. Interpret *S*[0:32] as a 256-bit integer *k*L in little-endian byte order. Let *k*R := *S*[32:64] and use (*k*L, *k*R) as the root extended private key and *c* := *S*[64:96] as the root chain code. + +## Child key derivation + +The derivation of child keys in the Cardano deterministic key hierarchy is specified in [BIP32-Ed25519](https://doi.org/10.1109/EuroSPW.2017.47) and also described in the [Cardano documentation](https://github.com/input-output-hk/technical-docs/blob/main/cardano-components/cardano-wallet/doc/Wallet-Cryptography-and-Encoding.md#hierarchical-deterministic-wallets). + +## Compliance + +When SLIP-0039 is used as the source of the master secret the master node for the Cardano deterministic key hierarchy MUST be derived using the Cardano universal master node derivation scheme as specified [above](#cardano-universal-master-node-derivation). + +When BIP-0039 is used as the source of the master secret the master node for the Cardano deterministic key hierarchy SHOULD be derived using the Cardano Icarus master node derivation scheme to maintain compatibility with existing wallets. + +## Test vectors + +In the following test vectors the values of *S*, *k*R, *A* and *c* are each encoded as a string containing two hexadecimal digits for each byte. The value of *k*L is encoded as an integer in base 10. + +### Test vector 1 for Cardano universal master node derivation (128 bits) + +Let the seed be *S* = "578d685d20b602683dc5171df411d3e2". + +Note that *S* is the master secret obtained from the following three SLIP-0039 share mnemonics with the passphrase "TREZOR": + +* "extra extend academic bishop cricket bundle tofu goat apart victim enlarge program behavior permit course armed jerky faint language modern", +* "extra extend academic acne away best indicate impact square oasis prospect painting voting guest either argue username racism enemy eclipse", +* "extra extend academic arcade born dive legal hush gross briefing talent drug much home firefly toxic analysis idea umbrella slice". + +The root extended private key is:
+*k*L = 38096432269777187972282727382530464140043628323029465813805073381215192153792
+*k*R = "4064253ffefc4127489bce1b825a47329010c5afb4d21154ef949ef786204405" + +The root public key is:
+*A* = "83e3ecaf57f90f022c45e10d1b8cb78499c30819515ad9a81ad82139fdb12a90" + +The root chain code is:
+*c* = "22c12755afdd192742613b3062069390743ea232bc1b366c8f41e37292af9305" + +The address for the derivation path 44'/1815'/0'/0/0 is:
+Ae2tdPwUPEYxF9NAMNdd3v2LZoMeWp7gCZiDb6bZzFQeeVASzoP7HC4V9s6 + +The address for the derivation path 44'/1815'/0'/0/1 is:
+Ae2tdPwUPEZ1TjYcvfkWAbiHtGVxv4byEHHZoSyQXjPJ362DifCe1ykgqgy + +The address for the derivation path 44'/1815'/0'/0/2 is:
+Ae2tdPwUPEZGXmSbda1kBNfyhRQGRcQxJFdk7mhWZXAGnapyejv2b2U3aRb + +### Test vector 2 for Cardano universal master node derivation (256 bits) + +Let the seed be *S* = "a055b781aac0c9dc1bfb7d803bc8ffd5d4392e506db2e4a5a93f0aba958c5be7". + +Note that this is the master secret obtained from the two SLIP-0039 share mnemonics with the passphrase "TREZOR": + +* "hobo romp academic axis august founder knife legal recover alien expect emphasis loan kitchen involve teacher capture rebuild trial numb spider forward ladle lying voter typical security quantity hawk legs idle leaves gasoline", +* "hobo romp academic agency ancestor industry argue sister scene midst graduate profile numb paid headset airport daisy flame express scene usual welcome quick silent downtown oral critical step remove says rhythm venture aunt". + +The extended private key is:
+*k*L = +35870817594148037193235249761081259065186522922583196642112477624627719791504 +
+*k*R = "f9d99bf3cd9c7e12663e8646afa40cb3aecf15d91f2abc15d21056c6bccb3414" + +The root public key is:
+*A* = "eea170f0ef97b59d22907cb429888029721ed67d3e7a1b56b81731086ab7db64" + +The root chain code is:
+*c* = "04f1de750b62725fcc1ae1b93ca4063acb53c486b959cadaa100ebd7828e5460" + +The address for the derivation path 44'/1815'/0'/0/0 is:
+Ae2tdPwUPEYyDD1C2FbVJFAE3FuAxLspfMYt29TJ1urnSKr57cVhEcioSCC + +The address for the derivation path 44'/1815'/0'/0/1 is:
+Ae2tdPwUPEZHJGtyz47F6wD7qAegt1JNRJWuiE36QLvFzeqJPBZ2EBvhr8M + +The address for the derivation path 44'/1815'/0'/0/2 is:
+Ae2tdPwUPEYxD9xNPBJTzYmtFVVWEPB6KW4TCDijQ4pDwU11wt5621PyCi4 + +## References + +* [BIP-0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki): Hierarchical Deterministic Wallets +* [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md): Universal private key derivation from master private key +* [BIP-0039](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki): Mnemonic code for generating deterministic keys +* [SLIP-0039](https://github.com/satoshilabs/slips/blob/master/slip-0039.md): Shamir's Secret-Sharing for Mnemonic Codes +* D. Khovratovich and J. Law: [BIP32-Ed25519 Hierarchical Deterministic Keys over a Non-linear Keyspace](https://doi.org/10.1109/EuroSPW.2017.47) diff --git a/slip-0024.md b/slip-0024.md new file mode 100644 index 00000000..a0b57914 --- /dev/null +++ b/slip-0024.md @@ -0,0 +1,231 @@ +# SLIP-0024 : Trezor payment request format + +``` +Number: SLIP-0024 +Title: Trezor payment request format +Type: Standard +Status: Draft +Authors: Andrew Kozlik +Created: 2021-12-09 +``` + +## Abstract + +A Trezor payment request is a message that is signed by a trusted party requesting payment of a specified amount to one or more addresses, similar in principle to [BIP-0070](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki). +This message can be processed by a payer's wallet in such a way that the payer does not have to inspect the destination address and only needs to confirm the payment of the requested amount to the recipient that is named in the payment request. + +## Motivation + +Before a cryptocurrency payment can be made, the recipient of the payment needs to securely communicate their receiving address to the payer. If the communication channel between the two parties is not well secured or if one of the endpoints is compromised by malware, then an attacker may modify the address, changing it to the attacker's own address in order to receive the payment instead of the legitimate recipient. This type of attack is known as *address spoofing*. + +Hardware wallets are known to be the most secure solution to cryptocurrency payments. They are generally very resilient to malware, but they do not protect the payer from address spoofing outside of the wallet. The task of authenticating the address is up to the payer who should ideally verify the correctness of the address by means of a second channel. Using multiple channels to communicate the address reduces the likelihood of an attacker being able to compromise all of them at once, but at the same time it hinders the user experience. + +This specification defines a new format of payment requests which aim to make cryptocurrency payments in hardware wallets safer and more user-friendly by allowing automated authentication of merchant's addresses using digital signatures. + +### Differences over BIP-0070 + +The Trezor payment request format is heavily inspired by the earlier [BIP-0070](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) specification. The main ways in which the present specification differs over BIP-0070 are summarized below. + +* Adapted to the needs of hardware wallets. + * A nonce challenge is used to guarantee freshness instead of creation/expiry time, since the current time is not reliably available in hardware wallets. + * The way in which the payment request data is hashed is optimized for memory-constrained environments. + * PKI is considered out of scope of this specification, thus X.509 support is not required. +* Designed for use with multiple cryptocurrencies. +* Defines new types of memo fields, which allow for new use-cases. +* The signature is required. + +## Payment request items + +### Recipient name + +The recipient name is shown to the payer instead of the address or addresses which the payment request represents. The payer must however have the option of inspecting the addresses on the wallet's screen if they wish. + +### Memos + +Memos are used to provide additional information to the payer about the purpose of the payment request. +A memo may also contain information that needs to be verified by the payer or their wallet. By making the payment to the specified address the payer confirms that the information in the memo is correct. + +A payment request may contain multiple instances of the same memo type. +For a memo type that is displayed to the payer, all instances of that memo type MUST be displayed in the same order as they are listed in the payment request. + +The following types of memos are defined. + +#### Text memo + +A text memo is a UTF-8 encoded, plain-text note explaining the purpose of the payment request. +The note MUST be displayed to the payer in full. + +#### Refund memo + +A refund memo specifies the address where the payment should be refunded to the customer if necessary. +The customer's wallet MUST verify that it controls this address, see [Verifying address ownership](#verifying-address-ownership). +The wallet does not have to display this information on the screen. + +#### Text details memo + +A text details memo is a plain-text note containing additional details about the payment request. It consists of a title and a text body. +The note MAY be displayed to the payer either automatically, upon their request, or not displayed at all, namely if the device has limited capabilities. + +#### Coin purchase memo + +A coin purchase memo can be used by a cryptocurrency exchange service to inform their customer about the cryptocurrency and amount that the customer will receive in exchange for the payment they make. The customer's wallet MUST display this information on the screen. The coin purchase memo also specifies the address to which the exchange will send the cryptocurrency purchased by the customer. The customer's wallet MUST verify that it controls this address, see [Verifying address ownership](#verifying-address-ownership). + +### Nonce + +A unique challenge generated by the payer's wallet. The nonce guarantees freshness of the payment request and prevents replaying the payment request to the wallet or to another wallet. A nonce SHOULD be present whenever one or more memos are present in the payment request. + +### Requested outputs + +A list of destination addresses with requested amounts. The payer is requested to pay the specified amount to each of the listed addresses. + +### Payment request signature + +A digital signature of the payment request issued by a party which is trusted by the payer. + +## Trusted party + +The definition of a trusted party is out of scope of this specification. It is up to the wallet vendor to choose how trusted parties are defined. For example, they may be defined by one or more pinned public keys in the wallet's firmware or the trusted public keys may be user-defined. Trust can also be derived from a PKI scheme, such as X.509 in the BIP-0070 specification. However, it should be noted that X.509 is not very well suited for use in hardware wallets due to its excessive complexity, e.g. certificate extensions, expiry dates or certificate validation and revocation rules. Each trusted party may be restricted to signing payment requests only for particular recipient names. + +## Workflows + +The following describes several scenarios involving a customer paying a merchant using cryptocurrency. The customer has a hardware wallet and a wallet application running on their computer which controls the hardware wallet. The merchant has access to a signing server whose signatures are trusted by the customer's wallet. + +### Basic scenario + +1. The customer creates an order with the merchant and chooses to pay using Bitcoin. +2. The merchant generates a unique receiving address for the customer's order. +3. The merchant authenticates itself to the signing server and sends it the receiving address and amount to be paid. +4. The signing server returns a signed payment request to the merchant containing the merchant's name, receiving address and amount to be paid. +5. The merchant verifies that the signature matches the provided data and generates a BIP-0021 URI with the payment request signature in `slip24sig` as described [below](#usage-with-the-bip-0021-uri-scheme). +6. The customer clicks the BIP-0021 URI which opens their wallet application. +7. The wallet application creates a transaction transferring the requested amount to the merchant's address. +8. The wallet application requests a transaction signature from the hardware wallet, providing the payment request data. +9. The hardware wallet verifies that the payment request signature was issued by a trusted party and displays a confirmation dialog to the user stating the merchant's name and amount to be sent. +10. The customer confirms the dialog and the hardware wallet generates the transaction signature. +11. The wallet application broadcasts the signed transaction. +12. The merchant monitors the blockchain for a transaction transferring the requested amount to its receiving address. + +If the trusted signing server is operated by a hardware wallet vendor, then in step 1 the customer may need to select the vendor of their wallet. The server may also be operated by the merchant itself, in which case the customer will have had to load the merchant's public key into their hardware wallet in advance. + +### Scenario with a refund memo + +1. The customer's wallet application selects an address which belongs to the customer and is suitable for receiving the refund of a payment. +2. The wallet application obtains two items from the hardware wallet: + * an address authentication code for the selected refund address and + * a nonce challenge, which the hardware wallet also records in a nonce cache in its volatile memory. +3. The wallet application provides the customer's refund address and nonce challenge to the merchant who will be receiving the payment. +4. The merchant generates a unique receiving address for the payment request. +5. The merchant authenticates itself to the signing server and sends it its receiving address, the amount to be paid, the customer's refund address and nonce challenge. +6. The signing server returns a signed payment request to the merchant. +7. The merchant verifies that the signature matches the provided data and returns the payment request to the customer's wallet application. +8. The wallet application creates a transaction transferring the requested amount to the merchant's address. +9. The wallet application requests a transaction signature from the hardware wallet, providing the payment request data together with the address authentication code of the refund address. +10. The hardware wallet takes the following steps: + * Verifies that it issued the nonce challenge by checking its nonce cache and removes it from the cache so that the payment request cannot be reused in the future. + * Verifies that it controls the refund address by validating the address authentication code. + * Verifies that the payment request signature was issued by a trusted party. + * Displays a confirmation dialog to the user stating the merchant's name and amount to be sent. +11. The customer confirms the dialog and the hardware wallet generates the transaction signature. +12. The wallet application broadcasts the signed transaction. +13. The merchant monitors the blockchain for a transaction transferring the requested amount to its receiving address. +14. If the merchant needs to refund the payment, then it may send it to the refund address that was specified in the payment request without any further interaction with the customer. + +## Signature generation + +The payment request signature is generated by signing the *paymentRequestDigest* using the private key of the trusted party. +The default signature scheme is ECDSA with SHA-256 and the curve secp256k1, but any other suitable signature scheme may be chosen by the trusted party instead. In case of the default scheme the signature is encoded in 64 bytes. The first 32 bytes encode the *r* component of the signature and the second 32 bytes encode the *s* component, both in big-endian byte order. + +The *paymentRequestDigest* is computed by hashing the concatenation of the following fields: + +* *versionMagic* (4 bytes): b"\x53\x4c\x00\x24" (this is "SL" followed by 0024 in compressed numeric form as an abbreviation for "SLIP-0024"). +* *nonce* (length-prefixed binary string): an optional nonce challenge from the wallet. If a nonce is not used, then a zero-length string should be provided. +* *recipientName* (length-prefixed UTF-8 string): a human-readable string identifying the recipient of the payment. +* *n* (CompactSize integer): the number of memos which follow. The CompactSize integer MUST be encoded in the fewest possible number of bytes. +* *memo*1 || *memo*2 || ... || *memo**n* (variable length): concatenation of the binary encoding of the memos, see below. +* *coinType* (4 bytes): 32-bit encoding of the SLIP-0044 coin type of the outputs in little-endian byte order. +* *outputsHash* (32 bytes): the hash of the binary encodings of all requested outputs, see below. + +A text memo is encoded as the concatenation of the following fields: + +* *memoType* (4 bytes): b"\x01\x00\x00\x00" (32-bit encoding of the integer 1 in little-endian byte order). +* *text* (length-prefixed UTF-8 string): a human-readable string providing information about the purpose of the payment. + +A refund memo is encoded as the concatenation of the following fields: + +* *memoType* (4 bytes): b"\x02\x00\x00\x00" (32-bit encoding of the integer 2 in little-endian byte order). +* *address* (length-prefixed string): the address where the payment should be refunded if necessary. + +A coin purchase memo is encoded as follows: + +* *memoType* (4 bytes): b"\x03\x00\x00\x00" (32-bit encoding of the integer 3 in little-endian byte order). +* *coinType* (4 bytes): 32-bit encoding of the SLIP-0044 coin type of the address where the coin purchase will be delivered in little-endian byte order. +* *amount* (length-prefixed UTF-8 string): the human-readable amount the address will receive including units, e.g. "0.025 BTC". +* *address* (length-prefixed string): the address where the coin purchase will be delivered. + +A text details memo is encoded as the concatenation of the following fields: + +* *memoType* (4 bytes): b"\x04\x00\x00\x00" (32-bit encoding of the integer 4 in little-endian byte order). +* *title* (length-prefixed UTF-8 string): a human-readable heading for the text. +* *text* (length-prefixed UTF-8 string): a human-readable string containing additional details about the payment. + +The value of *outputsHash* is computed as the hash of the concatenation of the binary encodings of the requested outputs. The binary encoding of an output is the concatenation of the following fields: + +* *amount* (*coinType*-dependent length): fixed-length encoding of the amount of the requested output in little-endian byte order, expressed in the smallest unit of the given cryptocurrency (satoshis, wei, etc.). The length of the encoding is equal to the length used natively for the given *coinType* to encode amounts, e.g. 8 bytes for Bitcoin-like coins and 32 bytes for EVM assets. +* *address* (length-prefixed string): the address of the requested output. + +All variable-length fields are encoded the same way as in Bitcoin transactions, as a [length-prefixed string](https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_string), where the length is encoded as a variable-length CompactSize integer. + +### Coin-specific encoding rules + +In case of *coinType* 144 (XRP), if a requested output includes a destination tag, then the address field in the binary encoding of the output is appended with the string `?dt=`, followed by the destination tag formatted as a decimal integer in the fewest possible number of characters. + +## Usage with the BIP-0021 URI scheme + +[BIP-0021](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) specifies a URI scheme for encoding Bitcoin payment requests. The present specification defines a new query key `slip24sig` for BIP-0021 URIs, allowing the URI to encode a basic Trezor payment request. If the `slip24sig` field is specified in the URI the `amount` and `label` fields MUST also be specified. + +The value of `slip24sig` is the base64 encoding of the SLIP-0024 payment request signature. Note that any `=` characters in the base64 encoding must be percent-encoded as `%3D`. When computing the hash of the payment request the *recipientName* is taken from the`label` field of the URI. If the `message` field is specified in the URI, then the message is processed as a text memo. The *outputsHash* value is the hash of exactly one output specified by the `address` and `amount` fields of the URI. A nonce is not used and the *coinType* is 0. + +## JSON schema + +Use-cases involving multiple outputs or nonces require a more complex protocol than BIP-0021. For this purpose a JSON schema will be defined to document the data interchange format between the merchant and customer's wallet application. The same format may also be used for communicating payment requests between the merchant and the signing server. + +TODO + +## Verifying address ownership + +This section is non-normative. One of the requirements in processing a refund memo or a coin purchase memo is that the customer's wallet must verify that the specified address is controlled by the wallet. The most common way of verifying address ownership by a wallet is to provide the BIP-0032 derivation path leading from the wallet's seed to the address. In cases where the address belongs to another coin type or uses non-standard parameters, address derivation can be more complicated. + +In order to simplify the communication protocol with the wallet, it is more convenient to verify address ownership by means of an address authentication code. When getting an address from the hardware wallet, the wallet can return an authentication code together with the address. This authentication code is saved by the calling application and used at a later point in time to prove to a stateless hardware wallet that the address was derived from its seed. + +### Address authentication code in Trezor + +The address authentication code defined in this section should only be issued for addresses that are fully controlled by the wallet, i.e. only for non-multisig addresses. + +Let *k* be a secret *address authentication key* derived from the wallet's master secret using the [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md) method for hierarchical derivation of symmetric keys as: + +``` +k = Key(m/"SLIP-0024"/"Address MAC key") +``` + +The address authentication code is computed as: + +``` +mac = HMAC-SHA256(key = k, msg = addressInfo) +``` + +where `addressInfo` is the concatenation of the following fields: + +* *coinType* (4 bytes): 32-bit encoding of the SLIP-0044 coin type of the address in little-endian byte order. +* The BIP-0032 path to derive the address from the master node, which consists of: + * *n* (CompactSize integer): the path length. + * *i*1 || *i*2 || ... || *i**n* (variable length): concatenation of the 32-bit encodings of the child indices, each in little-endian byte order. +* *address* (length-prefixed string): the address being authenticated. + +## Test vectors + +TODO + +## References + +* [BIP-0021](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki): URI Scheme +* [BIP-0070](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki): Payment Protocol diff --git a/slip-0025.md b/slip-0025.md new file mode 100644 index 00000000..ea5d755e --- /dev/null +++ b/slip-0025.md @@ -0,0 +1,120 @@ +# SLIP 25 : Key derivation for CoinJoin accounts + +``` +Number: SLIP-0025 +Title: Key derivation for CoinJoin accounts +Type: Standard +Status: Draft +Authors: Andrew R. Kozlik +Created: 2022-04-04 +``` + +## Abstract + +This document defines a logical hierarchy for deterministic wallets based on the algorithm defined in [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) and [SLIP 10](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) and the scheme described in [BIP 43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki). +The purpose of this document is largely the same as [BIP 86](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki), however the keys derived using the present hierarchy are meant to be used in so called *CoinJoin accounts*, which are managed by CoinJoin wallets. + +## Motivation + +A CoinJoin wallet allows its users to participate in a special kind of transaction which mixes the user's UTXOs with the UTXOs of other participants in order to obfuscate the ownership of the resulting CoinJoin outputs to external observers. +Each user receives the same amount from the CoinJoin transaction as they put in, minus a small coordination and mining fee. +Each UTXO that is managed by a CoinJoin wallet is assigned an anonymity rating based on its CoinJoin history and the user typically chooses to spend only those UTXOs which have achieved a sufficient level of anonymity. +The way in which the account keys and XPUBs are managed requires greater care than in the case of ordinary cryptocurrency accounts based on BIPs [44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki), [49](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki), [84](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) or [86](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki), which is why we define this domain-separated hierarchy. + +## Public key derivation + +We define the following 6 levels in the BIP 32 derivation path: + +``` +m / 10025' / coin_type' / account' / script_type' / change / address_index +``` + +`'` in the path indicates that hardened derivation is used. +A key derived with this derivation path pattern will be referred to as `derived_key` further in this document. + +### Coin type field + +The value of `coin_type` MUST be one of the coin types defined in [SLIP 44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). +The keys derived for a particular coin type SHOULD only be used in connection with the cryptocurrency specified in SLIP 44. + +One master node (seed) can be used for multiple cryptocurrency networks. +Sharing keys between different cryptocurrency networks or between mainnet and testnet may be especially dangerous if the cryptocurrency does not implemented strong replay protection, e.g. via `SIGHASH_FORKID`. +For example if a testnet application is allowed to access mainnet keys, then an attacker may be able to coerce the user into spending Bitcoin by signing a seemingly harmless testnet transaction. + +This level creates a separate subtree for every cryptocurrency, avoiding key reuse between networks and improving privacy. + +### Account field + +The value of `account` SHOULD be in the range from `0` to `100`. +Accounts are numbered from index `0` in a sequentially increasing manner. + +This level splits the key space into independent user identities. +Users can use these accounts to organize their funds in the same fashion as bank accounts for better overview of their operations, e.g. a business account and a personal account. +Some users may also choose to segregate coins into multiple identities as a fail-safe in case CoinJoin doesn't offer the advertised level of anonymity. + +Wallet software should prevent spending coins from different accounts in one transaction. +It should also prevent the creation of an account, i.e. accessing the new account's addresses, if a previous account does not have any transaction history. + +### Script type field + +The value of `script_type` MUST be `1`. +All other values are reserved for future use. + +The inclusion of this field is inspired by [BIP 48](https://github.com/bitcoin/bips/blob/master/bip-0048.mediawiki). +Being able to manage multiple script types under a single account may be especially useful in other privacy-focused applications such as [BIP 78](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki) PayJoin when the sender's script type needs to be matched by the receiving wallet. + +### Change field + +The value of `change` MUST be `0` or `1`. +All other values are reserved for future use. + +The value `0` is used for the *external chain* and the value `1` for the *internal chain* (also known as change addresses or internal addresses). +The external chain is used for addresses that are meant to be visible outside of the wallet, e.g. for receiving payments. +The Internal chain is used for addresses which are not meant to be visible outside of the wallet and is used either for returning transaction change or for outputs of CoinJoin transactions. + +### Address index field + +The value of `address_index` SHOULD be an integer in the range from `0` to `1000000` (inclusive). +Addresses are numbered from index `0` in a sequentially increasing manner. + +## Address derivation + +### Script type 1: P2TR + +If `script_type = 1` then the derived key MUST be used to generate a P2TR address. +The scriptPubKey is defined exactly as specified in the [Address derivation](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki#address-derivation) section of BIP 86: + +``` +internal_key: lift_x(derived_key) +32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G +scriptPubKey: 0x51 0x20 {32_byte_output_key} +``` + +## Handling XPUBs and addresses + +The UTXOs from a CoinJoin account SHOULD only be spent by a wallet that is able to rate the anonymity of the UTXOs and select the ones satisfying the user's anonymity threshold. + +Wallets MUST require user confirmation before releasing the XPUB to any node in the BIP 32 subtree of `m / 10025'`. + +Wallets SHOULD NOT display an address belonging to the internal chain (`change = 1`) of a CoinJoin account. + +## Backwards Compatibility + +This SLIP is not backwards compatible with earlier derivation schemes by design due to the special requirements for handling XPUBs and addresses. +An incompatible wallet will not discover these accounts, however the scheme is sufficiently similar to existing schemes, so that adding it to current implementations does not require any significant amount of new code. + +## Test vectors + +TODO + +## References + +* [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki): Hierarchical Deterministic Wallets +* [SLIP 10](https://github.com/satoshilabs/slips/blob/master/slip-0010.md): Universal private key derivation from master private key +* [BIP 44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki): Multi-Account Hierarchy for Deterministic Wallets +* [SLIP 44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md): Registered coin types for BIP 44 +* [BIP 48](https://github.com/bitcoin/bips/blob/master/bip-0048.mediawiki): Multi-Script Hierarchy for Multi-Sig Wallets +* [BIP 49](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki): Derivation scheme for P2WPKH-nested-in-P2SH based accounts +* [BIP 84](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki): Derivation scheme for P2WPKH based accounts +* [BIP 86](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki): Deterministic Entropy From BIP32 Keychains +* [BIP 78](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki): A Simple Payjoin Proposal diff --git a/slip-0039.md b/slip-0039.md index 71a317b7..7bd0edac 100644 --- a/slip-0039.md +++ b/slip-0039.md @@ -4,89 +4,283 @@ Number: SLIP-0039 Title: Shamir's Secret-Sharing for Mnemonic Codes Type: Standard -Status: Draft +Status: Final Authors: Pavol Rusnak - Tomas Susanka + Andrew Kozlik Ondrej Vejpustek + Tomas Susanka Marek Palatinus Jochen Hoenicke Created: 2017-12-18 ``` +## Table of contents + +* [Abstract](#abstract) +* [Notation](#notation) +* [Motivation](#motivation) +* [Shamir's secret-sharing](#shamirs-secret-sharing) +* [Two-level scheme](#two-level-scheme) +* [Format of the share mnemonic](#format-of-the-share-mnemonic) +* [Generating and combining the shares](#generating-and-combining-the-shares) + * [Polynomial interpolation](#polynomial-interpolation) + * [Sharing a secret](#sharing-a-secret) + * [Generating the shares](#generating-the-shares) + * [Combining the shares](#combining-the-shares) +* [Checksum](#checksum) +* [Passphrase](#passphrase) +* [Encryption of the master secret](#encryption-of-the-master-secret) +* [Decryption of the master secret](#decryption-of-the-master-secret) +* [Versioning](#versioning) +* [Localization](#localization) +* [Wordlist](#wordlist) +* [Specification for backing up BIP-0032 Hierarchical Deterministic Wallets](#specification-for-backing-up-bip-0032-hierarchical-deterministic-wallets) +* [Test vectors](#test-vectors) +* [Reference implementation](#reference-implementation) +* [Design rationale](#design-rationale) +* [References](#references) + ## Abstract -This SLIP describes a standard and interoperable implementation of Shamir's secret-sharing (SSS), which is a form of secret sharing, where a secret is divided into parts, giving each participant its own unique part, where some of the parts or all of them are needed in order to reconstruct the secret. +This SLIP describes a standard and interoperable implementation of Shamir's secret-sharing (SSS) and a specification for its use in backing up Hierarchical Deterministic Wallets described in [BIP-0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). SSS splits a master secret into unique parts which can be distributed among participants. A specified minimum number of parts is required to be supplied in order to reconstruct the original secret. Knowledge of fewer than the required number of parts does not leak information about the master secret. This SLIP is mainly intended as a replacement for [BIP-0039](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) and for the most part, the two are [not compatible](#Bip39Compatibility). + +## Notation + +Notation | Meaning +----------------|--------------------------------------------------------------- +*G* | total number of groups, a positive integer, 1 ≤ *G* ≤ 16 +*Ni* | total number of members in group *i*, a positive integer, 1 ≤ *Ni* ≤ 16 +*GT* | group threshold, a positive integer, 1 ≤ *GT* ≤ *G* +*Ti* | member threshold for group *i*, a positive integer, 1 ≤ *Ti* ≤ *Ni* +*id* | random identifier, a 15-bit unsigned integer +*ext* | extendable backup flag +*e* | iteration exponent, a 4-bit unsigned integer +*MS* | master secret, an octet string +*n* | length of the master secret in bytes +*EMS* | encrypted master secret, an octet string +|| | concatenation operator +xor | bit-wise exclusive-or of two octet strings ## Motivation -Preservation of digital assets is generally important and it is especially important in the case of decentralized payments systems such as Bitcoin, where there is no recourse in the case of loss of an asset. The usual approach to protecting digital assets is redundant backups, but when the asset itself is a valuable capability, there is a substantial risk of the backup holder absconding with the asset. Shamir's secret-sharing provides a better mechanism for replicating secrets without giving the capability to the backup holder. +Preservation of digital assets is generally important and it is especially important in the case of decentralized payments systems such as Bitcoin, where there is no recourse in the case of loss of an asset. The usual approach to protecting digital assets is redundant backups, but when the asset itself is of significant and liquidable value, there is a substantial risk of the backup holder absconding with the asset. Shamir's secret-sharing provides a better mechanism for backing up secrets by distributing custodianship among a number of trusted parties in a manner that can prevent loss even if one or a few of those parties become compromised. -However, SSS is not standardized today, making it possible for a future secret recovery to be put in jeopardy if the tools have changed. Therefore, we propose standardizing SSS so that SLIP-0039 compatible implementations will be interoperable. +However, the lack of SSS standardization to date presents a risk of being unable to perform secret recovery in the future should the tooling change. Therefore, we propose standardizing SSS so that SLIP-0039 compatible implementations will be interoperable. ## Shamir's secret-sharing -Shamir's secret-sharing (SSS) is a cryptographic mechanism how to divide a secret into `N` unique parts, where `M` of them are required to reconstruct the secret. First, a polynomial of `N-1` degree is constructed and each party is given a corresponding point - a non-zero integer input to the polynomial and the corresponding output. +Shamir's secret-sharing (SSS) is a cryptographic mechanism describing how to split a secret into *N* unique parts, where any *T* of them are required to reconstruct the secret. First, a polynomial *f* of degree *T* − 1 is constructed and each party is given a corresponding point - an integer input *x* to the polynomial and the corresponding output *f*(*x*). + +When any *T* points are provided, they exactly define the polynomial. Usually the value of the polynomial *f*(0) is used as the shared secret. In this specification the shared secret is stored as *f*(255)[3](#IndexEncoding). More details on SSS can be found on [Wikipedia](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing). + +We propose that given a secret, *T* − 2 shares be generated randomly and the remaining shares be computed in such a way that *f*(255) encodes the shared secret and *f*(254) encodes the digest[4](#Digest) of the shared secret. Encoding the digest makes it possible to verify that the shared secret has been correctly recovered. The diagram below illustrates the splitting of a secret into five shares such that any three are required to recover the shared secret (*N* = 5 and *T* = 3). + +![curve](slip-0039/shamir-curve.svg) + +Shamir's secret sharing scheme is applied separately to each byte of the shared secret and GF(256) is used as the underlying finite field[1](#FiniteField). Bytes are interpreted as elements of GF(256) using polynomial representation with operations modulo the Rijndael irreducible polynomial *x*8 + *x*4 + *x*3 + *x* + 1, see [AES](https://doi.org/10.6028/NIST.FIPS.197) sections 3.2, 4.1 and 4.2. + +## Two-level scheme + +One characteristic of Shamir’s secret sharing scheme is that all shares are equal. Thus if the owner of the secret needs to distribute the amount of trust unevenly between shareholders, then some shareholders need to be given multiple shares. Furthermore, as discussed by [Allen and Friedenbach](https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/social-key-recovery.md), the owner might want to restrict the combinations of shareholders which are able to reconstruct the secret, because some combinations of shareholders might be more likely to collude against the owner than others. To facilitate this we propose that the encrypted master secret (*EMS*) is first split using a *GT*-of-*G* scheme to obtain a set of first-level shares, aka *group shares*. The *i*-th group share, 1 ≤ *i* ≤ *G*, is then split using a *Ti*-of-*Ni* scheme to obtain a set of second-level shares, aka *member shares*, which are distributed among the shareholders. Two levels are assumed to be sufficient to accommodate the majority of use cases while maintaining a comprehensive user interface. + +For example, Alice wants to be able to reconstruct her *EMS* on her own using her 2 shares, which she has stored at different locations. In case these shares get destroyed, she also wants to have a backup with her friends and family in such a way that 3 of her 5 friends together with 2 of her 6 family members are required to reconstruct the *EMS*. A two-level secret sharing scheme can easily accommodate such requirements. In the given example Alice first splits the *EMS* using a 2-of-4 scheme to obtain the group shares A, B, C and D. She keeps A and B for herself and splits C further using a 3-of-5 scheme to obtain member shares C1, ... , C5, giving one to each friend. Similarly, Alice splits D among her family members using a 2-of-6 scheme. Thus family members receive a greater amount of trust than friends, without having to give one person multiple shares. However, even if all six family members collude against Alice, they cannot obtain the *EMS* without the help of at least three of Alice's friends or without stealing one of Alice's own shares. + +All shares created in accordance with this specification use the two-level secret sharing scheme. If the creator of the shares wishes to use only a basic single-level *T*-of-*N* scheme, then they SHOULD[2](#GroupPolicies) create a single group and conduct the splitting at the second level, i.e. *GT* = 1, *G* = 1, *T*1 = *T* and *N*1 = *N*. + +If the member threshold *Ti* of a group is 1, then the size *Ni* of the group SHOULD[2](#GroupPolicies) also be equal to 1. The one share can then be given to multiple members. + +## Format of the share mnemonic + +We propose the following format of the shares: + +| Identifier (*id*) | Extendable (*ext*) | Iteration exponent (*e*) | Group index (*GI*) | Group threshold (*Gt*) | Group count (*g*) | Member index (*I*) | Member threshold (*t*) | Padded share value (*ps*) | Checksum (*C*) | +|---------|-------|--------|--------|--------|--------|--------|--------|---------------------|---------| +| 15 bits | 1 bit | 4 bits | 4 bits | 4 bits | 4 bits | 4 bits | 4 bits | padding + 8*n* bits | 30 bits | + +* The **identifier** (*id*) field is a random 15-bit value which is the same for all shares and is used to verify that the shares belong together. +* The **extendable backup flag** (*ext*) field[10](#ExtendableBackup) indicates that the *id* is used as salt in the encryption of the master secret when *ext* = 0. +* The **iteration exponent** (*e*) field indicates the total number of iterations to be used in PBKDF2. The number of iterations is calculated as 10000×2*e*. +* The **group index** (*GI*) field[3](#IndexEncoding) is the *x* value of the group share. +* The **group threshold** (*Gt*) field[3](#IndexEncoding) indicates how many group shares are needed to reconstruct the master secret. The actual value is encoded as *Gt* = *GT* − 1, so a value of 0 indicates that a single group share is needed (*GT* = 1), a value of 1 indicates that two group shares are needed (*GT* = 2) etc. +* The **group count** (*g*) indicates the total number of groups. The actual value is encoded as *g* = *G* − 1. +* The **member index** (*I*) field[3](#IndexEncoding) is the *x* value of the member share in the given group. +* The **member threshold** (*t*) field[3](#IndexEncoding) indicates how many member shares are needed to reconstruct the group share. The actual value is encoded as *t* = *T* − 1. +* The **padded share value** (*ps*) field corresponds to a list of the SSS part's *fk*(*x*) values (see the diagram above), 1 ≤ *k* ≤ *n*. Each *fk*(*x*) value is encoded as a string of eight bits in big-endian order. The concatenation of these bit strings is the share value. This value is left-padded with "0" bits so that the length of the padded share value in bits becomes the nearest multiple of 10. +* The **checksum** (*C*) field is an RS1024 checksum (see [below](#checksum)) of the data part of the share (that is *id* || *ext* || *e* || *GI* || *Gt* || *g* || *I* || *t* || *ps*). The customization string (*cs*) of RS1024 is "shamir" if *ext* = 0 and "shamir_extendable" if *ext* = 1. + +This structure is then converted into a mnemonic code by splitting it up into 10-bit segments with each becoming an index into a word list containing exactly 1024 words (see [below](#wordlist)). Big-endian bit order is used in all conversions. The entropy[4](#Digest) of the master secret MUST be at least 128 bits and its length MUST be a multiple of 16 bits. All implementations MUST support master secrets of length 128 bits and 256 bits: + +| Security | Padded share value length | Total share length | +|----------|---------------------------|---------------------| +| 128 bits | 130 bits | 200 bits = 20 words | +| 256 bits | 260 bits | 330 bits = 33 words | + +This construction yields a beneficial property where the random identifier and the iteration exponent transform into the first two words of the mnemonic code, so the user can immediately tell whether the correct shares are being combined, i.e. they have to have the same first two words. Moreover, the third word encodes the group index, group threshold and part of the group count. Since the group threshold and group count are constant, all shares belonging to the same group start with the same three words. + +## Generating and combining the shares + +### Polynomial interpolation + +Given a set of *m* points (*xi*, *yi*), 1 ≤ *i* ≤ *m*, such that no two *xi* values equal, there exists a polynomial that assumes the value *yi* at each point *xi*. The polynomial of the lowest degree that satisfies these conditions is uniquely determined and can be obtained using the Lagrange interpolation formula given below. + +Since Shamir's secret sharing scheme is applied separately to each of the *n* bytes of the shared secret, we work with *y**i* as a vector of *n* values, where *y**i*[*k*] = *fk*(*xi*), 1 ≤ *k* ≤ *n*, and *fk* is the polynomial in the *k*-th instance of the scheme. + +#### Interpolate(*x*, {(*xi*, *y**i*), 1 ≤ *i* ≤ *m*}) + +**Input:** the desired index *x*, a set of index/value-vector pairs {(*xi*, *y**i*), 1 ≤ *i* ≤ *m*} ⊆ GF(256) × GF(256)*n* + +**Output:** the value-vector (*f*1(*x*), ... , *fn*(*x*)) + +![f_k(x) = \sum_{i=1}^m y_i[k] \prod_{\underset{j \neq i}{j=1}}^m \frac{x - x_j}{x_i - x_j}](slip-0039/lagrange.png) + +### Sharing a secret + +#### SplitSecret(*T*, *N*, *S*) + +**Input:** threshold *T*, number of shares *N*, secret *S* -In case sufficient `M` values are provided the points exactly define the polynomial. The polynomial's value of `f(0) = S` corresponds to the master secret. You may read more on SSS on [Wikipedia](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing). +**Output:** shares *y*1, ... , *yN* for share indices 0, ... , *N* − 1 -![curve](slip-0039/curve.png) +1. Check the following conditions: + * 0 < *T* ≤ *N* ≤ 16 + * The length of *S* in bits is at least 128 and a multiple of 16. -## From entropy to mnemonic secrets + If any of these conditions is not satisfied, then abort. +2. If *T* is 1, then let *yi* = *S* for all *i*, 1 ≤ *i* ≤ *N*, and return. +3. Let *n* be the length of *S* in bytes. Generate *R* ∈ GF(256)*n*−4 randomly with uniform distribution and let *D* be the concatenation of the first 4 bytes of HMAC-SHA256(key=*R*, msg=*S*) with the *n* − 4 bytes of *R*. +4. Let *y*1, ... , *y**T*−2 ∈ GF(256)*n* be generated randomly, independently with uniform distribution. +5. For *i* such that *T* − 2 < *i* ≤ *N* compute *yi* = Interpolation(*i* − 1, {(0, *y*1), ... , (*T* − 3, *y**T*−2), (254, *D*), (255, *S*)}). -The value to be encoded as the master secret must be a multiple of 8 bits. This is typically a wallet entropy, but may be another secret value which was uniformly chosen from its (key) space. The master secret is divided into `N` Shamir parts and `M` specifies how many of those parts do we need to reconstruct the master secret. We use `GF(256)` reduced by `x^8 + x^4 + x^3 + x + 1` (the Rijndael polynomial) as the underlying field. We consider the master secret in a form which includes its own checksum: +The source of randomness used to generate the values in steps 3 and 4 above MUST be suitable for generating cryptographic keys. -| master secret | 16-bit master secret checksum | -|---------------|-------------------------------| +#### RecoverSecret(*T*, [(*x*1, *y*1), ... , (*xm*, *ym*)]) -From this value, every byte is mapped to the specified field in a little-endian fashion (i.e. the first bit maps to `a_7`, the last bit maps to `a_0`). For each such field element, `N`-share field elements are generated and mapped back to bytes. Each participating party receives the following data: +**Input:** threshold *T*, a list of *m* share-index/share-value pairs [(*x*1, *y*1), ... , (*xm*, *ym*)] -| 5-bit index | 5-bit M threshold | variable-bit SSS part | 16-bit checksum | -|-------------|-------------------|-----------------------|-----------------| +**Output:** the shared secret *S* -The index corresponds to the SSS part's `x` value (see the diagram above) and the SSS part is the corresponding `y` value. +1. If *T* is 1, then let *S* = *y*1 and return. +2. Compute *S* = Interpolation(255, [(*x*1, *y*1), ... , (*xm*, *ym*)]). +3. Compute *D* = Interpolation(254, [(*x*1, *y*1), ... , (*xm*, *ym*)]). +4. Let *R* be the last *n* − 4 bytes of *D*. If the first 4 bytes of HMAC-SHA256(key=*R*, msg=*S*) are equal to the first 4 bytes of *D*, then return *S*, otherwise abort. -Index and threshold are encoding using the following scheme (convert from bits to decimal and add 1): +### Generating the shares -| 5-bit value | index/threshold value | -|-------------|-----------------------| -| 00000 | 1 | -| 00001 | 2 | -| 00010 | 3 | -| ... | ... | -| 11101 | 30 | -| 11110 | 31 | -| 11111 | 32 | +#### GenerateShares(*GT*, [(*T*1,*N*1), ... , (*TG*,*NG*)], *MS*, *P*, *e*) -The checksum field is a checksum of the whole share (i.e. index, threshold, SSS part). +**Input:** group threshold *GT*, list of member thresholds *T*1, ... , *TG* and group sizes *N*1, ... , *NG*, master secret *MS*, passphrase *P*, iteration exponent *e* -This structure is then converted into a mnemonic passphrase by splitting it up by 10 bits which correspond as an index to the a word list containing exactly 1024 words (see below). +**Output:** list of shares -| master secret | SSS part | share length | -|---------------|----------|------------------------| -| 128 bits | 144 bits | 170 bits = 17 words | -| 256 bits | 272 bits | 298 bits = 30 words | +1. If *Ti* = 1 and *Ni* > 1 for any *i*, then abort. +2. Generate a random 15-bit value *id*. +3. Let *ext* = 1. +4. Compute the encrypted master secret *EMS* = Encrypt(*MS*, *P*, *e*, *id*, *ext*). +5. Compute the group shares *s*1, ... , *sG* = SplitSecret(*GT*, *G*, *EMS*). +6. For each group share *si*, 1 ≤ *i* ≤ *G*, compute the member shares *s**i*,1, ... , *s**i*,*Ni* = SplitSecret(*Ti*, *Ni*, *si*). +7. For each *i* and each *j*, 1 ≤ *i* ≤ *G*, 1 ≤ *j* ≤ *Ni*, return (*id*, *ext*, *e*, *i* − 1, *GT* − 1, *j* − 1, *Ti* − 1, *si,j*). -The selection of 5-bit sizes for index/threshold values and 10-bit for wordlist index has a nice property that the first word of the mnemonic encodes exactly these two values. And, vice versa, only these two values determine the first word. +### Combining the shares + +**Input:** list of shares, passphrase *P* + +**Output:** master secret *MS* + +1. Check the following conditions: + * The checksum of each share MUST be valid. Implementations SHOULD NOT implement correction beyond potentially suggesting to the user where in the mnemonic an error might be found, without suggesting the correction to make[5](#ChecksumDesign). + * All shares MUST have the same identifier *id*, extendable backup flag *ext*, iteration exponent *e*, group threshold *GT*, group count *G* and length. The value of *G* MUST be greater than or equal to *GT*. + * Let *GM* be the number of pairwise distinct group indices among the given shares. Then *GM* MUST be equal to *GT*. + * All shares with a given group index *GIi*, 1 ≤ *i* ≤ *GM*, MUST have the same member threshold *Ti*, their member indices MUST be pairwise distinct and their count *Mi* MUST be equal to *Ti*. + * The length of the padding of the share value in bits, which is equal to the length of the padded share value in bits modulo 16, MUST NOT exceed 8 bits. + * All padding bits MUST be "0". + * The length of each share value MUST be at least 128 bits. + + Abort if any check fails. + +2. Let *si* = RecoverSecret([(*I**i*,1, *s**i*,1), ... , (*I**i*,*Mi*, *s**i*,*Mi*)]), where *Ii,j* and *si,j* are the member-index/share-value pairs of the shares with group index *GIi*. + +3. Let *EMS* = RecoverSecret([(*GI*1, *s*1), ... , (*GIGM*, *sGM*)]) + +4. Return *MS* = Decrypt(*EMS*, *P*, *e*, *id*, *ext*). ## Checksum -For the checksums we use the leftmost 16 bits of a SHA-256 hash digest of the relevant payload. +The last three words of the mnemonic form a checksum and contain no information. Valid mnemonics MUST pass the criteria for validity specified by the Python3 code snippet below. The function `rs1024_verify_checksum` must return true when its arguments are: + +* `cs`: the customization string +* `data`: the data part as a list of 10-bit integers, each corresponding to one word of the mnemonic + +``` +def rs1024_polymod(values): + GEN = [0xe0e040, 0x1c1c080, 0x3838100, 0x7070200, 0xe0e0009, 0x1c0c2412, 0x38086c24, 0x3090fc48, 0x21b1f890, 0x3f3f120] + chk = 1 + for v in values: + b = (chk >> 20) + chk = (chk & 0xfffff) << 10 ^ v + for i in range(10): + chk ^= GEN[i] if ((b >> i) & 1) else 0 + return chk + +def rs1024_verify_checksum(cs, data): + return rs1024_polymod([ord(x) for x in cs] + data) == 1 +``` + +This implements a Reed-Solomon code over GF(1024) that guarantees detection of any error affecting at most 3 words and has less than a 1 in 109 chance of failing to detect more errors. More details about the properties can be found in the Checksum Design appendix[5](#ChecksumDesign). The customization string is processed by feeding each character's US-ASCII value into the checksum calculation prior to the data. + +To construct a valid checksum given the customization string and the values of the data-part words, the code below can be used: + +``` +def rs1024_create_checksum(cs, data): + values = [ord(x) for x in cs] + data + polymod = rs1024_polymod(values + [0,0,0]) ^ 1 + return [(polymod >> 10 * (2 - i)) & 1023 for i in range(3)] +``` ## Passphrase -When enough `M` secrets are provided the master secret is reconstructed. To allow an additional protection of the final seed using a passphrase we will use a key derivation function to compute the seed. If no passphrase is provided an empty string should be used as a passphrase. +To allow additional protection, the master secret is encrypted with a passphrase using the encryption function described below. There is no way to verify that the correct passphrase was used to decrypt the encrypted master secret. This allows the user to obtain multiple master secrets from a single encrypted master secret by using different passphrases[8](#PassphraseVerification). + +In order to achieve the best interoperability among various operating systems and wallet implementations, the passphrase MUST be a string containing only printable ASCII characters (code points 32-126). If no passphrase is provided, an empty string SHALL be used as the passphrase. + +## Encryption of the master secret + +The master secret is encrypted using a wide-blocksize pseudorandom permutation[7](#Encryption) based on the Luby-Rackoff construction. It consists of a four-round Feistel network with the key derivation function PBKDF2[6](#KDFParam) as the round function. This scheme is invertible, which means that the creator of the shares can choose the master secret, making it possible to migrate a BIP-32 wallet from BIP-39 mnemonics to the new secret sharing scheme. The master secret is first split into two equally long parts, where `L` is the first *n*/2 bytes of the master secret and `R` is the last *n*/2 bytes of the master secret, and processed as follows: + +``` +L = MS[:len(S)/2] +R = MS[len(S)/2:] +for i in [0,1,2,3]: + (L, R) = (R, L xor F(i, R)) +``` + +The encrypted master secret is then `EMS = R || L`. + +The *i*-th round function `F(i, R)` is defined as follows: -Passphrase should contain only ASCII characters to achieve the best interoperability among various operating systems and wallet implementations. +``` +F(i, R) = PBKDF2(PRF = HMAC-SHA256, Password = (i || passphrase), Salt = (salt_prefix || R), iterations = 2500 << e, dkLen = n/2 bytes) +``` -![passphrase](slip-0039/passphrase.png) +The value of *i* is encoded as one byte. -We will use `PBKDF2(PRF = HMAC-SHA256, Password = master_secret, Salt = "SLIP0039" + passphrase, iterations = 20000, dkLen = 256 bits)` as the key derivation function. +If *ext* = 1, then `salt_prefix` is an empty string. +If *ext* = 0, then `salt_prefix = "shamir" || id`, where the random identifier value *id* is encoded as two bytes in big-endian byte order. -We suggest to use the obtained seed as a master seed `S` for Hierarchical Deterministic Wallets described in BIP-0032. +## Decryption of the master secret + +The only difference between encryption and decryption is the reversal of the order of the values of `i`: + +``` +L = EMS[:len(EMS)/2] +R = EMS[len(EMS)/2:] +for i in [3,2,1,0]: + (L, R) = (R, L xor F(i, R)) +MS = R || L +``` ## Versioning -Our scheme doesn't support versioning. This is intentional to avoid unclear claims such as SLIP-0039 compatibility without a clear understanding, which version of the scheme is actually meant. +Our scheme doesn't support versioning. This is intentional to avoid unclear claims such as SLIP-0039 compatibility without a clear understanding of which version of the scheme is actually meant. Any future enhancement of this specification should be standardized as a new BIP or SLIP and should use its own unique customization string so that shares created in accordance with the new specification cannot be mistaken for SLIP-0039 shares. ## Localization @@ -94,18 +288,145 @@ No localization is supported. This standard deals with a set of English words on ## Wordlist -Wordlist mandated by this SLIP is [available here](slip-0039/wordlist.txt). Several criteria were applied where creating the list: +The wordlist mandated by this SLIP is [available here](slip-0039/wordlist.txt). Several criteria were applied in the creation of the list: + +* The wordlist is alphabetically sorted. +* No word is shorter than 4 letters. +* No word is longer than 8 letters. +* All words begin with a unique 4-letter prefix. +* The wordlist contains only common English words (+ the word "satoshi"). +* The minimum Damerau-Levenshtein distance between any two words is at least 2. +* The similarity between the pronunciation of any two words has been minimized. + +(see the [test](slip-0039/test_wordlist.sh) which checks whether these criteria are fulfilled). + +## Specification for backing up BIP-0032 Hierarchical Deterministic Wallets + +SLIP-0039 can be used to back up any master secret *S* which satisfies the length constraints described above. However, any application implementing SLIP-0039 for backing up a [BIP-0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) Hierarchical Deterministic Wallet MUST use the [BIP-0032 master seed](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#master-key-generation) as the SLIP-0039 master secret *S*. To clarify, this is the initial generated seed byte sequence of 128-512 bits, which is used as the input to `HMAC-SHA512` for deriving the BIP-0032 master node. + +This specification is required to ensure that SLIP-0039 backups created in one wallet can be restored in any other wallet that implements SLIP-0039. + +## Test vectors + +The test vectors are given as a list of quadruples. The first element of the quadruple is a description of the test vector, the second is a list of mnemonics, the third is the master secret which results from combining the mnemonics and the fourth is the BIP32 master extended private key derived from the master secret. The master secret is encoded as a string containing two hexadecimal digits for each byte. If the string is empty, then attempting to combine the given set of mnemonics should result in an error. The passphrase "TREZOR" is used for all valid sets of mnemonics. + + + +## Reference implementation + +The reference implementation is available from +. + +## Other implementations + +C#: + +* +* + +Dart: + +* + +Go: + +* + +JavaScript: + +* +* + +Rust: + +* +* + +Wallets with SLIP39 support: + +* +* +* + +## Design rationale + +1. **Choice of finite field** + + Finite fields of the form GF(2*m*) and GF(*p*), where *p* is a prime number, were considered for this scheme. The field GF(256) was chosen because the field arithmetic is easy to implement in any programming language and many implementations are already available since it is used in the AES cipher. The fact that it is byte-oriented makes it easy to work with. + + Using a field of prime order GF(*p*), where log2 *p* is approximately the length of the master secret in bits, would require support for multi-precision arithmetic. Many programming languages, such as C/C++, do not support multi-precision arithmetic out of the box. Implementations would also need to store information about the prime number that should be used for each admissible length of the master secret or they would need to compute the prime number on the fly. + + Choosing GF(2*m*), where *m* is the length of the master secret in bits would require a more complicated implementation than GF(256). This is in part due to the multi-precision nature of the arithmetic and in part due to the fact that implementations would need to store an (e.g. lexicographically minimal) irreducible polynomial of degree *m* for each admissible value of *m* or they would need to be able to determine this polynomial on the fly. + +2. **Group policies** + + It is recommended that when a single-level *T*-of-*N* scheme is desired, then a single group share should be created and split into *N* member shares. The alternative would be to create *N* groups, with each group using a 1-of-1 member scheme. There is no difference in terms of security between the two methods. The advantage of using the recommended method is that when recovering the secret, it is possible to determine from any share that a single-level scheme was used. This makes it possible to provide a more comprehensive user experience. + + It is recommended that if the member threshold *Ti* of a group is 1, then the size *Ni* of the group should also be 1. Splitting a group share using a 1-of-*N* scheme for *N* > 1 provides no additional security over a 1-of-1 scheme because the shares in a group with threshold 1 will only differ in the member index (fourth word of the mnemonic) and in the three checksum words at the end of the mnemonic. If a user attempts to produce several member shares with threshold 1, then it is most likely to be a mistake or a failure to understand the consequences. + +3. **Index encoding** + + It is anticipated that 16 groups with 16 member shares in each group will be more than enough for any application of Shamir's Secret Sharing Scheme to BIP-32 master seeds. Thus to reduce the mnemonic length, the index and threshold values are restricted to 4 bits each. + + In this specification the shared secret is stored under index 255 instead of the usual index 0. The disadvantage of using index 0 for the shared secret is that 0 then cannot be used as the index value for a share, thus any shares with index value 0 have to be considered invalid. However, some implementations might fail to check this, which would open the door to the following attack: Assume that an implementation doesn't check that the supplied *x* value is non-zero. An attacker that has write access to one of the shares can then change the stored point from (*x*,*y*) to (0,*y*). If the implementation uses this value in the Lagrange interpolation formula, then the resulting shared secret will always be equal to *y* regardless of the values of the other shares. If this value is protected with a weak passphrase and used as a master seed for a BIP-32 wallet, then the attacker will be able to steal any funds transferred to this wallet because he knows *y*. + +4. **Digest** + + If the threshold *T* is at least 2, then share index 254 is used to encode the digest of the shared secret *S*. The share value *D* corresponding to index 254 consists of two parts. The first 4 bytes of *D* encode the actual digest and the remaining *n* − 4 bytes *R* are randomly generated. The digest is computed as the first four bytes of HMAC-SHA256(key=*R*, msg=*S*). Encoding the digest makes it possible to detect an invalid set of shares with a random failure chance of 2−32. Since each mnemonic has an identifier and an RS1024 checksum, an invalid set of shares is unlikely to appear randomly. Thus an invalid digest generally indicates that one or more of the provided shares have been maliciously fabricated by an attacker. + + Let *m* denote the entropy of the shared secret in bits. A disadvantage of encoding the digest of the shared secret is that an attacker who has knowledge of *T* − 1 share values can reduce the entropy of the shared secret to *m* − 32 bits by performing a brute-force search over the 2*m* possible values of the shared secret and eliminating the ones which give an invalid digest. The entropy of the shared secret must be sufficiently large to make such attacks impractical, which is why this specification requires that *m* ≥ 128. + + The advantage of using HMAC-SHA256(key=*R*, msg=*S*) as opposed to SHA-256(*S*) to compute the digest is that it provides better protection against attacks where the attacker has only partial knowledge of *T* − 1 shares or partial knowledge of the shared secret. For example, if the digest would only depend on *S* and not on *R*, then it would be possible to perform the attack described above with the knowledge of only the first 4 bytes of *T* − 1 share values. + +5. **Checksum design** + + The checksum design is heavily inspired by Bech32 defined in [BIP-0173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32). The RS1024 checksum uses a Reed-Solomon code over GF(1024) so that the code alphabet matches the 10-bit wordlist. A Reed-Solomon code over GF(1024) allows creating mnemonics of length up to a thousand words, which is plenty. Shared secrets that would require such length are impractical for human entry and should be stored in binary form rather than mnemonic form. We picked 3 checksum words as a trade-off between the length of the mnemonics and the error-detection capabilities, as 3 checksum words is the lowest number sufficient for a random failure chance below 1 per billion. RS1024 is an MDS code, which means that it is guaranteed to detect any 3 or fewer errors. This is the maximum possible for any kind of checksum that has length 3. Reed-Solomon codes can be viewed as a special case of BCH codes. In the Python3 code snippet, we use the BCH view of Reed-Solomon codes, because it allows for a more efficient implementation of the algorithms. The generating polynomial of the code is (*x* − *a*)(*x* − *a*2)(*x* − *a*3), where *a* is a root of the primitive polynomial *x*10 + *x*3 + 1 over GF(2). The elements of GF(1024) are represented as polynomials with operations modulo this primitive polynomial. + + Implementations should not implement correction beyond potentially suggesting to the user where in the mnemonic an error might be found, without suggesting the correction to make. The same recommendation is also made in BIP-0173 (Bech32), which uses a similar checksum scheme. The reason for this is that automated error-corrections change invalid mnemonics into valid mnemonics. The problem is that if more than a few errors are made, then the auto-corrected mnemonic will be valid but different from the original. Use of such a mnemonic may cause funds to be lost irrecoverably (most notably if the threshold is 1). This is why corrections should be made only by the user, who can inspect the hand-written mnemonic more closely and is therefore better qualified to decide where exactly the errors were made. + +6. **Choice of KDF function and parameters** + + PBKDF2 is a widely used standard password-based key derivation function. Newer key derivation functions such as scrypt or Argon2 were considered, but these require a large amount of memory, which is a limiting factor in hardware wallets. + + The SHA-256 algorithm operates on 32-bit words, whereas the SHA-512 algorithm operates on 64-bit words. As a consequence, SHA-512 is significantly faster on 64-bit platforms than on 32-bit platforms, but SHA-256 performs almost the same on both platforms. Using HMAC-SHA512 would put the user who may be running on a 32-bit platform at a significant disadvantage against an attacker which is running a brute force attack on a 64-bit platform. This is why HMAC-SHA256 was chosen as the pseudorandom function for PBKDF2. + + The total number of iterations in PBKDF2 was chosen to be at least 10000, i.e. 2500 iterations in each of the four rounds of the Feistel-based encryption function. A larger number of iterations in PBKDF2 would currently impact the user experience in hardware wallets. The creator of the shares is free to choose a larger number of iterations, theoretically as high as 327 million, making the format more future-proof and more suitable for a wider range of environments. + +7. **Encryption** + + The advantage of a wide-blocksize pseudorandom permutation over a simple encryption scheme is that it thwarts attacks where the adversary obtains, for example, the first several bytes of *T* different shares. If the master secret were not protected by a strong pseudorandom permutation, the adversary could compute a part of the master secret. This is a serious concern if the master secret is, for example, a private key. Protecting the master secret using AES in any of the common block cipher modes does not solve this problem. + + It might appear that such attacks would not be possible had a larger finite field been used, such as GF(2*m*) or GF(*p*), where *m* ≈ log2 *p* and *m* is the length of the master secret in bits. However, we are not aware of any proof that Shamir's secret sharing scheme is secure in scenarios where partial information about the shares is leaked. In fact, our preliminary investigation indicates that in certain cases information about the shared secret may leak if partial knowledge of *T* shares is available. Thus the use of a strong pseudorandom permutation is advisable regardless of the choice of the field. + + The role of the key derivation function in the Feistel-based encryption function is twofold. Firstly, it protects the passphrase against brute-force and dictionary attacks. Secondly, if the adversary obtains a part of the encrypted master secret as described above, the slow key derivation function protects against brute-force attacks which attempt to reveal the unknown part of the encrypted master secret. + +8. **Passphrase verification** + + The proposed design does not provide a way to verify that the correct passphrase was used to decrypt the encrypted master secret. This is an intentional feature which allows the user to obtain multiple master secrets from a single encrypted master secret by using different passphrases. This design allows for plausible deniability when the master secret is used as the master seed for a hierarchical deterministic wallet (see [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)). Every passphrase generates a valid seed but only the correct one will make the desired wallet available. Thus the owner can use one passphrase to access their real wallet and another passphrase to access a decoy wallet. If the owner is later coerced into revealing their passphrase either by [law](https://en.wikipedia.org/wiki/Key_disclosure_law) or by force, then they can reveal the passphrase which accesses the decoy wallet and [plausibly deny](https://en.wikipedia.org/wiki/Plausible_deniability) the existence of their real wallet, because there is no way for the coercer to prove that the decoy wallet is not the real one. + +9. **Compatibility with BIP-0039** + + **Converting an existing BIP-0039 mnemonic to SLIP-0039 shares** + + This is possible, but only at the price of all SLIP-0039 shares being 59 words long regardless of the length of the original BIP-0039 mnemonic. This is due to the fact that in BIP-0039 the mnemonic and passphrase are processed by PBKDF2-SHA-512 to produce a 512-bit seed which is what would need to be split using SLIP-0039. Furthermore, anyone who is using several different passphrases with one BIP-0039 mnemonic to have several wallets can convert only one of these wallets to SLIP-0039 shares. + + Users who wish to take advantage of Shamir's secret sharing are advised to transfer their funds from their old BIP-0039 wallet to a new wallet backed-up using SLIP-0039. Doing so has the advantage of fully eliminating the possibility of theft using the old BIP-0039 mnemonic, which may happen if the user unknowingly fails to destroy all of its copies. + + **Converting existing SLIP-0039 shares to a BIP-0039 mnemonic** + + This is not possible due to the overly coupled design of BIP-0039 and its use of a one-way derivation function. BIP-0039 works by first generating a high-entropy secret, then converting it to a mnemonic and finally using the mnemonic itself as input to PBKDF2 to derive the seed. This means that for any new scheme to be compatible with BIP-0039, it would have to be built on top of BIP-0039 with all of its now obsolete aspects. That includes the conversion of the high-entropy secret to the mnemonic using the old wordlist, which would have to be included in the implementation, unreasonably bloating its size. SLIP-0039 instead introduces a new decoupled design which is more feature-rich and allows maximum flexibility for future upgrades. + + Some individuals have expressed a concern that the inability to convert SLIP-0039 shares to BIP-0039 may lead to vendor lock-in due to the slow adoption of SLIP-0039 by hardware wallet vendors. This concern is unwarranted, since even if the conversion to BIP-0039 were possible and a user needed to recover their seed onto a device which does not support SLIP-0039, then they would need to use some conversion tool running on their computer. In that case, they might as well simply recover their SLIP-0039 shares in a software wallet running on their computer and send all of their funds to a new seed on their new device. Thus the ability to convert shares to a BIP-0039 mnemonic makes no difference in this respect. -* wordlist is alphabetically sorted -* wordlist contains only common English words -* no word is shorter than 4 letters and longer than 8 letters -* all words have unique 4-letter prefix +10. **Extendable backup flag** -## Test Vectors + When this flag is set, it indicates that the *id* is not used as salt in the encryption of the master secret, making it possible to create multiple sets of shares, such that each set of shares uses a different *id* and each set of shares leads to the same master secret for every passphrase. This is a desirable property, because it allows users to start working with their wallet by creating a single-share (1-of-1) scheme and later upgrade to a multi-share scheme while maintaining the same *EMS* and passphrases. In case the user upgrades two or more times to a multi-share scheme, then each set of shares will in all likelihood have a distinct *id*. Thus it will be possible to tell the sets apart and avoid their accidental mixing, which could potentially lead to loss of access to funds, since shares from different sets are incompatible even if they use the same scheme. -TBD + The *ext* flag was added in a later revision of this specification. Previously *ext* was the highest bit of a 5-bit iteration exponent. In newly created shares *ext* SHOULD be set to 1. However, since some users already have shares that use *ext* = 0, implementations MUST support master secret decryption using both *ext* values. If *ext* = 0, then implementations SHOULD NOT allow the intentional creation of another set of shares with the same *id* and *EMS*. Doing so would run the risk of users trying to recover shares from incompatible groups, which is something that implementations are not required to handle. ## References * [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) * [Secret Sharing Step by Step by Point Software](http://www.pointsoftware.ch/en/secret-sharing-step-by-step/) +* [FIPS-197: Specification for the Advanced Encryption Standard (AES)](https://doi.org/10.6028/NIST.FIPS.197) +* [C. Allen and M. Friedenbach: A New Approach to Social Key Recovery](https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/social-key-recovery.md) diff --git a/slip-0039/curve.png b/slip-0039/curve.png deleted file mode 100644 index 70f0d4c9..00000000 Binary files a/slip-0039/curve.png and /dev/null differ diff --git a/slip-0039/lagrange.png b/slip-0039/lagrange.png new file mode 100644 index 00000000..71e76812 Binary files /dev/null and b/slip-0039/lagrange.png differ diff --git a/slip-0039/passphrase.png b/slip-0039/passphrase.png deleted file mode 100644 index 1d45f1f9..00000000 Binary files a/slip-0039/passphrase.png and /dev/null differ diff --git a/slip-0039/shamir-curve.svg b/slip-0039/shamir-curve.svg new file mode 100644 index 00000000..84584e25 --- /dev/null +++ b/slip-0039/shamir-curve.svg @@ -0,0 +1,606 @@ + +image/svg+xmlShamir shares + + + + + + + + +digest of theshared secret + + + + + + + + + +1 + + + + + + + + +2 + + + + + + + + +3 + + + + + + + + +4 + + + + + + + + +y + + + + + + + + +x + + + + + + + + +254 + + + + + + + + + + + + + + + +255 + + + + + + + +sharedsecret + + + + + + + +0 + + + + + + \ No newline at end of file diff --git a/slip-0039/test_wordlist.sh b/slip-0039/test_wordlist.sh new file mode 100755 index 00000000..f03fc8e5 --- /dev/null +++ b/slip-0039/test_wordlist.sh @@ -0,0 +1,16 @@ +#!/bin/bash + +# wordlist is alphabetically sorted +diff wordlist.txt <(sort wordlist.txt) && echo OK + +# no word is shorter than 4 letters +diff wordlist.txt <(grep '^....' wordlist.txt) && echo OK + +# no word is longer than 8 letters +! grep -q '^.........' wordlist.txt && echo OK + +# all words have unique 4-letter prefix +diff <(cut -c 1-4 wordlist.txt) <(cut -c 1-4 wordlist.txt | sort -u) && echo OK + +# wordlist contains only common English words (+ the word "satoshi") +test "$(comm -23 wordlist.txt <(aspell -l en dump master | tr [A-Z] [a-z] | sort ))" = "satoshi" && echo OK diff --git a/slip-0039/wordlist.txt b/slip-0039/wordlist.txt index 77c8c2a3..5673e7ca 100644 --- a/slip-0039/wordlist.txt +++ b/slip-0039/wordlist.txt @@ -1,291 +1,284 @@ academic acid -acoustic -actor +acne +acquire +acrobat +activity actress adapt +adequate adjust admit +adorn adult advance -advice -aerobic +advocate afraid again -agent +agency agree +aide +aircraft +airline airport -aisle +ajar alarm album alcohol -alert alien +alive alpha already -also -alter +alto +aluminum always amazing +ambition amount -amused -analyst -anchor -anger +amuse +analysis +anatomy +ancestor +ancient +angel angry animal answer antenna -antique anxiety -anything apart -april -arctic +aquatic +arcade arena argue armed -armor -army -artefact artist artwork aspect -atom auction august aunt average -avocado +aviation avoid -awake +award away -awesome -awful -awkward axis -bean -beauty -because +axle +beam +beard +beaver become bedroom -behave +behavior +being believe -below -bench +belong benefit best -betray -between beyond -bicycle bike biology -bird -birth +birthday +bishop black -blame blanket -bleak +blessing +blimp blind -blossom -boat +blue body -bomb -border -bounce -bowl -bracket -brain -brand +bolt +boring +born +both +boundary +bracelet +branch brave -bread -bridge -brief -broccoli +breathe +briefing broken brother -brown -brush +browser +bucket budget -build +building bulb +bulge +bumpy +bundle burden -burger -burn +burning busy buyer -cactus +cage +calcium camera -campaign -canal +campus canyon +capacity capital -captain +capture carbon -career +cards +careful +cargo carpet -casino -castle -catalog -catch +carve category cause ceiling -cement -census -chair -chaos -chat -cheap +center +ceramic +champion +change +charity check -choice -chuckle -churn -circle -city +chemical +chest +chew +chubby +cinema civil -claim -clap -clarify -clean -clerk -clever -click +class +clay +cleanup client -climb +climate clinic -clog -close -cloth -clown +clock +clogs +closet +clothes club -clump cluster -coach -coconut -code -coil +coal +coastal +coding column -comfort -comic -coral -corn -cost -country -cousin +company +corner +costume +counter +course cover -coyote +cowboy cradle craft -crane -crater crazy credit -crew cricket -crime -crisp -critic -cross -crouch +criminal +crisis +critical crowd crucial -cruel -cruise crunch +crush crystal -cube -culture -cupboard +cubic +cultural curious -curve -cycle -daily +curly +custody +cylinder +daisy damage dance +darkness +database daughter -death +deadline +deal debris -decade -december +debut +decent decision -decline +declare decorate decrease -degree -delay deliver -denial -dentist +demand +density deny depart depend +depict +deploy describe desert -design -desk -despair +desire +desktop destroy -detail +detailed detect device devote -diamond -diary -diesel +diagnose +dictate diet dilemma -direct -disagree +diminish +dining +diploma +disaster +discuss +disease +dish dismiss display distance -divert +dive divorce -doctor -dolphin +document domain -dose -double -dozen +domestic +dominant +dough +downtown dragon -drama -drastic +dramatic dream dress drift drink -drum -duck -dumb -dune +drove +drug +dryer +duckling +duke +duration dwarf dynamic -eager -eagle early -earn earth +easel easy echo +eclipse ecology edge -edit +editor educate +either elbow elder -electric +election elegant element elephant elevator elite else -embrace -emerge -employ +email +emerald +emission +emperor +emphasis +employer empty +ending endless endorse enemy @@ -293,732 +286,739 @@ energy enforce engage enjoy -enlist -enroll -entire -entry +enlarge +entrance envelope +envy +epidemic episode -equal -erase +equation +equip +eraser erode -erosion -erupt escape estate -eternal -event +estimate +evaluate +evening evidence evil -evolve +evoke exact example -excess +exceed exchange exclude excuse execute exercise exhaust -exile -exist exotic expand expect -expire explain express extend extra eyebrow -face facility -faculty +fact +failure faint -faith +fake false family famous fancy +fangs fantasy -fashion fatal fatigue favorite +fawn fiber fiction -field -file filter -final -find -finish +finance +findings +finger +firefly firm fiscal -fish +fishing fitness -flag +flame +flash flavor +flea +flexible flip float -flower -fluid -foam +floral +fluff focus -fold +forbid force -forest +forecast forget -fork +formal fortune forward -fragile -frame +founder +fraction +fragment frequent -fresh -friend -fringe -frog +freshman +friar +fridge +friendly +frost +froth frozen -fruit -fuel -function -furnace -fury -gadget +fumes +funding +furl +fused galaxy +game +garbage garden garlic -gasp -gate -gauge +gasoline +gather general genius genre -gentle +genuine +geology gesture glad glance -glare -glide +glasses +glen glimpse -glue -goal +goat golden -grape -grass +graduate +grant +grasp gravity -great -grid +gray +greatest +grief +grill +grin grocery +gross group -grow -grunt +grownup +grumpy guard -guess +guest guilt guitar -half +gums +hairy hamster hand -harbor +hanger harvest +have +havoc hawk hazard -head -heart -heavy -hedgehog -help -hero -hockey +headset +health +hearing +heat +helpful +herald +herd +hesitate +hobo holiday +holy +home +hormone hospital -hotel hour huge human -hundred -hurdle -hurt +humidity +hunting husband +hush +husky hybrid idea identify idle image -imitate impact +imply improve impulse -inch +include income increase index +indicate industry infant -inflict inform -inhale inherit injury inmate -insane insect inside install -intact -invite +intend +intimate +invasion involve +iris island isolate item ivory jacket -jaguar -jealous -jeans -jewel +jerky +jewelry join -joke -judge +judicial juice jump -jungle +junction +junior junk -ketchup -kick -kingdom +jury +justice +kernel +keyboard +kidney +kind kitchen -kite -kiwi knife -lady +knit +laden +ladle +ladybug +lair lamp +language large -laugh +laser laundry -lava -lawn lawsuit -layer leader leaf -league -leave +learn +leaves lecture legal legend -leisure -lemon +legs +lend length -lens level liberty library license lift likely -limit -line +lilac +lily +lips +liquid +listen +literary living lizard loan -lobster -local -lock +lobe +location +losing loud -love -lucky +loyalty +luck lunar lunch +lungs luxury +lying lyrics machine magazine -magnet -maid -make -manage +maiden +mailman +main +makeup +making +mama +manager mandate -mango mansion manual -maple -marble +marathon march -mask -master +market +marvel +mason material -matrix +math maximum +mayor meaning -measure -media -melt +medal +medical member -menu -mercy -mesh -metal +memory +mental +merchant +merit method -midnight -minute +metric +midst +mild +military +mineral +minister miracle -misery -mistake mixed mixture mobile -model +modern modify +moisture moment -more morning -motor +mortgage +mother +mountain mouse -movie +move much mule -multiply +multiple muscle museum music -must -myself -mystery -myth -naive -name -napkin -neck +mustang +nail +national +necklace negative -neglect -neither -nephew -nerve +nervous network news -nice nuclear -number -obey +numb +numerous +nylon +oasis +obesity object -oblige -obscure +observe obtain ocean -october -odor often -olive olympic +omit +oral orange orbit +order ordinary -organ -orient -ostrich -other +organize +ounce oven +overall owner -oyster +paces +pacific package -pact +paid painting -pair -palace -panda -panic -panther +pajamas +pancake +pants +papa paper -parade -parent -park +parcel +parking party -path +patent patrol -pave payment -peace +payroll +peaceful peanut peasant -pelican +pecan penalty pencil +percent perfect -period permit +petition +phantom +pharmacy photo phrase -physical -piano -picnic +physics +pickup picture piece -pilot +pile pink -pipe +pipeline pistol pitch -planet +plains +plan plastic -plate -play -please -pledge -pluck -plug +platform +playoff +pleasure +plot plunge practice -predict +prayer +preach +predator +pregnant +premium prepare -present -pretty +presence +prevent +priest primary priority -prison -private +prisoner +privacy prize problem -produce -profit +process +profile program -promote -prosper -proud +promise +prospect +provide +prune public pulse -pumpkin -pupil +pumps +punish +puny +pupal purchase -purpose -push -pyramid -quantum +purple +python +quantity quarter -question quick -quiz -quote -rack +quiet +race +racism radar -radio -raise -ranch -rapid -rare -raven -razor -ready -real -rebel +railroad +rainbow +raisin +random +ranked +rapids +raspy +reaction +realize +rebound +rebuild recall -receive -recipe -recycle +receiver +recover regret regular reject -relax -rely +relate +remember remind remove render repair repeat replace +require rescue -resemble -resist +research +resident response +result +retailer retreat reunion +revenue review reward +rhyme rhythm rich -rifle -ring -risk rival river -road -robot -robust -rocket -romance -rotate -rough +robin +rocky +romantic +romp +roster +round royal -rude -runway -rural -sadness -salad +ruin +ruler +rumor +sack +safari +salary salon salt satisfy satoshi -sauce -sausage -scale -scan +saver +says +scandal +scared scatter scene -school +scholar science -scissors -scorpion scout -scrap -screen +scramble +screw script -scrub -search -seat -second +scroll +seafood +season secret security segment -select senior -sense -sentence -service -seven shadow shaft -share -shed +shame +shaped +sharp +shelter sheriff -shock -shoe short -shoulder +should shrimp -sibling -siege +sidewalk silent silver similar simple -siren +single sister -size -skate -sketch skin -skirt -skull -slender +skunk +slap +slavery +sled slice -slogan +slim slow slush -small smart -smile -smoke +smear +smell +smirk +smith +smoking +smug snake -social -soda -soft +snapshot +sniff +society +software soldier -solve -someone +solution soul -sound source -spawn -special -spell +space +spark +speak +species +spelling spend -sphere +spew spider -spike +spill +spine spirit -split +spit spray -spread -spring +sprinkle +square squeeze stadium staff -stage -stamp -stand +standard +starting station stay -steak +steady step -stereo stick -still -sting -stomach -stove +stilt +story +strategy strike -strong style +subject +submit sugar -suit -sunset -super +suitable +sunlight +superior surface -survey -swallow -swap -swear -swift -swim +surprise +survive +sweater +swimming +swing switch -sword -symbol -symptom +symbolic +sympathy +syndrome system tackle -tail +tactics +tadpole talent -target +task +taste +taught taxi -teach -team +teacher +teammate +teaspoon +temple tenant -text +tendency +tension +terminal +testify +texture thank +that theater -theme theory -throw +therapy +thorn +threaten +thumb thunder ticket -tilt +tidy timber -time -tiny -tired -title -toast -today +timely +ting +tofu together -toilet -token -tomato -torch -tornado -tortoise +tolerate total -tourist -tower -town -trade +toxic +tracks traffic +training transfer trash -travel -tray +traveler +treat trend trial -trick -trim +tricycle +trip +triumph trouble true -trumpet trust -twelve -twenty twice twin -twist type typical ugly +ultimate umbrella -unaware -uncle uncover -under +undergo unfair unfold unhappy -unique +union universe +unkind unknown -until +unusual +unwrap upgrade -upset -urge -usage -used -useless +upstairs +username +usher usual -vacant -vacuum -vague valid -valve +valuable +vampire vanish -vast -vault +various +vegan velvet -vendor venture +verdict verify very veteran -vibrant -vicious -victory +vexed +victim video view vintage -violin -virus -visa -visit -vital -vivid +violence +viral +visitor +visual +vitamins +vocal voice -volcano volume -vote -voyage -wage -wagon -wait +voter +voting walnut -warfare -warm -warning -wash -waste -water -wealth +warmth +warn +watch +wavy +wealthy weapon -weather -weird +webcam welcome +welfare western -whale -wheat -when -where width -wild +wildlife window -winter -wire +wine +wireless wisdom +withdraw +wits wolf woman -world -worth +work +worthy wrap -wreck -wrestle wrist -write -yard -young -zebra +writing +wrote +year +yelp +yield +yoga +zero diff --git a/slip-0044.md b/slip-0044.md index 0f630128..0ada8d35 100644 --- a/slip-0044.md +++ b/slip-0044.md @@ -4,7 +4,7 @@ Number: SLIP-0044 Title: Registered coin types for BIP-0044 Type: Standard -Status: Draft +Status: Active Authors: Pavol Rusnak Marek Palatinus Created: 2014-07-09 @@ -26,255 +26,1415 @@ These are the registered coin types for usage in level 2 of BIP44 described in c All these constants are used as hardened derivation. -index | hexa | symbol | coin -------|------------|--------|----------------------------------- -0 | 0x80000000 | BTC | [Bitcoin](https://bitcoin.org/) -1 | 0x80000001 | | Testnet (all coins) -2 | 0x80000002 | LTC | [Litecoin](https://litecoin.org/) -3 | 0x80000003 | DOGE | [Dogecoin](https://github.com/dogecoin/dogecoin) -4 | 0x80000004 | RDD | Reddcoin -5 | 0x80000005 | DSH | [Dash](https://github.com/dashpay/dash) (ex Darkcoin) -6 | 0x80000006 | PPC | [Peercoin](https://peercoin.net/) -7 | 0x80000007 | NMC | [Namecoin](http://namecoin.info/) -8 | 0x80000008 | FTC | [Feathercoin](https://www.feathercoin.com/) -9 | 0x80000009 | XCP | [Counterparty](http://counterparty.io/) -10 | 0x8000000a | BLK | [Blackcoin](http://blackcoin.co/) -11 | 0x8000000b | NSR | [NuShares](https://nubits.com/nushares/introduction) -12 | 0x8000000c | NBT | NuBits -13 | 0x8000000d | MZC | Mazacoin -14 | 0x8000000e | VIA | Viacoin -15 | 0x8000000f | XCH | ClearingHouse -16 | 0x80000010 | RBY | Rubycoin -17 | 0x80000011 | GRS | Groestlcoin -18 | 0x80000012 | DGC | Digitalcoin -19 | 0x80000013 | CCN | Cannacoin -20 | 0x80000014 | DGB | DigiByte -21 | 0x80000015 | | [Open Assets](https://github.com/OpenAssets/open-assets-protocol) -22 | 0x80000016 | MONA | Monacoin -23 | 0x80000017 | CLAM | Clams -24 | 0x80000018 | XPM | Primecoin -25 | 0x80000019 | NEOS | Neoscoin -26 | 0x8000001a | JBS | Jumbucks -27 | 0x8000001b | ZRC | ziftrCOIN -28 | 0x8000001c | VTC | Vertcoin -29 | 0x8000001d | NXT | NXT -30 | 0x8000001e | BURST | Burst -31 | 0x8000001f | MUE | MonetaryUnit -32 | 0x80000020 | ZOOM | Zoom -33 | 0x80000021 | VPN | Vpncoin -34 | 0x80000022 | CDN | [Canada eCoin](https://github.com/Canada-eCoin/) -35 | 0x80000023 | SDC | ShadowCash -36 | 0x80000024 | PKB | [ParkByte](https://github.com/parkbyte/) -37 | 0x80000025 | PND | Pandacoin -38 | 0x80000026 | START | StartCOIN -39 | 0x80000027 | MOIN | [MOIN](https://discovermoin.com) -40 | 0x80000028 | EXP | [Expanse](http://www.expanse.tech/) -41 | 0x80000029 | EMC2 | [Einsteinium](https://www.emc2.foundation/) -42 | 0x8000002a | DCR | [Decred](https://decred.org/) -43 | 0x8000002b | XEM | [NEM](https://github.com/NemProject) -44 | 0x8000002c | PART | [Particl](https://particl.io/) -45 | 0x8000002d | ARG | [Argentum](http://www.argentum.io) -46 | 0x8000002e | | [Libertas](https://github.com/dangershony/Libertas) -47 | 0x8000002f | | [Posw coin](https://poswallet.com) -48 | 0x80000030 | SHR | [Shreeji](https://github.com/SMJBIT/SHREEJI) -49 | 0x80000031 | GCR | Global Currency Reserve (GCRcoin) -50 | 0x80000032 | NVC | [Novacoin](https://github.com/novacoin-project/novacoin) -51 | 0x80000033 | AC | [Asiacoin](https://github.com/AsiaCoin/AsiaCoinFix) -52 | 0x80000034 | BTCD | [Bitcoindark](https://github.com/jl777/btcd) -53 | 0x80000035 | DOPE | [Dopecoin](https://github.com/dopecoin-dev/DopeCoinV3) -54 | 0x80000036 | TPC | [Templecoin](https://github.com/9cat/templecoin) -55 | 0x80000037 | AIB | [AIB](https://github.com/iobond/aib) -56 | 0x80000038 | EDRC | [EDRCoin](https://github.com/EDRCoin/EDRcoin-src) -57 | 0x80000039 | SYS | [Syscoin](https://github.com/syscoin/syscoin2) -58 | 0x8000003a | SLR | [Solarcoin](https://github.com/onsightit/solarcoin) -59 | 0x8000003b | SMLY | [Smileycoin](https://github.com/tutor-web/smileyCoin) -60 | 0x8000003c | ETH | [Ether](https://ethereum.org/ether) -61 | 0x8000003d | ETC | [Ether Classic](https://ethereumclassic.github.io) -62 | 0x8000003e | PSB | [Pesobit](https://github.com/pesobitph/pesobit-source) -63 | 0x8000003f | LDCN | [Landcoin](http://landcoin.co/) -64 | 0x80000040 | | [Open Chain](https://github.com/openchain/) -65 | 0x80000041 | XBC | [Bitcoinplus](https://bitcoinplus.org) -66 | 0x80000042 | IOP | [Internet of People](http://www.fermat.org) -67 | 0x80000043 | NXS | [Nexus](http://www.nexusearth.com/) -68 | 0x80000044 | INSN | [InsaneCoin](http://insanecoin.com) -69 | 0x80000045 | OK | [OKCash](https://github.com/okcashpro/) -70 | 0x80000046 | BRIT | [BritCoin](https://britcoin.com) -71 | 0x80000047 | CMP | [Compcoin](https://compcoin.com) -72 | 0x80000048 | CRW | [Crown](http://crown.tech/) -73 | 0x80000049 | BELA | [BelaCoin](http://belacoin.org) -74 | 0x8000004a | VASH | [Virtual Cash](http://www.bitnet.cc/) the new version of Vpncoin -75 | 0x8000004b | FJC | [FujiCoin](http://www.fujicoin.org/) -76 | 0x8000004c | MIX | [MIX](https://www.mix-blockchain.org/) -77 | 0x8000004d | XVG | [Verge](https://github.com/vergecurrency/verge/) -78 | 0x8000004e | EFL | [Electronic Gulden](https://egulden.org/) -79 | 0x8000004f | CLUB | [ClubCoin](https://clubcoin.co/) -80 | 0x80000050 | RICHX | [RichCoin](https://richcoin.us/) -81 | 0x80000051 | POT | [Potcoin](http://potcoin.com/) -82 | 0x80000052 | QRK | Quarkcoin -83 | 0x80000053 | TRC | Terracoin -84 | 0x80000054 | GRC | Gridcoin -85 | 0x80000055 | AUR | [Auroracoin](http://auroracoin.is/) -86 | 0x80000056 | IXC | IXCoin -87 | 0x80000057 | NLG | [Gulden](https://Gulden.com/) -88 | 0x80000058 | BITB | [BitBean](http://bitbean.org/) -89 | 0x80000059 | BTA | [Bata](http://bata.io/) -90 | 0x8000005a | XMY | [Myriadcoin](http://myriadcoin.org) -91 | 0x8000005b | BSD | [BitSend](http://bitsend.info) -92 | 0x8000005c | UNO | [Unobtanium](http://http://unobtanium.uno/) -93 | 0x8000005d | MTR | [MasterTrader](https://github.com/CrypticApplications/MTR-Update/) -94 | 0x8000005e | GB | [GoldBlocks](https://github.com/goldblockscoin/goldblocks) -95 | 0x8000005f | SHM | [Saham](https://github.com/SahamDev/SahamDev) -96 | 0x80000060 | CRX | [Chronos](https://github.com/chronoscoin/Chronoscoin) -97 | 0x80000061 | BIQ | [Ubiquoin](https://github.com/ubiquoin/ubiq) -98 | 0x80000062 | EVO | [Evotion](https://github.com/evoshiun/Evotion) -99 | 0x80000063 | STO | [SaveTheOcean](https://github.com/SaveTheOceanMovement/SaveTheOceanCoin) -100 | 0x80000064 | BIGUP | [BigUp](https://github.com/BigUps/) -101 | 0x80000065 | GAME | [GameCredits](https://github.com/gamecredits-project) -102 | 0x80000066 | DLC | [Dollarcoins](https://github.com/dollarcoins/source) -103 | 0x80000067 | ZYD | [Zayedcoin](https://github.com/ZayedCoin/Zayedcoin) -104 | 0x80000068 | DBIC | [Dubaicoin](https://github.com/DubaiCoinDev/DubaiCoin) -105 | 0x80000069 | STRAT | [Stratis](http://www.stratisplatform.com) -106 | 0x8000006a | SH | [Shilling](https://github.com/yavwa/Shilling) -107 | 0x8000006b | MARS | [MarsCoin](http://www.marscoin.org/) -108 | 0x8000006c | UBQ | [Ubiq](https://github.com/Ubiq) -109 | 0x8000006d | PTC | [Pesetacoin](http://pesetacoin.info/) -110 | 0x8000006e | NRC | [Neurocoin](https://neurocoin.org) -111 | 0x8000006f | ARK | [ARK](https://ark.io) -112 | 0x80000070 | USC | [UltimateSecureCashMain](http://ultimatesecurecash.info) -113 | 0x80000071 | HMP | [Hempcoin](http://hempcoin.org) -114 | 0x80000072 | LINX | [Linx](https://mylinx.io) -115 | 0x80000073 | ECN | [Ecoin](https://www.ecoinsource.com) -116 | 0x80000074 | DNR | [Denarius](https://denarius.io) -117 | 0x80000075 | PINK | [Pinkcoin](http://getstarted.with.pink) -118 | 0x80000076 | PIGGY | [PiggyCoin](https://www.piggy-coin.com/) -119 | 0x80000077 | PIVX | [Pivx](https://github.com/PIVX-Project/PIVX) -120 | 0x80000078 | FLASH | [Flashcoin](https://flashcoin.io) -121 | 0x80000079 | ZEN | [Zencash](https://zensystem.io) -122 | 0x8000007a | PUT | [Putincoin](https://putincoin.info) -123 | 0x8000007b | ZNY | [BitZeny](http://bitzeny.org/) -124 | 0x8000007c | UNIFY | [Unify](http://unifycryptocurrency.com) -125 | 0x8000007d | XST | [StealthCoin](http://www.stealthcoin.com) -126 | 0x8000007e | BRK | [Breakout Coin](http://www.breakoutcoin.com) -127 | 0x8000007f | VC | [Vcash](https://vcash.info) -128 | 0x80000080 | XMR | [Monero](https://getmonero.org/) -129 | 0x80000081 | VOX | [Voxels](https://www.voxelus.com) -130 | 0x80000082 | NAV | [NavCoin](https://github.com/navcoindev/navcoin2) -131 | 0x80000083 | FCT | [Factom Factoids](https://github.com/FactomProject/FactomDocs/blob/master/wallet_info/wallet_test_vectors.md) -132 | 0x80000084 | EC | [Factom Entry Credits](https://github.com/FactomProject) -133 | 0x80000085 | ZEC | [Zcash](https://z.cash) -134 | 0x80000086 | LSK | [Lisk](https://lisk.io/) -135 | 0x80000087 | STEEM | [Steem](http://steem.io) -136 | 0x80000088 | XZC | [ZCoin](https://zcoin.io) -137 | 0x80000089 | RSK | [Rootstock](http://www.rsk.co/) -138 | 0x8000008a | | [Giftblock](https://github.com/gyft/giftblock) -139 | 0x8000008b | RPT | [RealPointCoin](https://github.com/MaxSmile/RealPointCoinQt) -140 | 0x8000008c | LBC | [LBRY Credits](https://lbry.io/) -141 | 0x8000008d | KMD | [Komodo](https://komodoplatform.com/) -142 | 0x8000008e | BSQ | [bisq Token](http://bisq.io/) -143 | 0x8000008f | RIC | [Riecoin](https://github.com/riecoin/riecoin) -144 | 0x80000090 | XRP | [Ripple](https://ripple.com) -145 | 0x80000091 | BCH | [Bitcoin Cash](https://www.bitcoincash.org) -146 | 0x80000092 | NEBL | [Neblio](https://nebl.io) -147 | 0x80000093 | ZCL | [ZClassic](http://zclassic.org/) -148 | 0x80000094 | XLM | [Stellar Lumens](https://www.stellar.org/) -149 | 0x80000095 | NLC2 | [NoLimitCoin2](http://www.nolimitcoin.org) -150 | 0x80000096 | WHL | [WhaleCoin](https://whalecoin.org/) -151 | 0x80000097 | ERC | [EuropeCoin](https://www.europecoin.eu.org/) -152 | 0x80000098 | DMD | [Diamond](http://bit.diamonds) -153 | 0x80000099 | BTM | [Bytom](https://bytom.io) -154 | 0x8000009a | BIO | [Biocoin](https://biocoin.bio) -155 | 0x8000009b | XWC | [Whitecoin](https://www.whitecoin.info) -156 | 0x8000009c | BTG | [Bitcoin Gold](http://www.btcgpu.org) -157 | 0x8000009d | BTC2X | [Bitcoin 2x](https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77) -158 | 0x8000009e | SSN | [SuperSkynet](http://wwww.superskynet.org/) -159 | 0x8000009f | TOA | [TOACoin](http://www.toacoin.com) -160 | 0x800000a0 | BTX | [Bitcore](https://bitcore.cc) -161 | 0x800000a1 | ACC | [Adcoin](https://www.getadcoin.com/) -162 | 0x800000a2 | BCO | [Bridgecoin](https://bridgecoin.org/) -163 | 0x800000a3 | ELLA | [Ellaism](https://ellaism.org) -164 | 0x800000a4 | PIRL | [Pirl](https://pirl.io) -165 | 0x800000a5 | XRB | [RaiBlocks](https://raiblocks.com) -166 | 0x800000a6 | VIVO | [Vivo](https://www.vivocrypto.com/) -167 | 0x800000a7 | FRST | [Firstcoin](http://firstcoinproject.com) -168 | 0x800000a8 | HNC | [Helleniccoin](http://www.helleniccoin.gr/) -169 | 0x800000a9 | BUZZ | [BUZZ](http://www.buzzcoin.info/) -170 | 0x800000aa | MBRS | [Ember](https://www.embercoin.io/) -171 | 0x800000ab | HSR | [Hcash](https://h.cash) -172 | 0x800000ac | HTML | [HTMLCOIN](https://htmlcoin.com/) -173 | 0x800000ad | ODN | [Obsidian](https://obsidianplatform.com/) -174 | 0x800000ae | ONX | [OnixCoin](https://www.onixcoin.com/) -175 | 0x800000af | RVN | [Ravencoin](https://ravencoin.org/) -176 | 0x800000b0 | GBX | [GoByte](https://gobyte.network) -177 | 0x800000b1 | BTCZ | [BitcoinZ](https://btcz.rocks/en/) -178 | 0x800000b2 | POA | [Poa](https://poa.network) -179 | 0x800000b3 | NYC | [NewYorkCoin](http://nycoin.net) -180 | 0x800000b4 | MXT | [MarteXcoin](http://martexcoin.org) -181 | 0x800000b5 | WC | [Wincoin](https://wincoin.co) -182 | 0x800000b6 | MNX | [Minexcoin](https://minexcoin.com) -183 | 0x800000b7 | BTCP | [Bitcoin Private](https://btcprivate.org) -184 | 0x800000b8 | MUSIC | [Musicoin](https://www.musicoin.org) -185 | 0x800000b9 | BCA | [Bitcoin Atom](https://bitcoinatom.io) -186 | 0x800000ba | CRAVE | [Crave](https://craveproject.net) -187 | 0x800000bb | STAK | [STRAKS](https://straks.io) -188 | 0x800000bc | WBTC | [World Bitcoin](http://www.wbtcteam.org/) -189 | 0x800000bd | LCH | [LiteCash](http://www.litecash.info/) -190 | 0x800000be | EXCL | [ExclusiveCoin](https://exclusivecoin.pw/) -191 | 0x800000bf | | [Lynx](https://getlynx.io) -192 | 0x800000c0 | LCC | [LitecoinCash](https://litecoinca.sh) -193 | 0x800000c1 | FRM | [Feirm](https://www.feirm.com) -197 | 0x800000c5 | HUSH | [HUSH](https://myhush.org) -200 | 0x800000c8 | OMNI | [Omni](http://www.omnilayer.org) -215 | 0x800000d7 | BOXY | [BoxyCoin](http://www.boxycoin.org/) -222 | 0x800000de | BITG | [Bitcoin Green](https://savebitcoin.io) -223 | 0x800000df | ASK | [AskCoin](https://askcoin.org) -224 | 0x800000e0 | SMART | [Smartcash](https://smartcash.cc) -225 | 0x800000e1 | XUEZ | [XUEZ](https://xuezcoin.com) -233   | 0x800000e9 | VAR   | [Varda](https://varda.io) -247 | 0x800000f7 | UC | [Ulord](http://ulord.one) -255 | 0x800000ff | | [SmartHoldem](https://smartholdem.io) -256 | 0x80000100 | NANO | [Bitcoin Nano](https://www.btcnano.org) -258 | 0x80000102 | | [Zen Protocol](https://www.zenprotocol.com/) -312 | 0x80000138 | ARA | [Aura](https://auraledger.com/) -321 | 0x80000141 | RAP | [Rapture](https://our-rapture.com/) -328 | 0x80000148 | BLOCK | [Blocknet](https://blocknet.co/) -333 | 0x8000014d | MEM | [MemCoin](https://memcoin.org) -444 | 0x800001bc | PHR | [Phore](https://phore.io) -510 | 0x800001fe | KOTO | [Koto](https://koto.cash/) -512 | 0x80000200 | XRD | [Radiant](https://radiant.cash/) -555 | 0x8000022b | BCS | [Bitcoin Smart](http://bcs.info) -666 | 0x8000029a | ACT | [Achain](https://www.achain.com/) -777 | 0x80000309 | BTW | [Bitcoin World](http://btw.one) -808 | 0x80000328 | QVT | [Qvolta](https://qvolta.com) -888 | 0x80000378 | NEO | [NEO](https://neo.org/) -999 | 0x800003e7 | BCD | [Bitcoin Diamond](http://btcd.io/) -1000 | 0x800003e8 | BTN | [Bitcoin New](http://bitcoinnew.org/) -1111 | 0x80000457 | BBC | [Big Bitcoin](http://bigbitcoins.org/) -1145 | 0x80000479 | CDY | [Bitcoin Candy](http://www.bitcoincandy.one) -1337 | 0x80000539 | DFC | [Defcoin](http://defcoin-ng.org) -1524 | 0x800005f4 | | [Taler](http://taler.site) -1815 | 0x80000717 | ADA | [Cardano](https://www.cardanohub.org/en/home/) -1977 | 0x800007b9 | XMX | [Xuma](http://www.xumacoin.org/) -1989 | 0x800007c5 | HODL | [HOdlcoin](https://hodlcoin.com/) -2301 | 0x800008fd | QTUM | [QTUM](https://qtum.org/en/) -4242 | 0x80001092 | AXE | [Axe](https://github.com/AXErunners/axe) -6666 | 0x80001a0a | BPA | [Bitcoin Pizza](http://p.top/) -6688 | 0x80001a20 | SAFE | [SAFE](http://www.anwang.com/) -8339 | 0x80002093 | BTQ   | [BitcoinQuark](https://www.bitcoinquark.org) -8888 | 0x800022b8 | SBTC | [Super Bitcoin](https://www.superbtc.org) -8999 | 0x80002327 | BTP | [Bitcoin Pay](http://www.btceasypay.com) -9888 | 0x800026a0 | BTF | [Bitcoin Faith](http://bitcoinfaith.org) -9999 | 0x8000270f | BTV | [Bitvote](www.bitvote.one) -37310 | 0x800091be | | [Rootstock Testnet](http://www.rsk.co/) -88888 | 0x80015b38 | ORT | [Orientum](https://orientum.io) -5718350 | 0x8057414e | WAN   | [Wanchain](https://wanchain.org/) -5741564 | 0x80579bfc | WAVES  | [Waves](https://wavesplatform.com/) +| Coin type | Path component (`coin_type'`) | Symbol | Coin | +| ---------- | ----------------------------- | ------- | --------------------------------- | +| 0 | 0x80000000 | BTC | Bitcoin | +| 1 | 0x80000001 | | Testnet (all coins) | +| 2 | 0x80000002 | LTC | Litecoin | +| 3 | 0x80000003 | DOGE | Dogecoin | +| 4 | 0x80000004 | RDD | Reddcoin | +| 5 | 0x80000005 | DASH | Dash | +| 6 | 0x80000006 | PPC | Peercoin | +| 7 | 0x80000007 | NMC | Namecoin | +| 8 | 0x80000008 | FTC | Feathercoin | +| 9 | 0x80000009 | XCP | Counterparty | +| 10 | 0x8000000a | BLK | Blackcoin | +| 11 | 0x8000000b | NSR | NuShares | +| 12 | 0x8000000c | NBT | NuBits | +| 13 | 0x8000000d | MZC | Mazacoin | +| 14 | 0x8000000e | VIA | Viacoin | +| 15 | 0x8000000f | XCH | ClearingHouse | +| 16 | 0x80000010 | RBY | Rubycoin | +| 17 | 0x80000011 | GRS | Groestlcoin | +| 18 | 0x80000012 | DGC | Digitalcoin | +| 19 | 0x80000013 | CCN | Cannacoin | +| 20 | 0x80000014 | DGB | DigiByte | +| 21 | 0x80000015 | | Open Assets | +| 22 | 0x80000016 | MONA | Monacoin | +| 23 | 0x80000017 | CLAM | Clams | +| 24 | 0x80000018 | XPM | Primecoin | +| 25 | 0x80000019 | NEOS | Neoscoin | +| 26 | 0x8000001a | JBS | Jumbucks | +| 27 | 0x8000001b | ZRC | ziftrCOIN | +| 28 | 0x8000001c | VTC | Vertcoin | +| 29 | 0x8000001d | NXT | NXT | +| 30 | 0x8000001e | BURST | Burst | +| 31 | 0x8000001f | MUE | MonetaryUnit | +| 32 | 0x80000020 | ZOOM | Zoom | +| 33 | 0x80000021 | VASH | Virtual Cash | +| 34 | 0x80000022 | CDN | Canada eCoin | +| 35 | 0x80000023 | SDC | ShadowCash | +| 36 | 0x80000024 | PKB | ParkByte | +| 37 | 0x80000025 | PND | Pandacoin | +| 38 | 0x80000026 | START | StartCOIN | +| 39 | 0x80000027 | MOIN | MOIN | +| 40 | 0x80000028 | EXP | Expanse | +| 41 | 0x80000029 | EMC2 | Einsteinium | +| 42 | 0x8000002a | DCR | Decred | +| 43 | 0x8000002b | XEM | NEM | +| 44 | 0x8000002c | PART | Particl | +| 45 | 0x8000002d | ARG | Argentum (dead) | +| 46 | 0x8000002e | | Libertas | +| 47 | 0x8000002f | | Posw coin | +| 48 | 0x80000030 | SHR | Shreeji | +| 49 | 0x80000031 | GCR | Global Currency Reserve (GCRcoin) | +| 50 | 0x80000032 | NVC | Novacoin | +| 51 | 0x80000033 | AC | Asiacoin | +| 52 | 0x80000034 | BTCD | BitcoinDark | +| 53 | 0x80000035 | DOPE | Dopecoin | +| 54 | 0x80000036 | TPC | Templecoin | +| 55 | 0x80000037 | AIB | AIB | +| 56 | 0x80000038 | EDRC | EDRCoin | +| 57 | 0x80000039 | SYS | Syscoin | +| 58 | 0x8000003a | SLR | Solarcoin | +| 59 | 0x8000003b | SMLY | Smileycoin | +| 60 | 0x8000003c | ETH | Ether | +| 61 | 0x8000003d | ETC | Ether Classic | +| 62 | 0x8000003e | PSB | Pesobit | +| 63 | 0x8000003f | LDCN | Landcoin (dead) | +| 64 | 0x80000040 | | Open Chain | +| 65 | 0x80000041 | XBC | Bitcoinplus | +| 66 | 0x80000042 | IOP | Internet of People | +| 67 | 0x80000043 | NXS | Nexus | +| 68 | 0x80000044 | INSN | InsaneCoin | +| 69 | 0x80000045 | OK | OKCash | +| 70 | 0x80000046 | BRIT | BritCoin | +| 71 | 0x80000047 | CMP | Compcoin | +| 72 | 0x80000048 | CRW | Crown | +| 73 | 0x80000049 | BELA | BelaCoin | +| 74 | 0x8000004a | ICX | ICON | +| 75 | 0x8000004b | FJC | FujiCoin | +| 76 | 0x8000004c | MIX | MIX | +| 77 | 0x8000004d | XVG | Verge Currency | +| 78 | 0x8000004e | EFL | Electronic Gulden | +| 79 | 0x8000004f | CLUB | ClubCoin | +| 80 | 0x80000050 | RICHX | RichCoin | +| 81 | 0x80000051 | POT | Potcoin | +| 82 | 0x80000052 | QRK | Quarkcoin | +| 83 | 0x80000053 | TRC | Terracoin | +| 84 | 0x80000054 | GRC | Gridcoin | +| 85 | 0x80000055 | AUR | Auroracoin | +| 86 | 0x80000056 | IXC | IXCoin | +| 87 | 0x80000057 | NLG | Gulden | +| 88 | 0x80000058 | BITB | BitBean | +| 89 | 0x80000059 | BTA | Bata | +| 90 | 0x8000005a | XMY | Myriadcoin | +| 91 | 0x8000005b | BSD | BitSend | +| 92 | 0x8000005c | UNO | Unobtanium | +| 93 | 0x8000005d | MTR | MasterTrader | +| 94 | 0x8000005e | GB | GoldBlocks | +| 95 | 0x8000005f | SHM | Saham | +| 96 | 0x80000060 | CRX | Chronos | +| 97 | 0x80000061 | BIQ | Ubiquoin | +| 98 | 0x80000062 | EVO | Evotion | +| 99 | 0x80000063 | STO | SaveTheOcean | +| 100 | 0x80000064 | BIGUP | BigUp | +| 101 | 0x80000065 | GAME | GameCredits | +| 102 | 0x80000066 | DLC | Dollarcoins | +| 103 | 0x80000067 | ZYD | Zayedcoin | +| 104 | 0x80000068 | DBIC | Dubaicoin | +| 105 | 0x80000069 | STRAT | Stratis | +| 106 | 0x8000006a | SH | Shilling | +| 107 | 0x8000006b | MARS | MarsCoin | +| 108 | 0x8000006c | UBQ | Ubiq | +| 109 | 0x8000006d | PTC | Pesetacoin | +| 110 | 0x8000006e | NRO | Neurocoin | +| 111 | 0x8000006f | ARK | ARK | +| 112 | 0x80000070 | USC | UltimateSecureCashMain | +| 113 | 0x80000071 | THC | Hempcoin | +| 114 | 0x80000072 | LINX | Linx | +| 115 | 0x80000073 | ECN | Ecoin | +| 116 | 0x80000074 | DNR | Denarius | +| 117 | 0x80000075 | PINK | Pinkcoin | +| 118 | 0x80000076 | ATOM | Atom | +| 119 | 0x80000077 | PIVX | Pivx | +| 120 | 0x80000078 | FLASH | Flashcoin | +| 121 | 0x80000079 | ZEN | Zencash | +| 122 | 0x8000007a | PUT | Putincoin | +| 123 | 0x8000007b | ZNY | BitZeny | +| 124 | 0x8000007c | UNIFY | Unify | +| 125 | 0x8000007d | XST | StealthCoin | +| 126 | 0x8000007e | BRK | Breakout Coin | +| 127 | 0x8000007f | VC | Vcash | +| 128 | 0x80000080 | XMR | Monero | +| 129 | 0x80000081 | VOX | Voxels | +| 130 | 0x80000082 | NAV | NavCoin | +| 131 | 0x80000083 | FCT | Factom Factoids | +| 132 | 0x80000084 | EC | Factom Entry Credits | +| 133 | 0x80000085 | ZEC | Zcash | +| 134 | 0x80000086 | LSK | Lisk | +| 135 | 0x80000087 | STEEM | Steem | +| 136 | 0x80000088 | XZC | ZCoin | +| 137 | 0x80000089 | RBTC | Rootstock | +| 138 | 0x8000008a | | Giftblock | +| 139 | 0x8000008b | RPT | RealPointCoin | +| 140 | 0x8000008c | LBC | LBRY Credits | +| 141 | 0x8000008d | KMD | Komodo | +| 142 | 0x8000008e | BSQ | bisq Token | +| 143 | 0x8000008f | RIC | Riecoin | +| 144 | 0x80000090 | XRP | XRP | +| 145 | 0x80000091 | BCH | Bitcoin Cash | +| 146 | 0x80000092 | NEBL | Neblio | +| 147 | 0x80000093 | ZCL | ZClassic | +| 148 | 0x80000094 | XLM | Stellar Lumens | +| 149 | 0x80000095 | NLC2 | NoLimitCoin2 | +| 150 | 0x80000096 | WHL | WhaleCoin | +| 151 | 0x80000097 | ERC | EuropeCoin | +| 152 | 0x80000098 | DMD | Diamond | +| 153 | 0x80000099 | BTM | Bytom | +| 154 | 0x8000009a | BIO | Biocoin | +| 155 | 0x8000009b | XWCC | Whitecoin Classic | +| 156 | 0x8000009c | BTG | Bitcoin Gold | +| 157 | 0x8000009d | BTC2X | Bitcoin 2x | +| 158 | 0x8000009e | SSN | SuperSkynet | +| 159 | 0x8000009f | TOA | TOACoin | +| 160 | 0x800000a0 | BTX | Bitcore | +| 161 | 0x800000a1 | ACC | Adcoin | +| 162 | 0x800000a2 | BCO | Bridgecoin | +| 163 | 0x800000a3 | ELLA | Ellaism | +| 164 | 0x800000a4 | PIRL | Pirl | +| 165 | 0x800000a5 | XNO | Nano | +| 166 | 0x800000a6 | VIVO | Vivo | +| 167 | 0x800000a7 | FRST | Firstcoin | +| 168 | 0x800000a8 | HNC | Helleniccoin | +| 169 | 0x800000a9 | BUZZ | BUZZ | +| 170 | 0x800000aa | MBRS | Ember | +| 171 | 0x800000ab | HC | Hcash | +| 172 | 0x800000ac | HTML | HTMLCOIN | +| 173 | 0x800000ad | ODN | Obsidian | +| 174 | 0x800000ae | ONX | OnixCoin | +| 175 | 0x800000af | RVN | Ravencoin | +| 176 | 0x800000b0 | GBX | GoByte | +| 177 | 0x800000b1 | BTCZ | BitcoinZ | +| 178 | 0x800000b2 | POA | Poa | +| 179 | 0x800000b3 | NYC | NewYorkCoin | +| 180 | 0x800000b4 | MXT | MarteXcoin | +| 181 | 0x800000b5 | WC | Wincoin | +| 182 | 0x800000b6 | MNX | Minexcoin | +| 183 | 0x800000b7 | BTCP | Bitcoin Private | +| 184 | 0x800000b8 | MUSIC | Musicoin | +| 185 | 0x800000b9 | BCA | Bitcoin Atom | +| 186 | 0x800000ba | CRAVE | Crave | +| 187 | 0x800000bb | STAK | STRAKS | +| 188 | 0x800000bc | WBTC | World Bitcoin | +| 189 | 0x800000bd | LCH | LiteCash | +| 190 | 0x800000be | EXCL | ExclusiveCoin | +| 191 | 0x800000bf | LYNX | Lynx | +| 192 | 0x800000c0 | LCC | LitecoinCash | +| 193 | 0x800000c1 | XFE | Feirm | +| 194 | 0x800000c2 | EOS | EOS | +| 195 | 0x800000c3 | TRX | Tron | +| 196 | 0x800000c4 | KOBO | Kobocoin | +| 197 | 0x800000c5 | HUSH | HUSH | +| 198 | 0x800000c6 | BAN | Banano | +| 199 | 0x800000c7 | ETF | ETF | +| 200 | 0x800000c8 | OMNI | Omni | +| 201 | 0x800000c9 | BIFI | BitcoinFile | +| 202 | 0x800000ca | UFO | Uniform Fiscal Object | +| 203 | 0x800000cb | CNMC | Cryptonodes | +| 204 | 0x800000cc | BCN | Bytecoin | +| 205 | 0x800000cd | RIN | Ringo | +| 206 | 0x800000ce | ATP | Alaya | +| 207 | 0x800000cf | EVT | everiToken | +| 208 | 0x800000d0 | ATN | ATN | +| 209 | 0x800000d1 | BIS | Bismuth | +| 210 | 0x800000d2 | NEET | NEETCOIN | +| 211 | 0x800000d3 | BOPO | BopoChain | +| 212 | 0x800000d4 | OOT | Utrum | +| 213 | 0x800000d5 | ALIAS | Alias | +| 214 | 0x800000d6 | MONK | Monkey Project | +| 215 | 0x800000d7 | BOXY | BoxyCoin | +| 216 | 0x800000d8 | FLO | Flo | +| 217 | 0x800000d9 | MEC | Megacoin | +| 218 | 0x800000da | BTDX | BitCloud | +| 219 | 0x800000db | XAX | Artax | +| 220 | 0x800000dc | ANON | ANON | +| 221 | 0x800000dd | LTZ | LitecoinZ | +| 222 | 0x800000de | BITG | Bitcoin Green | +| 223 | 0x800000df | ICP | Internet Computer (DFINITY) | +| 224 | 0x800000e0 | SMART | Smartcash | +| 225 | 0x800000e1 | XUEZ | XUEZ | +| 226 | 0x800000e2 | HLM | Helium | +| 227 | 0x800000e3 | WEB | Webchain | +| 228 | 0x800000e4 | ACM | Actinium | +| 229 | 0x800000e5 | NOS | NOS Stable Coins | +| 230 | 0x800000e6 | BITC | BitCash | +| 231 | 0x800000e7 | HTH | Help The Homeless Coin | +| 232 | 0x800000e8 | TZC | Trezarcoin | +| 233 | 0x800000e9 | VAR | Varda | +| 234 | 0x800000ea | IOV | IOV | +| 235 | 0x800000eb | FIO | FIO | +| 236 | 0x800000ec | BSV | BitcoinSV | +| 237 | 0x800000ed | DXN | DEXON | +| 238 | 0x800000ee | QRL | Quantum Resistant Ledger | +| 239 | 0x800000ef | PCX | ChainX | +| 240 | 0x800000f0 | LOKI | Loki | +| 241 | 0x800000f1 | | Imagewallet | +| 242 | 0x800000f2 | NIM | Nimiq | +| 243 | 0x800000f3 | SOV | Sovereign Coin | +| 244 | 0x800000f4 | JCT | Jibital Coin | +| 245 | 0x800000f5 | SLP | Simple Ledger Protocol | +| 246 | 0x800000f6 | EWT | Energy Web | +| 247 | 0x800000f7 | UC | Ulord | +| 248 | 0x800000f8 | EXOS | EXOS | +| 249 | 0x800000f9 | ECA | Electra | +| 250 | 0x800000fa | SOOM | Soom | +| 251 | 0x800000fb | XRD | Redstone | +| 252 | 0x800000fc | FREE | FreeCoin | +| 253 | 0x800000fd | NPW | NewPowerCoin | +| 254 | 0x800000fe | BST | BlockStamp | +| 255 | 0x800000ff | | SmartHoldem | +| 256 | 0x80000100 | NANO | Bitcoin Nano | +| 257 | 0x80000101 | BTCC | Bitcoin Core | +| 258 | 0x80000102 | | Zen Protocol | +| 259 | 0x80000103 | ZEST | Zest | +| 260 | 0x80000104 | ABT | ArcBlock | +| 261 | 0x80000105 | PION | Pion | +| 262 | 0x80000106 | DT3 | DreamTeam3 | +| 263 | 0x80000107 | ZBUX | Zbux | +| 264 | 0x80000108 | KPL | Kepler | +| 265 | 0x80000109 | TPAY | TokenPay | +| 266 | 0x8000010a | ZILLA | ChainZilla | +| 267 | 0x8000010b | ANK | Anker | +| 268 | 0x8000010c | BCC | BCChain | +| 269 | 0x8000010d | HPB | HPB | +| 270 | 0x8000010e | ONE | ONE | +| 271 | 0x8000010f | SBC | SBC | +| 272 | 0x80000110 | IPC | IPChain | +| 273 | 0x80000111 | DMTC | Dominantchain | +| 274 | 0x80000112 | OGC | Onegram | +| 275 | 0x80000113 | SHIT | Shitcoin | +| 276 | 0x80000114 | ANDES | Andescoin | +| 277 | 0x80000115 | AREPA | Arepacoin | +| 278 | 0x80000116 | BOLI | Bolivarcoin | +| 279 | 0x80000117 | RIL | Rilcoin | +| 280 | 0x80000118 | HTR | Hathor Network | +| 281 | 0x80000119 | ACME | Accumulate | +| 282 | 0x8000011a | BRAVO | BRAVO | +| 283 | 0x8000011b | ALGO | Algorand | +| 284 | 0x8000011c | BZX | Bitcoinzero | +| 285 | 0x8000011d | GXX | GravityCoin | +| 286 | 0x8000011e | HEAT | HEAT | +| 287 | 0x8000011f | XDN | DigitalNote | +| 288 | 0x80000120 | FSN | FUSION | +| 289 | 0x80000121 | CPC | Capricoin | +| 290 | 0x80000122 | BOLD | Bold | +| 291 | 0x80000123 | IOST | IOST | +| 292 | 0x80000124 | TKEY | Tkeycoin | +| 293 | 0x80000125 | USE | Usechain | +| 294 | 0x80000126 | BCZ | BitcoinCZ | +| 295 | 0x80000127 | IOC | Iocoin | +| 296 | 0x80000128 | ASF | Asofe | +| 297 | 0x80000129 | MASS | MASS | +| 298 | 0x8000012a | FAIR | FairCoin | +| 299 | 0x8000012b | NUKO | Nekonium | +| 300 | 0x8000012c | GNX | Genaro Network | +| 301 | 0x8000012d | DIVI | Divi Project | +| 302 | 0x8000012e | CMT | Community | +| 303 | 0x8000012f | EUNO | EUNO | +| 304 | 0x80000130 | IOTX | IoTeX | +| 305 | 0x80000131 | ONION | DeepOnion | +| 306 | 0x80000132 | 8BIT | 8Bit | +| 307 | 0x80000133 | ATC | AToken Coin | +| 308 | 0x80000134 | BTS | Bitshares | +| 309 | 0x80000135 | CKB | Nervos CKB | +| 310 | 0x80000136 | UGAS | Ultrain | +| 311 | 0x80000137 | ADS | Adshares | +| 312 | 0x80000138 | ARA | Aura | +| 313 | 0x80000139 | ZIL | Zilliqa | +| 314 | 0x8000013a | MOAC | MOAC | +| 315 | 0x8000013b | SWTC | SWTC | +| 316 | 0x8000013c | VNSC | vnscoin | +| 317 | 0x8000013d | PLUG | Pl^g | +| 318 | 0x8000013e | MAN | Matrix AI Network | +| 319 | 0x8000013f | ECC | ECCoin | +| 320 | 0x80000140 | RPD | Rapids | +| 321 | 0x80000141 | RAP | Rapture | +| 322 | 0x80000142 | GARD | Hashgard | +| 323 | 0x80000143 | ZER | Zero | +| 324 | 0x80000144 | EBST | eBoost | +| 325 | 0x80000145 | SHARD | Shard | +| 326 | 0x80000146 | MRX | Metrix Coin | +| 327 | 0x80000147 | CMM | Commercium | +| 328 | 0x80000148 | BLOCK | Blocknet | +| 329 | 0x80000149 | AUDAX | AUDAX | +| 330 | 0x8000014a | LUNA | Terra | +| 331 | 0x8000014b | ZPM | zPrime | +| 332 | 0x8000014c | KUVA | Kuva Utility Note | +| 333 | 0x8000014d | MEM | MemCoin | +| 334 | 0x8000014e | CS | Credits | +| 335 | 0x8000014f | SWIFT | SwiftCash | +| 336 | 0x80000150 | FIX | FIX | +| 337 | 0x80000151 | CPC | CPChain | +| 338 | 0x80000152 | VGO | VirtualGoodsToken | +| 339 | 0x80000153 | DVT | DeVault | +| 340 | 0x80000154 | N8V | N8VCoin | +| 341 | 0x80000155 | MTNS | OmotenashiCoin | +| 342 | 0x80000156 | BLAST | BLAST | +| 343 | 0x80000157 | DCT | DECENT | +| 344 | 0x80000158 | AUX | Auxilium | +| 345 | 0x80000159 | USDP | USDP | +| 346 | 0x8000015a | HTDF | HTDF | +| 347 | 0x8000015b | YEC | Ycash | +| 348 | 0x8000015c | QLC | QLC Chain | +| 349 | 0x8000015d | TEA | Icetea Blockchain | +| 350 | 0x8000015e | ARW | ArrowChain | +| 351 | 0x8000015f | MDM | Medium | +| 352 | 0x80000160 | CYB | Cybex | +| 353 | 0x80000161 | LTO | LTO Network | +| 354 | 0x80000162 | DOT | Polkadot | +| 355 | 0x80000163 | AEON | Aeon | +| 356 | 0x80000164 | RES | Resistance | +| 357 | 0x80000165 | AYA | Aryacoin | +| 358 | 0x80000166 | DAPS | Dapscoin | +| 359 | 0x80000167 | CSC | CasinoCoin | +| 360 | 0x80000168 | VSYS | V Systems | +| 361 | 0x80000169 | NOLLAR | Nollar | +| 362 | 0x8000016a | XNOS | NOS | +| 363 | 0x8000016b | CPU | CPUchain | +| 364 | 0x8000016c | LAMB | Lambda Storage Chain | +| 365 | 0x8000016d | VCT | ValueCyber | +| 366 | 0x8000016e | CZR | Canonchain | +| 367 | 0x8000016f | ABBC | ABBC | +| 368 | 0x80000170 | HET | HET | +| 369 | 0x80000171 | XAS | Asch | +| 370 | 0x80000172 | VDL | Vidulum | +| 371 | 0x80000173 | MED | MediBloc | +| 372 | 0x80000174 | ZVC | ZVChain | +| 373 | 0x80000175 | VESTX | Vestx | +| 374 | 0x80000176 | DBT | DarkBit | +| 375 | 0x80000177 | SEOS | SuperEOS | +| 376 | 0x80000178 | MXW | Maxonrow | +| 377 | 0x80000179 | ZNZ | ZENZO | +| 378 | 0x8000017a | XCX | XChain | +| 379 | 0x8000017b | SOX | SonicX | +| 380 | 0x8000017c | NYZO | Nyzo | +| 381 | 0x8000017d | ULC | ULCoin | +| 382 | 0x8000017e | RYO | Ryo Currency | +| 383 | 0x8000017f | KAL | Kaleidochain | +| 384 | 0x80000180 | XSN | Stakenet | +| 385 | 0x80000181 | DOGEC | DogeCash | +| 386 | 0x80000182 | BMV | Bitcoin Matteo's Vision | +| 387 | 0x80000183 | QBC | Quebecoin | +| 388 | 0x80000184 | IMG | ImageCoin | +| 389 | 0x80000185 | QOS | QOS | +| 390 | 0x80000186 | PKT | PKT | +| 391 | 0x80000187 | LHD | LitecoinHD | +| 392 | 0x80000188 | CENNZ | CENNZnet | +| 393 | 0x80000189 | HSN | Hyper Speed Network | +| 394 | 0x8000018a | CRO | Crypto Chain | +| 395 | 0x8000018b | UMBRU | Umbru | +| 396 | 0x8000018c | EVER | Everscale | +| 397 | 0x8000018d | NEAR | NEAR Protocol | +| 398 | 0x8000018e | XPC | XPChain | +| 399 | 0x8000018f | ZOC | 01coin | +| 400 | 0x80000190 | NIX | NIX | +| 401 | 0x80000191 | UC | Utopiacoin | +| 402 | 0x80000192 | GALI | Galilel | +| 403 | 0x80000193 | OLT | Oneledger | +| 404 | 0x80000194 | XBI | XBI | +| 405 | 0x80000195 | DONU | DONU | +| 406 | 0x80000196 | EARTHS | Earths | +| 407 | 0x80000197 | HDD | HDDCash | +| 408 | 0x80000198 | SUGAR | Sugarchain | +| 409 | 0x80000199 | AILE | AileCoin | +| 410 | 0x8000019a | TENT | TENT | +| 411 | 0x8000019b | TAN | Tangerine Network | +| 412 | 0x8000019c | AIN | AIN | +| 413 | 0x8000019d | MSR | Masari | +| 414 | 0x8000019e | SUMO | Sumokoin | +| 415 | 0x8000019f | ETN | Electroneum | +| 416 | 0x800001a0 | BYTZ | BYTZ | +| 417 | 0x800001a1 | WOW | Wownero | +| 418 | 0x800001a2 | XTNC | XtendCash | +| 419 | 0x800001a3 | LTHN | Lethean | +| 420 | 0x800001a4 | NODE | NodeHost | +| 421 | 0x800001a5 | AGM | Argoneum | +| 422 | 0x800001a6 | CCX | Conceal Network | +| 423 | 0x800001a7 | TNET | Title Network | +| 424 | 0x800001a8 | TELOS | TelosCoin | +| 425 | 0x800001a9 | AION | Aion | +| 426 | 0x800001aa | BC | Bitcoin Confidential | +| 427 | 0x800001ab | KTV | KmushiCoin | +| 428 | 0x800001ac | ZCR | ZCore | +| 429 | 0x800001ad | ERG | Ergo | +| 430 | 0x800001ae | PESO | Criptopeso | +| 431 | 0x800001af | BTC2 | Bitcoin 2 | +| 432 | 0x800001b0 | XRPHD | XRPHD | +| 433 | 0x800001b1 | WE | WE Coin | +| 434 | 0x800001b2 | KSM | Kusama | +| 435 | 0x800001b3 | PCN | Peepcoin | +| 436 | 0x800001b4 | NCH | NetCloth | +| 437 | 0x800001b5 | ICU | CHIPO | +| 438 | 0x800001b6 | FNSA | FINSCHIA | +| 439 | 0x800001b7 | DTP | DeVault Token Protocol | +| 440 | 0x800001b8 | BTCR | Bitcoin Royale | +| 441 | 0x800001b9 | AERGO | AERGO | +| 442 | 0x800001ba | XTH | Dothereum | +| 443 | 0x800001bb | LV | Lava | +| 444 | 0x800001bc | PHR | Phore | +| 445 | 0x800001bd | VITAE | Vitae | +| 446 | 0x800001be | COCOS | Cocos-BCX | +| 447 | 0x800001bf | DIN | Dinero | +| 448 | 0x800001c0 | SPL | Simplicity | +| 449 | 0x800001c1 | YCE | MYCE | +| 450 | 0x800001c2 | XLR | Solaris | +| 451 | 0x800001c3 | KTS | Klimatas | +| 452 | 0x800001c4 | DGLD | DGLD | +| 453 | 0x800001c5 | XNS | Insolar | +| 454 | 0x800001c6 | EM | EMPOW | +| 455 | 0x800001c7 | SHN | ShineBlocks | +| 456 | 0x800001c8 | SEELE | Seele | +| 457 | 0x800001c9 | AE | æternity | +| 458 | 0x800001ca | ODX | ObsidianX | +| 459 | 0x800001cb | KAVA | Kava | +| 460 | 0x800001cc | GLEEC | GLEEC | +| 461 | 0x800001cd | FIL | Filecoin | +| 462 | 0x800001ce | RUTA | Rutanio | +| 463 | 0x800001cf | CSDT | CSDT | +| 464 | 0x800001d0 | ETI | EtherInc | +| 465 | 0x800001d1 | ZSLP | Zclassic Simple Ledger Protocol | +| 466 | 0x800001d2 | ERE | EtherCore | +| 467 | 0x800001d3 | DX | DxChain Token | +| 468 | 0x800001d4 | CPS | Capricoin+ | +| 469 | 0x800001d5 | BTH | Bithereum | +| 470 | 0x800001d6 | MESG | MESG | +| 471 | 0x800001d7 | FIMK | FIMK | +| 472 | 0x800001d8 | AR | Arweave | +| 473 | 0x800001d9 | OGO | Origo | +| 474 | 0x800001da | ROSE | Oasis Network | +| 475 | 0x800001db | BARE | BARE Network | +| 476 | 0x800001dc | GLEEC | GleecBTC | +| 477 | 0x800001dd | CLR | Color Coin | +| 478 | 0x800001de | RNG | Ring | +| 479 | 0x800001df | OLO | Tool Global | +| 480 | 0x800001e0 | PEXA | Pexa | +| 481 | 0x800001e1 | MOON | Mooncoin | +| 482 | 0x800001e2 | OCEAN | Ocean Protocol | +| 483 | 0x800001e3 | BNT | Bluzelle Native | +| 484 | 0x800001e4 | AMO | AMO Blockchain | +| 485 | 0x800001e5 | FCH | FreeCash | +| 486 | 0x800001e6 | LAT | PlatON | +| 487 | 0x800001e7 | COIN | Bitcoin Bank | +| 488 | 0x800001e8 | VEO | Amoveo | +| 489 | 0x800001e9 | CCA | Counos Coin | +| 490 | 0x800001ea | GFN | Graphene | +| 491 | 0x800001eb | BIP | Minter Network | +| 492 | 0x800001ec | KPG | Kunpeng Network | +| 493 | 0x800001ed | FIN | FINL Chain | +| 494 | 0x800001ee | BAND | Band | +| 495 | 0x800001ef | DROP | Dropil | +| 496 | 0x800001f0 | BHT | Bluehelix Chain | +| 497 | 0x800001f1 | LYRA | Scrypta | +| 498 | 0x800001f2 | CS | Credits | +| 499 | 0x800001f3 | RUPX | Rupaya | +| 500 | 0x800001f4 | THETA | Theta | +| 501 | 0x800001f5 | SOL | Solana | +| 502 | 0x800001f6 | THT | ThoughtAI | +| 503 | 0x800001f7 | CFX | Conflux | +| 504 | 0x800001f8 | KUMA | Kumacoin | +| 505 | 0x800001f9 | HASH | Provenance | +| 506 | 0x800001fa | CSPR | Casper | +| 507 | 0x800001fb | EARTH | EARTH | +| 508 | 0x800001fc | EGLD | MultiversX | +| 509 | 0x800001fd | CHI | Xaya | +| 510 | 0x800001fe | KOTO | Koto | +| 511 | 0x800001ff | OTC | θ | +| 512 | 0x80000200 | RXD | Radiant | +| 513 | 0x80000201 | SEELEN | Seele-N | +| 514 | 0x80000202 | AETH | AETH | +| 515 | 0x80000203 | DNA | Idena | +| 516 | 0x80000204 | VEE | Virtual Economy Era | +| 517 | 0x80000205 | SIERRA | SierraCoin | +| 518 | 0x80000206 | LET | Linkeye | +| 519 | 0x80000207 | BSC | Bitcoin Smart Contract | +| 520 | 0x80000208 | BTCV | BitcoinVIP | +| 521 | 0x80000209 | ABA | Dabacus | +| 522 | 0x8000020a | SCC | StakeCubeCoin | +| 523 | 0x8000020b | EDG | Edgeware | +| 524 | 0x8000020c | AMS | AmsterdamCoin | +| 525 | 0x8000020d | GOSS | GOSSIP Coin | +| 526 | 0x8000020e | BU | BUMO | +| 527 | 0x8000020f | GRAM | GRAM | +| 528 | 0x80000210 | YAP | Yapstone | +| 529 | 0x80000211 | SCRT | Secret Network | +| 530 | 0x80000212 | NOVO | Novo | +| 531 | 0x80000213 | GHOST | Ghost | +| 532 | 0x80000214 | HST | HST | +| 533 | 0x80000215 | PRJ | ProjectCoin | +| 534 | 0x80000216 | YOU | YOUChain | +| 535 | 0x80000217 | XHV | Haven Protocol | +| 536 | 0x80000218 | BYND | Beyondcoin | +| 537 | 0x80000219 | JOYS | Joys Digital | +| 538 | 0x8000021a | VAL | Valorbit | +| 539 | 0x8000021b | FLOW | Flow | +| 540 | 0x8000021c | SMESH | Spacemesh Coin | +| 541 | 0x8000021d | SCDO | SCDO | +| 542 | 0x8000021e | IQS | IQ-Cash | +| 543 | 0x8000021f | BIND | Compendia | +| 544 | 0x80000220 | COINEVO | Coinevo | +| 545 | 0x80000221 | SCRIBE | Scribe | +| 546 | 0x80000222 | HYN | Hyperion | +| 547 | 0x80000223 | BHP | BHP | +| 548 | 0x80000224 | BBC | BigBang Core | +| 549 | 0x80000225 | MKF | MarketFinance | +| 550 | 0x80000226 | XDC | XinFin | +| 551 | 0x80000227 | STR | Straightedge | +| 552 | 0x80000228 | SUM | Sumcoin | +| 553 | 0x80000229 | HBC | HuobiChain | +| 554 | 0x8000022a | --- | reserved | +| 555 | 0x8000022b | BCS | Bitcoin Smart | +| 556 | 0x8000022c | KTS | Kratos | +| 557 | 0x8000022d | LKR | Lkrcoin | +| 558 | 0x8000022e | TAO | Tao | +| 559 | 0x8000022f | XWC | Whitecoin | +| 560 | 0x80000230 | DEAL | DEAL | +| 561 | 0x80000231 | NTY | Nexty | +| 562 | 0x80000232 | TOP | TOP NetWork | +| 563 | 0x80000233 | --- | reserved | +| 564 | 0x80000234 | AG | Agoric | +| 565 | 0x80000235 | CICO | Coinicles | +| 566 | 0x80000236 | IRIS | Irisnet | +| 567 | 0x80000237 | NCG | Nine Chronicles | +| 568 | 0x80000238 | LRG | Large Coin | +| 569 | 0x80000239 | SERO | Super Zero Protocol | +| 570 | 0x8000023a | BDX | Beldex | +| 571 | 0x8000023b | CCXX | Counos X | +| 572 | 0x8000023c | SLS | Saluscoin | +| 573 | 0x8000023d | SRM | Serum | +| 574 | 0x8000023e | --- | reserved | +| 575 | 0x8000023f | VIVT | VIDT Datalink | +| 576 | 0x80000240 | BPS | BitcoinPoS | +| 577 | 0x80000241 | NKN | NKN | +| 578 | 0x80000242 | ICL | ILCOIN | +| 579 | 0x80000243 | BONO | Bonorum | +| 580 | 0x80000244 | PLC | PLATINCOIN | +| 581 | 0x80000245 | DUN | Dune | +| 582 | 0x80000246 | DMCH | Darmacash | +| 583 | 0x80000247 | CTC | Creditcoin | +| 584 | 0x80000248 | KELP | Haidai Network | +| 585 | 0x80000249 | GBCR | GoldBCR | +| 586 | 0x8000024a | XDAG | XDAG | +| 587 | 0x8000024b | PRV | Incognito Privacy | +| 588 | 0x8000024c | SCAP | SafeCapital | +| 589 | 0x8000024d | TFUEL | Theta Fuel | +| 590 | 0x8000024e | GTM | Gentarium | +| 591 | 0x8000024f | RNL | RentalChain | +| 592 | 0x80000250 | GRIN | Grin | +| 593 | 0x80000251 | MWC | MimbleWimbleCoin | +| 594 | 0x80000252 | DOCK | Dock | +| 595 | 0x80000253 | POLYX | Polymesh | +| 596 | 0x80000254 | DIVER | Divergenti | +| 597 | 0x80000255 | XEP | Electra Protocol | +| 598 | 0x80000256 | APN | Apron | +| 599 | 0x80000257 | TFC | Turbo File Coin | +| 600 | 0x80000258 | UTE | Unit-e | +| 601 | 0x80000259 | MTC | Metacoin | +| 602 | 0x8000025a | NC | NobodyCash | +| 603 | 0x8000025b | XINY | Xinyuehu | +| 604 | 0x8000025c | DYN | Dynamo | +| 605 | 0x8000025d | BUFS | Buffer | +| 606 | 0x8000025e | STOS | Stratos | +| 607 | 0x8000025f | TON | TON | +| 608 | 0x80000260 | TAFT | TAFT | +| 609 | 0x80000261 | HYDRA | HYDRA | +| 610 | 0x80000262 | NOR | Noir | +| 611 | 0x80000263 | | Manta Network Private Asset | +| 612 | 0x80000264 | | Calamari Network Private Asset | +| 613 | 0x80000265 | WCN | Widecoin | +| 614 | 0x80000266 | OPT | Optimistic Ethereum | +| 615 | 0x80000267 | PSWAP | PolkaSwap | +| 616 | 0x80000268 | VAL | Validator | +| 617 | 0x80000269 | XOR | Sora | +| 618 | 0x8000026a | SSP | SmartShare | +| 619 | 0x8000026b | DEI | DeimosX | +| 620 | 0x8000026c | --- | reserved | +| 621 | 0x8000026d | ZERO | Singularity | +| 622 | 0x8000026e | ALPHA | AlphaDAO | +| 623 | 0x8000026f | BDECO | BDCashProtocol Ecosystem | +| 624 | 0x80000270 | NOBL | Nobility | +| 625 | 0x80000271 | EAST | Eastcoin | +| 626 | 0x80000272 | KDA | Kadena | +| 627 | 0x80000273 | SOUL | Phantasma | +| 628 | 0x80000274 | LORE | Gitopia | +| 629 | 0x80000275 | FNR | Fincor | +| 630 | 0x80000276 | NEXUS | Nexus | +| 631 | 0x80000277 | QTZ | Quartz | +| 632 | 0x80000278 | MAS | Massa | +| 633 | 0x80000279 | CALL | Callchain | +| 634 | 0x8000027a | VAL | Validity | +| 635 | 0x8000027b | POKT | Pocket Network | +| 636 | 0x8000027c | EMIT | EMIT | +| 637 | 0x8000027d | APTOS | Aptos | +| 638 | 0x8000027e | ADON | ADON | +| 639 | 0x8000027f | BTSG | BitSong | +| 640 | 0x80000280 | LFC | Leofcoin | +| 641 | 0x80000281 | KCS | KuCoin Shares | +| 642 | 0x80000282 | KCC | KuCoin Community Chain | +| 643 | 0x80000283 | AZERO | Aleph Zero | +| 644 | 0x80000284 | TREE | Tree | +| 645 | 0x80000285 | LX | Lynx | +| 646 | 0x80000286 | XLN | Lunarium | +| 647 | 0x80000287 | CIC | CIC Chain | +| 648 | 0x80000288 | ZRB | Zarb | +| 649 | 0x80000289 | --- | reserved | +| 650 | 0x8000028a | UCO | Archethic | +| 651 | 0x8000028b | SFX | Safex Cash | +| 652 | 0x8000028c | SFT | Safex Token | +| 653 | 0x8000028d | WSFX | Wrapped Safex Cash | +| 654 | 0x8000028e | USDG | US Digital Gold | +| 655 | 0x8000028f | WMP | WAMP | +| 656 | 0x80000290 | EKTA | Ekta | +| 657 | 0x80000291 | YDA | YadaCoin | +| 658 | 0x80000292 | WHIVE | Whive | +| 659 | 0x80000293 | KOIN | Koinos | +| 660 | 0x80000294 | PIRATE | PirateCash | +| 661 | 0x80000295 | UNQ | Unique | +| 662 | 0x80000296 | ULM | UltonSmartchain | +| 663 | 0x80000297 | SFRX | EtherGem Sapphire | +| 664 | 0x80000298 | BSTY | GlobalBoost-Y | +| 665 | 0x80000299 | IMP | Impact Protocol | +| 666 | 0x8000029a | ACT | Achain | +| 667 | 0x8000029b | PRKL | Perkle | +| 668 | 0x8000029c | SSC | SelfSell | +| 669 | 0x8000029d | GC | GateChain | +| 670 | 0x8000029e | PLGR | Pledger | +| 671 | 0x8000029f | MPLGR | Pledger | +| 672 | 0x800002a0 | KNOX | Knox | +| 673 | 0x800002a1 | ZED | ZED | +| 674 | 0x800002a2 | CNDL | Candle | +| 675 | 0x800002a3 | WLKR | Walker Crypto Innovation Index | +| 676 | 0x800002a4 | WLKRR | Walker | +| 677 | 0x800002a5 | YUNGE | Yunge | +| 678 | 0x800002a6 | Voken | Voken | +| 679 | 0x800002a7 | APL | Apollo | +| 680 | 0x800002a8 | Evrynet | Evrynet | +| 681 | 0x800002a9 | NENG | Nengcoin | +| 682 | 0x800002aa | CHTA | Cheetahcoin | +| 683 | 0x800002ab | ALEO | Aleo Network | +| 684 | 0x800002ac | HMS | Hemis | +| 685 | 0x800002ad | OAS | Oasys | +| 686 | 0x800002ae | KAR | Karura Network | +| 687 | 0x800002af | FLON | FullOn Network | +| 688 | 0x800002b0 | CET | CoinEx Chain | +| 689 | 0x800002b1 | XLINK | XLink Chain | +| 690 | 0x800002b2 | KLV | KleverChain | +| 691 | 0x800002b3 | TNT | Tangle | +| 692 | 0x800002b4 | GTG | Gotigin | +| 693 | 0x800002b5 | NET | RealityNet | +| 694 | 0x800002b6 | VTBC | VTB Community | +| 695 | 0x800002b7 | DIONE | Odyssey Chain | +| 696 | 0x800002b8 | LUM | Lumos | +| 697 | 0x800002b9 | AVA | Avalon | +| 698 | 0x800002ba | VEIL | Veil | +| 699 | 0x800002bb | GTB | GotaBit | +| 700 | 0x800002bc | XDAI | xDai | +| 701 | 0x800002bd | COM | Commercio | +| 702 | 0x800002be | CCC | Commercio Cash Credit | +| 703 | 0x800002bf | SNR | Sonr | +| 704 | 0x800002c0 | RAQ | Ra Quantum | +| 705 | 0x800002c1 | PEG | Pegasus Token | +| 706 | 0x800002c2 | LKG | Lionking | +| 707 | 0x800002c3 | MCOIN | Moneta Coin | +| 708 | 0x800002c4 | --- | reserved | +| 709 | 0x800002c5 | AVAIL | Avail | +| 710 | 0x800002c6 | FURY | Highbury | +| 711 | 0x800002c7 | CHC | Chaincoin | +| 712 | 0x800002c8 | SERF | Serfnet | +| 713 | 0x800002c9 | XTL | Katal Chain | +| 714 | 0x800002ca | BNB | Binance | +| 715 | 0x800002cb | SIN | Sinovate | +| 716 | 0x800002cc | DLN | Delion | +| 717 | 0x800002cd | BONTE | Bontecoin | +| 718 | 0x800002ce | PEER | Peer | +| 719 | 0x800002cf | ZET | Zetacoin | +| 720 | 0x800002d0 | ABY | Artbyte | +| 721 | 0x800002d1 | PGX | Mirai Chain | +| 722 | 0x800002d2 | IL8P | InfiniLooP | +| 723 | 0x800002d3 | VOI | Voi | +| 724 | 0x800002d4 | XVC | Vanillacash | +| 725 | 0x800002d5 | MCX | MultiCash | +| 726 | 0x800002d6 | TARA | Taraxa | +| 727 | 0x800002d7 | BLU | BluCrates | +| 728 | 0x800002d8 | BFC | BFC | +| 729 | 0x800002d9 | DCC | DecentraCast | +| 730 | 0x800002da | HEALIOS | Tenacity | +| 731 | 0x800002db | BMK | Bitmark | +| 732 | 0x800002dc | FUGA | Fuga token | +| 733 | 0x800002dd | TBC | TBChat | +| 734 | 0x800002de | DENTX | DENTNet | +| 735 | 0x800002df | NBY | Neobytes | +| 736 | 0x800002e0 | BABY | BABY | +| 737 | 0x800002e1 | ATOP | Financial Blockchain | +| 738 | 0x800002e2 | BTE | Bitweb | +| 739 | 0x800002e3 | DPC | Dpowcoin (DualPowCoin) | +| 740 | 0x800002e4 | MDC | MyDataCoin | +| 741 | 0x800002e5 | RIV | Rigvid | +| 742 | 0x800002e6 | LTO | LTO Network | +| 743 | 0x800002e7 | LKY | LuckyCoin | +| 744 | 0x800002e8 | DUSK | Dusk | +| 745 | 0x800002e9 | DIMI | DiminutiveCoin | +| 746 | 0x800002ea | PLM | Palladium | +| 747 | 0x800002eb | CFG | Centrifuge | +| 748 | 0x800002ec | | +| 749 | 0x800002ed | | +| 750 | 0x800002ee | XPRT | Persistence | +| 751 | 0x800002ef | | +| 752 | 0x800002f0 | | +| 753 | 0x800002f1 | | Age X25519 Encryption | +| 754 | 0x800002f2 | | Age NIST Encryption | +| 755 | 0x800002f3 | | +| 756 | 0x800002f4 | | +| 757 | 0x800002f5 | HONEY | HoneyWood | +| 758 | 0x800002f6 | XDD | XDDCoin | +| 759 | 0x800002f7 | TBI | TBicloud | +| 760 | 0x800002f8 | | +| 761 | 0x800002f9 | | +| 762 | 0x800002fa | BELLS | Bellscoin | +| 763 | 0x800002fb | | +| 764 | 0x800002fc | | +| 765 | 0x800002fd | TGN | Tagion | +| 766 | 0x800002fe | | +| 767 | 0x800002ff | LLD | Liberland | +| 768 | 0x80000300 | BALLZ | Ballzcoin | +| 769 | 0x80000301 | | +| 770 | 0x80000302 | COSA | Cosanta | +| 771 | 0x80000303 | BR | BR | +| 772 | 0x80000304 | | +| 773 | 0x80000305 | CSB | CosmoBliss | +| 774 | 0x80000306 | | +| 775 | 0x80000307 | PLSR | Pulsar Coin | +| 776 | 0x80000308 | KEY | Keymaker Coin | +| 777 | 0x80000309 | BTW | Bitcoin World | +| 778 | 0x8000030a | | +| 779 | 0x8000030b | UCHAIN | UCHAIN | +| 780 | 0x8000030c | PLCUC | PLC Ultima Classic | +| 781 | 0x8000030d | PLCUX | PLC Ultima X | +| 782 | 0x8000030e | PLCU | PLC Ultima | +| 783 | 0x8000030f | SMARTBC | SMART Blockchain | +| 784 | 0x80000310 | SUI | Sui | +| 785 | 0x80000311 | ULTIMA | ULTIMA | +| 786 | 0x80000312 | UIDD | UIDD | +| 787 | 0x80000313 | ACA | Acala | +| 788 | 0x80000314 | BNC | Bifrost | +| 789 | 0x80000315 | TAU | Lamden | +| 790 | 0x80000316 | LKY | Luckycoin | +| 791 | 0x80000317 | SOMA | Soma | +| 792 | 0x80000318 | | +| 793 | 0x80000319 | | +| 794 | 0x8000031a | INTR | Interlay | +| 795 | 0x8000031b | KINT | Kintsugi | +| 796 | 0x8000031c | | +| 797 | 0x8000031d | | +| 798 | 0x8000031e | | +| 799 | 0x8000031f | PDEX | Polkadex | +| 800 | 0x80000320 | BEET | Beetle Coin | +| 801 | 0x80000321 | DST | DSTRA | +| 802 | 0x80000322 | CY | Cyberyen | +| 803 | 0x80000323 | RYME | Ryme Network | +| 804 | 0x80000324 | ZKS | zkSync | +| 805 | 0x80000325 | SCASH | Scash | +| 806 | 0x80000326 | | +| 807 | 0x80000327 | | +| 808 | 0x80000328 | QVT | Qvolta | +| 809 | 0x80000329 | SDN | Shiden Network | +| 810 | 0x8000032a | ASTR | Astar Network | +| 811 | 0x8000032b | --- | reserved | +| 812 | 0x8000032c | | +| 813 | 0x8000032d | MEER | Qitmeer | +| 814 | 0x8000032e | | +| 815 | 0x8000032f | FACT | ImFACT | +| 816 | 0x80000330 | FSC | FSC | +| 817 | 0x80000331 | | +| 818 | 0x80000332 | VET | VeChain Token | +| 819 | 0x80000333 | REEF | Reef | +| 820 | 0x80000334 | CLO | Callisto | +| 821 | 0x80000335 | | +| 822 | 0x80000336 | BDB | BigchainDB | +| 823 | 0x80000337 | TBL | TBLINK | +| 824 | 0x80000338 | RBNT | Redbelly Network | +| 825 | 0x80000339 | | +| 826 | 0x8000033a | YBC | YBChain | +| 827 | 0x8000033b | ACE | Endurance | +| 828 | 0x8000033c | CCN | ComputeCoin | +| 829 | 0x8000033d | BBA | BBACHAIN | +| 830 | 0x8000033e | | +| 831 | 0x8000033f | CRUZ | cruzbit | +| 832 | 0x80000340 | SAPP | Sapphire | +| 833 | 0x80000341 | 777 | Jackpot | +| 834 | 0x80000342 | KYAN | Kyanite | +| 835 | 0x80000343 | AZR | Azzure | +| 836 | 0x80000344 | CFL | CryptoFlow | +| 837 | 0x80000345 | DASHD | Dash Diamond | +| 838 | 0x80000346 | TRTT | Trittium | +| 839 | 0x80000347 | UCR | Ultra Clear | +| 840 | 0x80000348 | PNY | Peony | +| 841 | 0x80000349 | BECN | Beacon | +| 842 | 0x8000034a | MONK | Monk | +| 843 | 0x8000034b | SAGA | CryptoSaga | +| 844 | 0x8000034c | SUV | Suvereno | +| 845 | 0x8000034d | ESK | EskaCoin | +| 846 | 0x8000034e | OWO | OneWorld Coin | +| 847 | 0x8000034f | PEPS | PEPS Coin | +| 848 | 0x80000350 | BIR | Birake | +| 849 | 0x80000351 | MOBIC | MobilityCoin | +| 850 | 0x80000352 | FLS | Flits | +| 851 | 0x80000353 | FRECO | Freco | +| 852 | 0x80000354 | DSM | Desmos | +| 853 | 0x80000355 | PRCY | PRCY Coin | +| 854 | 0x80000356 | | +| 855 | 0x80000357 | | +| 856 | 0x80000358 | | +| 857 | 0x80000359 | | +| 858 | 0x8000035a | HVH | HAVAH | +| 859 | 0x8000035b | | +| 860 | 0x8000035c | XBIT | XBIT Coin | +| 861 | 0x8000035d | | +| 862 | 0x8000035e | | +| 863 | 0x8000035f | | +| 864 | 0x80000360 | CVM | Convex | +| 865 | 0x80000361 | | +| 866 | 0x80000362 | MOB | MobileCoin | +| 867 | 0x80000363 | | +| 868 | 0x80000364 | IF | Infinitefuture | +| 869 | 0x80000365 | | +| 870 | 0x80000366 | | +| 871 | 0x80000367 | | +| 872 | 0x80000368 | | +| 873 | 0x80000369 | QUORUM | Quorum | +| 874 | 0x8000036a | | +| 875 | 0x8000036b | | +| 876 | 0x8000036c | | +| 877 | 0x8000036d | NAM | Namada | +| 878 | 0x8000036e | SCR | Scorum Network | +| 879 | 0x8000036f | | +| 880 | 0x80000370 | LUM | Lum Network | +| 881 | 0x80000371 | AEGS | Aegisum +| 882 | 0x80000372 | | +| 883 | 0x80000373 | ZBC | ZooBC | +| 884 | 0x80000374 | | +| 885 | 0x80000375 | | +| 886 | 0x80000376 | ADF | AD Token | +| 887 | 0x80000377 | | +| 888 | 0x80000378 | NEO | NEO | +| 889 | 0x80000379 | TOMO | TOMO | +| 890 | 0x8000037a | XSEL | Seln | +| 891 | 0x8000037b | | +| 892 | 0x8000037c | | +| 893 | 0x8000037d | | +| 894 | 0x8000037e | | +| 895 | 0x8000037f | | +| 896 | 0x80000380 | LKSC | LKSCoin | +| 897 | 0x80000381 | | +| 898 | 0x80000382 | AS | Assetchain | +| 899 | 0x80000383 | XEC | eCash | +| 900 | 0x80000384 | LMO | Lumeneo | +| 901 | 0x80000385 | NXT | NxtMeta | +| 902 | 0x80000386 | | +| 903 | 0x80000387 | | +| 904 | 0x80000388 | HNT | Helium | +| 905 | 0x80000389 | | +| 906 | 0x8000038a | XPX | Sirius | +| 907 | 0x8000038b | FIS | StaFi | +| 908 | 0x8000038c | | +| 909 | 0x8000038d | SGE | Saage | +| 910 | 0x8000038e | | +| 911 | 0x8000038f | GERT | Gert | +| 912 | 0x80000390 | | +| 913 | 0x80000391 | VARA | Vara Network | +| 914 | 0x80000392 | | +| 915 | 0x80000393 | | +| 916 | 0x80000394 | META | Metadium | +| 917 | 0x80000395 | FRA | Findora | +| 918 | 0x80000396 | | +| 919 | 0x80000397 | CCD | Concordium | +| 920 | 0x80000398 | | +| 921 | 0x80000399 | AVN | Avian Network | +| 922 | 0x8000039a | | +| 923 | 0x8000039b | | +| 924 | 0x8000039c | | +| 925 | 0x8000039d | DIP | Dipper Network | +| 926 | 0x8000039e | | +| 927 | 0x8000039f | | +| 928 | 0x800003a0 | GHM | HermitMatrixNetwork | +| 929 | 0x800003a1 | | +| 930 | 0x800003a2 | | +| 931 | 0x800003a3 | RUNE | THORChain (RUNE) | +| 932 | 0x800003a4 | | +| 933 | 0x800003a5 | | +| 934 | 0x800003a6 | | +| 935 | 0x800003a7 | | +| 936 | 0x800003a8 | | +| 937 | 0x800003a9 | | +| 938 | 0x800003aa | MGO | Mango Network | +| 939 | 0x800003ab | AB | Argot Protocol | +| 940 | 0x800003ac | | +| 941 | 0x800003ad | --- | reserved | +| 942 | 0x800003ae | KCN | Kylacoin | +| 943 | 0x800003af | LCN | Lyncoin | +| 944 | 0x800003b0 | | +| 945 | 0x800003b1 | UNLOCK | Jasiri protocol | +| 946 | 0x800003b2 | | +| 947 | 0x800003b3 | | +| 948 | 0x800003b4 | | +| 949 | 0x800003b5 | | +| 950 | 0x800003b6 | CNDT | Conduct Protocol | +| 951 | 0x800003b7 | | +| 952 | 0x800003b8 | | +| 953 | 0x800003b9 | | +| 954 | 0x800003ba | | +| 955 | 0x800003bb | LTP | LifetionCoin | +| 956 | 0x800003bc | | +| 957 | 0x800003bd | | +| 958 | 0x800003be | | KickSoccer | +| 959 | 0x800003bf | | +| 960 | 0x800003c0 | VKAX | Vkax | +| 961 | 0x800003c1 | | +| 962 | 0x800003c2 | | +| 963 | 0x800003c3 | | +| 964 | 0x800003c4 | | +| 965 | 0x800003c5 | ATLA | Atleta Network | +| 966 | 0x800003c6 | MATIC | Matic | +| 967 | 0x800003c7 | | +| 968 | 0x800003c8 | UNW | UNW | +| 969 | 0x800003c9 | QI | Quai Network | +| 970 | 0x800003ca | TWINS | TWINS | +| 971 | 0x800003cb | | +| 972 | 0x800003cc | | +| 973 | 0x800003cd | | +| 974 | 0x800003ce | | +| 975 | 0x800003cf | | TrustNet | +| 976 | 0x800003d0 | | +| 977 | 0x800003d1 | TLOS | Telos | +| 978 | 0x800003d2 | | +| 979 | 0x800003d3 | | +| 980 | 0x800003d4 | | +| 981 | 0x800003d5 | TAFECO | Taf ECO Chain | +| 982 | 0x800003d6 | | +| 983 | 0x800003d7 | | +| 984 | 0x800003d8 | | +| 985 | 0x800003d9 | AU | Autonomy | +| 986 | 0x800003da | | +| 987 | 0x800003db | VCG | VipCoin | +| 988 | 0x800003dc | XAZAB | Xazab core | +| 989 | 0x800003dd | AIOZ | AIOZ | +| 990 | 0x800003de | CORE | Coreum | +| 991 | 0x800003df | PEC | Phoenix | +| 992 | 0x800003e0 | UNT | Unit | +| 993 | 0x800003e1 | XRB | X Currency | +| 994 | 0x800003e2 | QUAI | Quai Network | +| 995 | 0x800003e3 | CAPS | Ternoa | +| 996 | 0x800003e4 | OKT | OKChain Token | +| 997 | 0x800003e5 | SUM | Solidum | +| 998 | 0x800003e6 | LBTC | Lightning Bitcoin | +| 999 | 0x800003e7 | BCD | Bitcoin Diamond | +| 1000 | 0x800003e8 | BTN | Bitcoin New | +| 1001 | 0x800003e9 | TT | ThunderCore | +| 1002 | 0x800003ea | BKT | BanKitt | +| 1003 | 0x800003eb | NODL | Nodle | +| 1004 | 0x800003ec | PCOIN | PCOIN | +| 1005 | 0x800003ed | TAO | Bittensor | +| 1006 | 0x800003ee | HSK | HashKey Chain | +| 1007 | 0x800003ef | FTM | Fantom | +| 1008 | 0x800003f0 | RPG | RPG | +| 1009 | 0x800003f1 | LAKE | iconLake | +| 1010 | 0x800003f2 | HT | Huobi ECO Chain | +| 1011 | 0x800003f3 | ELV | Eluvio | +| 1012 | 0x800003f4 | JOC | Japan Open Chain | +| 1013 | 0x800003f5 | BIC | Beincrypto | +| 1014 | 0x800003f6 | JOY | Joystream | +| 1015 | 0x800003f7 | ZCX | ZEN Exchange Token | +| 1016 | 0x800003f8 | --- | reserved | +| 1017 | 0x800003f9 | ZTC | Zenchain | +| 1020 | 0x800003fc | EVC | Evrice | +| 1022 | 0x800003fe | XRD | Radix DLT | +| 1023 | 0x800003ff | ONE | HARMONY-ONE (Legacy) | +| 1024 | 0x80000400 | ONT | Ontology | +| 1025 | 0x80000401 | CZZ | Classzz | +| 1026 | 0x80000402 | KEX | Kira Exchange Token | +| 1027 | 0x80000403 | MCM | Mochimo | +| 1028 | 0x80000404 | PLS | Pulse Coin | +| 1032 | 0x80000408 | BTCR | BTCR | +| 1042 | 0x80000412 | MFID | Moonfish ID | +| 1100 | 0x8000044c | CROSS | Cross Chain | +| 1110 | 0x80000456 | ZRA | ZERA | +| 1111 | 0x80000457 | BBC | Big Bitcoin | +| 1116 | 0x8000045c | CORE | Core | +| 1120 | 0x80000460 | RISE | RISE | +| 1122 | 0x80000462 | CMT | CyberMiles Token | +| 1128 | 0x80000468 | ETSC | Ethereum Social | +| 1129 | 0x80000469 | DFI | DeFiChain | +| 1130 | 0x8000046a | DFI | DeFiChain EVM Network | +| 1134 | 0x8000046e | MESH | StateMesh | +| 1137 | 0x80000471 | $DAG | Constellation Labs | +| 1145 | 0x80000479 | CDY | Bitcoin Candy | +| 1155 | 0x80000483 | ENJ | Enjin Coin | +| 1170 | 0x80000492 | HOO | Hoo Smart Chain | +| 1200 | 0x800004b0 | GNK | Gonka | +| 1234 | 0x800004d2 | ALPH | Alephium | +| 1236 | 0x800004d4 | | Masca | +| 1237 | 0x800004d5 | | Nostr | +| 1280 | 0x80000500 | | Kudos Setler | +| 1284 | 0x80000504 | GLMR | Moonbeam | +| 1285 | 0x80000505 | MOVR | Moonriver | +| 1286 | 0x80000506 | DSG | Dessage Social Protocol | +| 1298 | 0x80000512 | WPC | Wpc | +| 1308 | 0x8000051c | WEI | WEI | +| 1312 | 0x80000520 | BITS | Entropy | +| 1337 | 0x80000539 | DFC | Defcoin | +| 1338 | 0x8000053a | IRON | Iron Fish | +| 1348 | 0x80000544 | ISLM | IslamicCoin | +| 1397 | 0x80000575 | HYC | Hycon | +| 1410 | 0x80000582 | TENTSLP | TENT Simple Ledger Protocol | +| 1420 | 0x8000058c | DEV | DogecoinEV | +| 1447 | 0x800005a7 | DNR | Dinero | +| 1510 | 0x800005e6 | XSC | XT Smart Chain | +| 1512 | 0x800005e8 | AAC | Double-A Chain | +| 1524 | 0x800005f4 | | Taler | +| 1533 | 0x800005fd | BEAM | Beam | +| 1536 | 0x80000600 | GAS | BubiChain | +| 1540 | 0x80000604 | ATHENA | Athena | +| 1551 | 0x8000060f | SDK | Sovereign SDK | +| 1555 | 0x80000613 | APC | Apc Chain | +| 1616 | 0x80000650 | ELF | AELF | +| 1618 | 0x80000652 | AUDL | AUDL | +| 1620 | 0x80000654 | ATH | Atheios | +| 1627 | 0x8000065b | LUME | Lume Web | +| 1642 | 0x8000066a | NEW | Newton | +| 1657 | 0x80000679 | BTA | Btachain | +| 1668 | 0x80000684 | NEOX | Neoxa | +| 1669 | 0x80000685 | MEWC | Meowcoin | +| 1688 | 0x80000698 | BCX | BitcoinX | +| 1707 | 0x800006ab | TRMP | TrumPOW | +| 1729 | 0x800006c1 | XTZ | Tezos | +| 1776 | 0x800006f0 | LBTC | Liquid BTC | +| 1777 | 0x800006f1 | BBP | Biblepay | +| 1784 | 0x800006f8 | JPYS | JPY Stablecoin | +| 1788 | 0x800006fc | USVAC | USVACoin | +| 1789 | 0x800006fd | VEGA | Vega Protocol | +| 1815 | 0x80000717 | ADA | Cardano | +| 1818 | 0x8000071a | CUBE | Cube Chain Native Token | +| 1888 | 0x80000760 | ZTX | Zetrix | +| 1899 | 0x8000076b | XEC | eCash token | +| 1900 | 0x8000076c | XNA | Neurai | +| 1901 | 0x8000076d | CLC | Classica | +| 1907 | 0x80000773 | BITCI | Bitcicoin | +| 1918 | 0x8000077e | BKC | Briskcoin | +| 1919 | 0x8000077f | VIPS | VIPSTARCOIN | +| 1926 | 0x80000786 | CITY | City Coin | +| 1951 | 0x8000079f | ESA | Esa | +| 1952 | 0x800007a0 | ESC | EsaCoin | +| 1955 | 0x800007a3 | XX | xx coin | +| 1969 | 0x800007b1 | MVRK | Mavryk Network | +| 1977 | 0x800007b9 | XMX | Xuma | +| 1984 | 0x800007c0 | TRTL | TurtleCoin | +| 1985 | 0x800007c1 | SLRT | Solarti Chain | +| 1986 | 0x800007c2 | QTH | Qing Tong Horizon | +| 1987 | 0x800007c3 | EGEM | EtherGem | +| 1988 | 0x800007c4 | MIRA | Mira Chain | +| 1989 | 0x800007c5 | HODL | HOdlcoin | +| 1990 | 0x800007c6 | PHL | Placeholders | +| 1991 | 0x800007c7 | SC | Sia | +| 1995 | 0x800007cb | MYDOGE | Mydogecoin | +| 1996 | 0x800007cc | MYT | Mineyourtime | +| 1997 | 0x800007cd | POLIS | Polis | +| 1998 | 0x800007ce | XMCC | Monoeci | +| 1999 | 0x800007cf | COLX | ColossusXT | +| 2000 | 0x800007d0 | GIN | GinCoin | +| 2001 | 0x800007d1 | MNP | MNPCoin | +| 2002 | 0x800007d2 | MLN | Miraland | +| 2003 | 0x800007d3 | ISNA | iSarrana | +| 2010 | 0x800007da | XBT | Bitcoin Classic | +| 2013 | 0x800007dd | JKC | Junkcoin | +| 2015 | 0x800007df | TEER | Integritee | +| 2017 | 0x800007e1 | KIN | Kin | +| 2018 | 0x800007e2 | EOSC | EOSClassic | +| 2019 | 0x800007e3 | GBT | GoldBean Token | +| 2020 | 0x800007e4 | PKC | PKC | +| 2021 | 0x800007e5 | SKT | Sukhavati | +| 2022 | 0x800007e6 | XHT | Xinghuo Token | +| 2023 | 0x800007e7 | COC | Chat On Chain | +| 2024 | 0x800007e8 | USBC | Universal Ledger USBC | +| 2025 | 0x800007e9 | ROCK | Zenrock Labs | +| 2026 | 0x800007ea | ASTRON | ASTRON Token | +| 2046 | 0x800007fe | ANY | Any | +| 2048 | 0x80000800 | MCASH | MCashChain | +| 2049 | 0x80000801 | TRUE | TrueChain | +| 2050 | 0x80000802 | MOVO | Movo Smart Chain | +| 2086 | 0x80000826 | KILT | KILT Spiritnet | +| 2091 | 0x8000082b | FRQCY | Frequency | +| 2109 | 0x8000083d | SAMA | Exosama Network | +| 2112 | 0x80000840 | IoTE | IoTE | +| 2121 | 0x80000849 | CBTC | Coordinate BTC (Anduro) | +| 2122 | 0x8000084a | QBTC | Quasar BTC (Anduro) | +| 2125 | 0x8000084d | BAY | BitBay | +| 2137 | 0x80000859 | XRG | Ergon | +| 2199 | 0x80000897 | SAMA | Moonsama Network | +| 2221 | 0x800008ad | ASK | ASK | +| 2222 | 0x800008ae | CWEB | Coinweb | +| 2285 | 0x800008ed | | Qiyi Chain | +| 2301 | 0x800008fd | QTUM | QTUM | +| 2302 | 0x800008fe | ETP | Metaverse | +| 2303 | 0x800008ff | GXC | GXChain | +| 2304 | 0x80000900 | CRP | CranePay | +| 2305 | 0x80000901 | ELA | Elastos | +| 2338 | 0x80000922 | SNOW | Snowblossom | +| 2365 | 0x8000093d | XIN | Mixin | +| 2500 | 0x800009c4 | NEXI | Nexi | +| 2570 | 0x80000a0a | AOA | Aurora | +| 2686 | 0x80000a7e | AIPG | AIPowerGrid | +| 2718 | 0x80000a9e | NAS | Nebulas | +| 2809 | 0x80000af9 | LAN | Lanify | +| 2894 | 0x80000b4e | REOSC | REOSC Ecosystem | +| 2941 | 0x80000b7d | BND | Blocknode | +| 3000 | 0x80000bb8 | SM | Stealth Message | +| 3003 | 0x80000bbb | LUX | LUX | +| 3030 | 0x80000bd6 | HBAR | Hedera HBAR | +| 3054 | 0x80000bee | HIVE | Hive Blockchain | +| 3077 | 0x80000c05 | COS | Contentos | +| 3131 | 0x80000c3b | EZC | Ezcon Blockchain | +| 3141 | 0x80000c45 | B1T | Bit | +| 3276 | 0x80000ccc | CCC | CodeChain | +| 3344 | 0x80000d10 | PLMC | Polimec | +| 3333 | 0x80000d05 | SXP | Solar | +| 3338 | 0x80000d0a | PEAQ | peaq | +| 3377 | 0x80000d31 | ROI | ROIcoin | +| 3381 | 0x80000d35 | DYN | Dynamic | +| 3383 | 0x80000d37 | SEQ | Sequence | +| 3434 | 0x80000d6a | PEPE | Pepecoin Core | +| 3499 | 0x80000dab | BLAZE | Blaze | +| 3501 | 0x80000dad | JFIN | JFIN Coin | +| 3552 | 0x80000de0 | DEO | Destocoin | +| 3564 | 0x80000dec | DST | DeStream | +| 3601 | 0x80000e11 | CY | Cybits | +| 3630 | 0x80000e2e | EPPIE | Eppie | +| 3757 | 0x80000ead | MPC | Partisia Blockchain | +| 3840 | 0x80000f00 | RED | ReDeFi RED | +| 4040 | 0x80000fc8 | FC8 | FCH Network | +| 4096 | 0x80001000 | YEE | YeeCo | +| 4218 | 0x8000107a | IOTA | IOTA | +| 4219 | 0x8000107b | SMR | Shimmer | +| 4242 | 0x80001092 | AXE | Axe | +| 4343 | 0x800010f7 | XYM | Symbol | +| 4444 | 0x8000115c | C4E | Chain4Energy | +| 4474 | 0x8000117a | SHIC | ShibaCoin | +| 4646 | 0x80001226 | MST | MST | +| 4919 | 0x80001337 | XVM | Venidium | +| 4976 | 0x80001370 | VARA | Vara | +| 4999 | 0x80001387 | BXN | BlackFort Exchange Network | +| 5000 | 0x80001388 | V12 | Vet The Vote | +| 5006 | 0x8000138e | SBC | Senior Blockchain | +| 5248 | 0x80001480 | FIC | FIC | +| 5353 | 0x800014e9 | HNS | Handshake | +| 5404 | 0x8000151c | ISK | ISKRA | +| 5467 | 0x8000155b | ALTME | ALTME | +| 5555 | 0x800015b3 | FUND | Unification | +| 5757 | 0x8000167d | STX | Stacks | +| 5895 | 0x80001707 | VOW | VowChain VOW | +| 5920 | 0x80001720 | SLU | SILUBIUM | +| 5995 | 0x8000176b | DUSK | Dusk Network | +| 6060 | 0x800017ac | GO | GoChain GO | +| 6144 | 0x80001800 | DTS | Datos | +| 6174 | 0x8000181e | MOI | My Own Internet | +| 6278 | 0x80001886 | STEAMX | Rails Network Mainnet | +| 6310 | 0x800018a6 | VRL | Virel Protocol | +| 6532 | 0x80001984 | UM | Penumbra | +| 6599 | 0x800019c7 | RSC | Royal Sports City | +| 6666 | 0x80001a0a | BPA | Bitcoin Pizza | +| 6688 | 0x80001a20 | SAFE | SAFE | +| 6767 | 0x80001a6f | CC | Canton Coin | +| 6779 | 0x80001a7b | COTI | COTI | +| 6969 | 0x80001b39 | ROGER | TheHolyrogerCoin | +| 7000 | 0x80001b58 | ZETA | ZetaChain | +| 7027 | 0x80001b73 | ELLA | Ella the heart | +| 7028 | 0x80001b74 | AA | Arthera | +| 7070 | 0x80001b9e | DOI | Doichain | +| 7091 | 0x80001bb3 | TOPL | Topl | +| 7272 | 0x80001c68 | ABTC | Alys BTC (Anduro) | +| 7331 | 0x80001ca3 | KLY | KLYNTAR | +| 7341 | 0x80001cad | SHFT | Shyft | +| 7518 | 0x80001d5e | MEV | MEVerse | +| 7576 | 0x80001d98 | ADIL | ADIL Chain | +| 7777 | 0x80001e61 | BTV | Bitvote | +| 7779 | 0x80001e63 | CPV | Compverse | +| 8000 | 0x80001f40 | SKY | Skycoin | +| 8008 | 0x80001f48 | BERA | Berachain | +| 8017 | 0x80001f51 | ISC | iSunCoin | +| 8080 | 0x80001f90 | | DSRV | +| 8181 | 0x80001ff5 | BOC | BeOne Chain | +| 8192 | 0x80002000 | PAC | pacprotocol | +| 8217 | 0x80002019 | KAIA | KAIA | +| 8339 | 0x80002093 | BTQ | BitcoinQuark | +| 8444 | 0x800020fc | XCH | Chia | +| 8453 | 0x80002105 | | Base | +| 8520 | 0x80002148 | --- | reserved | +| 8680 | 0x800021e8 | PLMNT | Planetmint | +| 8732 | 0x8000221c | BLN | Bullions | +| 8738 | 0x80002222 | ALPH | Alph Network | +| 8866 | 0x800022a2 | GGX | Golden Gate | +| 8886 | 0x800022b6 | GGXT | Golden Gate Sydney | +| 8888 | 0x800022b8 | SBTC | Super Bitcoin | +| 8964 | 0x80002304 | NULS | NULS | +| 8997 | 0x80002325 | BBC | Babacoin | +| 8998 | 0x80002326 | JGC | JagoanCoin | +| 8999 | 0x80002327 | BTP | Bitcoin Pay | +| 9000 | 0x80002328 | AVAX | Avalanche | +| 9001 | 0x80002329 | ARB1 | Arbitrum | +| 9002 | 0x8000232a | BOBA | Boba | +| 9003 | 0x8000232b | LOOP | Loopring | +| 9004 | 0x8000232c | STRK | StarkNet | +| 9005 | 0x8000232d | AVAXC | Avalanche C-Chain | +| 9006 | 0x8000232e | BSC | Binance Smart Chain | +| 9007 | 0x8000232f | SATOX | Satoxcoin | +| 9797 | 0x80002645 | NRG | Energi | +| 9888 | 0x800026a0 | BTF | Bitcoin Faith | +| 9969 | 0x800026f1 | OSMI | Osmium | +| 9999 | 0x8000270f | GOD | Bitcoin God | +| 10000 | 0x80002710 | FO | FIBOS | +| 10001 | 0x80002711 | SPACE | Space | +| 10007 | 0x80002717 | S | SONIC | +| 10111 | 0x8000277f | DHP | dHealth | +| 10226 | 0x800027f2 | RTM | Raptoreum | +| 10242 | 0x80002802 | AA | Arthera | +| 10291 | 0x80002833 | XRC | XRhodium | +| 10507 | 0x8000290b | NUM | Numbers Protocol | +| 10605 | 0x8000296d | XPI | Lotus | +| 11111 | 0x80002b67 | ESS | Essentia One | +| 11742 | 0x80002dde | VARCH | InvArch | +| 11743 | 0x80002ddf | TNKR | Tinkernet | +| 12345 | 0x80003039 | IPOS | IPOS | +| 12586 | 0x8000312a | MINA | Mina | +| 12850 | 0x80003232 | ANLOG | Analog Timechain | +| 13107 | 0x80003333 | BTY | BitYuan | +| 13108 | 0x80003334 | YCC | Yuan Chain Coin | +| 13381 | 0x80003445 | PHX | Phoenix | +| 14001 | 0x800036b1 | WAX | Worldwide Asset Exchange | +| 15845 | 0x80003de5 | SDGO | SanDeGo | +| 16181 | 0x80003f35 | XTX | Totem Live Network | +| 16754 | 0x80004172 | ARDR | Ardor | +| 18000 | 0x80004650 | MTR | Meter | +| 19165 | 0x80004add | SAFE | Safecoin | +| 19167 | 0x80004adf | FLUX | Flux | +| 19169 | 0x80004ae1 | RITO | Ritocoin | +| 19788 | 0x80004d4c | ML | Mintlayer | +| 20036 | 0x80004e44 | XND | ndau | +| 21004 | 0x8000520c | C4EI | c4ei | +| 21337 | 0x80005359 | XAH | Xahau | +| 21888 | 0x80005580 | PAC | Pactus | +| 22504 | 0x800057e8 | PWR | PWRcoin | +| 23000 | 0x800059d8 | EPIC | Epic Cash | +| 25252 | 0x800062a4 | BELL | Bellcoin | +| 25718 | 0x80006476 | CHX | Own | +| 26417 | 0x80006731 | G1 | Ğ1 | +| 29223 | 0x80007227 | NEXA | Nexa | +| 30001 | 0x80007531 | --- | reserved | +| 31102 | 0x8000797e | ESN | EtherSocial Network | +| 31337 | 0x80007a69 | | ThePower | +| 33416 | 0x80008288 | TEO | Trust Eth reOrigin | +| 33878 | 0x80008456 | BTCS | Bitcoin Stake | +| 34952 | 0x80008888 | BTT | ByteTrade | +| 37992 | 0x80009468 | FXTC | FixedTradeCoin | +| 39321 | 0x80009999 | AMA | Amabig | +| 42069 | 0x8000a455 | FACT | FACT0RN | +| 43028 | 0x8000a814 | AXIV | AXIV | +| 47803 | 0x8000babb | BAX | BAX | +| 49262 | 0x8000c06e | EVE | evan | +| 49344 | 0x8000c0c0 | STASH | STASH | +| 52752 | 0x8000ce10 | CELO | Celo | +| 54176 | 0x8000d3a0 | OVER | OverProtocol | +| 61616 | 0x8000f0b0 | TH | TianHe | +| 65536 | 0x80010000 | KETH | Krypton World | +| 69420 | 0x80010f2c | GRLC | Garlicoin | +| 70007 | 0x80011177 | GWL | Gewel | +| 83293 | 0x8001455d | QUBIC | Qubic | +| 77777 | 0x80012fd1 | ZYN | Wethio | +| 88888 | 0x80015b38 | RYO | c0ban | +| 99999 | 0x8001869f | WICC | Waykichain | +| 100500 | 0x80018894 | HOME | HomeCoin | +| 101010 | 0x80018a92 | STC | Starcoin | +| 104109 | 0x800196ad | | Seed Hypermedia | +| 105105 | 0x80019a91 | STRAX | Strax | +| 111111 | 0x8001b207 | KAS | Kaspa | +| 121337 | 0x8001d9f9 | KLS | Karlsen | +| 123456 | 0x8001e240 | SPR | Spectre | +| 130822 | 0x8001ff06 | WBT | WhiteBIT Coin | +| 161803 | 0x8002780b | APTA | Bloqs4Good | +| 189189 | 0x8002e305 | QUAN | Quantus Network | +| 200625 | 0x80030fb1 | AKA | Akroma | +| 200901 | 0x800310c5 | BTR | Bitlayer | +| 224433 | 0x80036cb1 | CONET | CONET Holesky Network | +| 246529 | 0x8003c301 | ATS | ARTIS sigma1 | +| 261131 | 0x8003fc0b | ZAMA | Zama | +| 314159 | 0x8004cb2f | PI | Pi Network | +| 333332 | 0x80051614 | VALUE | Value Chain | +| 333333 | 0x80051615 | 3333 | Pi Value Consensus | +| 424242 | 0x80067932 | X42 | x42 | +| 440017 | 0x8006b6d1 | @G | Graphite | +| 534352 | 0x80082750 | SCR | Scroll | +| 666666 | 0x800a2c2a | VITE | Vite | +| 696365 | 0x800b3206 | ICE | Ice Network | +| 696969 | 0x800aa289 | TXC | TEXITcoin | +| 827166 | 0x800c9f1e | | RGB on Bitcoin (mainnet) | +| 827167 | 0x800c9f1f | | RGB on Bitcoin (testnet) | +| 828942 | 0x800ca60e | | RGB on Liquid (mainnet) | +| 888888 | 0x800d9038 | SEA | Second Exchange Alliance | +| 1048576 | 0x80100000 | AMAX | Armonia Meta Chain | +| 1171337 | 0x8011df89 | ILT | iOlite | +| 1313114 | 0x8014095a | ETHO | Etho Protocol | +| 1313500 | 0x80140adc | XERO | Xerom | +| 1712144 | 0x801a2010 | LAX | LAPO | +| 3924011 | 0x803be02b | EPK | EPIK Protocol | +| 4741444 | 0x80485944 | HYD | Hydra Token | +| 5063758 | 0x804d444e | | Miden | +| 5249353 | 0x80501949 | BCO | BitcoinOre | +| 5249354 | 0x8050194a | BHD | BitcoinHD | +| 5264462 | 0x8050544e | PTN | PalletOne | +| 5655640 | 0x80564c58 | VLX | Velas | +| 5718350 | 0x8057414e | WAN | Wanchain | +| 5741564 | 0x80579bfc | WAVES | Waves | +| 5741565 | 0x80579bfd | WEST | Waves Enterprise | +| 6382179 | 0x80616263 | ABC | Abcmint | +| 6517357 | 0x8063726d | CRM | Creamcoin | +| 7171666 | 0x806d6e52 | BROCK | Bitrock | +| 7562605 | 0x8073656d | SEM | Semux | +| 7567736 | 0x80737978 | ION | ION | +| 7777777 | 0x8076adf1 | FCT | FirmaChain | +| 7825266 | 0x80776772 | WGR | WGR | +| 7825267 | 0x80776773 | OBSR | OBServer | +| 8163271 | 0x807c8fc7 | AFS | ANFS | +| 10000118 | 0x805d30b6 | OSMO | Osmosis | +| 15118976 | 0x80e6b280 | XDS | XDS | +| 19000118 | 0x8121eb36 | SEI | SEI | +| 22000118 | 0x814fb1f6 | DYDX | Dydx | +| 61717561 | 0x83adbc39 | AQUA | Aquachain | +| 77777777 | 0x84a2cb71 | AZT | Aztecoin | +| 88888888 | 0x854c5638 | HATCH | Hatch | +| 91927009 | 0x857ab1e1 | kUSD | kUSD | +| 99999996 | 0x85f5e0fc | GENS | GENS | +| 99999997 | 0x85f5e0fd | EQ | EQ | +| 99999998 | 0x85f5e0fe | FLUID | Fluid Chains | +| 99999999 | 0x85f5e0ff | QKC | QuarkChain | +| 11259375 | 0x80abcdef | LBR | 0L | +| 20230101 | 0x8134afd5 | ROH | Rooch | +| 20240430 | 0x8134d82e | NLK | NuLinkCoin | +| 240079435 | 0x8e4f524b | ZORK | Zork Network | +| 268435779 | 0x90000143 | MON | Monad | +| 608589380 | 0xa4465644 | FVDC | ForumCoin | +| 1010101010 | 0xbc34eb12 | FAIC | Free AI Chain | +| 1179993420 | 0xc655454c | | Fuel | +| 1179993421 | 0xc655454d | TTNC | TakeTitan | +| 1179993431 | 0xc6554557 | MTGBP | MTGBP | +| 1179993441 | 0xc6554561 | QFS | Qfs | +| 1179993451 | 0xc655456b | RWA | Asset Chain | +| 1179993461 | 0xc6554575 | HXC | HuaXia Chain | +| 1179993471 | 0xc655457f | AME | AME Chain | Coin types will be added only if there is a wallet implementing BIP-0044 for desired coin. ## Libraries -* [BIP44-constants](https://www.npmjs.com/package/bip44-constants) ([source](http://github.com/bitcoinjs/bip44-constants)) JavaScript package with described coin types +- [BIP44-constants](https://www.npmjs.com/package/bip44-constants) ([source](http://github.com/bitcoinjs/bip44-constants)) JavaScript package with described coin types ## References -* [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) +- [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) diff --git a/slip-0048.md b/slip-0048.md index 32145638..b25cc397 100644 --- a/slip-0048.md +++ b/slip-0048.md @@ -3,8 +3,8 @@ ``` Number: SLIP-0048 Title: Deterministic key hierarchy for Graphene-based networks -Type: Informational -Status: Draft +Type: Standard +Status: Active Authors: Fabian Schuh Created: 2016-10-18 ``` @@ -30,7 +30,9 @@ The `memo` key is different in that it is **not** a roles but a single key that ## Deterministic Key Hierarchy - m / purpose' / network' / role' / account-index' / key-index' +``` +m / purpose' / network' / role' / account-index' / key-index' +``` Each level has a special meaning, described in the chapters below. Apostrophe in the path indicates that BIP32 hardened derivation is used. @@ -61,7 +63,9 @@ Hardened derivation is used at this level. The Role comes prior to the Account index so that a role-specific parent key can be derived which allows to derive child keys that do not interfer with other roles. A simple use-case would be a mobile wallet app that does not want to expose owner keys but only has active keys available by going through the tree starting with: - m / purpose' / network' / [active] +``` +m / purpose' / network' / [active] +``` ### Account-Index @@ -119,20 +123,38 @@ Disadvantages are: ## Registered networks -Index | Network | Roles ----------------|-------------|--------------------------------------------------------- -0x00000000 | Steem | `0x0`: owner, `0x1`: active, `0x3`: memo, `0x4`: posting -0x00000001 | BitShares | `0x0`: owner, `0x1`: active, `0x3`: memo -0x00000002 | PeerPlays | `0x0`: owner, `0x1`: active, `0x3`: memo -0x00000003 | Muse | `0x0`: owner, `0x1`: active, `0x3`: memo -0x00000003 | EOS | t.b.d. +Index | Network | Roles +---------------|--------------|--------------------------------------------------------- +0x00000000 | Steem | `0x0`: owner, `0x1`: active, `0x3`: memo, `0x4`: posting +0x00000001 | BitShares | `0x0`: owner, `0x1`: active, `0x3`: memo +0x00000002 | PeerPlays | `0x0`: owner, `0x1`: active, `0x3`: memo +0x00000003 | Muse | `0x0`: owner, `0x1`: active, `0x3`: memo +0x00000004 | EOS | `0x0`: owner, `0x1`: active +0x00000005 | FIBOS | `0x0`: owner, `0x1`: active +0x00000006 | ONE | `0x0`: owner, `0x1`: active +0x00000007 | SBC | `0x0`: owner, `0x1`: active +0x00000008 | YOYOW | `0x0`: owner, `0x1`: active, `0x3`: memo, `0x4`: secondary +0x00000009 | BOS | `0x0`: owner, `0x1`: active +0x0000000a | ONEGRAM | `0x0`: owner, `0x1`: active +0x0000000b | BRAVO | `0x0`: owner, `0x1`: active, `0x3`: memo, `0x4`: posting +0x0000000c | DECENT | `0x0`: owner, `0x1`: active, `0x3`: memo +0x00000bee | Hive | `0x0`: owner, `0x1`: active, `0x3`: memo, `0x4`: posting +0x00001388 | Vet The Vote | `0x0`: owner, `0x1`: active, `0x3`: memo, `0x4`: posting, `0x5`: comms +0x000014da | Keet | `0x0`: owner ## Examples Network | Role | Account-index | Key-Index | Path -----------|---------------|----------------|-----------|---------------------------- -Steem | active | first | first | m / 48' / 0' / 1' / 0' / 0' -BitShares | owner | forth | forth | m / 48' / 1' / 0' / 3' / 3' +Steem | active | first | first | m / 48' / 0' / 1' / 0' / 0' +BitShares | owner | forth | forth | m / 48' / 1' / 0' / 3' / 3' +EOS | owner | first | first | m / 48' / 4' / 0' / 0' / 0' +FIBOS | owner | first | first | m / 48' / 5' / 0' / 0' / 0' +BOS | owner | first | first | m / 48' / 9' / 0' / 0' / 0' +ONEGRAM | owner | first | first | m / 48' / 10' / 0' / 0' / 0' +HIVE | active | first | first | m / 48' / 3054' / 1' / 0' / 0' +V12 | comms | first | first | m / 48' / 5000' / 5' / 0' / 0' + ## References diff --git a/slip-0077.md b/slip-0077.md new file mode 100644 index 00000000..7b63915a --- /dev/null +++ b/slip-0077.md @@ -0,0 +1,66 @@ +# SLIP-0077 : Deterministic blinding key derivation for Confidential Transactions + +``` +Number: SLIP-0077 +Title: Deterministic blinding key derivation for Confidential Transactions +Type: Standard +Status: Draft +Authors: Roman Zeyde +Created: 2019-06-15 +``` + +## Abstract + +This document describes a method for blinding key derivation +for Confidential Transactions, using a deterministic hierarchy. + +## General design + +In confidential transactions, the sender and the receiver use ECDH to derive a shared nonce, which is then used for hiding/recovering of the actual value and asset type being transacted. +In Elements/Liquid, the receiver uses the following derivation scheme for his ECDH public/private keys: + +``` +blinding_private_key := HMAC_SHA256(key=master_blinding_key, msg=script_pubkey) +blinding_public_key := secp256k1_publickey(private_key=blinding_private_key) +``` + +Note: `blinding_private_key` (as 256-bit scalar) must be less than the secp256k1 curve group order - otherwise, the derivation above must fail. + +The receiver is using `blinding_public_key` to construct a "confidential address", which is used by the sender to blind the relevant transaction outputs. Each such blinded transaction output also contains the sender's ECDH public key, so the receiver would be able to recover the shared nonce using its `blinding_private_key`. + +An additional use-case is sharing some/all of the receiver's blinding private keys with an external auditor, allowing unblinding the audited outputs without being able to spend them. + +## Design details + +### Master blinding key derivation + +In order to use similar blinding key derivation scheme on TREZOR, we suggest using [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md) derivation scheme for `master_blinding_key`: + +``` +domain := b"Symmetric key seed" +root := HMAC_SHA512(key=domain, msg=seed) + +label := b"SLIP-0077" +node := HMAC_SHA512(key=root[0:32], msg=(b"\x00" + label)) + +master_blinding_key := node[32:64] +``` + +The above seed should be derived using [BIP-0039](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#from-mnemonic-to-seed) mnemonic and passphrase (if available). + +### Shared nonce derivation + +The shared nonce is derived using ECDH and double-SHA256 of the compressed shared public key: + +``` +shared := secp256k1_multiply(blinding_private_key, sender_public_key, compressed=True) +nonce := SHA256(SHA256(shared)) +``` + +## References + +* [An investigation into Confidential Transactions](https://github.com/AdamISZ/ConfidentialTransactionsDoc/blob/master/essayonCT.pdf) +* [Confidential Transactions tutorial](https://elementsproject.org/elements-code-tutorial/confidential-transactions#blindingkey) +* [Liquid Developer Guide](https://docs.blockstream.com/liquid/developer-guide/developer-guide-index.html#confidential-transactions) +* [Elements' blinding key derivation](https://github.com/ElementsProject/elements/blob/a6beb256ed5195c2a1014a34fdf354d5797247a8/src/wallet/wallet.cpp#L5594) +* [Elements' output unblinding using ECDH](https://github.com/ElementsProject/elements/blob/66c015529e7846f8491bcafd986326bcafc1bfcb/src/blind.cpp#L53) diff --git a/slip-0132.md b/slip-0132.md index 1c106d6b..1e197036 100644 --- a/slip-0132.md +++ b/slip-0132.md @@ -4,22 +4,22 @@ Number: SLIP-0132 Title: Registered HD version bytes for BIP-0032 Type: Standard -Status: Draft +Status: Active Authors: Clark Moody Created: 2018-02-08 ``` ## Abstract -BIP-0032 defines the derivation scheme for heirarchical deterministic wallets, which encode their public and private keys in an extended serialization format known as `xpub`. The `xpub` prefix is an artifact of Base58 encoding the four version bytes of the serialization format. +BIP-0032 defines the derivation scheme for hierarchical deterministic wallets, which encode their public and private keys in an extended serialization format known as `xpub`. The `xpub` prefix is an artifact of Base58 encoding the four version bytes of the serialization format. ## Motivation The BIP repository defines public and private key version bytes for Bitcoin's mainnet and testnet. However, other cryptocurrencies use different version bytes for encoding HD seeds, and the BIP repository is focused on Bitcoin. Thus, we propose this SLIP act as a registry for all coin HD version bytes. -Since BIP-0032 does not specify the address format for a given derivation path, wallet developers [have proposed](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014907.html) altering the version bytes to achieve this. With the activation of SegWit on Bitcoin, the number of ways of encoding an address public key has increased. While [BIP-0049](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki) proposes a method for encoding P2WPKH-nested-in-P2SH addresses, it fails to change the HD seed version bytes (retains `xpub` prefix), leading to unsustainable user confusion. Either the user must know that the `xpub` uses BIP-0049 derivation, or the consumer of the `xpub` must scan both address spaces (P2PKH and P2WPKH-in-P2SH). +Since BIP-0032 does not specify the address format for a given derivation path, wallet developers [have proposed](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014907.html) altering the version bytes to achieve this. With the activation of SegWit on Bitcoin, the number of ways of encoding an address public key has increased. While [BIP-0049](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki) proposes a method for encoding P2WPKH-nested-in-P2SH addresses, its original version failed to change the HD seed version bytes (retained `xpub` prefix), leading to unsustainable user confusion. Either the user must know that the `xpub` uses BIP-0049 derivation, or the consumer of the `xpub` must scan both address spaces (P2PKH and P2WPKH-in-P2SH). -[BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) proposes a native-SegWit derivation scheme, encoding P2WPKH addresses in Bech32. However, the extended serialization format is presented with a `zpub` prefix but no version bytes. This is an issue since multiple values of the version bytes may encode to the same prefix. +[BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) proposes a native-SegWit derivation scheme, encoding P2WPKH addresses in Bech32. However, the extended serialization format was originally presented with a `zpub` prefix but no version bytes. This is an issue since multiple values of the version bytes may encode to the same prefix. A final important motiviation for establishing a clearinghouse of HD version bytes is the fact that the extended serialization format does not encode the coin type. The [SLIP-0032](https://github.com/satoshilabs/slips/blob/master/slip-0032.md) proposal attempts a remedy by including the full BIP-0032 derivation path within the serialized key. Along with a human-readable prefix of `xpub` and Bech32 encoding, SLIP-0032 should greatly improve the wallet ecosystem. Until wallets begin implementation of SLIP-0032, however, this registry aims to alleviate the confusion. @@ -27,21 +27,41 @@ A final important motiviation for establishing a clearinghouse of HD version byt These are the registered HD version bytes for extended serialization of public and private keys. -Coin | Public Key | Private Key | Address Encoding | -------------------------------------------|-----------------------|-----------------------|------------------| -[Bitcoin](https://bitcoin.org/) | `0x0488b21e` - `xpub` | `0x0488ade4` - `xprv` | P2PKH or P2SH | -Bitcoin | `0x049d7cb2` - `ypub` | `0x049d7878` - `yprv` | P2WPKH in P2SH | -Bitcoin | `0x0295b43f` - `Ypub` | `0x0295b005` - `Yprv` | P2WSH in P2SH | -Bitcoin | `0x04b24746` - `zpub` | `0x04b2430c` - `zprv` | P2WPKH | -Bitcoin | `0x02aa7ed3` - `Zpub` | `0x02aa7a99` - `Zprv` | P2WSH | -Bitcoin Testnet | `0x043587cf` - `tpub` | `0x04358394` - `tprv` | P2PKH or P2SH | -Bitcoin Testnet | `0x044a5262` - `upub` | `0x044a4e28` - `uprv` | P2WPKH in P2SH | -Bitcoin Testnet | `0x045f1cf6` - `vpub` | `0x045f18bc` - `vprv` | P2WPKH | -Bitcoin Testnet | `0x02575483` - `Vpub` | `0x02575048` - `Vprv` | P2WSH | -[Litecoin](https://litecoin.org/) | `0x019da462` - `Ltub` | `0x019d9cfe` - `Ltpv` | P2PKH or P2SH | -Litecoin | `0x01b26ef6` - `Mtub` | `0x01b26792` - `Mtpv` | P2WPKH in P2SH | -Litecoin Testnet | `0x0436f6e1` - `ttub` | `0x0436ef7d` - `ttpv` | P2PKH or P2SH | -[Vertcoin](https://vertcoin.org/) | `0x0488b21e` - `vtcp` | `0x0488ade4` - `vtcv` | P2PKH or P2SH | +Coin | Public Key | Private Key | Address Encoding | BIP 32 Path | +------------------------------------------|-----------------------|-----------------------|----------------------------------|-------------| +Bitcoin | `0x0488b21e` - `xpub` | `0x0488ade4` - `xprv` | P2PKH or P2SH | m/44'/0' | +Bitcoin | `0x049d7cb2` - `ypub` | `0x049d7878` - `yprv` | P2WPKH in P2SH | m/49'/0' | +Bitcoin | `0x04b24746` - `zpub` | `0x04b2430c` - `zprv` | P2WPKH | m/84'/0' | +Bitcoin | `0x0295b43f` - `Ypub` | `0x0295b005` - `Yprv` | Multi-signature P2WSH in P2SH | - | +Bitcoin | `0x02aa7ed3` - `Zpub` | `0x02aa7a99` - `Zprv` | Multi-signature P2WSH | - | +Bitcoin Testnet | `0x043587cf` - `tpub` | `0x04358394` - `tprv` | P2PKH or P2SH | m/44'/1' | +Bitcoin Testnet | `0x044a5262` - `upub` | `0x044a4e28` - `uprv` | P2WPKH in P2SH | m/49'/1' | +Bitcoin Testnet | `0x045f1cf6` - `vpub` | `0x045f18bc` - `vprv` | P2WPKH | m/84'/1' | +Bitcoin Testnet | `0x024289ef` - `Upub` | `0x024285b5` - `Uprv` | Multi-signature P2WSH in P2SH | - | +Bitcoin Testnet | `0x02575483` - `Vpub` | `0x02575048` - `Vprv` | Multi-signature P2WSH | - | +Groestlcoin | `0x0488b21e` - `xpub` | `0x0488ade4` - `xprv` | P2PKH or P2SH | m/44'/17' | +Groestlcoin | `0x049d7cb2` - `ypub` | `0x049d7878` - `yprv` | P2WPKH in P2SH | m/49'/17' | +Groestlcoin | `0x04b24746` - `zpub` | `0x04b2430c` - `zprv` | P2WPKH | m/84'/17' | +Groestlcoin | `0x0295b43f` - `Ypub` | `0x0295b005` - `Yprv` | Multi-signature P2WSH in P2SH | - | +Groestlcoin | `0x02aa7ed3` - `Zpub` | `0x02aa7a99` - `Zprv` | Multi-signature P2WSH | - | +Groestlcoin Testnet | `0x043587cf` - `tpub` | `0x04358394` - `tprv` | P2PKH or P2SH | m/44'/1' | +Groestlcoin Testnet | `0x044a5262` - `upub` | `0x044a4e28` - `uprv` | P2WPKH in P2SH | m/49'/1' | +Groestlcoin Testnet | `0x045f1cf6` - `vpub` | `0x045f18bc` - `vprv` | P2WPKH | m/84'/1' | +Groestlcoin Testnet | `0x024289ef` - `Upub` | `0x024285b5` - `Uprv` | Multi-signature P2WSH in P2SH | - | +Groestlcoin Testnet | `0x02575483` - `Vpub` | `0x02575048` - `Vprv` | Multi-signature P2WSH | - | +Kylacoin | `0x038f332e` - `kpub` | `0x038f2ef4` - `kprv` | P2PKH or P2SH | - | +Kylacoin Testnet | `0x045f1cf6` - `vpub` | `0x045f18bc` - `vprv` | P2PKH or P2SH | - | +Litecoin | `0x019da462` - `Ltub` | `0x019d9cfe` - `Ltpv` | P2PKH or P2SH | m/44'/2' | +Litecoin | `0x01b26ef6` - `Mtub` | `0x01b26792` - `Mtpv` | P2WPKH in P2SH | m/49'/2' | +Litecoin Testnet | `0x0436f6e1` - `ttub` | `0x0436ef7d` - `ttpv` | P2PKH or P2SH | m/44'/1' | +Lyncoin | `0x019c354f` - `Lpub` | `0x019c3115` - `Lprv` | P2PKH or P2SH | - | +Lyncoin Testnet | `0x022dbf5b` - `Tpub` | `0x022dbb21` - `Tprv` | P2PKH or P2SH | - | +Nexa | `0x42696720` - `xpub` | `0x426c6b73` - `xprv` | P2PKT or P2PKH or P2SH | m/44'/29223'| +Nexa Testnet | `0x043587cf` - `xpub` | `0x04358394` - `xprv` | P2PKT or P2PKH or P2SH | m/44'/1' | +Vertcoin | `0x0488b21e` - `vtcp` | `0x0488ade4` - `vtcv` | P2PKH or P2SH | m/44'/28' | +Polis | `0x03e25d7e` - `ppub` | `0x03e25945` - `pprv` | P2PKH | m/44'/1997' | +Syscoin | `0x04b24746` - `zpub` | `0x04b2430c` - `zprv` | P2WPKH | m/84'/57' | +Syscoin | `0x02aa7ed3` - `Zpub` | `0x02aa7a99` - `Zprv` | Multi-signature P2WSH | - | ## Bitcoin Test Vectors @@ -71,5 +91,5 @@ bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu ## References -* [BIP-0032: Heirarchical Deterministic Wallets # Serialization](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format) +* [BIP-0032: Hierarchical Deterministic Wallets # Serialization](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format) * [SLIP-0032: Extended serialization format for BIP-32 wallets](https://github.com/satoshilabs/slips/blob/master/slip-0032.md) diff --git a/slip-0173.md b/slip-0173.md index 7ed190b8..4258cc1a 100644 --- a/slip-0173.md +++ b/slip-0173.md @@ -4,7 +4,7 @@ Number: SLIP-0173 Title: Registered human-readable parts for BIP-0173 Type: Standard -Status: Draft +Status: Active Authors: Clark Moody Created: 2017-05-17 ``` @@ -21,20 +21,335 @@ The BIP repository does not want to deal with assigning the values for various c These are the registered human-readable parts for usage in Bech32 encoding of witness programs. -hrp | coin | hrp | coin | -------|------------------------------------------|--------|--------------------------| -`bc` | [Bitcoin](https://bitcoin.org/) | `tb` | Bitcoin Testnet | -`ltc` | [Litecoin](https://litecoin.org/) | `tltc` | Litecoin Testnet | -`vtc` | [Vertcoin](https://vertcoin.org/) | `tvtc` | Vertcoin Testnet | -`btg` | [Bitcoin Gold](https://bitcoingold.org/) | `tbtg` | Bitcoin Gold Testnet | -`btp` | [Bitcoin Platinum](https://btcplt.org/) | `tbtp` | Bitcoin Platinum Testnet | -`zen` | [Zen Protocol](https://zenprotocol.com/) | `tzn` | Zen Protocol Testnet | -`grs` | [Groestlcoin](https://groestlcoin.org/) | `tgrs` | Groestlcoin Testnet | +| Coin | Mainnet | Testnet | Regtest | +| ------------------------ | ------------- | -------- | ----------- | +| 8ball | `8ball` | | | +| Aaron Network | `aaron` | | | +| Acrechain | `acre` | | | +| Agoric | `agoric` | | | +| AIOZ Network | `aioz` | | | +| Akash | `akash` | | | +| Allora | `allo` | | | +| Andromeda | `andr` | | | +| Alaya | `atp` | `atx` | | +| Althea | `althea` | | | +| Archway | `archway` | `const` | | +| Apc | `apc` | | | +| Arkhadian | `arkh` | | | +| Arkeo | `arkeo` | `tarkeo` | | +| AssetMantle | `mantle` | | | +| Athena | `ath` | `atest` | | +| AtomOne | `atone` | | | +| Aura Network | `aura` | | | +| Axelar | `axelar` | | | +| Axone | `axone` | | | +| Babylon | `bbn` | | | +| BARE | `bare` | `tbare` | `bart` | +| Band Protocol | `band` | | | +| BeeZee | `bze` | `tbz` | | +| Bellcoin | `bm` | `bt` | `br` | +| BeOne Chain | `boc` | `tboc` | | +| Binance Chain | `bnb` | | | +| BitCanna | `bcna` | | | +| BitBadges | `bb` | | | +| Bitcoin | `bc` | `tb` | `bcrt` | +| Bitcoin Atom | `bca` | `tbca` | `bcart` | +| Bitcoin Gold | `btg` | `tbtg` | | +| Bitcoin Platinum | `btp` | `tbtp` | | +| Bitcoin Post-Quantum | `pq` | `tq` | `pqrt` | +| Bitcoin Private | `btcp` | `tbtcp` | `regbtcp` | +| Bitcore | `btx` | `tbtx` | | +| BitSong | `bitsong` | | | +| BitZeny | `bz` | `tz` | `rz` | +| Blackcoin | `blk` | `tblk` | `blrt` | +| Blacknet | `blacknet` | | `rblacknet` | +| BlockX | `blockx` | | | +| BlueChip | `bcp` | | | +| Bluzelle | `bluzelle` | | | +| bostrom | `bostrom` | | | +| Bouachain | `bouachain` | | | +| Canto | `canto` | | | +| Carbon | `swth` | | | +| Celestia | `celestia` | | | +| Cerberus | `cerberus` | | | +| Chain4Energy | `c4e` | | | +| cheqd | `cheqd` | | | +| Chia | `xch` | `txch` | | +| Chihuahua | `chihuahua` | | | +| Chimba | `chimba` | | | +| Chronic Chain | `chronic` | | | +| Cifer | `cife` | `cift` | | +| City Coin | `city` | `tcity` | | +| Cnho Stables | `cnho` | | | +| Comdex | `comdex` | | | +| Commercio | `did:com:` | | | +| Composable | `centauri` | | | +| ConsciousDAO | `cvn` | | | +| Coreum | `core` |`testcore`| | +| Cosmos Hub | `cosmos` | | | +| Coss Chain | `coss` | `tcoss` | | +| CPUchain | `cpu` | `tcpu` | `rcpu` | +| Craft Economy | `craft` | | | +| CranePay | `cp` | `cpt` | `cpr` | +| Crescent | `cre` | | | +| Cronos | `crc` | | | +| Crypto Chain | `cro` | `tcro` | | +| Cudos | `cudos` | | | +| Cyber | `cyber` | | | +| Cyberyen | `cy` | `tcy` | `rcy` | +| DC3 Network | `dc3` | `tdc3` | | +| Decentr | `decentr` | | | +| Desmos | `desmos` | | | +| dHealth | `dh` | | | +| Dig Chain | `dig` | | | +| DigiByte | `dgb` | `dgbt` | `dgbrt` | +| Dora Vota | `dora` | | | +| Developer Network | `dev` | | | +| Dungeon Network | `dungeon` | | | +| dYdX Protocol | `dydx` | | | +| Dymension | `dym` | | | +| Dyson Protocol | `dys` | | | +| Echelon | `echelon` | | | +| e-Money | `emoney` | | | +| Elys Network | `elys` | | | +| EmpowerChain | `empower` | | | +| Epix | `epix` | | | +| Ethos | `ethos` | | | +| Evmos | `evmos` | | | +| Fetch | `fetch` | | | +| Finschia | `link` | `tlink` | | +| FirmaChain | `firma` | | | +| Fren.ai | `fren` | `fren-1` | | +| FujiCoin | `fc` | `tf` | `fcrt` | +| Furya | `furya` | | | +| f(x)Core | `fx` | | | +| Galaxy | `galaxy` | | | +| GovGen | `govgen` | | | +| Wormhole Gateway | `wormhole` | | | +| GenesisL1 | `genesis` | | | +| GGEZ1 Chain | `ggez` | | | +| Gitopia | `gitopia` | | | +| GlobalBoost-Y | `gb` | `gbt` | `gbrt` | +| Golden Gate | `ggx` | `ggxt` | | +| Gravity Bridge | `gravity` | | | +| Groestlcoin | `grs` | `tgrs` | `grsrt` | +| Handshake | `hs` | `ts` | `rs` | +| Haqq Network | `haqq` | | | +| Hash | `pb` | `tp` | | +| HashKey Chain | `hsk` | `hst` | | +| Hedge | `hedge` | | | +| HeliChain | `heli` | | | +| Highbury | `fury` | | | +| Hippo Protocol | `hippo` | | | +| HoneyWood | `bears` | | | +| Humans | `human` | | | +| Hypersign | `hid` | | | +| IDEP | `idep` | | | +| Imversed | `imv` | | | +| Int3face | `int3` | | | +| Initia | `init` | | | +| Injective | `inj` | | | +| IOTA | `iota` | `atoi` | | +| IoTeX | `io` | `it` | | +| IRISnet | `iaa` | | | +| Impact Hub | `ixo` | | | +| Jackal | `jkl` | | | +| Juno | `juno` | | | +| Joltify | `jolt` | | | +| Kava | `kava` | | | +| Ki | `ki` | | | +| Kima Network | `kima` | | | +| Kira Network | `kira` | | | +| Konstellation | `darc` | | | +| kopi | `kopi` | | | +| Kujira | `kujira` | | | +| Kylacoin | `kc` | `tkc` | `kcrt` | +| KYVE | `kyve` | | | +| Lambda | `lamb` | | | +| LatticeX | `pla` | `plt` | | +| Lava | `lava@` | `lava@` | | +| Lefeef | `lefeef` | | | +| LikeCoin | `like` | | | +| Litecoin | `ltc` | `tltc` | `rltc` | +| Logos | `logos` | | | +| Loop | `loop` | | | +| Lorenzo | `lrz` | | | +| Loyal | `loyal` | | | +| Lum Network | `lum` | | | +| LumenX | `lumen` | | | +| Lyncoin | `lc` | `tlc` | `lcrt` | +| Lynx | `lynx` | `tlynx` | `rlynx` | +| Mande Network | `mande` | | | +| Manifest Network | `manifest` | | | +| MANTRA Chain | `mantra` | | | +| Mars Protocol | `mars` | | | +| Maya Protocol | `maya` | `smaya` | | +| Medas Digital | `medas` | | | +| Medibloc | `panacea` | | | +| MEME | `meme` | | | +| MetaNova Verse | `mnova` | | | +| Microtick | `micro` | | | +| Miden | `mm` | `mtst` | | +| Migaloo | `migaloo` | | | +| MilkyWay | `milk` | | | +| Mises | `mises` | | | +| Monacoin | `mona` | `tmona` | `rmona` | +| Moneta Coin | `moneta` | | | +| MTGBP | `mtgbp` | `tmtgbp` | `rmtgbp` | +| MUN Blockchain | `mun` | | | +| Mutelandia Network | `mute` | | | +| Myriad | `my` | `tm` | | +| Mythos | `mythos` | | | +| Namecoin | `nc` | `tn` | `ncrt` | +| Neura | `neura` | | | +| Neutaro | `neutaro` | | | +| Neutron | `neutron` | | | +| Nexa | `nexa` |`nexatest`| `nexareg` | +| Nibiru | `nibi` | | | +| Nillion | `nillion` | | | +| Nim | `nim` | | | +| Noble | `noble` | | | +| Nois | `nois` | | | +| Nomic | `nomic` | | | +| Nyx | `n` | | | +| Oasis Network | `oasis` | `oasis` | | +| Octa | `octa` | | | +| Odin Protocol | `odin` | | | +| OKExChain | `ex` | | | +| OKP4 | `okp4` | | | +| Omni | `o` | `to` | `ocrt` | +| OmniFlix | `omniflix` | | | +| OPCT Chain | `opct` | | | +| Onomy | `onomy` | | | +| Oraichain | `orai` | | | +| Osmosis | `osmo` | | | +| Paloma | `paloma` | | | +| Passage | `pasg` | | | +| Peercoin | `xpc` | `tpc` | | +| Persistence | `persistence` | | | +| Picasso | `pica` | | | +| PKT | `pkt` | `tpk` | | +| Planq | `plq` | | | +| PlatON | `lat` | `lax` | | +| Point Network | `point` | `xpoint` | | +| Provenance | `pb` | `tp` | | +| Pryzm | `pryzm` | | | +| Pundi X Chain | `px` | | | +| Pylons | `pylo` | | | +| QFS | `qfs` | `tqfs` | `rqfs ` | +| Quantum Resistant Ledger | `qrl` | `tqrl` | `qrlrt` | +| Quasar | `quasar` | | | +| Quicksilver | `quick` | | | +| Qwoyn Blockchain | `qwoyn` | | | +| Ravencoin | `rc` | `tr` | `rcrt` | +| Realio Network | `realio` | | | +| Rebus | `rebus` | | | +| Regen | `regen` | | | +| Riecoin | `ric` | `tric` | `rric` | +| Rizon | `rizon` | | | +| Router Protocol | `router` | | | +| Saga | `saga` | `tsaga` | | +| Scash | `scash` | `tscash` | `rscash` | +| Scorum Network | `scorum` | | | +| SEDA | `seda` | | | +| Secret Network | `secret` | | | +| Sei | `sei` | | | +| Self Chain | `self` | | | +| Sentinel | `sent` | | | +| SGE Network | `sge` | | | +| ShareLedger | `shareledger` | | | +| Shentu | `shentu` | | | +| Shido | `shido` | | | +| Shimmer | `smr` | `rms` | | +| Side Chain | `side` | | | +| Sifchain | `sif` | | | +| SIX Protocol | `6x` | | | +| Sommelier | `somm` | | | +| Sonr | `idx` | | | +| Source | `source` | | | +| Spacemesh | `sm` | `stest` | | +| StaFiHub | `stafi` | | | +| Stargaze | `stars` | | | +| Starname | `star` | | | +| Straightedge | `str` | | | +| Stratos | `st` | | | +| Stride | `stride` | | | +| Sugarchain | `sugar` | `tugar` | `rugar` | +| Susucoin | `susu` | `tutu` | `ruru` | +| Symphony | `symphony` | | | +| Synternet | `synt` | `amber` | | +| Syscoin | `sys` | `tsys` | `scrt` | +| TakeTitan | `ttnc` | `tttnc` | `rttnc` | +| Tenet | `tenet` | | | +| Teritori | `tori` | | | +| Terp | `terp` | | | +| Terra | `terra` | | | +| Tgrade | `tgrade` | | | +| Thorchain | `thor` | | | +| Titan | `titan` | | | +| Ulas | `ulas` | | | +| Umee | `umee` | | | +| Unification | `und` | | | +| UnUniFi | `ununifi` | | | +| Unit-e | `ue` | `tue` | `uert` | +| Uptick | `uptick` | | | +| USVACoin | `usvac` | `tusvac` | | +| Vertcoin | `vtc` | `tvtc` | | +| Viacoin | `via` | `tvia` | | +| Vidulum | `vdl` | `tvdl` | | +| VinceChain | `vce` | | | +| VIPSTARCOIN | `vips` | `tvips` | | +| Wpc | `wpc` | | | +| Xion | `xion` | `txion` | | +| XPLA | `xpla` | | | +| YeeCo | `yee` | `tyee` | | +| Zen Protocol | `zen` | `tzn` | | +| ZetaChain | `zeta` | | | +| ZIGChain | `zig` | | | +| Zilliqa | `zil` | `tzil` | | +| Zork Network | `zork` |`zorktest`| `zorksim` | + +## Non-Segwit-compatible uses of Bech32 / Bech32m + +The following human-readable parts are registered for formats using Bech32 or Bech32m +that are not compatible with Segwit. Entries annotated with "(m)" use Bech32m [BIP-0350]; +other entries use Bech32. `[text]` indicates variable content in the human-readable part. + +| Project | Mainnet / Production | Testnet | Regtest | +| ----------------- | ------------------------------ | -------------------------- | ----------------------------- | +| age | `age` | +| | `age-secret-key-` | +| | `age1[name]` | +| | `age-plugin-[name]-` | +| Lightning Network | `ln[currency prefix + amount]` | +| Zcash | `zs` | `ztestsapling` | `zregtestsapling` | +| | `zivks` | `zivktestsapling` | `zivkregtestsapling` | +| | `zxviews` | `zxviewtestsapling` | `zxviewregtestsapling` | +| | `zxsprout` | `zxtestsprout` | `zxregtestsprout` | +| | `secret-spending-key-main` | `secret-spending-key-test` | `secret-spending-key-regtest` | +| | `secret-extended-key-main` | `secret-extended-key-test` | `secret-extended-key-regtest` | +| | `u` (m) | `utest` (m) | `uregtest` (m) | +| | `uivk` (m) | `uivktest` (m) | `uivkregtest` (m) | +| | `uview` (m) | `uviewtest` (m) | `uviewregtest` (m) | + +## Uses of codex32 + +The codex32 format is used to store master secret data. It features an extended +checksum versus the one used in Bech32 in order to support enhanced error +correction. Codex32 uses the same notion of a human-readable part and the same +set of 32 characters as other Bech32 formats. + +| Application | Human-readable part | +| -------------------- | -------------------- | +| CLN's HSM secret | `cl` | +| BIP-0032 master seed | `ms` | ## Libraries -* [Reference Implementations](https://github.com/sipa/bech32/tree/master/ref) +- [Reference Implementations](https://github.com/sipa/bech32/tree/master/ref) ## References -* [BIP-0173: Base32 address format for native v0-16 witness outputs](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) +- [BIP-0173: Base32 address format for native v0-16 witness outputs](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) +- [BIP-0350: Bech32m format for v1+ witness addresses](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki) +- [BIP-0093: codex32: Checksummed SSSS-aware BIP32 seeds](https://github.com/bitcoin/bips/blob/master/bip-0093.mediawiki)