Nostr notes by Pavol Rusnak [ARCHIVE]

📅 Original date posted:2020-02-02 📝 Original message: Hi ...

2023-06-09T12:58:29Z

In reply to nevent1q…jc7t
_________________________

📅 Original date posted:2020-02-02
📝 Original message:
Hi all!

I have a couple of unrelated questions, hope you can give me some pointers.

1) Is c-lightning going to support Sphinx or other form of spontaneous
payments?

2) Can a lightning node (such as lnd or c-lightning) send a push
notification (e.g. to a webhook) when it receives or routes a payment? If
yes, is this notification cryptographically signed (for example with the
node's private key)? Is this documented somewhere?

Thanks!

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200202/1528e829/attachment.html>;

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

2023-06-09T12:53:35Z

In reply to nevent1q…5q2e
_________________________

📅 Original date posted:2018-12-23
📝 Original message:
Hi all!

Currently, when I perform a payment via QR code, I usually check the
payee node id (public key) in the send dialog. However, this is a rather
long hex value, so for example Eclair app shows just the beginning and
the end of the value.

Idea: Can we show an identicon (for example https://jdenticon.com/) of
payee node id (= public key) next to the QR code, so user can visually
quickly check whether the recipient is correct?

We'd need to add this to UI of all Lightning user-facing wallets to make
sense, though.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

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

2023-06-07T23:19:40Z

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-07T23:13:04Z

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:2022-08-05 📝 Original message:Hi ...

2023-06-07T23:12:30Z

In reply to nevent1q…7n9w
_________________________

📅 Original date posted:2022-08-05
📝 Original message:Hi Ali!

Nice work. Since it seems this is a strict superset of BIP137, why not just
focus on things that you are adding (Taproot) while saying your BIP is an
expansion of BIP137?

Your approach make it unnecessarily hard to figure out whether you are
changing anything in handling of ECDSA signature types or not. If it was
clearly stated you are just expanding BIP137 and removes everything that’s
already described in BIP137, it would be much more obvious to everyone.

On Thu 4. 8. 2022 at 17:49, Ali Sherief via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi,
>
> I have created a new BIP, called notatether-signedmessage. It can be
> viewed at
> https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawiki
> .
>
> For those who want a quick summary, it defines a step-by-step process for
> signing and verifying messages from legacy, native/nested segwit, and
> taproot addresses. It does not define a new signature format itself, except
> in the case of Taproot. For those addresses, I have defined a signature
> format that has 1 byte header/recID, 64 bytes signature, and 32 bytes x
> coordinate of a public key. This is required to run the BIP340 Schnorr
> verify algorithm using only the signature - and the header byte is added
> for backwards compatibility. Otherwise, it completely integrates BIP137
> signatures.
>
> I am planning to move that format to its own BIP as soon as possible, in
> lieu that it is unacceptable to define formats in an Informational BIP.
>
> Please leave your comments in this mailing list. CC'ing BIP editors.
>
> - Ali
>
> _______________________________________________
> 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/20220805/a38c1a1d/attachment-0001.html>;

📅 Original date posted:2022-07-27 📝 Original message:On ...

2023-06-07T23:12:16Z

In reply to nevent1q…rwmr
_________________________

📅 Original date posted:2022-07-27
📝 Original message:On Wed, 27 Jul 2022 at 00:28, Andrew Chow <achow101-lists at achow101.com>
wrote:

> However I don't see why this couldn't generalize to any sized tuples. As
> long as the tuples are all the same length, and the limit is one tuple per
> key expression, then we don't get any combinatorial blowup issues.
>

I think it's worthwhile to generalize for any sized tuples. I don't have
any existing particular use case in mind, because BIP-44, BIP-84, etc. are
fine with just using <0;1>, but there might be some upcoming standards in
the future that will want to introduce more sub-paths.

--
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/20220727/d71a012a/attachment.html>;

📅 Original date posted:2022-07-26 📝 Original message:Thanks ...

2023-06-07T23:12:15Z

In reply to nevent1q…mkux
_________________________

📅 Original date posted:2022-07-26
📝 Original message:Thanks Andrew for this BIP. We've been already using this for quite some
time for Trezor in production.

Just one clarification: Should <NUM;NUM;NUM>, <NUM;NUM;NUM;NUM>, ... also
work or we only aim to support only tuples of exactly two values?

On Tue, 26 Jul 2022 at 23:51, Andrew Chow via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi All,
>
> I would like to propose a BIP that de-duplicates and simplifies how we
> represent descriptors for receiving and change addresses. Under the
> existing BIPs, this requires two descriptors, where the vast majority of
> the descriptors are the same, except for a single derivation path
> element. This proposal allows descriptors to have a single derivation
> path element that can specify a pair of indexes. Parsers would then
> expand these into two almost identical descriptors with the difference
> being that the first uses the first of the pair of indexes, and the
> second uses the second.
>
> The proposed notation is `<a;b>`. As an example,
> `wpkh(xpub.../0/<0;1>/*)` would be expanded into `wpkh(xpub.../0/0/*)`
> and `wpkh(xpub.../0/1/*)`.
>
> This also works for descriptors involving multiple keys - the first
> element in every pair is used for the first descriptor, and the second
> element of each pair in the second descriptor.
>
> The full text of the BIP can be found at
>
> https://github.com/achow101/bips/blob/bip-multipath-descs/bip-multipath-descs.mediawiki
> and also copied below. An implementation of it to Bitcoin Core is
> available at https://github.com/bitcoin/bitcoin/pull/22838.
>
> Any feedback on this would be appreciated.
>
> Thanks,
> Andrew Chow
>
> ---
>
> <pre>
> BIP: multipath-descs
> Layer: Applications
> Title: Multipath Descriptor Key Expressions
> Author: Andrew Chow <andrew at achow101.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-multipath-descs
> Status: Draft
> Type: Informational
> Created: 2022-07-26
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This document specifies a modification to Key Expressions of Descriptors
> that are described in BIP 380.
> This modification allows Key Expressions to indicate BIP 32 derivation
> path steps that can have multiple values.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Descriptors can describe the scripts that are used in a wallet, but
> wallets often require at least two descriptors for all of the scripts
> that they watch for.
> Wallets typically have one descriptor for producing receiving addresses,
> and the other for change addresses.
> These descriptors are often extremely similar - they produce the same
> types of scripts, derive keys from the same master key, and use
> derivation paths that are almost identical.
> The only differences are in the derivation path where one of the steps
> will be different between the descriptors.
> Thus it is useful to have a notation to represent both descriptors as a
> single descriptor where one of the derivation steps is a pair of values.
>
> ==Specification==
>
> For extended keys and their derivations paths in a Key Expression, BIP
> 380 states:
>
> * <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
> extended private key (as defined in BIP 32)
> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
> step to denote all direct unhardened or hardened children.
>
> This is modifed to state:
>
> * <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
> extended private key (as defined in BIP 32)
> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Followed by zero or one <tt>/<NUM;NUM></tt> (<tt>NUM</tt> may be
> followed by <tt>h</tt> to indicated a hardened step) path element
> indicating a pair of BIP 32 derivation steps to be taken after the given
> extended key.
> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
> step to denote all direct unhardened or hardened children.
>
> When a <tt>/<NUM;NUM></tt> is encountered, parsers should produce two
> descriptors where the first descriptor uses the first <tt>NUM</tt>, and
> a second descriptor uses the second <tt>NUM</tt>.
>
> The common use case for this is to represent descriptors for producing
> receiving and change addresses.
> When interpreting for this use case, wallets should use the first
> descriptor for producing receiving addresses, and the second descriptor
> for producing change addresses.
> For this use case, the element will commonly be the value <tt>/<0;1></tt>
>
> ==Test Vectors==
>
> TBD
>
> ==Backwards Compatibility==
>
> This is an addition to the Key Expressions defined in BIP 380.
> Key Expressions using the format described in BIP 380 are compatible
> with this modification and parsers that implement this will still be
> able to parse such descriptors.
> However as this is an addition to Key Expressions, older parsers will
> not be able to understand such descriptors.
>
> This modification to Key Expressions uses two new characters: <tt><</tt>
> and <tt>;</tt>.
> These are part of the descriptor character set and so are covered by the
> checksum algorithm.
> As these are previously unused characters, old parsers will not
> accidentally mistake them for indicating something else.
>
> ==Reference Implementation==
>
> https://github.com/bitcoin/bitcoin/pull/22838
>
>
> _______________________________________________
> 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/20220726/cef0a54a/attachment-0001.html>;

📅 Original date posted:2022-07-07 📝 Original message:There ...

2023-06-07T23:11:15Z

In reply to nevent1q…yerl
_________________________

📅 Original date posted:2022-07-07
📝 Original message:There is. Just encode the index of permutation used to scramble the
otherwise sorted list. For 12 words you need to store 12! = ~32 bits so 3
words should be enough.

Repetitions make this more difficult, though.

On Thu 7. 7. 2022 at 19:41, Bram Cohen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Thu, Jul 7, 2022 at 7:43 AM Anton Shevchenko via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I made a python implementation for a different mnemonic encoding. The
>> encoding requires user to remember words but not the order of those words.
>> The code is open (MIT license) at https://github.com/sancoder/noomnem
>
>
> Thanks Anton. There's an interesting mathematical question of whether it's
> possible to make a code like this which always uses the BIP-39 words for
> the same key as part of its encoding, basically adding a few words as error
> correction in case the order is lost or confused. If the BIP-39 contains a
> duplicate you can add an extra word.
> _______________________________________________
> 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/20220707/cf37de1e/attachment-0001.html>;

📅 Original date posted:2021-05-15 📝 Original message:Please ...

2023-06-07T22:53:25Z

In reply to nevent1q…h3cz
_________________________

📅 Original date posted:2021-05-15
📝 Original message:Please read the Bitcoin whitepaper. It's a very interesting read.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-founder and CTO, SatoshiLabs

On Sat, May 15, 2021, 23:57 Michael Fuhrmann via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello,
>
> Bitcoin should create blocks every 10 minutes in average. So why do
> miners need to mine the 9 minutes after the last block was found? It's
> not necessary.
>
> Problem: How to prevent "pre-mining" in the 9 minutes time window?
>
> Possible ideas for discussion:
>
> - (maybe most difficult) global network timer sending a salted hash time
> code after 9 minutes. this enables validation by nodes.
>
> - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just
> high enough) times higher difficulty. so everyone can mine any time but
> before to 9 minutes are up there will be a too high downside. It is more
> efficient to wait then paying high bills. The bitcoin will get a "puls".
>
>
> I dont think I see all problems behind these ideas but if there is a
> working solution to do so then the energy fud will find it's end. Saving
> energy without loosing rosbustness.
>
>
>
> :)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210516/48aac0b2/attachment-0001.html>;

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

