If you're smarter than me and see how to do it please let me know!
I believe I have a way to overcome the lack of nLockTime. Firstly let's observe that A can use the scripting language to pose B a problem to which A knows the solution, and which B can quickly verify is very likely to have a solution, and for which B cannot feasibly do any precomputation to calculate the solution faster than brute force.
One example of this would be for A to challenge B to provide a number X in some random interval of size 2^N such that hash160(X) falls in some interval of size 2^(160-M).
There seems to be no faster way to independently find a solution than for B to perform a number of hashes roughly equal to 2^M. If N is somewhat larger than M then anyone can verify that it's extremely likely that a solution exists. If the random interval is chosen over the range of 160 bit numbers and if N is significantly smaller than 160 it's unlikely that B will have chosen to precompute the hashes of any values in the interval.
So the proposal in my last post would have worked if there was something preventing A spending the inputs crediting B.
To solve this we arrange that before the start of the procedure B poses A a brute-force problem as defined above to prevent A spending the inputs crediting B without either the solution from B or alternatively exhaustively searching for the solution. B must be able to bound the amount of time A must spend to perform the exhaustive search as this will dictate how long B will wait for A to complete the next stage of the protocol. If A does not follow the protocol within a short-enough period of time then B will terminate or unwind the protocol.
There now needs to be some incentive for A to promptly sign Z by revealing the secret S after B has sent the the transaction crediting A, otherwise there's nothing preventing A performing the exhaustive search to spend the inputs of the transaction crediting B.
To solve this, we arrange that when A sends B the partially signed transaction A also sends an easier brute-force problem for B. When B constructs the transaction crediting A, he makes it so that it is alternatively redeemable by B if B has solved A's brute-force problem.
As soon as B sends this transaction to A he starts work on A's brute-force problem.
If A doesn't immediately sign Z by revealing S then B is very likely to solve A's problem before A solves B's problem. This means that B can recover the funds that were going to go to A and some time later A will solve B's problem and recover the use of the funds that were intended for B.
If A does immediately sign Z by revealing S then A must also publish a transaction which spends the transaction crediting A as B will be trying to solve A's problem and if B is successful before the A spends it then B will spend it instead.
So now B, knowing S can reveal the answer to the problem he posed A in order to allow the redemption of A's inputs to the transaction crediting B. B publishes A's transaction which credits him.
This isn't the clearest explanation nor am I sure that it's the simplest solution but I lack the time to improve it at the moment.
ByteCoin