I don't remember who stated it above, but I do agree that the lack of exchange/merchant adoption might have something to do with the hassle of depending on users to include payment IDs.
Pay ID serialisation into the receiving address looks pretty far down on the roadmap. In the meantime, is there a reason why Payment IDs can't simply be appended to the address and parsed automatically by the client? That would make it much easier for third parties to manage payments until "stealth" payment IDs eventually get implemented.
Pay ID serialisation into the receiving address looks pretty far down on the roadmap. In the meantime, is there a reason why Payment IDs can't simply be appended to the address and parsed automatically by the client? That would make it much easier for third parties to manage payments until "stealth" payment IDs eventually get implemented.
No checksum is one reason why this will potentially backfire. That and the payment ID space is unnecessarily huge.
I'll take a look at my notes from the MRL meetup in November last year, we had some ideas about fixing the payment ID format and serialising it, there may be a quick win to be had whilst we chip away at the stealth payment IDs.
Adding the payment ID with checksum seems fairly simple. I went and created a test address just now:
Code:
Standard Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byMUKoz6m
Payment ID: feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed
Payment ID: feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed
Code:
Integrated Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byXSb563RKvyBgorjsFGwyx9gorjsFGwyx9gorjsFGwyx9TpPbbCy
What I did:
Instead of the standard hex format - ('12' network byte) + (public spend key 64 digits) + (public view key 64 digits) + (checksum 8 digits) - I stripped the checksum and appended the payment ID, then recalculated and appended the new checksum. This creates a 101 byte address instead of the standard 69 byte, and 139 "Public Address" characters vs 95 standard.
cnBase58 --> hex the above "Integrated Address" and you get (separated for clarity):
Code:
12 55a1e49673f5a8faa6ba4f942585695ceee5c7522496be6fc38d3f09905e3f8b ca6313deac11aff9a7241e7095863b0be3099d50d7a0cd11e0adbcf4990e64b5 feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed b1d0950e
The code just needs to check for length to determine the type. Alternatively, (I don't know what all the other cryptonotes are using) the network byte could be changed to 0x13 or something for the "Integrated Address".
Looks very nice. Something like this seems like the way to go, especially in that it can be recognized as a different address type. You can shorten the pid (and the whole thing) by converting it to base58 instead of hex.
Thanks. On your last sentence, I'm not sure if I was clear: the base58 version is above in the code section "Integrated Address". That would be the version you'd actually use. The hex version at the bottom was for explanation only.