2023-06-07T18:28:33Z

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:2020-12-17 📝 Original message:I ...

2023-06-07T18:27:50Z

In reply to nevent1q…q40z
_________________________

📅 Original date posted:2020-12-17
📝 Original message:I applaud this effort!

We tried to document the 48 path usage in this document:

https://github.com/trezor/trezor-firmware/blob/master/docs/misc/purpose48.md

The only difference I can spot is that our document also documents script_type=0 which is for the raw BIP-11 multisig. While almost not used in the wild, it could be imho documented in this proposed BIP as well.

—
Best Regards / S pozdravom,

Pavol “stick” Rusnak
Co-founder and CTO, SatoshiLabs

> On Wednesday, Dec 16, 2020 at 2:48 PM, dentondevelopment via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org (mailto:bitcoin-dev at lists.linuxfoundation.org)> wrote:
> Hello,
>
> I would like to propose bip48 (taking bip44 as inspiration), with the purpose of documenting modern multi-sig derivations.
>
> Please see a rough draft of the proposed bip attached, comments/input welcome.
>
> Regards,
> Fontaine
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201217/b47648bc/attachment.html>;

📅 Original date posted:2020-04-30 📝 Original ...

2023-06-07T18:24:10Z

In reply to nevent1q…je7g
_________________________

