Nostr notes by

📅 Original date posted:2023-02-16 🗒️ Summary of this ...

2023-06-08T01:19:40+02:00

In reply to nevent1q…gkhn
_________________________

📅 Original date posted:2023-02-16
🗒️ Summary of this message: A BIP proposes a new secret sharing system, but its only advantage over the existing SLIP-0039 may not be significant. The BIP's focus on hand computation is also unclear.
📝 Original message:Hi!

The BIP states that its only advantage over SLIP-0039, which has been used
in production for nearly three years (in at at least 3 SW/HW wallet
implementations), is that it aims to be simple enough for hand computation.
However, the BIP also indicates that "details of hand computation are
outside the scope of this standard, and implementers do not need to be
concerned with this possibility." Therefore, I am curious about how
significant this advantage over SLIP-0039 really is. If hand computation is
not straightforward and there are no other substantial advantages over
SLIP-0039, I cannot help but feel that this BIP is simply a result of
not-invented-here syndrome, but please correct me if I am wrong.

Keep in mind that the encoded shares in SLIP-0039 consist of exactly 200 or
330 bits, both of which are divisible by 5. This makes it straightforward
to encode them as Bech32 strings.

On Thu, 16 Feb 2023 at 09:30, Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I've been asked by Dr. Curr and Professor Snead to forward this message to
> this mailing list, as it may be of general interest to Bitcoin users.
>
> Dear Colleague:
>
> In 1967, during excavation for the construction of a new shopping center
> in
> Monroeville, Pennsylvania, workers uncovered a vault containing a cache of
> ancient scrolls[1]. Most were severely damaged, but those that could be
> recovered confirmed the existence of a secret society long suspected to
> have
> been active in the region around the year 200 BC.
>
> Based on a translation of these documents, we now know that the society,
> the
> Cult of the Bound Variable, was devoted to the careful study of
> computation,
> over two millennia before the invention of the digital computer.
>
> While the Monroeville scrolls make reference to computing machines made of
> sandstone, most researchers believed this to be a poetic metaphor and that
> the
> "computers" were in fact the initiates themselves, carrying out the
> unimaginably tedious steps of their computations with reed pens on
> parchment.
>
> Within the vault, a collection of sandstone wheels marked in a language
> consisting of 32 glyphs was found. After 15 years of study, we have
> successfully
> completed the translation of what is known as "Codex32," a document that
> describes the functions of the wheels. It was discovered that the wheels
> operate
> a system of cryptographic computations that was used by cult members to
> safeguard their most valuable secrets.
>
> The Codex32 system allows secrets to be carved into multiple tablets and
> scattered to the far corners of the earth. When a sufficient number of
> tablets are
> brought together the stone wheels are manipulated in a manner to recover
> the
> secrets. This finding may be of particular interest to the Bitcoin
> community.
>
> Below we provide a summary of the cult's secret sharing system, which is
> graciously hosted at
> <
> https://github.com/apoelstra/bips/blob/2023-02--volvelles/bip-0000.mediawiki
> >.
> We are requesting a record assignment in the Bibliography of Immemorial
> Philosophy (BIP) repository.
>
> Thank you for your consideration.
>
> Dr. Leon O. Curr and Professor Pearlwort Snead
> Department of Archaeocryptography
> Harry Q. Bovik Institute for the Advancement
>
> [1] http://www.boundvariable.org/task.shtml
>
> -----BEGIN BIP-----
>
> <pre>
> BIP: ????
> Layer: Applications
> Title: codex32
> Author: Leon Olsson Curr and Pearlwort Sneed <pearlwort at wpsoftware.net>
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: ????
> Created: 2023-02-13
> License: BSD-3-Clause
> Post-History: FIXME
> </pre>
>
> ==Introduction==
>
> ===Abstract===
>
> This document describes a standard for backing up and restoring the master
> seed of a
> [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032]
> hierarchical deterministic wallet, using Shamir's secret sharing.
> It includes an encoding format, a BCH error-correcting checksum, and
> algorithms for share generation and secret recovery.
> Secret data can be split into up to 31 shares.
> A minimum threshold of shares, which can be between 1 and 9, is needed to
> recover the secret, whereas without sufficient shares, no information about
> the secret is recoverable.
>
> ===Copyright===
>
> This document is licensed under the 3-clause BSD license.
>
> ===Motivation===
>
> BIP-0032 master seed data is the source entropy used to derive all private
> keys in an HD wallet.
> Safely storing this secret data is the hardest and most important part of
> self-custody.
> However, there is a tension between security, which demands limiting the
> number of backups, and resilience, which demands widely replicated backups.
> Encrypting the seed does not change this fundamental tradeoff, since it
> leaves essentially the same problem of how to back up the encryption key(s).
>
> To allow users freedom to make this tradeoff, we use Shamir's secret
> sharing, which guarantees that any number of shares less than the threshold
> leaks no information about the secret.
> This approach allows increasing safety by widely distributing the
> generated shares, while also providing security against the compromise of
> one or more shares (as long as fewer than the threshold have been
> compromised).
>
> [https://github.com/satoshilabs/slips/blob/master/slip-0039.md SLIP-0039]
> has essentially the same motivations as this standard.
> However, unlike SLIP-0039, this standard also aims to be simple enough for
> hand computation.
> Users who demand a higher level of security for particular secrets, or
> have a general distrust in digital electronic devices, have the option of
> using hand computation to backup and restore secret data in an
> interoperable manner.
> Note that hand computation is optional, the particular details of hand
> computation are outside the scope of this standard, and implementers do not
> need to be concerned with this possibility.
>
> [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039]
> serves the same purpose as this standard: encoding master seeds for storage
> by users.
> However, BIP-0039 has no error-correcting ability, cannot sensibly be
> extended to support secret sharing, has no support for versioning or other
> metadata, and has many technical design decisions that make implementation
> and interoperability difficult (for example, the use of SHA-512 to derive
> seeds, or the use of 11-bit words).
>
> ==Specification==
>
> ===codex32===
>
> A codex32 string is similar to a Bech32 string defined in [
> https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-0173].
> It reuses the base32 character set from BIP-0173, and consists of:
>
> * A human-readable part, which is the string "ms" (or "MS").
> * A separator, which is always "1".
> * A data part which is in turn subdivided into:
> ** A threshold parameter, which MUST be a single digit between "2" and
> "9", or the digit "0".
> *** If the threshold parameter is "0" then the share index, defined below,
> MUST have a value of "s" (or "S").
> ** An identifier consisting of 4 Bech32 characters.
> ** A share index, which is any Bech32 character. Note that a share index
> value of "s" (or "S") is special and denotes the unshared secret (see
> section "Unshared Secret").
> ** A payload which is a sequence of up to 74 Bech32 characters. (However,
> see '''Long codex32 Strings''' below for an exception to this limit.)
> ** A checksum which consists of 13 Bech32 characters as described below.
>
> As with Bech32 strings, a codex32 string MUST be entirely uppercase or
> entirely lowercase.
> The lowercase form is used when determining a character's value for
> checksum purposes.
> For presentation, lowercase is usually preferable, but uppercase SHOULD be
> used for handwritten codex32 strings.
>
> ===Checksum===
>
> The last thirteen characters of the data part form a checksum and contain
> no information.
> Valid strings MUST pass the criteria for validity specified by the Python3
> code snippet below.
> The function <code>ms32_verify_checksum</code> must return true when its
> argument is the data part as a list of integers representing the characters
> converted using the bech32 character table from BIP-0173.
>
> To construct a valid checksum given the data-part characters (excluding
> the checksum), the <code>ms32_create_checksum</code> function can be used.
>
> <source lang="python">
> MS32_CONST = 0x10ce0795c2fd1e62a
>
> def ms32_polymod(values):
> GEN = [
> 0x19dc500ce73fde210,
> 0x1bfae00def77fe529,
> 0x1fbd920fffe7bee52,
> 0x1739640bdeee3fdad,
> 0x07729a039cfc75f5a,
> ]
> residue = 0x23181b3
> for v in values:
> b = (residue >> 60)
> residue = (residue & 0x0fffffffffffffff) << 5 ^ v
> for i in range(5):
> residue ^= GEN[i] if ((b >> i) & 1) else 0
> return residue
>
> def ms32_verify_checksum(data):
> if len(data) >= 96: # See Long codex32 Strings
> return ms32_verify_long_checksum(data)
> if len(data) <= 93:
> return ms32_polymod(data) == MS32_CONST
> return False
>
> def ms32_create_checksum(data):
> if len(data) > 80: # See Long codex32 Strings
> return ms32_create_long_checksum(data)
> values = data
> polymod = ms32_polymod(values + [0] * 13) ^ MS32_CONST
> return [(polymod >> 5 * (12 - i)) & 31 for i in range(13)]
> </source>
>
> ===Error Correction===
>
> A codex32 string without a valid checksum MUST NOT be used.
> The checksum is designed to be an error correcting code that can correct
> up to 4 character substitutions, up to 8 unreadable characters (called
> erasures), or up to 13 consecutive erasures.
> Implementations SHOULD provide the user with a corrected valid codex32
> string if possible.
> However, implementations SHOULD NOT automatically proceed with a corrected
> codex32 string without user confirmation of the corrected string, either by
> prompting the user, or returning a corrected string in an error message and
> allowing the user to repeat their action.
> We do not specify how an implementation should implement error correction.
> However, we recommend that:
>
> * Implementations make suggestions to substitute non-bech32 characters
> with bech32 characters in some situations, such as replacing "B" with "8",
> "O" with "0", "I" with "l", etc.
> * Implementations interpret "?" as an erasure.
> * Implementations optionally interpret other non-bech32 characters, or
> characters with incorrect case, as erasures.
> * If a string with 8 or fewer erasures can have those erasures filled in
> to make a valid codex32 string, then the implementation suggests such a
> string as a correction.
> * If a string consisting of valid Bech32 characters in the proper case can
> be made valid by substituting 4 or fewer characters, then the
> implementation suggests such a string as a correction.
>
> ===Unshared Secret===
>
> When the share index of a valid codex32 string (converted to lowercase) is
> the letter "s", we call the string a codex32 secret.
> The subsequent data characters in a codex32 secret, excluding the final
> checksum of 13 characters, is a direct encoding of a BIP-0032 HD master
> seed.
>
> The master seed is decoded by converting the data to bytes:
>
> * Translate the characters to 5 bits values using the bech32 character
> table from BIP-0173, most significant bit first.
> * Re-arrange those bits into groups of 8 bits. Any incomplete group at the
> end MUST be 4 bits or less, and is discarded.
>
> Note that unlike the decoding process in BIP-0173, we do NOT require that
> the incomplete group be all zeros.
>
> For an unshared secret, the threshold parameter (the first character of
> the data part) is ignored (beyond the fact it must be a digit for the
> codex32 string to be valid).
> We recommend using the digit "0" for the threshold parameter in this case.
> The 4 character identifier also has no effect beyond aiding users in
> distinguishing between multiple different master seeds in cases where they
> have more than one.
>
> ===Recovering Master Seed===
>
> When the share index of a valid codex32 string (converted to lowercase) is
> not the letter "s", we call the string an codex32 share.
> The first character of the data part indicates the threshold of the share,
> and it is required to be a non-"0" digit.
>
> In order to recover a master seed, one needs a set of valid codex32 shares
> such that:
>
> * All shares have the same threshold value, the same identifier, and the
> same length.
> * All of the share index values are distinct.
> * The number of codex32 shares is exactly equal to the (common) threshold
> value.
>
> If all the above conditions are satisfied, the <code>ms32_recover</code>
> function will return a codex32 secret when its argument is the list of
> codex32 shares with each share represented as a list of integers
> representing the characters converted using the bech32 character table from
> BIP-0173.
>
> <source lang="python">
> bech32_inv = [
> 0, 1, 20, 24, 10, 8, 12, 29, 5, 11, 4, 9, 6, 28, 26, 31,
> 22, 18, 17, 23, 2, 25, 16, 19, 3, 21, 14, 30, 13, 7, 27, 15,
> ]
>
> def bech32_mul(a, b):
> res = 0
> for i in range(5):
> res ^= a if ((b >> i) & 1) else 0
> a *= 2
> a ^= 41 if (32 <= a) else 0
> return res
>
> def bech32_lagrange(l, x):
> n = 1
> c = []
> for i in l:
> n = bech32_mul(n, i ^ x)
> m = 1
> for j in l:
> m = bech32_mul(m, (x if i == j else i) ^ j)
> c.append(m)
> return [bech32_mul(n, bech32_inv[i]) for i in c]
>
> def ms32_interpolate(l, x):
> w = bech32_lagrange([s[5] for s in l], x)
> res = []
> for i in range(len(l[0])):
> n = 0
> for j in range(len(l)):
> n ^= bech32_mul(w[j], l[j][i])
> res.append(n)
> return res
>
> def ms32_recover(l):
> return ms32_interpolate(l, 16)
> </source>
>
> ===Generating Shares===
>
> If we already have ''t'' valid codex32 strings such that:
>
> * All strings have the same threshold value ''t'', the same identifier,
> and the same length
> * All of the share index values are distinct
>
> Then we can derive additional shares with the
> <code>ms32_interpolate</code> function by passing it a list of exactly
> ''t'' of these codex32 strings, together with a fresh share index distinct
> from all of the existing share indexes.
> The newly derived share will have the provided share index.
>
> Once a user has generated ''n'' codex32 shares, they may discard the
> codex32 secret (if it exists).
> The ''n'' shares form a ''t'' of ''n'' Shamir's secret sharing scheme of a
> codex32 secret.
>
> There are two ways to create an initial set of ''t'' valid codex32
> strings, depending on whether the user already has an existing master seed
> to split.
>
> ====For an existing master seed====
>
> Before generating shares for an existing master seed, it first must be
> converted into a codex32 secret, as described above.
> The conversion process consists of:
>
> * Choosing a threshold value ''t'' between 2 and 9, inclusive
> * Choosing a 4 bech32 character identifier
> ** We do not define how to choose the identifier, beyond noting that it
> SHOULD be distinct for every master seed the user may need to disambiguate.
> * Setting the share index to "s"
> * Setting the payload to a Bech32 encoding of the master seed, padded with
> arbitrary bits
> * Generating a valid checksum in accordance with the Checksum section
>
> Along with the codex32 secret, the user must generate ''t''-1 other
> codex32 shares, each with the same threshold value, the same identifier,
> and a distinct share index.
> The set of share indexes may be chosen arbitrarily.
> The payload of each of these codex32 shares is chosen uniformly at random
> such that it has the same length as the payload of the codex32 secret.
> For each share, a valid checksum must be generated in accordance with the
> Checksum section.
>
> The codex32 secret and the ''t''-1 codex32 shares form a set of ''t''
> valid codex32 strings from which additional shares can be derived as
> described above.
>
> ====For a fresh master seed====
>
> In the case that the user wishes to generate a fresh master seed, the user
> chooses a threshold value ''t'' and an identifier, then generates ''t''
> random codex32 shares, using the generation procedure from the previous
> section.
> As before, each share must have the same threshold value ''t'', the same
> identifier, and a distinct share index.
>
> With this set of ''t'' codex32 shares, new shares can be derived as
> discussed above. This process generates a fresh master seed, whose value
> can be retrieved by running the recovery process on any ''t'' of these
> shares.
>
> ===Long codex32 Strings===
>
> The 13 character checksum design only supports up to 80 data characters.
> Excluding the threshold, identifier and index characters, this limits the
> payload to 74 characters or 46 bytes.
> While this is enough to support the 32-byte advised size of BIP-0032
> master seeds, BIP-0032 allows seeds to be up to 64 bytes in size.
> We define a long codex32 string format to support these longer seeds by
> defining an alternative checksum.
>
> <source lang="python">
> MS32_LONG_CONST = 0x43381e570bf4798ab26
>
> def ms32_long_polymod(values):
> GEN = [
> 0x3d59d273535ea62d897,
> 0x7a9becb6361c6c51507,
> 0x543f9b7e6c38d8a2a0e,
> 0x0c577eaeccf1990d13c,
> 0x1887f74f8dc71b10651,
> ]
> residue = 0x23181b3
> for v in values:
> b = (residue >> 70)
> residue = (residue & 0x3fffffffffffffffff) << 5 ^ v
> for i in range(5):
> residue ^= GEN[i] if ((b >> i) & 1) else 0
> return residue
>
> def ms32_verify_long_checksum(data):
> return ms32_long_polymod(data) == MS32_LONG_CONST
>
> def ms32_create_long_checksum(data):
> values = data
> polymod = ms32_long_polymod(values + [0] * 15) ^ MS32_LONG_CONST
> return [(polymod >> 5 * (14 - i)) & 31 for i in range(15)]
> </source>
>
> A long codex32 string follows the same specification as a regular codex32
> string with the following changes.
>
> * The payload is a sequence of between 75 and 103 Bech32 characters.
> * The checksum consists of 15 Bech32 characters as defined above.
>
> A codex32 string with a data part of 94 or 95 characters is never legal as
> a regular codex32 string is limited to 93 data characters and a long
> codex32 string is at least 96 characters.
>
> Generation of long shares and recovery of the master seed from long shares
> proceeds in exactly the same way as for regular shares with the
> <code>ms32_interpolate</code> function.
>
> The long checksum is designed to be an error correcting code that can
> correct up to 4 character substitutions, up to 8 unreadable characters
> (called erasures), or up to 15 consecutive erasures.
> As with regular checksums we do not specify how an implementation should
> implement error correction, and all our recommendations for error
> correction of regular codex32 strings also apply to long codex32 strings.
>
> ==Rationale==
>
> This scheme is based on the observation that the Lagrange interpolation of
> valid codewords in a BCH code will always be a valid codeword.
> This means that derived shares will always have valid checksum, and a
> sufficient threshold of shares with valid checksums will derive a secret
> with a valid checksum.
>
> The header system is also compatible with Lagrange interpolation, meaning
> all derived shares will have the same identifier and will have the
> appropriate share index.
> This fact allows the header data to be covered by the checksum.
>
> The checksum size and identifier size have been chosen so that the
> encoding of 128-bit seeds and shares fit within 48 characters.
> This is a standard size for many common seed storage formats, which has
> been popularized by the 12 four-letter word format of the BIP-0039 mnemonic.
>
> The 13 character checksum is adequate to correct 4 errors in up to 93
> characters (80 characters of data and 13 characters of the checksum). This
> is somewhat better quality than the checksum used in SLIP-0039.
>
> For 256-bit seeds and shares our strings are 74 characters, which fits
> into the 96 character format of the 24 four-letter word format of the
> BIP-0039 mnemonic, with plenty of room to spare.
>
> A longer checksum is needed to support up to 512-bit seeds, the longest
> seed length specified in BIP-0032, as the 13 character checksum isn't
> adequate for more than 80 data characters.
> While we could use the 15 character checksum for both cases, we prefer to
> keep the strings as short as possible for the more common cases of 128-bit
> and 256-bit master seeds.
> We only guarantee to correct 4 characters no matter how long the string is.
> Longer strings mean more chances for transcription errors, so shorter
> strings are better.
>
> The longest data part using the regular 13 character checksum is 93
> characters and corresponds to a 400-bit secret.
> At this length, the prefix <code>MS1</code> is not covered by the checksum.
> This is acceptable because the checksum scheme itself requires you to know
> that the <code>MS1</code> prefix is being used in the first place.
> If the prefix is damaged and a user is guessing that the data might be
> using this scheme, then the user can enter the available data explicitly
> using the suspected <code>MS1</code> prefix.
>
> ==Backwards Compatibility==
>
> codex32 is an alternative to BIP-0039 and SLIP-0039.
> It is technically possible to derive the BIP32 master seed from seed words
> encoded in one of these schemes, and then to encode this seed in codex32.
> For BIP-0039 this process is irreversible, since it involves hashing the
> original words.
> Furthermore, the resulting seed will be 512 bits long, which may be too
> large to be safely and conveniently handled.
>
> SLIP-0039 seed words can be reversibly converted to master seeds, so it is
> possible to interconvert between SLIP-0039 and codex32.
> However, SLIP-0039 '''shares''' cannot be converted to codex32 shares
> because the two schemes use a different underlying field.
>
> The authors of this BIP do not recommend interconversion.
> Instead, users who wish to switch to codex32 should generate a fresh seed
> and sweep their coins.
>
> ==Reference Implementation==
>
> * [https://secretcodex32.com/docs/2023-02-14--bw.ps Reference PostScript
> Implementation]
> * FIXME add Python implementation
> * FIXME add Rust implementation
>
> ==Test Vectors==
>
> ===Test vector 1===
>
> This example shows the codex32 format, when used without splitting the
> secret into any shares.
> The data part contains 26 Bech32 characters, which corresponds to 130
> bits. We truncate the last two bits in order to obtain a 128-bit master
> seed.
>
> codex32 secret (Bech32):
> <code>ms10testsxxxxxxxxxxxxxxxxxxxxxxxxxx4nzvca9cmczlw</code>
>
> Master secret (hex): <code>318c6318c6318c6318c6318c6318c631</code>
>
> * human-readable part: <code>ms</code>
> * separator: <code>1</code>
> * k value: <code>0</code> (no secret splitting)
> * identifier: <code>test</code>
> * share index: <code>s</code> (the secret)
> * data: <code>xxxxxxxxxxxxxxxxxxxxxxxxxx</code>
> * checksum: <code>4nzvca9cmczlw</code>
>
> ===Test vector 2===
>
> This example shows generating a new master seed using "random" codex32
> shares, as well as deriving an additional codex32 share, using ''k''=2 and
> an identifier of <code>NAME</code>.
> Although codex32 strings are canonically all lowercase, it's also valid to
> use all uppercase.
>
> Share with index <code>A</code>:
> <code>MS12NAMEA320ZYXWVUTSRQPNMLKJHGFEDCAXRPP870HKKQRM</code>
>
> Share with index <code>C</code>:
> <code>MS12NAMECACDEFGHJKLMNPQRSTUVWXYZ023FTR2GDZMPY6PN</code>
>
> * Derived share with index <code>D</code>:
> <code>MS12NAMEDLL4F8JLH4E5VDVULDLFXU2JHDNLSM97XVENRXEG</code>
> * Secret share with index <code>S</code>:
> <code>MS12NAMES6XQGUZTTXKEQNJSJZV4JV3NZ5K3KWGSPHUH6EVW</code>
> * Master secret (hex): <code>d1808e096b35b209ca12132b264662a5</code>
>
> Note that per BIP-0173, the lowercase form is used when determining a
> character's value for checksum purposes.
> In particular, given an all uppercase codex32 string, we still use
> lowercase <code>ms</code> as the human-readable part during checksum
> construction.
>
> ===Test vector 3===
>
> This example shows splitting an existing 128-bit master seed into "random"
> codex32 shares, using ''k''=3 and an identifier of <code>cash</code>.
> We appended two zero bits in order to obtain 26 Bech32 characters (130
> bits of data) from the 128-bit master seed.
>
> Master secret (hex): <code>ffeeddccbbaa99887766554433221100</code>
>
> Secret share with index <code>s</code>:
> <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln</code>
>
> Share with index <code>a</code>:
> <code>ms13casha320zyxwvutsrqpnmlkjhgfedca2a8d0zehn8a0t</code>
>
> Share with index <code>c</code>:
> <code>ms13cashcacdefghjklmnpqrstuvwxyz023949xq35my48dr</code>
>
> * Derived share with index <code>d</code>:
> <code>ms13cashd0wsedstcdcts64cd7wvy4m90lm28w4ffupqs7rm</code>
> * Derived share with index <code>e</code>:
> <code>ms13casheekgpemxzshcrmqhaydlp6yhms3ws7320xyxsar9</code>
> * Derived share with index <code>f</code>:
> <code>ms13cashf8jh6sdrkpyrsp5ut94pj8ktehhw2hfvyrj48704</code>
>
> Any three of the five shares among <code>acdef</code> can be used to
> recover the secret.
>
> Note that the choice to append two zero bits was arbitrary, and any of the
> following four secret shares would have been valid choices.
> However, each choice would have resulted in a different set of derived
> shares.
>
> * <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln</code>
> * <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qpte35dvzkjpt0r</code>
> * <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qzfatvdwq5692k6</code>
> * <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qrsx6ydhed97jx2</code>
>
> ===Test vector 4===
>
> This example shows converting a 256-bit secret into a codex32 secret,
> without splitting the secret into any shares.
> We appended four zero bits in order to obtain 52 Bech32 characters (260
> bits of data) from the 256-bit secret.
>
> 256-bit secret (hex):
> <code>ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100</code>
>
> * codex32 secret:
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma</code>
>
> Note that the choice to append four zero bits was arbitrary, and any of
> the following sixteen codex32 secrets would have been valid:
>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqpj82dp34u6lqtd</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqzsrs4pnh7jmpj5</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqrfcpap2w8dqezy</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqy5tdvphn6znrf0</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq9dsuypw2ragmel</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqx05xupvgp4v6qx</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq8k0h5p43c2hzsk</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqgum7hplmjtr8ks</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqf9q0lpxzt5clxq</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq28y48pyqfuu7le</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqt7ly0paesr8x0f</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqvrvg7pqydv5uyz</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqd6hekpea5n0y5j</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqwcnrwpmlkmt9dt</code>
> *
> <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq0pgjxpzx0ysaam</code>
>
> ===Test vector 5===
>
> This example shows generating a new 512-bit master seed using "random"
> codex32 characters and appending a checksum.
> The payload contains 103 Bech32 characters, which corresponds to 515 bits.
> The last three bits are discarded when converting to a 512-bit master seed.
>
> This is an example of a '''Long codex32 String'''.
>
> * Secret share with index <code>S</code>:
> <code>MS100C8VSM32ZXFGUHPCHTLUPZRY9X8GF2TVDW0S3JN54KHCE6MUA7LQPZYGSFJD6AN074RXVCEMLH8WU3TK925ACDEFGHJKLMNPQRSTUVWXY06FHPV80UNDVARHRAK</code>
> * Master secret (hex):
> <code>dc5423251cb87175ff8110c8531d0952d8d73e1194e95b5f19d6f9df7c01111104c9baecdfea8cccc677fb9ddc8aec5553b86e528bcadfdcc201c17c638c47e9</code>
>
> ==Appendix==
>
> ===Mathematical Companion===
>
> Below we use the Bech32 character set to denote values in GF[32].
> In Bech32, the letter <code>Q</code> denotes zero and the letter
> <code>P</code> denotes one.
> The digits <code>0</code> and <code>2</code> through <code>9</code> do
> ''not'' denote their numeric values.
> They are simply elements of GF[32].
>
> The generating polynomial for our BCH code is as follows.
>
> We extend GF[32] to GF[1024] by adjoining a primitive cube root of unity,
> <code>ζ</code>, satisfying <code>ζ^2 = ζ + P</code>.
>
> We select <code>β := G ζ</code> which has order 93, and construct the
> product <code>(x - β^i)</code> for <code>i</code> in <code>{17, 20, 46, 49,
> 52, 77, 78, 79, 80, 81, 82, 83, 84}</code>.
> The resulting polynomial is our generating polynomial for our 13 character
> checksum:
>
> x^13 + E x^12 + M x^11 + 3 x^10 + G x^9 + Q x^8 + E x^7 + E x^6 + E
> x^5 + L x^4 + M x^3 + C x^2 + S x + S
>
> For our long checksum, we select <code>γ := E + X ζ</code>, which has
> order 1023, and construct the product <code>(x - γ^i)</code> for
> <code>i</code> in <code>{32, 64, 96, 895, 927, 959, 991, 1019, 1020, 1021,
> 1022, 1023, 1024, 1025, 1026}</code>.
> The resulting polynomial is our generating polynomial for our 15 character
> checksum for long strings:
>
> x^15 + 0 x^14 + 2 x^13 + E x^12 + 6 x^11 + F x^10 + E x^9 + 4 x^8 + X
> x^7 + H x^6 + 4 x^5 + X x^4 + 9 x^3 + K x^2 + Y x^1 + H
>
> (Reminder: the character <code>0</code> does ''not'' denote the zero of
> the field.)
>
> -----END BIP-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--
Best Regards / S pozdravom,

Pavol "Stick" Rusnak
Co-Founder, SatoshiLabs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230216/d2e67885/attachment-0001.html>;

📅 Original date posted:2022-08-24 📝 Original message:There ...

2023-06-08T01:13:04+02:00

In reply to nevent1q…3yq4
_________________________

📅 Original date posted:2022-08-24
📝 Original message:There is already a JSON standard that has been already used in the wild for
the last 7 years described in SLIP-0015 (mentioned by Clark in this
thread). No need to reinventing the wheel again.

On Wed 24. 8. 2022 at 21:44, Ryan Havar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I'd strongly suggest not using CSV. Especially for a standard. I've worked
> with it as an interchange format many a times, and it's always been a
> clusterfuck.
>
> Right off the bat, you have stuff like "The fields may be quoted, but this
> is unnecessary as the first comma in the line will always be the delimiter"
> which invariably leads to some implementations doing it, some
> implementations not doing it, and others that are intolerant of the other
> way.
>
> And you have also made the classic mistake of not strictly defining escape
> rules. So everyone will pick their own (e.g. some will \, escape commas,
> others will not cause it's quoted and escape quotes, and others will assume
> no escaping is required since its the last column in a csv).
>
> Over time it morphs into its own mini-monster that introduces so much pain.
>
> On a similar note, allowing alternatives (like: txid>index vs txid:index)
> provides no benefit, but creates additional work for implementations (who
> quite likely only test formats they produce) and future incompatibilities.
>
> I know everyone loves to hate on it, but really (line-separated?) json is
> the way to go.
>
> { "tx": "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎",
> "label": "wow, such label" }
> { "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b",
> "txout": 4, "label": "omg this is so easy to parse" }
> { "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b",
> "txin": 0, "label": "wow this is going to be extensible as well" }
>
>
>
>
> -Ryan
>
> ------- Original Message -------
>
> On Wednesday, August 24th, 2022 at 2:18 AM, Craig Raw via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> I would like to propose a BIP that specifies a format for the export and
> import of labels from a wallet. While transferring access to funds across
> wallet applications has been made simple through standards such as BIP39,
> wallet labels remain siloed and difficult to extract despite their value,
> particularly in a privacy context.
>
> The proposed format is a simple two column CSV file, with the reference to
> a transaction, address, input or output in the first column, and the label
> in the second column. CSV was chosen for its wide accessibility, especially
> to users without specific technical expertise. Similarly, the CSV file may
> be compressed using the ZIP format, and optionally encrypted using AES.
>
> The full text of the BIP can be found at
> https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki
> and also copied below.
>
> Feedback is appreciated.
>
> Thanks,
> Craig Raw
>
> ---
>
> <pre>
> BIP: wallet-labels
> Layer: Applications
> Title: Wallet Labels Export Format
> Author: Craig Raw <craig at sparrowwallet.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels
> Status: Draft
> Type: Informational
> Created: 2022-08-23
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This document specifies a format for the export of labels that may be
> attached to the transactions, addresses, input and outputs in a wallet.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> The export and import of funds across different Bitcoin wallet
> applications is well defined through standards such as BIP39, BIP32, BIP44
> etc.
> These standards are well supported and allow users to move easily between
> different wallets.
> There is, however, no defined standard to transfer any labels the user may
> have applied to the transactions, addresses, inputs or outputs in their
> wallet.
> The UTXO model that Bitcoin uses makes these labels particularly valuable
> as they may indicate the source of funds, whether received externally or as
> a result of change from a prior transaction.
> In both cases, care must be taken when spending to avoid undesirable leaks
> of private information.
> Labels provide valuable guidance in this regard, and have even become
> mandatory when spending in several Bitcoin wallets.
> Allowing users to export their labels in a standardized way ensures that
> they do not experience lock-in to a particular wallet application.
> In addition, by using common formats, this BIP seeks to make manual or
> bulk management of labels accessible to users without specific technical
> expertise.
>
> ==Specification==
>
> In order to make the import and export of labels as widely accessible as
> possible, this BIP uses the comma separated values (CSV) format, which is
> widely supported by consumer, business, and scientific applications.
> Although the technical specification of CSV in RFC4180 is not always
> followed, the application of the format in this BIP is simple enough that
> compatibility should not present a problem.
> Moreover, the simplicity and forgiving nature of CSV (over for example
> JSON) lends itself well to bulk label editing using spreadsheet and text
> editing tools.
>
> A CSV export of labels from a wallet must be a UTF-8 encoded text file,
> containing one record per line, with records containing two fields
> delimited by a comma.
> The fields may be quoted, but this is unnecessary, as the first comma in
> the line will always be the delimiter.
> The first line in the file is a header, and should be ignored on import.
> Thereafter, each line represents a record that refers to a label applied
> in the wallet.
> The order in which these records appear is not defined.
>
> The first field in the record contains a reference to the transaction,
> address, input or output in the wallet.
> This is specified as one of the following:
> * Transaction ID (<tt>txid</tt>)
> * Address
> * Input (rendered as <tt>txid<index</tt>)
> * Output (rendered as <tt>txid>index</tt> or <tt>txid:index</tt>)
>
> The second field contains the label applied to the reference.
> Exporting applications may omit records with no labels or labels of zero
> length.
> Files exported should use the <tt>.csv</tt> file extension.
>
> In order to reduce file size while retaining wide accessibility, the CSV
> file may be compressed using the ZIP file format, using the <tt>.zip</tt>
> file extension.
> This <tt>.zip</tt> file may optionally be encrypted using either AES-128
> or AES-256 encryption, which is supported by numerous applications
> including Winzip and 7-zip.
> In order to ensure that weak encryption does not proliferate, importers
> following this standard must refuse to import <tt>.zip</tt> files encrypted
> with the weaker Zip 2.0 standard.
> The textual representation of the wallet's extended public key (as defined
> by BIP32, with an <tt>xpub</tt> header) should be used as the password.
>
> ==Importing==
>
> When importing, a naive algorithm may simply match against any reference,
> but it is possible to disambiguate between transactions, addresses, inputs
> and outputs.
> For example in the following pseudocode:
> <pre>
> if reference length < 64
> Set address label
> else if reference length == 64
> Set transaction label
> else if reference contains '<'
> Set input label
> else
> Set output label
> </pre>
>
> Importing applications may truncate labels if necessary.
>
> ==Test Vectors==
>
> The following fragment represents a wallet label export:
> <pre>
> Reference,Label
>
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎,Transaction
> 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎<0,Input
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎>0,Output
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎:0,Output
> (alternative)
> </pre>
>
> ==Reference Implementation==
>
> TBD
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-Founder, SatoshiLabs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220824/36ce85ba/attachment-0001.html>;

