Topic: [ANN] bip32.org - JavaScript BIP32 deterministic wallet generator (Read 3608 times)

Thanks for your input.  Which standard do you think is relevant and which approach do you think is the best?  Please see my post at https://bitcointalksearch.org/topic/m.5047724

I like the mainnet convention you're using. It's probably the most human-readable to be done in 4 characters. Would you consider changing the testnet prefix to XXtv, XXtb for private and public extended keys, respectively?


BIP32 is likely not the relevant standard if you want users to send and withdraw bitcoin. Also that post is from 2011 and the approach may no longer be best.

Where is the "Keypair index"?  You wrote: "...paste in the key you just copied."  Paste it where?  Most of the fields cannot be pasted into.


It seems that this is already for more advanced users.

I just want to enable my users to send and withdraw bitcoin.  I'm trying to see if the approach suggested by just_someguy at https://bitcointalksearch.org/topic/m.5058875 is the way to go.  I've already spent 2 months to see if I can integrate Bitcoin to my web app.  Do I need to understand cryptography, Depth, Parent Fingerprint, Child Index, Chain Code, Derivation Path, Derived Private Key, Private Key (WIF), Derived Public Key, Public Key (Hex), XXpv/XXub, base58_decode, magic bytes, encode, DOGE, Ltpv, Ltub, dgpv, dgub, etc. in order to do so?

There isn't a spec for the alt coins as far as I'm aware. It'd be nice if there was.

TBH, I was hoping that my version bytes would become the standard. Hypothetically, if my implementation were actually used by alt-coiners then when drafting the spec it'd be more of an issue that the spec has to deal with (that people have already adopted a standard to use).  Unfortunately, there's just no BIP-style development for any of the other coins, so I was forced to improvise if I wanted to support altcoins.

I was indeed going with XXpv/XXub for the public/private keypair prefixes.  For testnet, I was a little less concerned about consistency but it seems you have gotten the general gist of things.

The code isn't set in stone. If you guys want the version bytes changed, let me know:)

I've been curious about this as well. Maybe there should be consensus before we plough ahead with this.

People would freak if they had sent coins to an address derived from these scripts but the key wouldn't import in a client eventually. They would have to base58_decode, change the magic bytes, encode, and go with that, but they probably won't manage unless they can code. If your code/bytes get implemented elsewhere the problem would be widespread, and cause a lot of fuss for those people.

Sarchar, the "version" values your BIP32 implementation uses for DOGE/DOGE-testnet and LTC/LTC-testnet, are these in some specification somewhere or is this your own? I'm implementing BIP32 for some alts and I'm curious what version values I ought to use.

I see in Base58 yours result in: Ltpv, Ltub, dgpv, dgub prepended to the extended keys. Ok so I get the convention you're using -- first two characters denote coin, ub/pv denote public/private. Is this a standard defined or discussed somewhere? The testnet version strings are problematic since yours are: ttpv, ttub, tgpv, tgub. This leaves only one character to denote the coin and in these cases already it's awfully ambiguous.

For altcoins something like XXmP/XXmp to denote mainnet public/private keys (where XX is the coin code) and XXtP/XXtp to denote testnet public/private keys would at least leave two characters to denote the coin.

DGmP/DGmp, DGtP/DGtp, LTmP/LTmp, LTtP/LTtp?

What are your thoughts?

I've added Litecoin support.

I wondered this as well, however, I think it's worthwhile to make the effort to keep the keys separate.  The same argument applies to standard addresses: there's no reason any of the altcoins changed their version byte.  Also, why not use the same version bytes for bitcoin test and main networks?

I am not sure if inventing special BIP32 versions for altcoins is a good idea.

There's no reason why you couldn't use the same BIP32 tree for all altcoins. Let's say path m/0/... for bitcoins, m/1/... for crapcoin and m/2/ for different shitcoin, etc.

I want to announce http://bip32.org, a JavaScript implementation of BIP32.  This project is based on my Multisignature P2SH project.

What is BIP32?

BIP0032 is a Bitcoin Improvement Proposal that describes a method to determinsiticly generate Bitcoin addresses and private keys. It also describes some really cool features such as public key derivation which allows you to generate new addresses without needing a private key.

Why should I care?

If you're like me, then you just care because this Bitcoin stuff is cool.  If you're not quite like me, then you're probably only interested in this if you like and/or use Brain Wallets.  This implementation allows you to produce Extended Private Keys based only on a single passphrase, which is in turn used to produce multiple Bitcoin addresses.  You have the advantage of deriving new addresses without ever needing to type in your passphrase.

How do I use it?

Simple. Type in a passphrase into the "Passphrase" box and tweak the value in "Account index".  If you select another derivation path, "Keypair index" is available to change as well.  The generated keys are shown at the bottom of the page, along with a Bitcoin address you can send coins to.  

In order to spend, copy the "Derived private key", change the button at the top of the page to "BIP32 Key" and paste in the key you just copied to the BIP32 extended key field.  Now copy the "Key" in the Key Info section.  This is the Bitcoin private key, and it can be used to spend by using the transaction generator at http://brainwallet.org/

More advanced users can use the site to do the following things:

• Inspect extended key information: Simply paste in the key, and the Key Info fields are shown
• Use any key derivation path you want: Switch the "Derivation Path" to "Custom" and enter your key path. The key must being with an "m". Variables "i" and "k" can show up in the path (k cannot be last), and you can only use private key derivation (using the apostrophe symbol) if the extended key you're deriving from is a private key.
• The public key/private key derivation method only describes whether the final Keypair Index is generated using Public Key or Private Key derivation.  If this doesn't make sense to you, ignore it and leave it set to "Public Key"

Thanks. Feedback appreciated!  Donations are welcome: 1NXvAo6tDoSxAqsrcNQ5PPJJM87gR4dHr7