📅 Original date posted:2020-04-30
📝 Original message:https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

On Thu, Apr 30, 2020, 10:21 SatoshiSingh via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi list. I've been a lurker for quite sometime and this is my first post.
>
> The problem I'm addressing is that generally wallet devs construct the tx
> with the 2nd output being of the sender as change. This helps chain
> analysers to identity addresses and invade the users privacy.
>
> I'm suggesting to sort the outputs in alphabetic order (or by pure random
> order) before broadcasting. This way the chain analyser cannot be sure
> which output is the change output and will improve privacy a little.
>
> Thanks_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200430/48d74736/attachment.html>;

📅 Original date posted:2020-03-20 📝 Original message:On ...

2023-06-07T18:23:22Z

In reply to nevent1q…dnad
_________________________

📅 Original date posted:2020-03-20
📝 Original message:On 20/03/2020 16:44, Ethan Kosakovsky via bitcoin-dev wrote:
> I would like to present a proposal for discussion and peer review

I read your proposal twice and I still don't know what kind of problem
are you trying to solve.

This should be obvious from the "Abstract" and it's bad if it's not.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

📅 Original date posted:2019-12-24 📝 Original ...

2023-06-07T18:22:06Z

In reply to nevent1q…5z7z
_________________________

📅 Original date posted:2019-12-24
📝 Original message:I'd rather see something using Base58 or even better Bech32. Base64 is not
URL/QR code friendly.

On Tue, Dec 24, 2019, 18:06 Chris Belcher via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I've recently been playing around with descriptors, and they are very
> nice to work with. They should become the standard for master public
> keys IMO.
>
> One downside is that users cant easily copypaste them to-and-fro to make
> watch-only wallet. The descriptors contain parenthesis and commas which
> stop highlighting by double-clicking. Also the syntax might look scary
> to newbs.
>
> An obvious solution is to base64 encode the descriptors. Then users
> would get a text blog as the master public key without any extra details
> to bother them, and developers can easily base64 decode for developing
> with them.
>
> A complication might be the descriptor checksum. If there's a typo in
> the base64 text then that could decode into multiple character errors in
> the descriptor, which might be problematic for the checksum. Maybe the
> descriptor could be base64 encoded without the checksum, then attach the
> checksum to the end of the base64 text.
>
> Thoughts?
>
> I didn't come up with these ideas, they came from discussions with
> achow101.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191224/8cbce0ca/attachment.html>;

📅 Original date posted:2019-04-09 📝 Original message:We are ...

2023-06-07T18:17:31Z

In reply to nevent1q…3akm
_________________________

📅 Original date posted:2019-04-09
📝 Original message:We are in process of finalizing it, so it is not live in Trezor yet. It
will be soon, though. I suppose every wallet that uses BIP39 will adopt
this one as well.

On Tue, Apr 9, 2019, 11:46 Aymeric Vitte <vitteaymeric at gmail.com> wrote:

