However a limitation with key stretching is it incurs computational load on the client, which maybe a smart-phone or single desktop class machine.  eg 16384 scrypt iterations are suggested in BIP 038, chosen to be fast enough to tolerate in javascript.

So it would be desirable to have a secure server offloadable KDF, which means a kind of blindable deterministic proof-of-work.  

So I had a go at deciphering BIP 038 in summary what I think its doing is (ommitting lot and sequence and deterinistic IVs for simplicity):

user:

x1 = Scrypt( salt=random, pass )
P = x1*G

send (salt, P) to coin manufacturer ->

                                manufacturer:

                                x2 = random 24bytes
                                Q = x2*P
                                k = Scrypt( salt2=H(Q)||salt, pass=P )
                                e = AES_k( x2 )

                                manufacturer puts e inside coin.

                <- send coin, (salt, e, Q) to user

                                then optionally creates conf code:

                                B = x2*G
                                c = AES_k( B )

                <- send conf code c to user

verify code c:

(by recreating P, then k from Q & P, decrypt c to get B, check Q = x1*B)

x1 = Scrypt( salt, pass )
P = x1*G
k = Scrypt( salt2=H(Q)||salt, pass=P )

Which seems reasonable enough, however its unfortunate that you have to repeat the Scrypt work at setup.

One thing that occurs to me eg as mentioned by Rivest et al in their time-lock puzzle paper is that it is easy to create work, if you are ok with parallelizable symmetric constructions (like scrypt(i) or PBKDF2(i) with i iterations) without *doing* the work during setup.

It seems to me therefore that the above protocol could avoid the javascript overhead issue that forces users to choose a weak iteration level if they want to create the wallet in that way.

eg create a 32-bit random salt, replace scrypt(i=16384, salt, pass) with scrypt(i=1,salt, pass) to be brute forced based on deleted salt.  Immediate 2^32 = 4billion iteration salt without any significant setup cost.  (Or if you want to limit the parallelism say scrypt(i=65536, salt, pass) with a deleted 16-bit salt.  That should be parallelizable up to 65536 GPU cores (32x 7970 chips).

Symmetric time-lock puzzles can achieve decrypt asymmetry without repeating the work at setup...

(Rivest et al go on to avoid using that symmetric construct with an RSA related mechanism, because they are trying to lock information for an approximate future date, rather than protected by a specific amount of grinding work.)