Re: [bitcoin-dev] Introducing a version field to BIP39 mnemonic phrases

[Pavol Rusnak via bitcoin-dev]

On Sat, 13 Jan 2024 at 10:53, Leslie <0300dbd...@protonmail.com> wrote:

> Developments like aezeed[1] or Electrum V2[2] also demonstrate that the
> standard BIP39 entropy might not always suffice for specific applications,
> leading to alternative standards being developed.
> This reality underscores the need to consider ways to enhance the existing
> system to more effectively accommodate these evolving requirements.
>

It is a very unrealistic that any kind of seed standard with extra metadata
will cover all possible future usecases.
Therefore new standards will always keep emerging.

LND coming up with a new aezeed standard and not using Electrum v2 are good
example of this.

For LND, the documentation[1] tells you to convert the seed using a website
(not great) AND on top of that you also need to provide the derivation path
for the funds(!) because the aezeed version is not used to encode the
derivation path used.
Probably the LND folks also realized it is not feasible to regenerate the
seed (and bother user with the backup)
every time wallet starts to use the new address format.

On the other side, CLN is perfectly fine with using BIP39, making it very
easy to recover CLN funds in any BIP39 compatible wallet.

[1]
https://www.lightningnode.info/technicals/restorelndonchainfundsinelectrum

In summary, while I hold deep respect for the fundamental principles of
> BIP39, I firmly believe that exploring the potential of versioned mnemonics
> can effectively address the dynamic nature of user practices and
> application demands, all while preserving the core strengths of the BIP39
> standard.
>

>From where I stand, adding metadata to seed is a fool's errand.
Every year, new people coming to Bitcoin try it and fail.

Everything said, feel free to experiment, but your experiments should be
different standard than BIP39.
I would like to keep the BIP39 base entropy layer "ossified".
Moreover, it would be best if your experiments do not interfere with BIP39
to avoid confusion.
That is, your seeds should not be of lengths 12, 15, 18, 21 or 24 words.

-- 
Best Regards / S pozdravom,

Pavol "Stick" Rusnak
Co-Founder, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Introducing a version field to BIP39 mnemonic phrases

[Pavol Rusnak via bitcoin-dev]

Hi Leslie, hi list!

BIP39 author here. Not having version was a design decision, not accidental
omission.

When designing BIP39 we were striving for maximum interoperability. There
are thousands of BIP39 applications and all of them have 100% interoperable
way how to share entropy using a single seed.

If there was a version field involved in BIP39 allowing different key
stretching methods, all these implementations would choose to implement
only different subsets which would lead to interoperability disaster.

To give some examples of what I mean:
- there is no way hardware wallets would be able to keystretch using Argon2
or other methods that require lot of memory and/or CPU bandwidth
- having version paves the way to proprietary key stretching algorithms

BIP39 is the universal base layer for sharing entropy. Everything else is
delegated to upper layers.

Adding version that encodes derivation paths is making the scheme less
future proof, not more future proof.

Imagine you created the seed in 2014 that includes version that prescribes
using BIP44 as a derivation path. Now everytime there is a new standard
(Segwit, Compat Segwit, Taproot, etc.). You need to generate (and backup!)
the new seed.

What if you want to use the seed for Nostr? Lightning? Cashu? Ark? User
would be forced to backup multiple seeds for every single application,
leading to sloppy backups.

With BIP39 you can just use the single seed for everything.


—

Best Regards / S pozdravom,

Pavol "Stick" Rusnak
Co-Founder, SatoshiLabs