> Is it final now and live in Trezor? Do you know who else will adopt it?
>
> Regards
>
> Aymeric
> Le 03/04/2019 à 11:19, Pavol Rusnak via bitcoin-dev a écrit :
>
> I am the author of the wordlist. Feel free to use it without any
> restrictions.
>
> However, we are finalizing SLIP39 standard for splitting shares which uses
> a different wordlist with better properties. It might be more suitable for
> your project.
>
> See https://github.com/satoshilabs/slips/blob/master/slip-0039.md and
> https://github.com/satoshilabs/slips/blob/master/slip-0039/wordlist.txt
>
>
>
> On Wed, Apr 3, 2019, 09:32 Elia via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would like to use the BIP39 word lists posted in the Github BIP repo
>> for my own project.
>>
>>
>> Unfortunately there is no license associated with the lists provided on
>> Github so I am not sure whether usage for other projects is permitted. I
>> am not able to file issues on the repo either to suggest adding a license.
>>
>> Does anybody know under which license these lists are published?
>>
>>
>> Best regards,
>>
>> Elia
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190409/45c69dcd/attachment-0001.html>;

📅 Original date posted:2019-02-16 📝 Original message:On ...

2023-06-07T18:16:29Z

In reply to nevent1q…quda
_________________________

📅 Original date posted:2019-02-16
📝 Original message:On 15/02/2019 16:18, Luke Dashjr via bitcoin-dev wrote:
>> The proposed proof-file format provides a standard way of combining
>> multiple proofs and associated metadata. The specification of the format
>> is in the Protocol
>> Buffers<ref>https://github.com/protocolbuffers/protobuf/</ref>; format.
>
> IIRC, this has been contentious for its use in BIP70 and may hinder adoption.

Off-topic to main discussion of this thread. But I need to voice my opinion.

We've been using Protocol buffers in Trezor since the beginning and so
far it has proven to be as a great choice.

While I agree it is always risky to add an exotic dependency to a
software project, this one has lots of interoperable implementations in
all possible languages you can name and it's very easy to work with.

In the past, the Bitcoin dev community used the same arguments with
regards to PSBT and we ended up with something that is almost as complex
as protobuf, but it's de-facto proprietary to Bitcoin.

Cherry on top is that PSBT format can be easily translated back and
forth to PB making it even more obvious that PB should have been used in
the first place.

Now everyone ELSE needs to implement this proprietary format and this
actually hinders adoption, not using Protocol Buffers. If these were
used since the beginning, there would be much more PSBT usage already.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

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

2023-06-07T18:15:51Z

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-10-21 📝 Original message:Your ...

2023-06-07T18:15:03Z

In reply to nevent1q…tcql
_________________________

📅 Original date posted:2018-10-21
📝 Original message:Your solution in the second part of the email does not solve the problem
you indicated in the first part of your email.

On Sun, Oct 21, 2018, 23:41 Ryan Havar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Right now it's just *way* too easy to spot the boundaries between
> different wallets. There's a lot of things that contribute to that, but the
> one that concerns me the most is the way wallets sort transaction inputs
> and outputs.
>
> Some wallets and protocols (especially HW wallets) have a strong
> preference for deterministic sorting (i.e. using bip69), while other
> wallets have a lot of objections to this.
>
> I'm not sure I fully understand the objections, but I think they can be
> summarized as "during the transition period there will be a lot of privacy
> loss" and "if in the future someone wants to use bitcoin in a way that's
> not compatible with bip69 their transactions will stick out heavily".
>
> I wonder if this impasse could be solved with deterministic sorting, but
> based on a semi-secret. Like `sortingSecret = hmac(walletSeed,
> "sortingSecret")` and then there's a standardized sort order based on the
> sortingSecret. e.g. sort inputs/output by the `hash(data ||
> sortingSecret)`. Wallets could come up with their own way of computing
> (or storing) the "sortingSecret" but from there it's standardized.
>
> I has the advantages of deterministic sorting (as long as you know the
> sortingSecret) you can verify it's done correctly and externally looks
> totally randomized.
>
> Am I missing something, or could this be the way forward?
>
> -Ryan
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181021/2cf792a9/attachment.html>;

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

2023-06-07T18:09:31Z

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-07T18:09:30Z

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-09 📝 Original message:On ...

2023-06-07T18:09:30Z

In reply to nevent1q…7muu
_________________________

📅 Original date posted:2018-01-09
📝 Original message: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?

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

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

2023-06-07T18:09:27Z

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-07T18:09:26Z

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-07T18:09:16Z

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-07 📝 Original message:On ...

2023-06-07T18:05:34Z

In reply to nevent1q…8w70
_________________________

📅 Original date posted:2017-09-07
📝 Original message:On 07/09/17 18:30, Kabuto Samourai wrote:
> Why not make this block height, rather than a timestamp?

Blockheight depends on the chain. XPUB is not tied to particular
chain/coin.

Also there are already cryptocurrencies that do not use blockchain, but
directed acyclic graph (DAG) for storing transactions. So it would not
be obvious what number to use as a blockheight.

