Reserve coin type 2 for Litecoin (implemented in Electrum-ltc)

[slush0]

BIP44 has list of reserved coin types other than Bitcoin, please accept this simple pull request which make reservation for Litecoin.

[luke-jr]

NACK, Off-topic.

[slush0]

It's on topic in context of BIP44.

[luke-jr]

Bitcoin Improvement Proposals are for Bitcoin.

[slush0]

Ok, then please remove BIP44 from BIPs completely, we will use our own repository for such specifications. Such discussions about every single line are really annoying.

[gavinandresen]

ACK.

[andre-amorim]

:. Andre Amorim .:

Key-ID:

A70B444E

Fingerprint:

FAAD3B6556A8877B938EAB2FC05E2CB0A70B444E

On 16 August 2014 01:51, Gavin Andresen notifications@github.com wrote:

ACK.

—
Reply to this email directly or view it on GitHub
#93 (comment).

[jgarzik]

ACK

[luke-jr]

@slush0 Discussions are to be expected for BIPs; that's the whole point of collaboration. It isn't merely a tool where one person asserts their pre-decided 'authority' on others, but one where multiple people discuss and come up with a standard that works for everyone. With regard to this specific case, the change clearly goes contrary to the purpose of BIPs; one reasonable/workable alternative would be to reserve all numbers outside of Bitcoin and testnet for an external number repository. I appreciate your efforts to collaborate, but please don't expect to simply get exceptions because you threaten to stop collaborating.

@gavinandresen @jgarzik You're setting a dangerous precedent ACKing things because of threats made. (Edit: My apologies for jumping to conclusions if that isn't your actual reason)

[jgarzik]

@luke-jr Something receives my ACK here because it is the right thing to do, from a technical perspective.

[luke-jr]

@jgarzik Please explain how defining standards for Litecoin in any way improves Bitcoin. BIPs have had a certain policy against defining altcoin things up to now.

[bip39JP]

@luke-jr I understand the idea of keeping BIP about Bitcoin, but in reality, most alt-coin devs come to the Bitcoin bips section to gather information on implementing BIP protocols into their alt softwares.

tbi I think BIP32 is less about Bitcoin and more about crypto in general (as it defines a method to generate Public private keypairs.) and so I think that it seems prudent to have an index of standardized usages in a place where anyone looking up the protocol will see them.

This prevents things such as Hive-js (web.hivewallet.com) which uses the same m/0'/0/k for both Bitcoin AND Litecoin. (revealing the same public keys on both blockchains.)

(slightly OT, but this is why I personally think that BIP32 should add a prominent link pointing to BIP44, and the m/0'/0/k stuff on BIP32 should be moved to BIP44 as a "This is what people used before BIP44" side-note instead, but that's another discussion for another day)

[gmaxwell]

@luke-jr "Please explain how defining standards for Litecoin in any way improves Bitcoin" It prevents conflicting or colliding use. If it were a case that extensive specification were required I'd say instead the LTC specific things should be specified elsewhere and we should have a reference saying that codepoint is reserved for that other use. ... but here where only the fact that its reserved for litecoin is harmless.

Some color on this— there is some amount of discomfort in the Bitcoin technical community where people involved in some altcoin or another exploit Bitcoin's adoption and brand to promote their own thing (e.g. if you call for speakers on Bitcoin you will often be flooded with people who will really spend 80% of the time talking about some alt thing) and create an appearance of increased legitimacy. This has created some understandable discomfort for Bitcoin people who feel that altcoins are taking without giving back... and it's a legitimate reason to not expend a bunch of resources on some alt BIP proposals. It's often hard to define a good inclusion criteria other than none or all ... but I think at this point we've now already wasted a bunch of effort by discussing it at all, when it's just a harmless entry.

On that basis— ACK, though if later it seems that we're being flooded by requests to register other altcoin IDs especially for altcoins which are not widely used ones I'm going to come back and suggest that we go and break out these definitions into some registry of altcoin version IDs, instead of individual specifications (and perhaps suggest we setup some natural rate limiting procedure for it (like paying bitcoin mining fees). :) I don't want to be in the business of gate keeping which altcoins can get listed, and yet also don't really want to be degrading the documents with altcoins which have intentionally offensive names or which are widely regarded as malware or other such nonsense.

[luke-jr]

Even aside from what's already been discussed, maybe there ought to be a numbered "crytocurrency namespace id" registry that can be used by multiple protocols, including this one, but also including others (like the payment protocol, if it didn't use strings already). This avoids not only trying to iterate every possible altcoin here, but also having to iterate altcoins for every protocol that wants to represent them by integer.

[laanwj]

Pulls like this have been closed unmerged many times.
See #83, #76
Not sure why it now suddenly gets ACKs.

[luke-jr]

Wow, the exact same change too. I suggest we go ahead and merge #84 - it's been sitting there for a month and looks quite reasonable.

[slush0]

Okay, I'm fine with #84. If you merge that, please ignore and close this PR.

[laanwj]

Closing in favor of #84