I think there is a deep misunderstanding here:
Blind signatures are not about
verification phase but about
signing phase :
Alice has a message m and wants Bob to sign it
blindly. i.e without disclosing m or leaking any information about it. Alice needs e= s(m,p
b) where s is the asymmetric encryption algorithm used (ECDSA 256k1 for bitcoin) and p
b is Bob's private key. The problem would be Bob generating e without becoming aware of original message m where he doesn't want to disclose his private key to Alice as well.
1- Alice first calcualtes m' = f(m) where f is a one way special function such that e(f(x), p) = e(x,p). Function f is a homomorphism but is not reversible.
2- Alice sends m' to Bob and he signs it by generating e= s(m',p
b). Bob has no clue about the actual message m being signed here.
3- Alice receives e from Bob and relays it to designated verifiers along with m (the original message) just like a normal signed message.
4- Verifiers check the signature e against Bob's public key and m without being aware of the blinding process at all and they will succeed because e= s(f(m),p
b) = s(m,p
b) according to the basic property of function f.
Blind signatures have various applications and as you may have already figured out, employing them in bitcoin is an application side issue and has nothing to do with full nodes and verifcation process.
For bitcoin ECDSA 256k1 encryption algorithm various blinding functions (f) has been proposed for instance:
https://eprint.iacr.org/2018/660.pdfI've no further information about the extents this technique is used in bitcoin ecosystem but the point is bitcoin nodes and their script processing engine are absolutely neutral in this regard and don't need to improve for supporting it.
