Less than two days until PoW-switch.

Number of publicly available GPU miners: zero.

This is gonna be a bloodbath.  Or a windfall.  Depending on your perspective.

I just realized that the beauty pageant has no requirement that the source code be released before the PoW-switch.  So GPU miner developers can mine privately for something like a whole month and win the pageant too.  Seems like a bad situation no?

If the current lyra2z hashrate is really coming from CPU botnets (which I doubt) then this is one problem that would actually get fixed by MTP.  A GPU-favoring algorithm like MTP would marginalize them.

I noticed that too.


MTP is not mature enough for prime time, and heavily favors GPUs over CPUs.

If they would have just owned up to these two realities I would have been satisfied.

But instead they got duped by some sales frontman for a fifty cent party who promised them that spin-doctoring and beauty pageants were cheaper than realistic timelines and cautious incentive structures.  And that his swarm of 20-post accounts would stand ready to flood this thread with trivial Q&A whenever uncomfortable issues came up.

I can guarantee you that pencil-and-paper mining will work.  It's also irrelevant.

The situation to worry about is not "there are zero people GPU mining".  That won't happen.

@JasonSW, curious, why you're shilling in support of this shady behavior instead of calling it out?

This whole situation is ridiculously shady.


After the PoW change? Seriously?

It's creating a "second instamine" where the PoW rules are changed in secret, the secret is revealed like a few hours before the PoW-change block, and as a result the only people who can develop miners that actually work on launch day are the insiders.

