A method to receive payments at obscured addresses The background:


We assume that coin ownership and payments are recorded on a public ledger.
Suppose Alice wants to publish some information to let her receive coins from anyone.
But she does not want to receive coins at a publicly known fixed address.
Instead, she wants the payer to generate a unique destination address each time.
The payer must not know the private key for the address; only Alice will know it.


I want to know if the following algorithm will achieve these goals. This combines Diffie-Hellman key exchange plus any digital signature algorithm. Are there subtle flaws that I am missing?


Suppose we use an elliptic curve for Diffie-Hellman, and $G$ is a publicly agreed base point.
Alice chooses a secret integer $a$.
Alice computes the public point. $A = a×G$
Alice publishes the statement "Alice will receive payments derived from the number $A$".
Alice will not change this statement for a long time (years, many payments).
Bob wants to pay Alice, so he retrieves Alice's value $A$ and will derive a new public key.
Bob chooses a secret integer $b$.
Bob computes the public point $B = b×G$.
Bob computes the shared secret integer $s = \text{hash}(b × A) = \text{hash}(b × a × G)$.
Bob computes the public key $K = A + s×G = a×G + s×G = (a + s) × G$.
Bob sends his payment to the address $K$, and also mentions the point $B$ within the payment message (recorded on the public ledger).
Bob tells Alice out of band, without using the public ledger, about the payment info $(K, B)$. This step doesn't need to be secure, but should be kept off the permanent public record.
Alice computes the shared secret integer $s = \text{hash}(a × B) = \text{hash}(a × b × G)$.
Alice computes the private key $k = a + s$, which corresponds to the public key $K$.
Now Alice can spend the payment she received from Bob, by creating a signature using $k$.
Your algorithm should be secure since it's basicly the same as the "one-time-address"-algorithm in the CryptoNote protocol, which is described as following:


Alice generates two secret keys $a$ and $b$ and publishes $A = aG$ and $B=bG$.
Bob, who wants to send a coin to Alice generates a random $r$ and publishes $R = rG$ and $P = H(rA)G+B$.
Alice (or any party knowing $a$) can check weather a payment belongs to Alice by checking whether $H(aR)G+B = P$. Note that this does not require $b$, so Alice can let any other party check for payment by sharing $a$ without risking them to spend her coins.
When Alice want's to spend the coin, she calculates $x = H(rA)+b$, which is the private key for $P$ since $P = xG = (H(rA)+b)G=H(rA)G+bG=H(rA)G+B$.


Your scheme is a variation of this algorithm with $a = b$ so that $A = B$. This leads to Bob calculation $P = H(rA)G + A$, a check can be performed with $H(aR)G+A = P$ and the secret key being $x = H(aR)+a$, so you can assume it being as secure as the CryptoNote's algorithm (which is pretty secure AFAIK), however you lose the ability to share a view key to let others search for transaction for Alice.