Not just the parameters, but the algorithm just changed this weekend? And no longer follows the paper? How are we supposed to code for a moving target like this?
Totally understand your concern that's why we haven't released the MTP miner bounty challenge yet. We will be releasing the details sometime this week which should give people more than a month to code miners.
Dude, this isn't about your beauty pageant. Radical last-minute changes like this guarantee that the best miners will be the ones that exploit some bug you introduced while frantically trying to plaster over another bug. And they will be kept private. Like the last Zcoin issuance bug.
And this didn't cause you to reconsider whether or not you understand what you're involved in here?
After consultation with Dmitry Khovratovich (co-author of MTP)
... and the same guy who utterly failed to foresee this entire class of attacks against his MTP scheme. Wouldn't it make more sense to gather opinions from the people who broke his scheme?
TLDR version:
A simpler way to put it: just like PoS is vulnerable to "stake grinding", it turns out MTP is vulnerable to "DAG grinding". Instead of grinding for a nonce as you would like them to do, the miners can instead grind for a favorable DAG that minimizes the chances of their bluff getting called when they stuff garbage into the Merkle Tree.
It's like letting a poker player sift through all the possible future call/check/raise patterns instead of sifting through all the possible hands he might be dealt. Once he finds the "future" where nobody calls his bluffs when he's bluffing, it doesn't matter what cards he's dealt. DAG grinding is still grinding of course and it's still work, but
it's not memory-hard anymore -- DAG grinding requires hardly any memory.
This calls into question any sort of scheme for validating only a pseudorandomly selected subset of the miner's work. The source of pseudorandomness has to come from the blockchain's blocks, which are selected by the miners themselves, meaning it will always be a potential alternative grinding target.
The band-aid hack bears a disturbing similarity to the Proof Of Stake cults lately, who just keep slapping on extra layers of complexity to hide the alternative-grinding problem, when in fact it raises fundamental issues with the entire scheme.
the changes in the algorithm which are relatively minor.
... and only fix the most epic and catastrophic attack. All you did was stop miners from reusing work across blocks; MTP is still no longer memory-hard in light of Dinur and Nadler's work, and can be mined using an ASIC with less than a megabyte of on-die SRAM (i.e. 20-year-old chip fabs). By the way I think it's utterly fascinating that Nadler is a semiconductor fab tool engineer/executive rather than a cryptographer (
check out the guy's career history). Dinur of course is a hardcore hashbreaker.
No planned changes on the block 47,500 switch.
Full speed ahead, trainwreck ahoy!
We don't forsee any further changes on the MTP algorithm itself.
Well since you didn't forsee this one that's not saying much.