Stealth Payment IDs 0.8.5

/*Stealth Short Payment IDs - proposal for shortening both "user" and "blockchain" payment IDs to 64 bit, incorporating a stealth feature to improve anonymity, and adding a new shorter v2 integrated address

We are basically discussing three different aspects here, which aren't strictly related:
1. Stealth IDs, which change every TX, just like (or rather, similar to) addresses

2. Shortened IDs, less characters to display, copy, store, etc. The current space 2^256 is absurdly large and unnecessary; this proposal reduces size on chain to 1/4th.
Example Addresses:
Standard (95):
45BEPXEXAN6YrvHgP3owF8GCzBZ2vCZNb9sMxZG6D7iuSvjVret5ciY2GfqVMHZiPoTEEcmSmVhcyaReTjJafrSqV26ZoYE
64-bit ID integrated (106):
4TZ76dT4mbsizsTtJzy7kYBo9f8xduc8wTsWb86pCmx5Cmh43CDxNS1FRcMrE3CNQ2ZT17vzCudc5TbNYBzizwqZFah5K1Js7VpL88qPSi
Full 256-bit ID integrated (139):
4LRv6jJYxh5Ba1Z4UfCZYmTzP7g1mP5uUC32KgWcMtBi2QV6xGjHpqs5ZeEnpAwaWVNgF7b7xtumQGoL9posmQMfRvFupJBXkZyWGdcDizfMUAiEgrG7cA98yf6vcqJzZT1EPg8A69e

3. New (v2) integrated addresses to replace/deprecate v1, which isn't in use yet.

We want to get the payment ID scheme to a point where it is ready for years of use with no further changes. To maintain compatibility with the current payment ID scheme during the transition, stealth payment IDs will only be generated by default through the use of integrated addresses. Thus, when recipients are ready to accept the new stealth version, they'd hand out integrated addresses.

This new 64 bit ID will be given a new tx_extra nonce tag: 0x01 (current payment ID is 0x00).

With 64 IDs, there's a non-negligible chance for collision if randomly generating. So recipients generating them randomly are advised to sanity check them for uniqueness.
Example: 1 million IDs at 64-bit (simplified): 1,000,000^2 / (2^64 * 2) = ~1/36,893,488
50% chance happens around 5.06 billion IDs generated.

For reference to those unfamiliar with the integrated address in current head, it looks like:
"netbyte (0x13 [standard Monero is 0x12])" + "32 byte public spend key" + "32 byte public view key" + "32 byte payment ID (8 byte proposed for v2)" + "4 byte checksum of all previous data"
*/

/*
For our stealth key, we will use a derivation of the shared secret used for public key generation. The varint encoding used by output indices gives us 128 1-byte options to use as part of our key:
0x80 - 0xFF

I've not come up with any not-completely-arbitrary choice, so here's an arbitrary one: charcode(I) + charcode(D) = 0x49 + 0x44 = 0x8d

encryption key = H(sharedSecret + 0x8d) // "+" is append
*/

//apologies for using javascript, it's the easiest way for me to express the implementation proposal
//using cnUtil.js from mymonero.com for functions

//---------------------------------------------------------
//proposal 1.5 (older ideas discarded as subpar and/or unscalable)
//xor payment ID with one-time key
var receiverKeys = create_address(rand_32()); //for example only
var payId = "0123456789abcdef"; //64-bit example
var txkey = random_keypair();
var der = generate_key_derivation(receiverKeys.view.pub, txkey.sec);
var stealthKey = cn_fast_hash(der + "8d").slice(0,16);
var encPayId = hexXor(stealthKey, PayId); //JS can only xor numbers, made up function to xor hex strings

//receiver would:
var der = generate_key_derivation(txkey.pub, receiverKeys.view.sec); //txkey.pub from tx_extra
var stealthKey = cn_fast_hash(der + "8d").slice(0,16);
var payId = hexXor(stealthKey, encPayId); //encPayId from tx_extra
//*compare payID with known set*
//---------------------------------------------------------


//Feedback welcome,
//luigi1111