On Thu 11. 1. 2024 at 6:17, Leslie via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 
>   BIP:
>   Layer: Applications
>   Title: Versioned BIP39 Mnemonic Phrases
>   Author: Leslie <0300dbd...@protonmail.com>
>   Status: None
>   Type: Standards Track
>   Created: 2024-01-10
> 
>
> ## Abstract
>
> This BIP proposes an enhancement to the BIP39 mnemonic phrases by
> introducing a version field.
> The version field will be a 32-bit field, prepended to the entropy of the
> BIP39 mnemonic phrase.
> The first 24 bits are for general purposes, and the subsequent 8 bits are
> for defining the version used.
>
> ## Motivation
> The current implementation of BIP39 mnemonic phrases lacks a crucial
> feature: versioning.
> This omission has been identified as a significant design flaw, affecting
> the robustness and future-proofness of the mnemonic phrase generation and
> usage.
> Notable community members and projects have expressed concerns over this
> shortcoming:
>
> >The lack of versioning is a serious design flaw in this proposal. On this
> basis alone I would recommend against use of this proposal.
>
> \- [Greg Maxwell 2017-03-14](
> https://github.com/bitcoin/bips/wiki/Comments:BIP-0039/fd2ddb6d840c6a91c98a29146b9a62d6a65d03bf
> )
>
>
> Furthermore, the absence of a version number in BIP39 seed phrases poses
> risks and inefficiencies in wallet software development and backward
> compatibility:
>
> >BIP39 seed phrases do not include a version number. This means that
> software should always know how to generate keys and addresses. BIP43
> suggests that wallet software will try various existing derivation schemes
> within the BIP32 framework. This is extremely inefficient and rests on the
> assumption that future wallets will support all previously accepted
> derivation methods. If, in the future, a wallet developer decides not to
> implement a particular derivation method because it is deprecated, then the
> software will not be able to detect that the corresponding seed phrases are
> not supported, and it will return an empty wallet instead. This threatens
> users funds.
> >
> >For these reasons, Electrum does not generate BIP39 seeds.
>
> \- [Electrum Documentation 2017-01-27](
> https://electrum.readthedocs.io/en/latest/seedphrase.html#motivation)
>
> The proposed BIP aims to address these concerns by introducing a version
> field in the BIP39 mnemonic phrases.
> The introduction of versioning is expected to enhance the mnemonic's
> adaptability to future changes, improve the efficiency of wallet software
> in handling different derivation methods, and secure users funds by
> reducing the risk of incompatibilities between mnemonic phrases and wallet
> implementations.
>
> ## Generating the Mnemonic
>
> In this proposal, we build upon the structure of BIP39 to include a
> versioned enhancement in the mnemonic generation process. The mnemonic
> encodes entropy, as in BIP39, but with a flexible approach to the size of
> the initial entropy (ENT).
>
> ### Version Field Inclusion:
>
> 1. **Initial Entropy Generation:**
>The initial entropy of ENT bits is generated, where ENT can be any size
> as long as it is a multiple of 32 bits.
>
> 2. **Version Field Prepending:**
>A crucial addition to this process is the prepending of a 32-bit
> version field to the initial entropy. This field is composed of:
>- The first 24 bits are reserved for general purposes, which can be
> utilized for 

Re: [bitcoin-dev] segwit naming ambiguity

[Pavol Rusnak via bitcoin-dev]

Here's my idea for a clean API:

1. `is_segwit()` returns true for a p2tr output

2. a function `segwit_version()` which returns an int according to segwit
version used

3. helper functions like `is_p2wpkh()`, `is_p2tr()`, `is_p2wsh()` for all
script types which all return a bool


On Fri, 11 Aug 2023 at 08:41, Tobin Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Question for OG bitcoin API designers please.
>
> If you were to see the following function
>
> `is_segwit()`
>
> would you assume it returns `true` or `false` for a p2tr transaction?
>
>
> Currently we (rust-bitcoin) are being liberal with the use of `v0` but
> its a pretty ugly. Is there an official, or widely used, name for segwit
> v0?
>
>
> Thanks,
> Tobin.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best Regards / S pozdravom,

Pavol "Stick" Rusnak
Co-Founder, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Codex32

[Pavol Rusnak via bitcoin-dev]

Thanks Andrew!

New draft makes it much more obvious what are the differences between
Codex32 and SLIP-0039 scheme.
-- 
Best Regards / S pozdravom,

Pavol "Stick" Rusnak
Co-Founder, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Codex32

[Pavol Rusnak via bitcoin-dev]

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@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-.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-
>
> 
>   BIP: 
>   Layer: Applications
>   Title: codex32
>   Author: Leon Olsson Curr and Pearlwort Sneed 
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
>   Status: Draft
>   Type: 
>   Created: 2023-02-13
>   License: BSD-3-Clause
>   Post-History: FIXME
> 
>
> ==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

Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format

[Pavol Rusnak via bitcoin-dev]

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@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@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
>
> ---
>
> 
> BIP: wallet-labels
> Layer: Applications
> Title: Wallet Labels Export Format
> Author: Craig Raw 
> 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
> 
>
> ==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 

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Pavol Rusnak via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-Founder, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor

[Pavol Rusnak via bitcoin-dev]

On Wed, 27 Jul 2022 at 00:28, Andrew Chow 
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor

[Pavol Rusnak via bitcoin-dev]

Thanks Andrew for this BIP. We've been already using this for quite some
time for Trezor in production.

Just one clarification: Should , , ... 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@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 ``. 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
>
> ---
>
> 
>BIP: multipath-descs
>Layer: Applications
>Title: Multipath Descriptor Key Expressions
>Author: Andrew Chow 
>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
> 
>
> ==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:
>
> * xpub encoded extended public key or xprv encoded
> extended private key (as defined in BIP 32)
> ** Followed by zero or more /NUM or /NUMh path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Optionally followed by a single /* or /*h final
> step to denote all direct unhardened or hardened children.
>
> This is modifed to state:
>
> * xpub encoded extended public key or xprv encoded
> extended private key (as defined in BIP 32)
> ** Followed by zero or more /NUM or /NUMh path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Followed by zero or one / (NUM may be
> followed by h 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 /NUM or /NUMh path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Optionally followed by a single /* or /*h final
> step to denote all direct unhardened or hardened children.
>
> When a / is encountered, parsers should produce two
> descriptors where the first descriptor uses the first NUM, and
> a second descriptor uses the second NUM.
>
> 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 /<0;1>
>
> ==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 

Re: [bitcoin-dev] No Order Mnemonic

[Pavol Rusnak via bitcoin-dev]

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@lists.linuxfoundation.org> wrote:

> On Thu, Jul 7, 2022 at 7:43 AM Anton Shevchenko via bitcoin-dev <
> bitcoin-dev@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-Founder, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bip39

[Pavol Rusnak via bitcoin-dev]

Trezor recovery cards look like this what addresses the issue:

https://wiki.trezor.io/images/Seed_card_example.jpg

1. Each word has a box around it.
2. You write the words one under the other, not next to each other.


On Mon, 17 Jan 2022 at 23:38, Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is a good point, but can be addressed by having a non-void whitespace
> character (e.g., win x estate).
>
> changing BIP39 would be hard since software expects a standard list; it
> would also be possible to rejection sample for seeds that do not contain
> these pairs, unclear how much entropy would be lost from that.
> --
> @JeremyRubin 
> 
>
>
> On Mon, Jan 17, 2022 at 2:26 PM Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> really don't like that art, work, and artwork are 3 different words
>>
>> would be nice to clean up adjacent ambiguity
>>
>> it's not a big deal, but it can lead to confusion when writing things down
>>
>>
>> dup: ('canal', 'arm') ('can', 'alarm')
>> dup: ('canal', 'one') ('can', 'alone')
>> dup: ('canal', 'ready') ('can', 'already')
>> dup: ('card', 'anger') ('car', 'danger')
>> dup: ('card', 'ice') ('car', 'dice')
>> dup: ('card', 'inner') ('car', 'dinner')
>> dup: ('card', 'raw') ('car', 'draw')
>> dup: ('cart', 'able') ('car', 'table')
>> dup: ('cart', 'ask') ('car', 'task')
>> dup: ('cart', 'hat') ('car', 'that')
>> dup: ('cart', 'hen') ('car', 'then')
>> dup: ('cart', 'issue') ('car', 'tissue')
>> dup: ('cart', 'one') ('car', 'tone')
>> dup: ('cart', 'own') ('car', 'town')
>> dup: ('cart', 'rack') ('car', 'track')
>> dup: ('cart', 'rain') ('car', 'train')
>> dup: ('cart', 'win') ('car', 'twin')
>> dup: ('catch', 'air') ('cat', 'chair')
>> dup: ('erase', 'arch') ('era', 'search')
>> dup: ('fatal', 'arm') ('fat', 'alarm')
>> dup: ('fatal', 'one') ('fat', 'alone')
>> dup: ('fatal', 'ready') ('fat', 'already')
>> dup: ('feed', 'anger') ('fee', 'danger')
>> dup: ('feed', 'ice') ('fee', 'dice')
>> dup: ('feed', 'inner') ('fee', 'dinner')
>> dup: ('feed', 'raw') ('fee', 'draw')
>> dup: ('feel', 'earn') ('fee', 'learn')
>> dup: ('feel', 'end') ('fee', 'lend')
>> dup: ('gasp', 'act') ('gas', 'pact')
>> dup: ('gasp', 'age') ('gas', 'page')
>> dup: ('gasp', 'air') ('gas', 'pair')
>> dup: ('gasp', 'ill') ('gas', 'pill')
>> dup: ('gasp', 'raise') ('gas', 'praise')
>> dup: ('gasp', 'rice') ('gas', 'price')
>> dup: ('gasp', 'ride') ('gas', 'pride')
>> dup: ('gasp', 'roof') ('gas', 'proof')
>> dup: ('kite', 'merge') ('kit', 'emerge')
>> dup: ('kite', 'motion') ('kit', 'emotion')
>> dup: ('kite', 'state') ('kit', 'estate')
>> dup: ('lawn', 'arrow') ('law', 'narrow')
>> dup: ('lawn', 'either') ('law', 'neither')
>> dup: ('lawn', 'ice') ('law', 'nice')
>> dup: ('legal', 'arm') ('leg', 'alarm')
>> dup: ('legal', 'one') ('leg', 'alone')
>> dup: ('legal', 'ready') ('leg', 'already')
>> dup: ('seat', 'able') ('sea', 'table')
>> dup: ('seat', 'ask') ('sea', 'task')
>> dup: ('seat', 'hat') ('sea', 'that')
>> dup: ('seat', 'hen') ('sea', 'then')
>> dup: ('seat', 'issue') ('sea', 'tissue')
>> dup: ('seat', 'one') ('sea', 'tone')
>> dup: ('seat', 'own') ('sea', 'town')
>> dup: ('seat', 'rack') ('sea', 'track')
>> dup: ('seat', 'rain') ('sea', 'train')
>> dup: ('seat', 'win') ('sea', 'twin')
>> dup: ('skin', 'arrow') ('ski', 'narrow')
>> dup: ('skin', 'either') ('ski', 'neither')
>> dup: ('skin', 'ice') ('ski', 'nice')
>> dup: ('tent', 'able') ('ten', 'table')
>> dup: ('tent', 'ask') ('ten', 'task')
>> dup: ('tent', 'hat') ('ten', 'that')
>> dup: ('tent', 'hen') ('ten', 'then')
>> dup: ('tent', 'issue') ('ten', 'tissue')
>> dup: ('tent', 'one') ('ten', 'tone')
>> dup: ('tent', 'own') ('ten', 'town')
>> dup: ('tent', 'rack') ('ten', 'track')
>> dup: ('tent', 'rain') ('ten', 'train')
>> dup: ('tent', 'win') ('ten', 'twin')
>> dup: ('used', 'anger') ('use', 'danger')
>> dup: ('used', 'ice') ('use', 'dice')
>> dup: ('used', 'inner') ('use', 'dinner')
>> dup: ('used', 'raw') ('use', 'draw')
>> dup: ('wine', 'merge') ('win', 'emerge')
>> dup: ('wine', 'motion') ('win', 'emotion')
>> dup: ('wine', 'state') ('win', 'estate')
>> dup: ('wing', 'host') ('win', 'ghost')
>> dup: ('wing', 'love') ('win', 'glove')
>> dup: ('wing', 'old') ('win', 'gold')
>> dup: ('wing', 'own') ('win', 'gown')
>> dup: ('wing', 'race') ('win', 'grace')
>> dup: ('wing', 'rain') ('win', 'grain')
>> dup: ('wink', 'now') ('win', 'know')
>> dup: ('youth', 'under') ('you', 'thunder')
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-Founder, 

Re: [bitcoin-dev] Derivation Paths for Single Key Taproot Scripts

[Pavol Rusnak via bitcoin-dev]

+1 from the author of BIP43, BIP44 and BIP84. The proposed BIP follows this
pattern nicely.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-founder and CTO, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

[Pavol Rusnak via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] 7z block compression, 18%

[Pavol Rusnak via bitcoin-dev]

If block compression is going to be considered, zstd provides better
properties than the competition.
Especially for the decompression. [1]

[1] https://github.com/facebook/zstd

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-founder and CTO, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Pavol Rusnak via bitcoin-dev]

> 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@lists.linuxfoundation.org> wrote:

>
>
> On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen <
> christoph...@lifewithalacrity.com> wrote:
>
>>
>>
>> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen  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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bip48 proposal

[Pavol Rusnak via bitcoin-dev]

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 
>  (mailto:bitcoin-dev@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Sorting outputs of a transaction in alphabetic order to protect privacy

[Pavol Rusnak via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Base64-encoded descriptors

[Pavol Rusnak via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] License for BIP39 word lists

[Pavol Rusnak via bitcoin-dev]

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  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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> ___
> bitcoin-dev mailing 
> listbitcoin-dev@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
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] License for BIP39 word lists

[Pavol Rusnak via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] NIH warning (was Re: [BIP Proposal] Simple Proof-of-Reserves Transactions)

[Pavol Rusnak via bitcoin-dev]

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
>> Buffershttps://github.com/protocolbuffers/protobuf/ 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP39 seeds

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transaction Input/Output Sorting

[Pavol Rusnak via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Pavol Rusnak via bitcoin-dev]

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



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Pavol Rusnak via bitcoin-dev]

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
> (2xhmac-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 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Pavol Rusnak via bitcoin-dev]

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



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Sign / Verify message against SegWit P2SH addresses.

[Pavol Rusnak via bitcoin-dev]

On 08/12/17 19:25, Dan Bryant via bitcoin-dev wrote:
> I know there are posts, and an issue opened against it, but is there
> anyone writing a BIP for Sign / Verify message against a SegWit address?

Dan, are you still planning to write this BIP?

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak via bitcoin-dev]

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



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts

[Pavol Rusnak via bitcoin-dev]

On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:
> == === ===
> VersionPrefix  Description
> == === ===
> 0x0488ade4 xprvP2PKH or P2SH
> 0x0488b21e xpubP2PKH or P2SH
> 0x049d7878 yprv(P2WPKH or P2WSH) nested in P2SH
> 0x049d7cb2 ypub(P2WPKH or P2WSH) nested in P2SH
> 0x04b2430c zprvP2WPKH or P2WSH
> 0x04b24746 zpubP2WPKH 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak via bitcoin-dev]

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



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak via bitcoin-dev]

On 14/05/16 09:00, Andreas Schildbach via bitcoin-dev wrote:
> The whole idea of BIP43 (which BIP44 bases on) is that how these BIPs
> define balance retrieval never changes. This is to make sure you always
> see the same balance on "same BIP" wallets (and same seed of course).

This! Thanks Andreas for formulating my thought that I was not able to
articulate earlier.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak via bitcoin-dev]

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



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak via bitcoin-dev]

On 13/05/16 18:03, Aaron Voisine wrote:
> I like the idea of specifying the type of address as a bit field flag.
> 0x8000 is already used to specify hardened derivation, so 0x4000
> 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'/0x4000 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak via bitcoin-dev]

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. ' 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fwd: Proposal to update BIP-32

[Pavol Rusnak via bitcoin-dev]

On 08/05/16 15:48, Marek Palatinus via bitcoin-dev wrote:
> unambiguously be used to refer to an idea. My suggestion would be to write
> a new BIP that overrides parts of BIP32, and then put a note in BIP32 that
> a better mechanism is available that is unlikely to change things in
> reality for the secp256k1 curve.

I guess, we'll write that down to SLIP-0032 then.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal to update BIP-32

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal to update BIP-32

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev