Talk:List of address prefixes
Shouldn't the line 128 5 Bitcoin Private key 5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq be 128 t Bitcoin Private key tHtn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq according to 127-128 t 34 ? --ThePiachu (talk) 01:59, 27 June 2012 (GMT)
What is the policy regarding addresses which are not altcoins but which relate to protocols being built on top of bitcoin? I think there is value in some kind of registry for such protocols to prevent address clashes, and help users know the purpose of different addresses. But I don't want to overstep if that's not the purpose of this page. --gidgreen 7 July 2014 (GMT)
- I'm not sure what you mean by that. Altcoins abusing bitcoin's blockchain are still altcoins. Also note that the version byte is for a version, not a namespace. CoinSpark seems to be inserting a "features" in the address. It makes sense to have this, I think, but it should be based on version 5 addresses (p2sh), not the obsolete version 0 (p2pkh)... Perhaps more importantly, this should be proposed on the development mailing list and made a BIP before appearing on this page. --Luke-jr (talk) 20:47, 7 July 2014 (UTC)
- CoinSpark is not an altcoin. It's a protocol for enriching bitcoin transactions via OP_RETURNs. Of the 5 features on the current roadmap, one is a variant on the idea of colored coins (I don't know if you would call that an altcoin or not) but the rest are all about making regular bitcoin transactions easier and more useful. I imagine it will be one of many such protocols which come out during the coming years, and I think there is sense in avoiding addressing clashes between these different protocols. As you say, [CoinSpark addresses http://coinspark.org/developers/coinspark-addresses/] encode several types of information but this is not really appropriate for a BIP since it's not an enhancement to the bitcoin protocol itself. (Think TCP/IP and the Web.) So what mechanism would you suggest for avoiding addressing clashes?