OTOH all blockchains contain timestamps in their blocks, so we can use that.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

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

2023-06-07T18:05:33Z

In reply to nevent1q…42hk
_________________________

📅 Original date posted:2017-09-07
📝 Original message:On 07/09/17 18:47, Jonas Schnelli wrote:
> But not sure if it’s worth to save ~two bytes for that.

I think it's not worth complicating the field just to save two bytes.

But if we agree (for privacy reasons) that resolution of this field
should be reduced to week-level (as suggested by Jonas) or month-level
(as sugested by Peter), we could use just 16 bits for this.

TBH I think TREZOR will provide hardcoded constant for this field
(1.1.2014 for all its P2PKH xpubs and 1.8.2017 for all its
P2WPKH-in-P2SH xpubs). So no privacy is lost in this case, but if we
want to ENFORCE this on BIP level, we should decrease the resolution.

> 2.
> Would it make sense to have special depth bytes that directly implies it’s a BIP44 master key (and therefore avoid the bip32 path serialisation)? I know some „centralised“ table need to be available for that which may be not a good idea. But maybe the BIP could reserve a couple of depth-bytes (maybe 0xF0 to 0xFF) for predefined paths.

I think this is exactly what Thomas meant by "wallet developers are
going to use dirtier tricks" in his email, that's why I specifically
tried to avoid this. I see no good reason to do this, unless we want to
save some bytes and I don't think we are in need of doing this.

> 3.
> Would adding a version bit make sense to allow future extensions?

I think changing the human-readable part is the way to go. That way the
wallet can immediately say if it understands the format or not, without
parsing the binary data contents. Version bits were introduced in older
standards, because there was no such thing as human-readable prefix.

--
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/20170907/1bdc5fe7/attachment.sig>;

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

2023-06-07T18:05:32Z

In reply to nevent1q…x7jh
_________________________

📅 Original date posted:2017-09-07
📝 Original message:On 07/09/17 21:35, Andreas Schildbach via bitcoin-dev wrote:
> In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
> we need this field.

But the depth of exported public key will be null. It does not make
sense to export xpub for m or m/0' for your particular case.

> I think it should always be present if a chain is
> limited to a certain script type.

I am fine with having the path there all the time.

> There is however the case where even on one chain, script types are
> mixed. In this case the field should be omitted and the wallet needs to
> scan for all (known) types. Afaik Bitcoin Core is taking this path.

Is that really the case? Why come up with a hierarchy and then don't use it?

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

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

2023-06-07T18:05:31Z

In reply to nevent1q…qc72
_________________________

📅 Original date posted:2017-09-07
📝 Original message:On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
> A solution is still needed to wallets who do not wish to use BIP43

What if we added another byte field OutputType for wallets that do not
follow BIP43?

0x00 - P2PKH output type
0x01 - P2WPKH-in-P2SH output type
0x02 - native Segwit output type

Would that work for you?

The question is whether this field should be present only if depth==0x00
or at all times. What is your suggestion, Thomas?

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

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

2023-06-07T18:05:31Z

In reply to nevent1q…jaxx
_________________________

📅 Original date posted:2017-09-07
📝 Original message:On 07/09/17 05:52, Kabuto Samourai wrote:
> The birthday field is interesting. Could you provide some motivation for
> its inclusion?

Birthday is something SPV wallet developers have been wanting for years.
It helps them with the initial scan, so SPV wallet does not have to
download every block in the blockchain, but only the ones after birthday.

> Could you also add some test vectors?

I will add some test vectors, when we agree this is the way to go.

> There are a few minor grammar / spelling errors, but we can nitpick
> those after this goes to the pull request stage on bitcoin/bips.

+1

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

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

2023-06-07T18:05:30Z

In reply to nevent1q…wyya
_________________________

📅 Original date posted:2017-09-06
📝 Original message:The discussion about changing bip32 version bytes for SegWit got me
thinking and I ended up with what I think is the best proposal:

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

(It is hosted in SL repo for now, but if there is will, I would love to
have this added to BIP repo as an extension to BIP32)

Feel free to comment.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

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

2023-06-07T18:05:22Z

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-07T18:05:21Z

In reply to nevent1q…5xvg
_________________________

