Update bip-0044.mediawiki

[jprichardson]

Add constants for Litecoin, Litecoin Testnet, Dogecoin, and Dogecoin Testnet

[jprichardson]

Or even better... some deterministic way to generate the constants for each crypto currency? For sake of compatibility, keep Bitcoin/Testnet at 0 and 1 respectively.

[gavinandresen]

"BIP" stands for "Bitcoin" improvement process.

This belongs in LIPS/DIPS, in my humble opinion. I don't want to get dragged into which coins deserve constants in BIPS and which ones don't.....

[jprichardson]

"BIP" stands for "Bitcoin" improvement process.

Yup.

Coin type is a constant, set for each cryptocoin. Cryptocoin developers may ask for registering unused number for their project.

The list of already allocated coin types is in the chapter "Registered coin types" below.

Might I suggest removing the aforementioned then? Perhaps the entire Coin Type section? Or make a statement about delegating the constants to the authority/developers of each respective crypto currency?

[laanwj]

Agree with @gavinandresen here. Maintaining a list of altcoins is outside of the scope of BIPs.

Let's just leave ours (bitcoin and bitcoin testnet) specified, and leave the rest up to developers of altcoins themselves.

[prusnak]

@jprichardson We can talk about assigning particular numbers when there already is a working BIP44 wallet for coin. Then you can ask for assigning a coin type into this document: https://github.com/satoshilabs/docs/blob/master/slips/slip-0044.rst

Which is regularly deployed here: http://doc.satoshilabs.com/slips/

[dcousens]

Is there any reason not to use a deterministic process for this instead of a centralized register?
I understand we are currently constrained to 31 bits and truncating SHA256('bitcoin') or SHA256('litecoin') is probably less than ideal.

But we are only constrained to that if we continue to separate coins using a derivation index, instead you could embed the separation into the derivation process.

Perhaps data = serP(point(kpar)) || ser32(index) || 'bitcoin' would be simpler?

[prusnak]

@dcousens your second idea seems ok, but i'm afraid it's too late to change it now

[dcousens]

@prusnak why is it too late?

This is still a draft, and I'd argue the centralization of constants through a 3rd party arbitrator is a critical flaw.

[jprichardson]

@dcousens your second idea seems ok, but i'm afraid it's too late to change it now

Why is it too late to change it now? As far as I can tell, BIPs change frequently, and since this is in the draft stage, what could it hurt to change it to something that makes more sense?

[prusnak]

Because the change involves changing BIP-0032 which is Accepted for quite some time. That also means this is not the right thread to propose the change.

[dcousens]

Out of interest, why was the BIP32 constant Bitcoin seed not changed?
It seems like it was the most straight forward and intended value to change to enable a cross-currency BIP32 implementations using a single master seed.

Was it purely to adhere with BIP43?

[luke-jr]

BIPs are Bitcoin Improvement Proposals; "cross-currency" isn't a goal. (altcoins that wish to use Bitcoin-designed protocols are free to make appropriate changes without worrying about the BIP specification)

[dcousens]

@luke-jr I don't disagree, yet this BIP centralizes entirely around a coin_type.

Coin type is a constant, set for each cryptocoin. Cryptocoin developers may ask for registering unused number for their project.

[dcousens]

@prusnak it doesn't involve changing BIP32, it involves changing this BIPs use/implementation of BIP32.

[prusnak]

@dcousens right. but this is still something i would not rather do as it breaks compatibility with BIP32 and has couple of other disadvantages when it comes to implementation.

[dcousens]

@prusnak what are the disadvantages?