📅 Original date posted:2021-02-11 📝 Original message:> ...

2023-06-07T20:28:33+02:00

In reply to nevent1q…32jt
_________________________

📅 Original date posted:2021-02-11
📝 Original message:> ENCRYPTION_KEY = SHA256(SHA256(TOKEN))

This scheme might be vulnerable to rainbow table attack.

The following scheme might be more secure:

DESCRIPTION = ASCII description provided by user
NONCE = 256-bit random number
ENCRYPTION_KEY = hmac-sha256(key=NONCE, msg=DESCRIPTION)

Coordinator distributes DESCRIPTION (fka TOKEN) together with NONCE to the
signers.

Also, is there any reason why you'd want to disable encryption? Why not
keep that as mandatory?

On Tue, 9 Feb 2021 at 12:39, Hugo Nguyen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
>
> On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen <
> ChristopherA at lifewithalacrity.com> wrote:
>
>>
>>
>> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen <hugo at nunchuk.io> wrote:
>>
>>>
>>> I don't think reusing XPUBs inside different multisig wallets is a good
>>> idea... For starters, loss of privacy in one wallet will immediately affect
>>> privacy of other wallets. I think multisig wallets should be completely
>>> firewalled from each other. That means one unique XPUB per wallet. This is
>>> what we have been doing with the Nunchuk wallet.
>>>
>>
>> To be clear, I have stated repeatedly that xpub reuse into multisig is a
>> poor practice. However, finding a trustless solution when a wallet is
>> airgapped with no network, or is stateless like Trezor, is quite hard.
>>
>> The challenge also includes how does an airgapped or stateless wallet
>> know that it is talking to the same process on the other side that that it
>> gave the xpub to in the first place. Without state to allow for a
>> commitment, or at least a TOFU, a cosigner who thought he was part of a 3
>> of 5 could discover that he instead is in a 2 of 3, or in a script with an
>> OR, as some form of scam.
>>
>
> The shared secret approach that I mentioned in the proposal actually can
> help you here. The TOKEN doubles as a session ID - thereby establishing a
> common state on both sides.
>
> Best,
> Hugo
>
>
>>
>> — Christopher Allen
>>
>>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210211/9aae5cfa/attachment.html>;

