I disagree that we need to do nothing while we work on something better (obviously one does not preclude the other at all).
There is no checksum now. The length and valid characters are checked but that's it. The exact same thing can still be checked if the format is changed, slightly to something like
Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em-e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac
Instead of
Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em
and use this payment ID
e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac
It is the exact same thing in terms of checksums, validation, etc. except that the second is far more likely to lead to people forgetting it or not understanding it, and also fits worse with the usual workflow of a btc-style coin where people generate new addresses for each customer/invoice/etc., and has a higher support burden. With the first method, you have have the exact same kind of button in an exchange wallet window that says "generate new address" and it can go ahead and generate a new address that happens to share the same prefix, instead of needing something different for "payment-id coins".
We're suffering this unnecessary mismatch from the usual model and confusion because the cryptonote/BCN guys didn't see the need for a payment ID at all in their earlier design at all and threw the payment ID on there later as an extra thing instead of including it in addresses (there are commits in their repo when they added it, so it is clear it was an added patch). If it were part of the original design I bet something more like the prefix-suffix syntax would have been used.
I noticed someone talking about the address + payment id topic a few weeks back, but didnt really think about it. Now Bassica pinged me about it and got me thinking about it.
The reason why someone suggested the idea was to fix the problem of Bitcoin users not paying attention to the payment ID field and making deposits the recipient cannot match, if I remember correctly. (Didnt find the original post or the source of the idea, so it might not be correct.)
I agree that the amount of data the users currently have to insert is close to insane, but I dont think stuffing the extra data into the actual destination address will make it better.
Instead it will make the address technically more complex (instead of 2 bits of information it would be storing potentially 3). Also one has to remember, if you introduce such feature you can pretty much never remove it.
From the technical side (of how payment ID is implemented) such solution would present user experience nightmares. Currently the payment ID is associated with the whole transaction, not the destination. If we had addresses which included the payment ID we would soon get users who would want to pay to several of those addresses, but since this is technically not possible we will forbid that. Now if the user did not care about the payment ID in one of the addresses there would be no easy way to just throw the payment ID out of the address.
The only good thing about the proposal is that the payment ID gets checksummed. But considering the amount of data users currently have to enter already, I dont think its feasible to think that anyone does it by hand - thus the importance of checksum on that data diminishes.
So lets think of the original problem and if this truly is the solution.
In Bitcoin when users deposit money the have to use unique addresses. This is due to just Bitcoin limitations. In traditional banking when paying your phone bill you always have to fill in the reference field as well. So we can safely say that its just a bad habit that users picked up from Bitcoin that they expect a unique account number to deposit their money into.
Lets think about how users can pay on a website.
- Using a mobile wallet. Entering the address manually is not an option. User friendly options for mobile is QR code. They can embed the payment ID in it without changing anything in the Monero address format. OpenAlias can be used as a fallback.
- Using a desktop wallet. In this case the desktop wallet should install some URI handler, which would allow the user to just click a link on the payment page which would open their wallet. Again, this URI can include the payment ID, thus no need for any changes in the Monero address format. OpenAlias can again be used as a fallback.
- Using a command line wallet. The website should just display the whole command for simplewallet users, which they can copy-paste into the terminal. But lets be honest nobody should expect non-technical Monero users to keep using simplewallet after a better alternative is out. Alternatively simplewallet could implement a new command to pay to payment URIs. That way users can Copy link address from web and paste it into simple wallet.
None of those use-cases could justify creating a new Monero account address format.
What responsible wallets could also do, to educate users about the reference field (payment IDs), is to prompt the user if they really want to leave the payment ID field empty. That way the users at least confirm that they know what theyre doing if they transfer money with an empty payment id.
Currently there are 3 (?) Monero wallets: simplewallet, MoneroX and MyMonero. One command line wallet and two friendly looking wallets. The simplest short-term fix until the URI formats are worked out, would be to show the whole simplewallet transfer command and for MoneroX and MyMonero to confirm empty payment ID from users.
Long story short: if someone does implement the address+payment ID in one address in the format it has been proposed I would be against it. However, I would fully support working out a URI scheme (think BIP21) which could be used to pay a single entity (ie help merchants to receive payments with correct IDs and cut down on support queries).
