biblepay coin BBP is cpu mine coin.

Vertcoin current protocol (lyra2rev) seems to be ASIC resistant  for now.

true ASIC resistant coin like VTC

Very cool and very interesting! I've always wondered why it never appears feasible to utilize a compression algorithm to shrink the size of the proof in this case, or compress data inside blocks in the case of btc.

I think the average data can be shrunk via compression is often by a factor of 1/3rd. From an amateur perspective, being able to fill roughly 3x the amount of data per size would seem to be a worthwhile approach. Especially as compression isn't particularly resource intensive, at least not in comparison to mining cryptographic functions. Adding a compression abstraction layer woudn't appear to bottleneck the process. But I would guess I'm missing some important point here as crypto engineers never seem to bother with compressing data?

Monero is memory intesive algo.

If Bitmain is able to create ASIC for memory intensive algo, probably they'll target ethereum (ethash) first

If one collects collisions on a central server (the most efficient way to find a lot of collisions in a big pool), one needs about 3 billion hashes to create 25 million 4-way collisions.  If one can live with 5 seconds delay (i.e. blocks miss some high-fee transactions from the last 5 seconds), one can  reduce this to 5 billion hashes in 5 seconds,

and verium is bad. it takes a long time to mine and the amount you get per block is tiny. Not really worth it from my 1 day experience

I'm just wondering if the Travelling salesman problem could be used as a PoW algorithm?

The calculation of the AE is slightly off, fixing now.

I propose if you're going to change Bitcoin's proof-of-work to something other than the current SHA-2(56) to something else then you might as well go all in on SHA-3 to make it even more secure against near-future quantum computing technology (which governments may already have).

SHA-3 does that.

There is a (v)movntdq(a) instruction (sse 4.1+ I think) that bypasses cache operations for faster mem writing if the data involved aren't going to be cached in any useful way. You might want to check whether it's useful for this case.

If anyone's interested Aeternity has a testnet running using Cuckoo Cycle https://github.com/aeternity/testnet

As you can guess from the title, I've made a benchmark list for Equihash. I've gathered info from bitcointalk and the Zcash/Zclassic chats/forums. The list is not yet complete (it will most likely never be since the miners get updated so often and plenty of new cards are coming up this year).

Much of the data is being hard to get without first hand experience but I managed to gather some, this is the list at the moment: https://zdeveloper.org/wiki:zcash_mining_benchmarks
I'm waiting for corrections and updates. Maybe it will helps some people decide which cards to get next time they assemble a rig. 

I understand that the miners don't want the lighting networks and I understand why - because it goes against their interests.

This seems to imply you are holding your bounties in bitcoin.
Since this is targeted at the bitcoin community, I assume you are also paying them in bitcoin.
Why, then, do you advertise the bounty amounts in dollars instead of in bitcoins?

I tried to compile this but failed due to non avx2 use, so it did compile some of the files... so I run cuckoo28:

perf stat -d -d -d ./cuckoo28

Further perf stats indicate a lot of overhead here (the cmpxchg stalls the jump?): http://imgur.com/a/zwEmP
(data obtained by running perf top while ./cuckoo28 was running).

Given that this was on a single thread, couldn't this be done with plain unlocked moves? Also, in multithreaded applications, would it be possible to gamble faster unlocked moves trading data accuracy in order to produce a faster version with possible data corruption?