📅 Original date posted:2017-09-05
📝 Original message:On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:
> ========== =========== ===================================
> Version Prefix Description
> ========== =========== ===================================
> 0x0488ade4 xprv P2PKH or P2SH
> 0x0488b21e xpub P2PKH or P2SH
> 0x049d7878 yprv (P2WPKH or P2WSH) nested in P2SH
> 0x049d7cb2 ypub (P2WPKH or P2WSH) nested in P2SH
> 0x04b2430c zprv P2WPKH or P2WSH
> 0x04b24746 zpub P2WPKH or P2WSH
> ========== =========== ===================================
> (source: http://docs.electrum.org/en/latest/seedphrase.html)
>
> I have heard the argument that xpub/xprv serialization is a format for
> keys, and that it should not be used to encode how these keys are used.

I used this argument for mnemonic/seed, not xpub/xprv. I am fine with
this proposal of yours, so don't worry.

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

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

2023-06-07T18:05:16Z

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-07T17:52:48Z

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-08-16 📝 Original message:I ...

2023-06-07T17:52:47Z

In reply to nevent1q…va05
_________________________

📅 Original date posted:2016-08-16
📝 Original message:I think it does not make sense to try to get this standardized for
current Bitcoin transactions. They are just too complex.

What might be interesting is to have something similar for Segwit and
Lightning transactions.

* TREZOR performs extended validation of the inputs, when all of
prev-txs are streamed into the device and validated. Your standard does
not tackle this at all and I don't think it's worthy to make this
standard unnecessarily complicated.

--
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/802e48ca/attachment.sig>;

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

2023-06-07T17:50:43Z

In reply to nevent1q…uuxs
_________________________

📅 Original date posted:2016-05-15
📝 Original message:On 14/05/16 18:14, Jonas Schnelli wrote:
> AFAIK: Bip39 import (cross-wallet) is not supported by Schildbachs
> android wallet [1] and Electrum [2] and Breadwallet [3].

They are not BIP44 compatible wallets. This thread is about BIP44.

> * What if the "old" wallet has used more then 1000 addresses? I guess

They are not following the spec and are thus not BIP44 compatible.

> * If I import a bip39 mnemonic into a hardware wallet (assume Trezor or
> Keepkey) I have to type in the words into my computer which bypasses
> some of the security my hardware wallet provides me (MITM seed attack).
> Together with the point above this reduces the security of a wallet (in
> particular cold storage significant).

You should send all your coins to the new seed anyway, but I agree this
might be tricky for non-power users.

--
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/20160515/81461096/attachment.sig>;

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

2023-06-07T17:50:42Z

In reply to nevent1q…7hry
_________________________

📅 Original date posted:2016-05-14
📝 Original message:On 14/05/16 10:16, Jonas Schnelli via bitcoin-dev wrote:
> Importing a bip32 wallet (bip44 or not) is still an expert job IMO.

That's simply not true. All reasonable wallets (reasonable = user
oriented) now use BIP39 mnemonic for doing exactly this.

--
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/20160514/0d9c8040/attachment.sig>;

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

2023-06-07T17:50:41Z

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-07T17:50:41Z

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-07T17:50:40Z

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:2016-05-08 📝 Original message:On ...

2023-06-07T17:50:24Z

In reply to nevent1q…gl97
_________________________

📅 Original date posted:2016-05-08
📝 Original message:On 21/04/16 14:08, Marek Palatinus via bitcoin-dev wrote:
> Sipa, you are probably the most competent to answer this.
> Could you please tell us your opinion? For me, this is
> straightforward, backward compatible fix and I like it a lot.
> Not sure about the process of changing "Final" BIP though.

Sipa: Marek told me you posted your answer and he received it, but it
never reached the list. Could you please resend after figuring out what
went wrong?

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com

📅 Original date posted:2016-04-21 📝 Original message:On ...

2023-06-07T17:50:10Z

In reply to nevent1q…nyk8
_________________________

📅 Original date posted:2016-04-21
📝 Original message:On 21/04/16 17:28, Eric Lombrozo via bitcoin-dev wrote:
> I don't think we've ever had to handle this case.

This is the main problem: we are not sure, because not a lot of software
does this checks. Also even if you do check, it's hard to handle an
exception (you can't always skip - what if the problematic node is m/44'?).

One of the motivations is to fix BIP-32 so it can be used for
non-secp256k1 curves as well. For NIST P-256 curve this chance is 2^-32.

Jochen even managed to find an example[1]:

m/28578'/33941 where m is derived from
"000102030405060708090a0b0c0d0e0f" seed.

[1]
https://github.com/trezor/trezor-crypto/commit/16ff4387ae79429e629a5454708abf7385b3a9a3

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com

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

2023-06-07T15:31:45Z

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:2015-02-03 📝 Original message:On ...

2023-06-07T15:29:27Z

In reply to nevent1q…263k
_________________________

📅 Original date posted:2015-02-03
📝 Original message:On 03/02/15 11:37, Andreas Schildbach wrote:
> Not really IMHO. Keys can be used on multiple blockchains.

Ah, correct. Timestamp it is.

Nitpick: They cannot be used on multiple blockchains according to BIP32.
In BIP43 we fixed that. :-)

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2015-02-02 📝 Original message:On ...

2023-06-07T15:29:26Z

In reply to nevent1q…52ed
_________________________

📅 Original date posted:2015-02-02
📝 Original message:On 02/02/15 15:17, Andreas Schildbach wrote:
> Yes, except that BIP32-hierarchy and BIP44 differ in some requirements
> (e.g. gap limit).

Right.

To me it seems more important to describe how addresses should be
discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G)
instead of how the xpub was created/obtained (bip32 vs bip44).

What do you thing about changing ?h=bip32 to something like

?t=01&g=20