📅 Original date posted:2018-12-23 📝 Original message:On ...

2023-06-07T20:15:51+02:00

In reply to nevent1q…z7hs
_________________________

📅 Original date posted:2018-12-23
📝 Original message:On 22/12/2018 00:58, Aymeric Vitte via bitcoin-dev wrote:
> Has anybody already looked at this: given N randomly chosen words
> belonging to a BIP39 2048 words dictionary, what is the probability to
> get a "valid" BIP39 seed (ie with the right checksum)?

1:256 for 24 words
1:16 for 12 words

This ratio is not too great and will be improved in the upcoming SLIP39
standard: https://github.com/satoshilabs/slips/blob/master/slip-0039.md

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

📅 Original date posted:2018-01-11 📝 Original message:On ...

2023-06-07T20:09:31+02:00

In reply to nevent1q…009j
_________________________

📅 Original date posted:2018-01-11
📝 Original message:On 11/01/18 00:47, Gregory Maxwell wrote:
> I believe that can be avoided by having the computer do somewhat more
> work and checking the consistency after the fact.
>
> (or for decode time, having a check value under the encryption...)

Can you describe these two methods more in detail? How exactly would
they work? What crypto primitives would you use and how?

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

📅 Original date posted:2018-01-10 📝 Original message:On ...

