I had an idea for a payment scheme that uses key derivation, but instead of the payee deriving the addresses, the payer would do it.

It would work like that:

• The payee publishes his master public key
• The payer generates a random "receipt number" (say, 25 random bytes)
• The payer derives an address from the master public key using the receipt number and pays to it
• The payer sends the receipt to the payee
• The payee derives a private key with that receipt and adds it to his wallet

Advantages:

• It increases privacy by avoiding address reuse
• The process is asynchronous. The payee is completely passive in the payment process and isn't required to provide new addresses before each payment (no payment server required)
• Its usable as a replacement for cases where re-used addresses are the most viable solution (like putting an address in a forum signature or as a development fund in a github readme)
• The receipt also acts as a proof of payment that the payer can provide to the payee
• Also, if the master is known to belong to someone, this also allows the payer prove to a third-party that the payment was made to that someone. If the output was spent, it also proves that he was aware of the payment and has the receipt.
• Its a really thin abstraction layer and doesn't require any protocol changes

Disadvantages:

• Losing the receipt numbers means losing access to your funds, they are random and there's no way to restore them
• It requires sending the receipt to the payee somehow. Email could work for that, but a better defined channel that also can talk to the Bitcoin client and add the receipt would be much better.

What do you think?