Thanks for your comments; this is the sort of discussion I was looking for.
Thanks for raising some excellent points in your original post and starting this discussion.
Sorry, you're right, I got the parameter names mixed up. What I'm talking about doesn't have a separate parameter in the scrypt specification. In scryptROMix step 3:
3. for i = 0 to N - 1 do
j = Integerify (X) mod N
where Integerify (B[0] ... B[2 * r - 1]) is defined
as the result of interpreting B[2 * r - 1] as a
little-endian integer.
T = X xor V[j]
X = scryptBlockMix (T)
end for
There's no reason why that for loop (bolded) has to be from 0..(N-1); the loop could run more or less than N times. That's the parameter (the number of times that loop runs) that I was thinking of reducing. Of course you still have to populate the memory in the first place, which takes N operations, so this isn't a complete solution yet.
Scrypt already allows for some time-memory trade-off (TMTO, or, as Dave suggested, "tomato":-)
Reducing iterations will make those trade-offs all the more effective.
Hrm, not hashcash based in what sense? If you mean not in the sense of using a SHA-family function then sure, but Litecoin is already "not hashcash based" in that sense.
Of course, Litecoin is very much hashcash-based, as are most PoWs proposed these days.
I'm talking about hashcash alternatives like Primecoin, Momentum, or my own design,
Cuckoo Cycle (
https://github.com/tromp/cuckoo).
I had hoped the latter could require many GBs of memory,
but Dave Anderson recently pointed out a huge improvement in the algorithm
that slashed the memory requirements by a factor of about 21, meaning it would take
half an hour to run a 16GB instance with 20 threads...