2023-06-07T20:09:30+02:00

In reply to nevent1q…cprm
_________________________

📅 Original date posted:2018-01-10
📝 Original message:On 09/01/18 16:12, Pavol Rusnak via bitcoin-dev wrote:
> On 09/01/18 00:47, Gregory Maxwell wrote:
>> Have you considered using blind host-delegated KDFs, where the KDF
>> runs on the user's computer instead of the hardware wallet, but the
>> computer doesn't learn anything about they keys?
>
> Any examples of these?

Actually, scratch that. HW wallet would not know whether the host
computer is lying or not. The computer would not learn about the keys,
but still could be malicious and provide invalid result. Is that correct?

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

📅 Original date posted:2018-01-08 📝 Original message:On ...

2023-06-07T20:09:27+02:00

In reply to nevent1q…45qg
_________________________

📅 Original date posted:2018-01-08
📝 Original message:On 08/01/18 13:45, Peter Todd wrote:
> Can you explain _exactly_ what scenario the "plausible deniability" feature
> refers to?

https://doc.satoshilabs.com/trezor-user/advanced_settings.html#multi-passphrase-encryption-hidden-wallets

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180108/41cd23c4/attachment.sig>;

📅 Original date posted:2018-01-08 📝 Original message:On ...

2023-06-07T20:09:26+02:00

