Change Litecoin BIP32 constants to xpub/xprv

[bluen]

• correct litecoin bip32 prefixes
• adjust unit test data to match the updated prefixes

See https://github.com/litecoin-project/litecoin/blob/master/src/chainparams.cpp#L133 and https://github.com/litecoin-project/litecoin/blob/master/src/chainparams.cpp#L134

[dcousens]

Now I don't know who to believe.

https://bitcoin.stackexchange.com/questions/35403/how-do-you-determine-magic-byte-or-version-for-alt-coins

https://bitcoin.stackexchange.com/questions/28380/i-want-to-generate-a-bip32-version-number-for-namecoin-and-other-altcoins

libbitcoin/libbitcoin-system#319 (comment)

[dcousens]

@coblee is it Ltub or xpub for LTC BIP32 keys?

[coblee]

It's Ltub and Ltpv for Litecoin

[dcousens]

@bluen probably should submit a PR to litecoin-project/litecoin

[coblee]

Actually my bad! Turns out we never used Ltub and Ltpv and stuck with the same as Bitcoin. Sorry!
This pull request is good it turns out. Sorry for the misinformation.

[dcousens]

ping @richardkiss, @bip32JP, @sbuss

For
https://github.com/richardkiss/pycoin
https://bip32jp.github.io/english/
https://github.com/sbuss/bitmerchant/

You're implementations have the wrong constants too, it would seem.
We should probably be consistent.

[dcousens]

@fanatid breaking change? Its a "fix" technically...

[richardkiss]

This seems like a bad idea, since now tools that accept BIP32 keys will need to be explicitly told that litecoin addresses are desired rather than automatically inferring it. It's odd to change formats for addresses and WIFs but not BIP32 keys. Since several tools use these L prefixes, maybe there's an argument to be made that that's become the emergent standard?

[jprichardson]

Not to mention this important gem from BIP43: https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki#node-serialization - in practice, we (Exodus) use xpub and xpriv for all assets.

Because this scheme can be used to generate nodes for more cryptocurrencies at once, or even something totally unrelated to cryptocurrencies, there's no point in using a special version magic described in section "Serialization format" of BIP32. We suggest to use always 0x0488B21E for public and 0x0488ADE4 for private nodes (leading to prefixes "xpub" and "xprv" respectively).

[coblee]

Yes, we have decided that using "xpub" and "xprv" for all assets is easiest. Please update the code. We will reach out to other libraries and update as necessary. Sorry for the confusion! I believe "Ltub" and "Ltpv" were chosen by the BIP32 creators and was never really supported by litecoin core. And since HD wallets weren't use for Litecoin until recently, it was never an issue. It makes sense now to standardize with what Bitcoin uses.

[dcousens]

@jprichardson would you consider this a breaking change?

[dcousens]

@trezor, @prusnak, @slush0

[prusnak]

TREZOR was using xpub/xprv prefixes for all altcoins not very long time ago. We fixed that (6-12 months ago maybe?) to use the correct prefix (Ltub) to get in sync with another implementations. I think it might be better to fix one implementation (Litecoin Core) rather than fixing all of the remaining ones. (This goes against my claim in BIP43 about using xpub/xprv all the time, but I am pragmatic and when I see all Litecoin implementations use Ltub, let's have it this way for Litecoin).

Now, I know this is not the right forum, but I really need to express how dissatisfied I am with the behaviour of Litecoin people when it comes to standards. They change the prefix Ltub, now they want to change it back, leaving a TOTAL MESS among various implementations, because they don't have the same tempo of applying changes. Situation with P2SH prefix in Litecoin is even bigger issue. They changed it from "3" to "M" around time Segwit was activated and NEVER realeased a stable version of Litecoind which supports the new prefix, so most of the businesses are stuck to old method and cannot send to new "M" addresses.

Please, do some research before you say something or change something in fundamentals of your coin, ideally you should also be looking over at the whole ecosystem and provide a coordinating role, not causing confusion and incompatibilities. This is not Twitter, where you can change your opinion every few hours. These are standards where every change rolls out VERY slowly and during these transition period you HURT your users very BADLY. Please, do care more about your users!

[dcousens]

If we stuck with Ltub/Ltpv, that would mean the majority of libraries/tooling are consistent.
For interactivity with the Litecoin client or BIP43, technical users could tweak the network parameters where needed?

Otherwise, assuming we take a position of most compromise, we can maybe allow both?

Finally, we can do a breaking change, and reject a [current] majority of tooling.

Or, we could drop Litecoin support, considered harmful.

---

I don't have a strong opinion either way, this really needs to be a decision made by our users.

[coblee]

We can probably support both.

[dcousens]

@coblee if you support both, we can simply stay as is 😃 (and later support both, PR's accepted)

[coblee]

Yes, I think that's fine for now.

[prusnak]

I am fine with Litecoin Core supporting both (if that is what they want), but I want to make sure it is just for Core, not all tooling. TREZOR is not going to support both, just Ltub version, if we agree to use that.

[jprichardson]

TREZOR is not going to support both, just Ltub version, if we agree to use that.

Exodus won't support both either. We'll stick with BIP43. Big picture, though, IDC - this feels like borderline bikeshedding. This library should just keep it as-is and we can revisit when we continue to breakdown bitcoinjs-lib to increase the maintainability.