- t=01 meaning that chains 0 and 1 should be scanned (feel free to
change "01" into any other descriptive string)
- g=20 meaning that gap 20 should be used

> Those strings are not meant to be read by humans. YYYYMMDD is more
> complicated than necessary, given that Bitcoin deals with seconds since
> epoch everywhere.

OK :-)

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2015-02-02 📝 Original message:On ...

2023-06-07T15:29:26Z

In reply to nevent1q…nuye
_________________________

📅 Original date posted:2015-02-02
📝 Original message:On 03/02/15 01:05, Andreas Schildbach wrote:
> I don't think that parameterizing will work, we can't predict future
> BIPs. It's the same as for BIP43, in the end we agreed on just putting
> the BIP number.

Hm, let me put the questions the other way around:

What gap limit should a wallet use if it encounters h=bip32?

What h value should I use for myTREZOR wallets? Which is essentially a
BIP44 wallet that produces h=bip32 xpubs with gap limit 20 ...

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2015-02-02 📝 Original message:On ...

2023-06-07T15:29:25Z

In reply to nevent1q…5l5n
_________________________

📅 Original date posted:2015-02-02
📝 Original message:On 02/02/15 13:38, Andreas Schildbach wrote:
> It's h=bip32 for the hierarchy used and

Do I understand this correctly and h=bip32 hierarchy means that both

xpub/0/i and xpub/1/j chains are scanned? (So it applies to BIP44
generated xpubs as well?)

> c=123456 for the creation date of the wallet (in seconds since epoch).

Uff, I would expect YYYYMMDD there so it's human readable as well.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2014-10-21 📝 Original message:On ...

2023-06-07T15:26:41Z

In reply to nevent1q…hp65
_________________________

📅 Original date posted:2014-10-21
📝 Original message:On 09/23/2014 11:12 PM, Mem Wallet wrote:
> communication. To address gmaxwell's criticism, I'd like to also
> follow up with a proposed change to BIP44, such that a structured
> wallet would also include a series of identity keys, both addresses
> which will be used for signing, and public keys which would be used
> as destinations for encrypted messages.

I don't know what criticism it was, but I feel that another BIP than
BIP44 should be created to describe which HD paths should be used for ECIES.

> If anyone is familiar with ECIES and would be interested, there is a
> working implementation at http://memwallet.info/btcmssgs.html,
> which also includes this whitepaper:

That looks great! I already implemented Electrum's way of ECIES into
TREZOR firmware, but yours version seems much more complete, so I am
inclined to throw it away and use your implementation.

Have you thought about pushing this as a new BIP (different one than I
mention above)? I think it's important to have it reviewed and
standardized ASAP.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

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

2023-06-07T15:19:00Z

In reply to nevent1q…7vla
_________________________

📅 Original date posted:2014-04-20
📝 Original message:On 04/20/2014 06:56 PM, Mike Caldwell wrote:
> I consider overload/conflict with existing meanings of "bit" as a non-issue for typical population at large.

So far I have not seen any reasonable name except for "bit". I also
tried to come up with something else (e.g.naka, toshi, etc.) to avoid
the confusion with bits used in computing, but I was not satisfied with
neither of them.

Then I though about "credit", which is more-or-less established in video
games and sci-fi literature and people are already used to sentences
like "Not enough credits" or "This item costs 10000 credits", because of
this. Also it would be particularly funny if these sci-fi pieces
predicted the future by actually defining it. ;-)

Another options might be "cubit" or "crebit", but the latter is
sometimes used as a compound word meaning both "credit" and "debit" such
as in "You can use crebit cards here".

Also this Wikipedia source is a list of sometimes rather funny
possibilites: https://en.wikipedia.org/wiki/List_of_fictional_currencies

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

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

2023-06-07T15:18:01Z

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-07T15:18:00Z

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-07T15:18:00Z

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-07T15:17:59Z

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-07T15:17:58Z

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-07T15:17:57Z

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-07T15:17:56Z

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-07T15:17:55Z

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-07T15:17:53Z

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-07T15:17:51Z

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-07T15:16:21Z

In reply to nevent1q…9qnk
_________________________

📅 Original date posted:2014-03-27
📝 Original message:On 03/26/2014 09:49 PM, Mike Hearn wrote:
> - cointype: This is zero for Bitcoin. This is here to support two
> things, one is supporting alt coins based off the same root seed. Right now
> nobody seemed very bothered about alt coins but sometimes feature requests

There is one "altcoin" that is pretty important even today and it is
Testnet.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

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

2023-06-07T15:16:19Z

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-07T15:16:18Z

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-07T15:16:17Z

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-07T15:15:17Z

In reply to nevent1q…qjth
_________________________

📅 Original date posted:2014-03-12
📝 Original message:On 03/12/2014 09:37 PM, William Yager wrote:
> (that group of people includes me), PBKDF2-HMAC-SHA512 is very easy to
> implement even on devices that only have a few kB of RAM, and even though
> our number of rounds is very aggressive (2^16 and 2^21), it will still run
> in reasonable time even on very slow embedded ARM processors.

