Are the devs even working on it? We have multiple proposals for mitigation of the attack now, is the problem in selecting the course of action or in executing it?
I agree, no sense.
I've detailed in my last post, let me know if you need more explanation/clarification.
This is some huge and complex change to the whole blockchain semantics.
Not really. It ultimately just changes the meaning of "one confirm" to mean "1-to-N blocks deep" instead of "1 block deep" resulting in effective network security being reduced by a factor of up to N. (And arguably only for the last N blocks!)
Otherwise what impact on semantics do you see?
I still don't understand how are you going to add transactions if you generate map only based on previous blocks.
We also already covered this earlier as well. In most blocks (assuming bots maintain majority of hashing) there will likely be no effective change, since botters will likely always submit their blocks with a map seed based on the "new" block itself, and thus securing the transactions at that moment. In the case where a new block is submitted based on a map seed 1 block deep, the new transactions are not at all secured ("yet") and the additional confirmation strength is given to the prior block. The new transactions in this new block may not actually be confirmed at all for 3 more blocks, but will be eventually. Similarly for 2 deep, and so on.
But anyway, this would require a lot of time to work out this scheme and a lot of changes to client.
Not really. The work structure given to motogame would need to be expanded to include data for the prior N blocks, the g_HasNextWork flag semantics would need to be modified some, work validation would need to check against the correct block data, and confirmation numbers would need to be divided by N. What else would need done? I could probably work up this patch in under a day of dedicated time.
If the developers are not committing to resolving these issues then they need to let us know.