In reply to nevent1q…gph5
_________________________

📅 Original date posted:2018-01-08
📝 Original message:On 08/01/18 05:22, Gregory Maxwell wrote:
>> https://github.com/satoshilabs/slips/blob/master/slip-0039.md

Hey Gregory!

Thanks for looking into the scheme. I appreciate your time!

> This specification forces the key being used through a one way
> function, -- so you cannot take a pre-existing key and encode it with
> this scheme.

Originally, we used a bi-directional function to be able to encode and
decode the key in both directions using the passphrase. We stretched the
passphrase using KDF and then applied AES or other symmetric cipher

We found the following (theoretical) problem:

If an attacker has knowledge of few words from the beginning of shares,
they are able to reconstruct the beginning of the master secret and if
the size of the reconstruced master secret is bigger then the cipher
blocksize (for block ciphers; for stream ciphers 1 bit is enough), then
they can reconstruct the beginning of the seed.

Can you find a scheme which does not have this problem? Or you think
this problem is not worth solving?

> The KDF it specifies is unconfigurable and fairly weak
> (20000xhmac-sha2-- which can be cracked at about 0.7M passwords a
> second on a single motherboard GPU cracker).

Yes. We want this to be possible to be computed on TREZOR-like devices
on boot, similarly how we compute BIP39 on boot right now.

> The construction also
> will silently result in the user getting a different private key if
> they enter the wrong passphrase-- which could lead to funds loss.

Again, this is by design and it is main point why plausible deniability
is achieved both in BIP39 and SLIP39. If we used a different
construction we'd loose plausible deniability.

> It
> is again, unversioned-- so it kinda of seems like it is intentionally
> constructed in a way that will prevent interoperable use, since the
> lack of versioning was a primary complaint from other perspective
> users. Of course, it fine if you want to make a trezor only thing,
> but why bother BIPing something that was not intended for
> interoperability? Even for a single vendor spec the lack of
> versioning seems to make things harder to support new key-related
> features such as segwit.

This is argument I keep having all the time.

Suppose we'd introduce a version to encode PBKDF2 rounds or even
different KDFs. We'll end up with different SLIP39 mnemonics, but they
will not be compatible among implementations (because TREZOR can only up
to 100.000 rounds of PBKDF2 and does not support Argon2 at all, while
other desktop implementation would rather use memory-hard Argon2).

My gut feeling is that this would lead to WORSE interoperability, not
better. Look at BIP32 for example. There are lots of wallet that claim
they are BIP32 compatible, but in reality they use different paths, so
they are not compatible. BIP32 is a good standard, but in reality
"BIP32-compatible" does not mean anything, whereas when you say the
wallet is "BIP44-compatible" you can be sure the migration path works.

> The 16-bit "checksum" based on sha2 seems pretty poor since basing
> small checksums on a cryptographic hash results in a fairly poor
> checksum that is surprisingly likely to accept an errored string. Your
> wordlist is 10 bits and you have much less than 1023*10 bits of input,
> so you could easily have a 20 bit code (two words) which guaranteed
> that up to two errored words would always be detected, and probably
> could choose one which catches three words much more often 1:2^20
> (sipa's crc tools can help find codes like this).

Originally, we wanted to use 16-bit of CRC32 for checksum, but after the
discussion with Daan Sprenkels we were suggested to change this for
cryptographically strong function. The argument was that CRC32 contains
less entropy and mixing high-entropy data (secret) with low-entropy data
(checksum) is not a good idea.

Also, there is an argument between a checksum and ECC. We discussed that
ECC might not be a good idea, because it helps the attacker to compute
missing information, while we only want to check for integrity. Also the
word mnemonic is itself a ECC, because if you see the word "acadornic"
it is probably the word "academic".

> The metadata seems to make fairly little affordance to help users
> avoid accidentally mixing shares from distinct sharings of the same
> key. Is it the idea that this is the only likely cause of a checksum
> error? (1:2^16 chance of silently returning the wrong key seems kinda
> bad). -- I'm not sure much could be done here, though, since
> additional payload is precious.

Yes, checksum is supposed to prevent that.

> As an aside, your specification might want to give some better advice
> about the SSS since my experience virtually everyone gets it wrong in
> ways that degrade or destroy its properties e.g. many fail to generate
> the additional coefficients of the polynominal randomly which results
> in insecurity (see armory for an example). Oh, also, I believe it is
> normally refereed to as "SSS" (three S)-- four S is the name of a
> linux program for secret sharing.

Will fix the spelling. About the generic advice about SSS, anyone is
welcome to contribute to the text.

> I'm happy to see that there is no obvious way to abuse this one as a
> brainwallet scheme!

Agreed!

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

📅 Original date posted:2018-01-07 📝 Original message:On ...

2023-06-07T20:09:16+02:00

In reply to nevent1q…5l8s
_________________________

📅 Original date posted:2018-01-07
📝 Original message:On 05/01/18 14:58, nullius via bitcoin-dev wrote:
> I propose and request as an enhancement that the BIP 39 wordlist set
> should specify canonical native language strings to identify each
> wordlist, as well as short ASCII language codes. At present, the
> languages are identified only by their names in English.

I am advising not to use any other language than English for BIP39. I
got persuaded to allow more languages when writing BIP39 spec, but I
learned that it was something I should've been more persistently against.

I am currently drafting a new standard[1] which will allow also Shamir
Secret Scheme Splitting and there we disallow usage of a custom wordlist
in order to eradicate this mess. Will try to push this as BIP too once
we get it to the point we are OK with the contents.

https://github.com/satoshilabs/slips/blob/master/slip-0039.md

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180107/8eef9b25/attachment.sig>;

📅 Original date posted:2017-09-06 📝 Original message:On ...

2023-06-07T20:05:22+02:00

In reply to nevent1q…ched
_________________________

📅 Original date posted:2017-09-06
📝 Original message:On 05/09/17 19:03, Luke Dashjr via bitcoin-dev wrote:
> I think it makes more sense to use a child number field for this purpose.
> It seems desirable to use the same seed for all different script formats...

If I were designing the serialization format today, I would drop the
fingerprint and expand child number to full BIP32 path. Good thing is
that we already have depth, so we know how long the BIP32 path would be.

So I suggest the following:

4 byte: version bytes
1 byte: depth
depth * 4 bytes: bip32 path
32 bytes
33 bytes

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

📅 Original date posted:2017-09-05 📝 Original message:On ...

2023-06-07T20:05:16+02:00

In reply to nevent1q…en03
_________________________

📅 Original date posted:2017-09-05
📝 Original message:On 05/09/17 09:10, shiva sitamraju via bitcoin-dev wrote:
> 0x042393df , sxpr , segwit mainnet private key
> 0x04239377 , sxpb , segwit mainnet public key
> 0x04222463 , stpb , segwit testnet public key
> 0x042224cc , stpr , segwit testnet private key

I am fine with both your proposal and proposal from Thomas
({x,y,z}{pub,prv}).

Let's just decide ASAP which one we'll use.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

📅 Original date posted:2016-08-16 📝 Original message:On ...

2023-06-07T19:52:48+02:00

In reply to nevent1q…khnl
_________________________

📅 Original date posted:2016-08-16
📝 Original message:On 16/08/16 17:13, Jonas Schnelli wrote:
> I'm aware of this approach but I don't think this makes sense long term.
> We need a better way on the protocol level to validate inputs amounts
> (where segwit is a first step towards this).

So you basically rephrased what I am saying but in another words.

> I think we should collaborate together and work out a standard.

I am for it. I am just saying we should create a standard for new forms
of transactions (Segwit and maybe Lightning), not the current "ugly" ones.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/07dddfef/attachment.sig>;

📅 Original date posted:2016-05-13 📝 Original message:On ...

2023-06-07T19:50:41+02:00

In reply to nevent1q…9awq
_________________________

📅 Original date posted:2016-05-13
📝 Original message:On 13/05/16 18:59, Aaron Voisine wrote:
> This scheme is independent of the number of accounts. It works with BIP44
> as well as BIP43 purpose 0, or any other BIP43 purpose/layout. Instead of
> overloading the account index to indicate the type of address, you use the
> chain index, which is already being used to indicate what the specific
> address chain is to be used for, i.e. receive vs change addresses.

I see the advantage here. But there is a major problem here.

We came up with BIP44 so a wallet can claim it is BIP44 compatible and
you can be 100% sure that you can migrate accounts from one wallet
implementation to another. This was not previously possible when a
wallet claimed it is BIP32 compatible.

Now we have a similar problem. When there is a BIP44 wallet, does it
mean it supports segwit or not? For this reason I would like to see
another BIPXX for segwit, so a wallet can claim it is BIP44, BIP44+BIPXX
or BIPXX compatible and you'll know what other wallets are compatible
with it.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com

📅 Original date posted:2016-05-13 📝 Original message:On ...

2023-06-07T19:50:41+02:00

In reply to nevent1q…5skr
_________________________

📅 Original date posted:2016-05-13
📝 Original message:On 13/05/16 18:03, Aaron Voisine wrote:
> I like the idea of specifying the type of address as a bit field flag.
> 0x80000000 is already used to specify hardened derivation, so 0x40000000
> would be the next available to specify witness addresses. This is
> compatible with existing accounts and wallet layouts.

I think this is over-optimization. What is the advantage of

m/0'/0x40000000 instead of m/whatever'/0 ?

But this is off-topic anyway, as we are discussing multiple-accounts per
wallet layout here, not one-account-per-wallet design.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com

📅 Original date posted:2016-05-13 📝 Original message:On ...

2023-06-07T19:50:40+02:00

In reply to nevent1q…6wpz
_________________________

📅 Original date posted:2016-05-13
📝 Original message:On 13/05/16 15:16, Daniel Weigl via bitcoin-dev wrote:
> 2) Define a new derivation path, parallel to Bip44, but a different 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44'). Let the user choose which account he want to add ("Normal account", "Witness account").

