Quote from: shesek on January 02, 2014, 03:39:14 PM

Its a really thin abstraction layer and doesn't require any protocol changes

It does require the payee to publish his full public key. That is not common practice today. Bitcoin receive addresses are hashes of public keys and can't be used to derive related keys.

Nice idea, though. See this related topic:

Quote from: ffe on April 11, 2013, 06:39:01 AM

This added note is to show how Alice allows a server fronting her business to verify that she owns a blinded transaction without requiring the server to have her secret key thus protecting her wallet if the server is hacked.

Its done this way:

Alice generates a secondary key used to verify blinded transactions from her master key. Her private key is a. She generates a verifier private part b by hashing a, b = Hash(a). Let the public part of a be A and the public part of b be B. A = aQ and B = bQ. The doublet A,B is published as the blind transaction enabling public key. A,B and the private verifier b are given to the server she is using to manage monitoring the block chain for her. With b the server can verify transaction ownership but not spend. Hacking the server does not give you a.

A sender would recognize A,B as a blindable key. The sender then generates "X" as follows: s = Hash(m,yB); X = sA. The sender sends coin to X.

A server holding verifier "b" can check every new transaction for the property that s = Hash(m,bY) and X = sA to know to add the coins to the balance in Alices wallet. (Note yB = bY). Notice that the server does not need a to verify the transaction. The server can verify X but cannot generate the private part of X.

Alice later generates "x", the private part of "X", as follows: She is given m and Y from the transaction; then s = Hash(m,bY); x = sa (modulo a large prime determined by the ECC); She can check that X = xQ. Alice can now sign a prepared transaction using x and publish the signed transaction when spending.