> At least Trezor and bitcoinj (Multibit) seems to be going in this way,
> which is 100% of clients which expressed interest in bip39 :-).
>
> slush
The the current spec with TREZOR's wordlist is also implemented by Bits of Proof
https://github.com/bitsofproof/supernode/blob/master/api/src/main/j
On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell
wrote:
> I'd point out that regardless of how long the desired prefix is, the
> encoded prefix should probably always be constant length in all
> reusable addresses.
I might be misunderstanding, but I think prefix length must be specified
in
Hi slush,
Thank you for your new proposal; it seems to be a compromise.
@Christophe Biocca:
If the wordlist becomes part of the standard, then we will run into
problems of collisions once users ask for wordlists in every language.
IMO the right approach is to implement checksums that do not dep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Proper Unicode handling is a serious issue however. You don't want
someone to move from one input method / machine to another and
suddenly find that their coins are inaccessible, because of an issue
of decomposed vs. compatibility forms or whatever.
O
On Tue, Jan 21, 2014 at 12:06 AM, Christophe Biocca <
christophe.bio...@gmail.com> wrote:
> I remember the wordlist choice getting bikeshedded to death a month ago.
>
> I would just include the wordlist as part of the standard (as a
> recommendation) so that fully compliant implementations can cor
Because the mnemonic is an encoding of a 128-bit random number using its
hash as a private key (or derived part of one) is not a problem, its just an
alternate alphabet encoding of the random private key.
Not being able to generically understand the checksum. Seems tricky to
solve other than say
I remember the wordlist choice getting bikeshedded to death a month ago.
I would just include the wordlist as part of the standard (as a
recommendation) so that fully compliant implementations can correct a
user's typos regardless of the original generator.
Those who don't like it will have to de
On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
> On Mon, Jan 20, 2014 at 11:42 AM, slush wrote:
>
> > Hi all,
> >
> > during recent months we've reconsidered all comments which we received
> > from the community about our BIP39 proposal and we tried to meet all
> > requirements for
On Mon, Jan 20, 2014 at 11:42 AM, slush wrote:
> Hi all,
>
> during recent months we've reconsidered all comments which we received
> from the community about our BIP39 proposal and we tried to meet all
> requirements for such standard. Specifically the proposal now doesn't
> require any specific
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since you are taking the hash of Unicode data, I would strongly
recommend using a canonical form, e.g. Normalized Form C.
On 01/20/2014 09:42 AM, slush wrote:
> Hi all,
>
> during recent months we've reconsidered all comments which we
> received from
On Mon, Jan 20, 2014 at 9:02 PM, Luke-Jr wrote:
>
> How are they compatible if they could be using entirely different word
> lists??
>
>
Wordlist is necessary for the step [seed]->[mnemonic]. Step
[mnemonic]->[bip32 root] doesn't need any wordlist, there's just hashing
involved.
For this reason c
On Monday, January 20, 2014 5:42:37 PM slush wrote:
> Hi all,
>
> during recent months we've reconsidered all comments which we received from
> the community about our BIP39 proposal and we tried to meet all
> requirements for such standard. Specifically the proposal now doesn't
> require any spec
We have an implementation of the latest spec in bitcoinj, with the wordlist
provided by slush+stick. As far as I can see it's all working fine so LGTM
from us.
On Mon, Jan 20, 2014 at 5:42 PM, slush wrote:
> Hi all,
>
> during recent months we've reconsidered all comments which we received
> fr
Hi all,
during recent months we've reconsidered all comments which we received from
the community about our BIP39 proposal and we tried to meet all
requirements for such standard. Specifically the proposal now doesn't
require any specific wordlist, so every client can use its very own list of
pref
On Sat, Jan 18, 2014 at 11:44:52AM -0600, Troy Benjegerdes wrote:
> > Ignoring prefixes the cost for each reusable address is only a small
> > percentage of the full node cost (rational: each transaction has one
> > or more ECDSA signatures, and the derivation is no more expensive), so
> > I would
On Sat, Jan 18, 2014 at 05:12:58PM -0600, Jeremy Spilman wrote:
>
>
> > On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner wrote:
> >> Isn't there a much faster asymmetric scheme that we can use? I've heard
> >> people talk about ed25519, though I'm not sure it can be used for
> >> encryption.
> >
16 matches
Mail list logo
