An issue with blinded transactions is that a network-facing server at a business allowing blinded transactions needs to verify payments and with the scheme above this requires knowledge of the secret key “a”. (Used in the check of every new transaction for the property that s = Hash(m,aY) and X = sA).

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.

It’s 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 Alice’s 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.