Stealth Payment IDs 0.7.8

/*Stealth Short Payment IDs - proposal for shortening "user" payment IDs (to 64 bit) while keeping full 32 byte "blockchain" payment IDs, incorporating a stealth feature to improve anonymity, and adding a new 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, etc. The current space 2^256 is absurdly large and unnecessary, but whether that justifies changing (while the "network" version remains 256-bit), I'm not sure. CN addresses are "long" in any case, but I believe there's a cutoff point around 110-120 characters that results in line wrapping even on 1080p screens on many webpages. I think it's warranted to try to keep it under that bound if there is little reason not to. I guess it boils down to: is public address space precious even though it's already very long, or is "wasting" more characters not of any/much consequence?
Example Addresses:
Standard (95):
45BEPXEXAN6YrvHgP3owF8GCzBZ2vCZNb9sMxZG6D7iuSvjVret5ciY2GfqVMHZiPoTEEcmSmVhcyaReTjJafrSqV26ZoYE
64-bit ID integrated (106):
4TZ76dT4mbsizsTtJzy7kYBo9f8xduc8wTsWb86pCmx5Cmh43CDxNS1FRcMrE3CNQ2ZT17vzCudc5TbNYBzizwqZFah5K1Js7VpL88qPSi
Full 256-bit ID integrated (139):
4LRv6jJYxh5Ba1Z4UfCZYmTzP7g1mP5uUC32KgWcMtBi2QV6xGjHpqs5ZeEnpAwaWVNgF7b7xtumQGoL9posmQMfRvFupJBXkZyWGdcDizfMUAiEgrG7cA98yf6vcqJzZT1EPg8A69e

3. New (v2) integrated addresses: not strictly necessary, unless implementing 2 as well.

Part of the idea is to not keep changing things all the time, so it seems reasonable to (at least try to) get it into a state where it can operate for years with no additional changes. #3 acts as a nice way to "tie it up with a bow", because shorter is better than longer (right?), and it creates an easy way to "enable" stealth IDs as the receivers take the time to implement them. If you just implement tx construction logic for stealth IDs, the existing payment ID implementation breaks (that seems bad). Thus if a receiver hands out v2 integrated addresses, they would be expected to support stealth IDs; if not, then use old method.

If shortening "user" payment IDs gets a general nack (there are some possibly valid considerations about out-of-band revealing of unwanted data by the ID generator/higher chance of "accidental" collision, etc, with a smaller set size), I would recommend the solution be to re-purpose the "existing" integrated address to use stealth logic (since no one has implemented it yet, it's not in a tagged release, etc) and continue to treat manual payment IDs the same as today (untouched). Even with consensus for shortening, I still feel it appropriate to "overwrite" v1 integrated addresses with the new short version; since no one supports them yet, we can avoid supporting them into perpetuity.

Chance of collision for randomly generating 1 million IDs at 64-bit: 1,000,000^2 / (2^64 * 2) = ~1/36,893,488
50% chance happens at 5.06 billion IDs generated.
If receivers are randomly generating IDs (and they should be, to avoid revealing data to their customers) with non-negligible chance of collision, values should be checked against existing.

For reference to those unfamiliar with the integrated address in current head, it looks like:
"netbyte (0x13)" + "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"

Another option for v2 integrated addresses is variable length IDs. This loses the consistency of all addresses being the same cnBase58 and hex length (BTC has the same hex length, but variable base58 length), but is only marginally more difficult for wallets to parse and account for.
*/

/*varint analysis for key generation for those unfamiliar with varint encoding (I was)
1 = 0x01
127 = 0x7f
128 = 0x8001
129 = 0x8101
255 = 0xff01
256 = 0x8002
16,383 = 0xff7f
16,384 = 0x808001
16,385 = 0x818001

We have to avoid using any valid varints, as those are used for output indexes. 0x80 - 0xff gives us 128 options using only one byte. I've not come up with any not-completely-arbitrary choice, so here's an arbitrary one: charcode(I) + charcode(D) = 0x49 + 0x44 = 0x8d
*/

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

//---------------------------------------------------------
//proposal 1.4.2 (older ideas discarded as subpar and/or unscalable)
//pad the short ID to 32-bytes, then xor with our one-time key
var receiverKeys = create_address(rand_32()); //for example only
var payId = "0123456789abcdef"; //64-bit example
var paddedPayId = payId;
while (paddedPayId.length < 64){paddedPayId += "00";}
var txkey = random_keypair();
var der = generate_key_derivation(receiverKeys.view.pub, txkey.sec);
var stealthKey = cn_fast_hash(der + "8d");
var realPayId = hexXor(stealthKey, paddedPayId); //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");
var paddedPayId = hexXor(stealthKey, realPayId); //realPayId from tx_extra
//*compare paddedPayID.slice(0,16) with known set*
//---------------------------------------------------------


//I appreciate any and all feedback!
//luigi1111