Thanks for running the calculations and creating this chart.  Definitely makes the hard-fork much more understandable.

Bingo... like anyone with half a brain that understands DarkCoin is going nowhere, and X11 is the worst considered proof of work algorithm yet (likely ASIC mined from the very beginning).

New "features" will either be rolled into the main secure blockchains (bitcoin and litecoin so far) that have enough consistent and growing hashing power to sustain orphan resistance.

Coin features are just gimmicks.

Uh... where's the option for none of the above?

The DRK community is full of idiots, and I wouldn't touch the coin itself with a 10-foot-pole.

MintPal fucked up... it's not the VRC community's responsibility to fix this.  MintPal needs to cover the lost coins out of their own pocket - PERIOD.

If the VRC devs try to push a roll back, this coin is worse then dead in the water.  Obviously, if a rollback like this is possible, the blockchain cannot be relied upon as a fixed ledger, and therefore the coin is useless.

Too bad about the hack.  But a rollback will do nothing but cause a loss of faith in this coin.

If the developers can start a rollback, then the blockchain's history is obviously worth nothing...

Dead coin now.  Too bad, so sad.

Yes, yes, and yes.  However, I removed nicehash.com, because they aren't actually a classic mining pool at all, and certainly don't run a DRK daemon themselves.

Everything else you said should be repeated over and over...

You're presuming nobody will run a 3rd party built client for some reason?  Pretty faulty reasoning if you think the only clients that exist are the one's published by the dev team.

100% agreement.

Pretty cool project.  Might have to setup a little windows box to test it out (or try to get it running under mono).

A significant lack of information in that post... How is your miner configured?  Did you specify custom multi-algo factors?

Thanks for contributing to the community.

I'm neither a competitor not trying to disrupt progress...  I'm suggesting that it's highly likely we are going to see more nasty forking issues over the next updates.  I've followed DRK development for long enough, and there definitely aren't any unanticipated surprises...

If enough people refuse to pay the 20% MN fee, then it simply won't happen.  This is simply how PoW crypto networks work.

That requires people to still update... durp.

Heh, I'll definitely come back end of July... but it won't be because the price is up.

XMR doesn't implement centralized mixing nodes...  it uses ring signatures.  As for your 'barriers to adoption' - who cares... it still makes DRK significantly inferior.

Most miners are just dumping what they mine almost immediately at this point anyway.


Unless enough people don't update, then we'll just end up with two forks.  Yay... more DRK forking in the near future.

Try some larger values. Your tests may be correct, but you're missing the 'lotto' aspect of this.  The odds of hitting a block greater then the minimum are fairly low.  Also, what happened to ceil() when calculating nSubsidy?  Shouldn't it be impossible to have an nSubsidy value less then 1 as a result of rounding with ceil()?

Here's how I read the code:

nSubsidy = ceil(((maxReward - minReward) * nCoefficient) + minReward);
nSubsidy = ceil(((1000 - .1) * nCoefficient) + .1)
nSubsidy = ceil((999.9 * nCoefficient) + .1)

Since ceil rounds up, if (999.9 * nCoefficient) is 0, then nSubsidy = 1.  So, for the lotto effect it must be true that (999.9 * nCoefficient) > .9:

nSubsidy = ceil(.9 + .1) = 1
nSubsidy = ceil(.91 + .1) = 2

So, what are the odds of hitting a lotto block?

(999.9 * nCoefficient) > .9
nCoefficient > .00090009
nCoefficient = randCoefficient^multFactor
nCoefficient = randCoefficient^3000
randCoefficient^3000 > .00090009
randCoefficient > .997665

So, you have 2,335/1,000,000 odds (467/200,000) of hitting a lotto block.

Of course, as randCoefficient grows, so does the reward.

nSubsidy = ceil(1.91 + .1) = 3
(999.9 * nCoefficient) > 1.91
nCoefficient > .00191019
randCoefficient^3000 > .00191019
randCoefficient > .997915

(2,085/1,000,000) odds of a reward >= 3

nSubsidy = ceil(98.91 + .1) = 100
(999.9 * nCoefficient) > 98.91
nCoefficient > .0989199
randCoefficient^3000 > .0989199
randCoefficient > .999229

(771/1,000,000) odds of a reward >= 100

nSubsidy = ceil(899.91 + .1) = 900
(999.9 * nCoefficient) > 899.91
nCoefficient > .9
randCoefficient^3000 > .9
randCoefficient > ~.999965

(35/1,000,000) odds of a reward >= 900

Max reward:
nSubsidy = ceil(998.91 + .1) = 1000
(999.9 * nCoefficient) > 998.91
nCoefficient > .99901
randCoefficient^3000 > .99901
randCoefficient > ~.9999996698

(almost impossible odds ~ 3/10,000,000)

I did this in my head while reading the code; no promises I didn't miss or miss-interpret something.

---

Yes, indeed... my comments were based on my read-thru of the latest github commits and the OP in this thread.

The fact that the lottery is an exponential decay function is exactly what I am asking that you explain properly in the OP.  Most people can't be expected to read or test the code to understand this, and I suggest that your explanations have been a bit overly simple so far.  How about a nice graph/chart showing the odds of different block rewards, along with a few more comments about how this is a positive thing?

Hardforks without detailed and well considered information about the effects of that hardfork are simply worrying.

---

~260 blocks left until lotto fork.

14.6RC2 or 14.7RC will offer speed increases over 14.4 for X?? algorithms.

Heh... here's to hoping the hold-out pools never update!

Centralized anonymizing nodes... it still cracks me up.

What a well considered and thoughtful comment  .  Your content for cryptoarticles.com must be seriously top notch with that quality of analysis and writing.

And with that... this coin is dead to me.

Too bad, was a damn decent idea.  Sad to see it abused by another greedy developer.

I hope CoinShield is the first coin that this project tried to destroy, lol.