GPU- "Proof" Hash Function?

Question

I’m thinking about developing a p2p network that requires a certain level of evidence of work for checking users (similar to Bitcoin) and regulating spam / ddos. Due to the nature of p2p, the only possible POW architecture I've seen is a solution validation model. Other challenge-response models seem very prone to Sybil attack, so I do not consider them.

Accessing hashes seems like a great way, but the GPU hash problem negates protocol validity by several orders of magnitude. In this regard, I am trying to identify hashing algorithms that are difficult / impossible to accelerate beyond the capabilities of a modern multi-core processor using a graphics processor.

Ideas?

Answer 1

My loop cuckoo protection scheme seems to fit the bill, as it is 5% of the calculations and 95% of random access to global shared memory, Delays. GPU memory is limited and has much worse latencies, and this is not enough computation to store more than a few dozen gpu cores.

Other features: it can require any required amount of RAM and is instantly checked.

See https://github.com/tromp/cuckoo for publication and implementation.

Answer 2

His entire arms race - while currently deployed hash functions are easily accelerated using the GPU, and newer / larger / longer hash functions are not (due to existing hardware limitations), because the technology will work on newer and improved equipment.

My first recommendation would be for the application to provide "hash packets" identified by a positive integer. Over time, you can switch to newer and more expensive operations, and new software tools will no longer accept evidence from sets of hashes with a lower number.

Also, be unconventional. Perhaps use a combination of all the new SHA-3 candidates (all of them, in some cascading series). Use block-cipher-hash algorithms (AES can be turned into an impromptu hash function). Do a lot of rounds. It may require signing with very large RSA keys (4096 bits or higher), and unique “discard” keys are also required.

You buy time, so the obsolescence mechanism is significantly more important than the choice of the actual algorithm.

Answer 3

I would recommend something like BCrypt, where the hash function has a variable number of rounds, usually in thousands. As long as the hashing function in the core of the algorithm remains secure, it may be more robust against brute force as time progresses, simply increasing the number of rounds.