21:33 @gmaxwell signer with pubkey P generates k, sends R = kG to user. User computes blinding factors a,b computes R' = R + aG + bP ; e' = H(R' || M) - b sends e' to signer, signer computes s' = k + e'x; user computes s = s' + a, signature is r',s.
(I derived that myself, it looks right to me-- anyone have a citation for that protocol?)
Looks like an implementation could also easily support multisig blindsigning as well.
I think you want e' = H(R'||M) + b, both for correctness and so that e' can't be derived from the published signature.
I don't have a citation; the only blind Schnorr description I'm aware of is Matt Green's, which uses the (s, e) form rather than (s, r).
s,e is for batch hating suckers. :) Have a link to Matt Green's?
Oh, I'm misremembering :) Matt Green's post is here http://blog.cryptographyengineering.com/p/note-on-blind-signature-schemes.html and up to notation it's identical to yours.
Worth keeping in mind that a straight forward naive blind signing approach is vulnerable to extracting >N signatures from N parallel signature attempts by using wagner's algorithm to lower the rank of the challenges.
Closing as blind signatures are likely a better fit for secp256k1-zkp, until such time as there's a usecase for Core (or other "typical" Bitcoin users).