To give you some numbers: TREZOR (120MHz ARM) does 1024 rounds of
PBKDF2-HMAC-SHA512 in around 1 second.

So 2^16 is around one minute, 2^21 is around half an hour.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

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

2023-06-07T15:15:16Z

In reply to nevent1q…cdjv
_________________________

📅 Original date posted:2014-03-12
📝 Original message:On 03/12/2014 09:10 PM, William Yager wrote:
> implement this is to allow semi-trusted devices (like desktop PCs) to do
> all the "heavy lifting". The way the spec is defined, it is easy to have a
> more powerful device do all the tough key stretching work without
> significantly compromising the security of the wallet.

By disclosing "preH" to compromised computer (between steps 4 and 5) you
make further steps 5-9 quite less important.

Too bad you started to work on spec just recently. :-/

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

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

2023-06-07T15:15:15Z

In reply to nevent1q…ake0
_________________________

📅 Original date posted:2014-03-12
📝 Original message:On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote:
> So upon entering a password with a typo, the user will not be notified of an
> error, but be presented with a wallet balance of 0, after the blockchain has
> been scanned. I'm sorry, but that's not the kind of experience I would want to
> present to my users.

Sure, you can have either plausible deniability or typo checking, not
both at the same time.

> Would you care to elaborate how optional outsourcing of the KDF breaks
> compatibility?

I'm afraid one would end up with code generated in one client that is
unusable in a different client, because the client's developer thought
that using fancier algorithm instead of the proposed ones was a good idea.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

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

2023-06-07T15:15:13Z

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:2014-02-24 📝 Original message:On ...

2023-06-07T15:13:57Z

In reply to nevent1q…s24g
_________________________

📅 Original date posted:2014-02-24
📝 Original message:On 02/24/2014 05:45 PM, Gavin Andresen wrote:
> 40 bytes is small enough to never require an OP_PUSHDATA1, too

So are 75 bytes. (I'm not trying to push anything. Just saying ...)

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

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

2023-06-07T15:13:32Z

In reply to nevent1q…s43d
_________________________

📅 Original date posted:2014-02-12
📝 Original message:On 02/10/2014 12:33 AM, Pieter Wuille wrote:
> The proposed document is here: https://gist.github.com/sipa/8907691

If we are bumping nVersion, how about dropping DER encoding completely
and using just 64 bytes directly for signature?

Also using 2 different variable integer encodings (in addition to what
DER already does) is very confusing.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2013-11-16 📝 Original message:On ...

2023-06-07T15:08:34Z

In reply to nevent1q…zmrv
_________________________

📅 Original date posted:2013-11-16
📝 Original message:On 17/11/13 01:42, Timo Hanke wrote:
> p.s. The question about auditing entropy would only apply to the generator,
> not the wallet. Is it yet documented how Trezor proves that external
> entropy was used?

We'll probably use the most straightforward way:
a) trezor prints entropy A on a display (probably in hex format, this
step is triggered by sending a special flag in initialize message)
b) trezor receives entropy B from external source
c) trezor creates sha256(A + B) and uses that as a seed
d) trezor prints used seed on a display (probably in BIP39 format)
e) user can check on a trusted computer that everything was ok

(note that steps b-d are the same regardless of whether the special flag
was set)

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

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

2023-06-07T15:07:31Z

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>

📅 Original date posted:2013-09-12 📝 Original message:On ...

2023-06-07T15:06:46Z

In reply to nevent1q…d9c9
_________________________

📅 Original date posted:2013-09-12
📝 Original message:On 10/09/13 23:03, Matthew Mitchell wrote:
> Maybe it would have been better without the aggressive words?

I revisited the wordlist and replaced around 67 words that can be
found offensive in some context.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

📅 Original date posted:2013-09-12 📝 Original message:On ...

2023-06-07T15:06:46Z

In reply to nevent1q…uxuk
_________________________

📅 Original date posted:2013-09-12
📝 Original message:On 11/09/13 14:49, Andreas Petersson wrote:
> using NLP we could generate a gramatically correct sentence out of 128
> completely random bits which is possible to remember. information could
> be encoded in the selection of words but also in the choice of the
> syntax tree.

We were playing with that idea quite a lot. The problem was that we
ended up with much bigger wordlist and thus it had to contain more
obscure words. Also remember that this scheme has to run on embedded
devices as well, so any unnecessary complexity should be avoided.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>

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

2023-06-07T15:06:45Z

In reply to nevent1q…3cmg
_________________________

📅 Original date posted:2013-09-10
📝 Original message:On 10/09/13 23:03, Matthew Mitchell wrote:
> Maybe it would have been better without the aggressive words?

Feel free to come up with wordlist enhancements. That's why we put
this BIP for discussion in the first place. Three people went through
the wordlist numerous number of times and as you can see it's still
not perfect.

Please bear in mind that for every word you remove from the list, you
have to come up with a good alternative that is unique and hard to
confuse with the others.

--
Best Regards / S pozdravom,

Pavol Rusnak <stick at gk2.sk>