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 only
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
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 sl...@centrum.cz wrote:
Hi all,
during recent months we've reconsidered all comments which we
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 specific
On Mon, Jan 20, 2014 at 9:02 PM, Luke-Jr l...@dashjr.org 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
-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 11:42 AM, slush sl...@centrum.cz 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
On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
On Mon, Jan 20, 2014 at 11:42 AM, slush sl...@centrum.cz 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
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
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
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 correct
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
On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell gmaxw...@gmail.com
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
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
14 matches
Mail list logo