We had quite a long discussion in our team some time ago and we agreed
on that option #2 is much better and we'd like to implement this way in
myTREZOR.

> +) Wallet needs only to take care of 1 address per public key

True, if this BIP only supports P2WPKH.

P2WSH should probably be handled by another account type and another
BIP, anyway.

> Has any Bip44 compliant wallet already done any integration at this point?

We have something in the pipeline, but no visible results yet.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com

📅 Original date posted:2015-03-07 📝 Original message:On ...

2023-06-07T17:31:45+02:00

In reply to nevent1q…jucj
_________________________

📅 Original date posted:2015-03-07
📝 Original message:On 07/03/15 16:53, Mem Wallet wrote:
> this allows a user to manage a GPG identity for encryption
> and signing with zero bytes of permanent storage. (on tails for example)

Hi!

As an author of BIP44 I don't think that you should use BIP44 for this
and a new BIP number should be allocated. To me it does not make much
sense to create GPG key hierarchy per Bitcoin account, but rather create
a GPG key hierarchy per device/master seed.

I am currently in process of implementing a SignIdentity message for
TREZOR, which will be used for HTTPS/SSH/etc. logins.

See PoC here:
https://github.com/trezor/trezor-emu/commit/9f612c286cc7b8268ebaec4a36757e1c19548717

The idea is to derive the BIP32 path from HTTPS/SSH URI (by hashing it
and use m/46'/a'/b'/c'/d' where a,b,c,d are first 4*32 bits of the hash)
and use that to derive the private key. This scheme might work for GPG
keys (just use gpg://user@host.com for the URI) as well.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-08-08 📝 Original message:Hi ...

2023-06-07T17:25:07+02:00

In reply to nevent1q…gvp5
_________________________

📅 Original date posted:2014-08-08
📝 Original message:Hi all!

I would like to discuss invalidation of nodes in BIP32. Currently the
document says:

a) Public CKD

In case I_L >= n or ki = 0, the resulting key is invalid, and one should
proceed with the next value for i.

b) Private CKD

In case I_L >= n or Ki is the point at infinity, the resulting key is
invalid, and one should proceed with the next value for i.

c) Master Key Generation

In case IL is 0 or I_L >= n, the master key is invalid.

(All these cases have probability lower than 1 in 2^127.)

What do you think about the following change for all 3 cases:

In case I_L >= n assign I_L := I_L mod n.

Rationale:

It's easy to say "mark as invalid and proceed with next", but actually
most of the implementations don't do the checking at all, because tjen
it's rather hard at application level to implement skipping logic. OTOH
it's quite straightforward to perform modulo if needed, so we probably
see more implementations doing the checking.

We would still need to deal with cases when I_L = 0 or ki = 0 or ki =
inf, but these have probability around 1 in 2^255.

Does anyone see any concerns when it comes to security of the proposed
change?

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:18:01+02:00

In reply to nevent1q…lwuh
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 11:18 PM, Luke-Jr wrote:
> Only a very niche user base needs funds isolated...

Our users do and we are creating this BIP for them, because we love them. ;)

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:18:00+02:00

In reply to nevent1q…lpqd
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 11:42 PM, Pieter Wuille wrote:
> In that case, maybe it makes sense to define another purpose id
> without accounts as well already.
>
> I believe many simple wallets will find multiple subwallets too
> burdening for the user experience, or not worth the technical
> complexity.

Right. See my previous email where I describe hypothetical creation of
BIP65 and BIP66 which the exact thing you describe.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:18:00+02:00

In reply to nevent1q…2jz4
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
> Hopefully it would be clarified as only a MUST NOT do so silently...
> "I have funds split across two wallets and it WONT LET ME SPEND THEM"
> sounds like a terrible user experience. :)

That is a subjective matter. To me it makes PERFECT SENSE that funds
across accounts NEVER MIX. One can still send funds from one account to
another and then perform another spend.

That's what I consider a consistent and thus GOOD user experience.
What's the purpose of Accounts if wallet mixes coins among them anyway?

I know it's not good to use classic bank accounts as analogy, but that's
exactly how they work. Or have you every done ONE transaction from two
bank accounts simultaneously?

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:17:59+02:00

In reply to nevent1q…k4nt
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 10:54 PM, Pieter Wuille wrote:
> Would you consider software which scans all accounts as specified by
> BIP64, but has no user interface option to distinguish them in any
> way, view them independently, and has no ability to keep the coins
> apart... compatible with BIP64?

This is not a desired behavior. Do you have any idea how to make it even
more explicit in the spec? Currently we just have (in Account sectrion):

"This level splits the key space into independent user identities, so
the wallet never mixes the coins across different accounts."

I would like to make it obvious from the spec that if you mix funds
accross the accounts you are not doing a right thing and you are not
compliant to the spec.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:17:58+02:00

In reply to nevent1q…cs98
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 10:41 PM, Luke-Jr wrote:
> I don't see how. The user knows he has money in different subwallets. As long
> as he has a way to specify which subwallet he is accessing in single-subwallet
> clients, there shouldn't be a problem.

Right. But these clients have no right to call themselves BIP64
compatible then.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:17:58+02:00

In reply to nevent1q…0k6e
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 10:32 PM, Luke-Jr wrote:
> f) I missed the part where BIP 32 redefined "account" to mean "subwallet"
> instead of what has traditionally been called "account" in Bitcoin.

Ah, okay. The last time I saw Bitcoin-qt it was still using independent
addresses.

> In that case, single-subwallet wallet software probably needs to have the user
> provide a subwallet number in addition to the seed.

Which brings us back to my original complaint that the user can be
confused because he doesn't see all his funds.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:17:57+02:00

In reply to nevent1q…qt6z
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 10:01 PM, Luke-Jr wrote:
> Yes, it should scan all possible (under the BIP-defined structure) branches
> regardless of which features it supports.

So you suggest to scan for accounts, show balances but don't allow user
to spend them? Does not seem right to me.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:17:57+02:00

In reply to nevent1q…frc5
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 10:09 PM, Luke-Jr wrote:
> Scan all branches for UTXOs, then you have the balance for the wallet. Account
> balances are metadata, so cannot be known from the seed alone. If you want to
> have a way to restore accounts, you must define some more detailed wallet file
> format (which could be built on top of this).

I think one of the following is happening:

a) you have not read the document
b) you don't understand what accounts are, because you have not read
the document
c) you don't understand how restoring accounts work, because you
have not read the document
d) you don't understand that accounts funds are not meant to be mixed
together, because you have not read the document
e) I got your emails wrong because I am not a native speaker,
but please read the the document ;-)

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:17:56+02:00

In reply to nevent1q…k470
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 09:44 PM, Luke-Jr wrote:
> Why do clients need to use the features in BIP 64? If Electrum doesn't want to
> use accounts, then it can just use account 0 for everything. Refund chains are

As Andreas wrote earlier in this thread: "There is no "bare minimum".
Either you implement the "BIP" fully or not."

What you suggest does not follow the principle of least surprise.
Suppose user imports his BIP64 compatible wallet into Electrum, which
claims it is BIP64 compatible, but actually implements just a subset of
the spec (sticking account index to 0). The user now sees just a
fraction of his coins and is puzzled.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:17:55+02:00

In reply to nevent1q…t3r0
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 09:00 PM, Tier Nolan wrote:
> The point is to have a single system that is compatible over a large number
> of systems.

There is such system and it is called BIP32.

On the other hand, in BIP64 we try to put a set of restrictions and
rules on top of BIP32. There will always be some special usecases where
BIP64 is not a good fit and there's no reason why you cannot use BIP32
in a different manner using a different "purpose" field.

Examples: Electrum does not want to use accounts and they start to use
scheme m/65'/change/address (where change = 0 or 1). Or Andreas
Schildbach wants to have refunds chain so he uses m/66'/chain/address
(where chain = 0, 1 or 2).

We wanted to find one good solution that fits all, but unfortunately it
turned out everyone wants something a little bit different.

The point of the whole effort is that you can have ONE SINGLE BACKUP
(master node) for all these independent purposes and suddenly claims
such as "my wallet is BIP64 and BIP66 compatible" actually mean
something as opposed to "BIP32 compatible" which actually means nothing
except that the wallet author is capable of using HMAC in context of
generating the tree.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:17:53+02:00

In reply to nevent1q…4rq3
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 08:39 PM, Tier Nolan wrote:
> A merchant could easily send 20 addresses in a row to customers and none of
> them bother to actually buy anything.

Such merchant would surely use some merchant system instead of generic
wallet software.

> Setting the gap limit to high is just a small extra cost in that case.

Not if you have 100 accounts on 10 different devices.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-04-08 📝 Original message:On ...

2023-06-07T17:17:51+02:00

In reply to nevent1q…rm3d
_________________________

📅 Original date posted:2014-04-08
📝 Original message:On 04/08/2014 03:53 PM, Pieter Wuille wrote:
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string "Bitcoin
> seed" is replaced by something chain-specific.
> * Every encoded node (including master nodes) has a chain-specific
> serialization magic.

This is possible, but I find it much more practical to use just one list
(assignment of coins to indexes) than to use two lists (assignment of
coins to key strings and to serialization magic).

Keeping two lists is harder and adds unnecessary friction. (Also I am
not very happy for the possibility we'll have to deal with key strings
"sCAMCo1N RULEZZZZ!!!! bRoUghT TO YoU bY M4rty" and serialization magic
that leads to prefix "lulz").

Also from wallet's implementer perspective it is a little easier to use
just one root node and then descend in tree as needed than to use method
you described.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-03-27 📝 Original message:On ...

2023-06-07T17:16:24+02:00

In reply to nevent1q…ssd4
_________________________

📅 Original date posted:2014-03-27
📝 Original message:On 03/27/2014 02:53 PM, Thomas Voegtlin wrote:
> Note: Maybe we could just look at the first address of each account,
> instead of the first 10 ?

This is a possible optimization, but it adds unnecessary logic. Also it
does not decrease the number of required requests between a client and a
server (e.g. when backend sends responses in "bulks" of 10 addresses or
more).

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-03-27 📝 Original message:On ...

2023-06-07T17:16:19+02:00

In reply to nevent1q…skzw
_________________________

📅 Original date posted:2014-03-27
📝 Original message:On 03/27/2014 05:14 PM, Pieter Wuille wrote:
> That said, I'm not convinced about the extra layers. The "cointype" in
> my opinion isn't necessary inside the derivation. There is already
> support (4 bytes!) for magic bytes in the serialized form. Inside

Cointype in path is for separation purposes, not for identification.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-03-27 📝 Original message:On ...

2023-06-07T17:16:18+02:00

In reply to nevent1q…6mcn
_________________________

📅 Original date posted:2014-03-27
📝 Original message:On 03/27/2014 04:57 PM, Allen Piscitello wrote:
> Don't most of these coins have a magic number already assigned that is
> unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for
> Litecoin, etc...). This seems like a good candidate for identifying coins,
> and also supports Testnet cases well. Maybe there are some alts without
> such a magic number that might prevent that?

That magic number is something I find very unfortunate and superflous in
BIP-32 design. Its only purpose is to distinguish BIP-32 trees for
various altcoins, but it doesn't make sense at all once you start
storing various altcoins in the same tree using the proposed
/m/cointype/reserved'/account'/change/n scheme.

I would love to see that removed from BIP-32 and use always
0x0488B21E/0x0488ADE4 (xpub/xpriv), but that is for different discussion
I guess.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-03-27 📝 Original message:On ...

2023-06-07T17:16:17+02:00

In reply to nevent1q…3wlc
_________________________

📅 Original date posted:2014-03-27
📝 Original message:On 03/27/2014 08:09 AM, Tamas Blummer wrote:
> A notable suggestion was to instead of building a directory of magic numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin", "Litecoin", "Dogecoin", so collosion is unlikely and
> cetral directory is not needed.

Nice idea, but keep in mind that you are hashing into 2^32 space, so
collisions will occur, unfortunately and we'll end up with directory
again :-/

Even if they did not occur you would need to keep up the registry of
names anyway (is it Peercoin or PPCoin, Testnet or TestNet ...)?

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-03-12 📝 Original message:On ...

2023-06-07T17:15:13+02:00

In reply to nevent1q…57du
_________________________

📅 Original date posted:2014-03-12
📝 Original message:On 03/12/2014 04:17 AM, Jean-Paul Kogelman wrote:
> We've been hard at work updating the spec to include features that were requested. We've removed the Scrypt dependency that was present in the initial drafts, added new KDFs, added plausible deniability and have a reference implementation.

Are you aware of BIP-0039?

https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-03-12 📝 Original message:On ...

2023-06-07T17:15:13+02:00

In reply to nevent1q…vys7
_________________________

📅 Original date posted:2014-03-12
📝 Original message:On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:
> Yes I am. There are some differences between BIP 39 and my proposal though.
>
> - BIP 39 offers an easy list of words, no gnarly string of case sensitive letters and numbers.

Which is better IMO. I can't imagine anyone writing down a long Base58
encoded string.

> - BIP 39 only offers one fixed length of entropy, always 12 words, no option to increase or decrease the length.

Not true, BIP39 supports 12/18/24 words (= 128/192/256 bits of entropy).

> - BIP 39 doesn't have a genesis date field, so no optimization during blockchain rescan.

This is nice addition, indeed. But we needed to limit the data as
possible in order not to increase the number of words needed to be noted
down.

> - BIP 39 doesn't have password typo detection. No easy way to recover a password if you know most of it.

It has a detection. Not correction though.

> - BIP 39 does not have a user selectable KDF, only 2048 round PBKDF2-HMAC-SHA512.
> - BIP 39 can't outsource the KDF computation to a 3rd party.

True, but having one or two solid options are better than having
gazillions of possible options.

> - BIP 39 wallet implementors can use their own word lists, breaking cross wallet compatibility.

True, but they are encouraged to use the list provided. Possibility to
outsource KDF outside of your "standard" breaks much more compatibility
than this.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2013-10-19 📝 Original message:On ...

2023-06-07T17:07:31+02:00

In reply to nevent1q…pq4h
_________________________

📅 Original date posted:2013-10-19
📝 Original message:On 19/10/13 01:58, Gregory Maxwell wrote:
> https://people.xiph.org/~greg/wordlist.visual.py

>> I've included the search utility I used below.

Yeah, there are lots of tools on the Internet. Posting links to them is
not helping. Sending pull requests with particular changesets with
explanation is. Well, or rather was. I think we are past the point where
it was wise to introduce changes to the word list ... (especially when
50 people have 51 different opinions on this topic)

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>