(And no, I still don't care about your stupid beauty pageant, stop using that as a distraction.)

Except for this part...


Wow dude, that is pretty hardcore, you went after them using RICO?  They deserve it, of course, but remind me not to mess with you

Curious, has there been any movement on this?  Wheels of justice move slowly and all, and I don't have a PACER account.  Would be pretty crazy if Sonny were declared to be a mob boss.  Mining mafia!

Sorry about the necropost here, but isn't the dataset for ZEC more than 32MB?  You wrote:


200bits*2million = 400mbits = 50mbytes, right?

If I got the math wrong, or if there is some trick for halving the storage requirements, I would be happy to be corrected.  Thanks!

That's my point -- except that I don't think the contest matters compared to the launch.  Who made more money from Zcash: Tromp or Claymore?  One day of Zcoin mining is worth more than the entire contest prize.

The constant last-minute changes to the PoW are just ridiculous at this point if you ask me.  Every time another one crops up MTP drops a few more notches further down my priority list.  Before your latest post I was fed up enough that I'd decided to wait until after the transition block to start working since at least at that point making any more changes would be more difficult for the zcoin politburo.  Now I'm starting to doubt even that as a reasonable time-management strategy.

I think it's incredibly disturbing that the zcoin devs are embargoing these discoveries when MTP has not been deployed yet.  There is no risk of an exploit since the exploitable code has not yet been deployed.  And it sounds like mrb's second discovery is more than the horridly-maintained codebase containing magic numbers like "4034".  But we have no way to know.

Shame on you, zcoin, for bribing researchers into silence.

Yes, when the difficulty is falling a small number of the blocks come with a larger block reward.

This prevents large sources of hashrate (like nicehash) from "coin hopping".

Coin hopping is a lot like the "pool hopping" scheme that was commonplace before PPLNS, but instead of switching pools you switch coins.  It is a problem for every GPU-mined coin.  No matter how fancy and clever the difficulty-adjustment algorithm is, if there any large single source of hashpower (cough cough nicehash) they can boost their income by jumping into a coin, mining until the difficulty catches up to their added hashrate, then jumping over to another coin.  Even if the difficulty adjusts in one block, they still got mined one block of low-difficulty using their high hashrate.  As long as there are enough coins to hop between they can hop on every block, doesn't matter how fast the difficulty adjusts since it is always based on the previous block(s).  Take a look at the Monero hashrate, it's been oscillating up and down with almost exactly a 24-hour period for a few years now (their difficulty adjustment window is based on the last 24 hours worth of blocks).

By giving more reward to a randomly chosen block during dropping-difficulty periods (which is effectively taken from the reward during rising-difficulty periods) nexus thwarts this exploit.  Well, in theory.  It looks like the formula for boosting the reward is messed up, the bonus blocks seem to be larger and less frequent than they should be, but it still helps.  The other drawback is that this only works for multi-algorithm coins where the network time is based on all mining algorithms.  If a single-algorithm coin tried to do this then a nicehash-like coin hopper could defeat the mechanism by screwing with the block timestamps, and with enough hashpower the chain wouldn't know they were fudging the timestamps (by a small amount) and making the chain think the difficulty was dropping (by speeding up time) when in fact it wasn't.  Everybody would do this and pretty soon the chain timestamps would be way ahead of the actual wall-clock time on all the non-mining clients.

With two or more mining algorithms there is no incentive for the miners on the other algorithms to do the same thing at the same time, so they don't.  On the other hand nexus's "unified time" causes a lot of other headaches for people, I'm not sure it was a good idea either.

Where?  Last commit here

https://github.com/zcoinofficial/zcoin/commits/merge-mtp

is 10 days ago.

Still waiting for this:


You may think it's minor, but any change that affects the consensus rules (and that includes every last detail of the PoW) is a big deal.

Pretty vague.

I think you misunderstood something there.  The existence of the time-memory tradeoff attack in no way frustrates me; as a matter of fact reading the Dinur+Nadler paper was quite an enjoyable experience.


This is incorrect; you are confused about what "memory-hard" means.  The definition is given on page 3 of  Stronger Key Derivation Via Sequential Memory-Hard Functions by Colin Percival:


There are plenty of functions in this class.  The fact that you can "exchange memory usage for CPU time" does not mean a function is not memory-hard.

Try more like 11x, dollar for dollar.  R7 370 should be above 300khash/sec.


I think you're referring to me; I definitely didn't expose it -- Itai Dinur and Niv Nadler did that and they deserve 100% of the credit for their excellent paper.

I do have very serious concerns with the band-aid cooked up in response to Dinur+Nadler's paper.

Yes, it made my hair grow back and led to world peace!

As long as the grass grows and the rivers run.


Innumerable and uncountable, vast and expansive.


You're very welcome!

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?


... 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?


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.


... 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.


Full speed ahead, trainwreck ahoy!


Well since you didn't forsee this one that's not saying much.

Uh, I guess not:

https://github.com/zcoinofficial/zcoin/commit/bc81678b7f9467fecf64e0a44dba35550e50619f

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?

What is going on here folks?  This is some serious seat-of-the-pants-nonsense.  If you are making changes like this then you'd better not be serious about the height=47500 target, and if you're not then that should be made public.

Either way I will be sitting out until the dust settles.

CPU mining MTP will not be profitable, except maybe the first few weeks if there is enough chaos.

It is a very, very GPU-favoring algorithm (8kbit stride!).  I think that's okay.  But I also think the people who wrote the MTP paper should be up-front about this.  They were wrong, very very wrong, about their claim that GPUs would have no advantage over CPUs mining Equihash:


Of course this was completely wrong.... show me a CPU that can mine equihash at 25% the hashes/$ or hashes/J of Claymore's GCN miner (see below).
That said the MTP PoW is very, very impressive, clearly the most advanced memory-hard PoW in existence.

Just don't sell it as something it's not (and doesn't need to be).

The best CPU miner (Tromp's) gets 27.2 sols/sec on a CPU that costs $320; the RAM and motherboard (not just one slot on a shared motherboard) will put the total cost way, way, above $400.  For $400 you can still get an R9 290 which does 331H/s -- and this is in the middle of the crazy GPU drought.  That's a 12x advantage, which is why (reality check here folks) nobody mines zcash with CPUs.  The GPU advantage was much much larger (like 20x-30x) before the GPU price spike last month due to short-term supply exhaustion.

it's in the code (along with a blocksize increase)

https://github.com/zcoinofficial/zcoin/commit/4ab72aa04249ec05b72c9f1af61d14de2d905e06#diff-e8db9b851adc2422aadfffca88f14c91R76

... aka about 5000 blocks from now, on 2017 July 27 give or take a day