[ANN] ELACOIN fork: retarg @19440 diff .3 |interval calc change? see page 11+

[barwizi]

hashrate down, will take long to cover the remaining <200 blocks

[barwizi]

and remove that god awful announcement, it will invite that attacker again. we need serious hash power to repel that kind of attack again guys. Would be nice if people spare 300mh each for 3 hours, we'd get these blocks done fast.

[nonameo]

It's moving along, the hash rate reported by the debug console isn't the immediate hashrate, it's calculated over several blocks. There's a fair amount(10mhash?) on the network right now just from talking to people. sometime tomorrow the retarget should roll around.

I let mat5x know about the title.

[mat5x]

and remove that god awful announcement, it will invite that attacker again. we need serious hash power to repel that kind of attack again guys. Would be nice if people spare 300mh each for 3 hours, we'd get these blocks done fast.

it will also invite miners. the attacker is VERY knowledgeable. hiding things wont work, they can obviously read the code, probably better than us.

[mat5x]

and remove that god awful announcement, it will invite that attacker again. we need serious hash power to repel that kind of attack again guys. Would be nice if people spare 300mh each for 3 hours, we'd get these blocks done fast.

it will also invite miners. the attacker is VERY knowledgeable. hiding things wont work, they can obviously read the code, probably better than us.

there's a new checkpoint in the code please update your miners. just for all our mutual benefit and security.

checkpoints.cpp  updated.

[mat5x]

and again for those who care,

 ./showblock.sh 19350
hash: c6c725fb3c376a2cc4a0796ab4aa04af1ff472628c8e82ece55657b60b3150a5

a new checkpoint.cpp is in the github

Id like to apologize to anyone 51%ing the coin on AWS. We know who you are.

[barwizi]

and again for those who care,

 ./showblock.sh 19350
hash: c6c725fb3c376a2cc4a0796ab4aa04af1ff472628c8e82ece55657b60b3150a5

a new checkpoint.cpp is in the github

Id like to apologize to anyone 51%ing the coin on AWS. We know who you are.

forward me their ip add, i have a special packet just for them.

[mat5x]

Update #6 06/07 07:21Z: MOAR checkpointz! update your clients: checkpoints.cpp: block 19400 hash: ce70abf9c0930d5cdcff555ceec6e6777f70f3a8bbc4b1efc9ac5c49a3b6c8e6

mac client not updated yet, please standby.

[mat5x]

CHANGING RETARG TO EVERY BLOCK?

I just realized something completely obvious (and no one else mentioned it either so we all fail).

This coin was originally launched to give a reward = diff but milkshake kinda mussed that up. But with the original idea, gaming the diff would never matter. Thus, logically, having a diff retarg frequently wouldnt matter either, there's no gaming to be had. A faster block time would ensure that people couldnt throw on and off hashing power (2 minutes is ok, 1 minute would be better, <40s is supposedly too fast for network equity, but i think we have to leave it at 2 minutes to avoid screwing things up), and further more it would solve stalled coinitis, allowing xactions to go thru.

Then we'd never suffer stalled blockchains when interest got low and giant swings in hashpower when valuations pile up (or decay) and then coinChoose suddenly indicates ELC's super profitable.

The point of this coin in fact WILL NOT WORK PROPERLY WITHOUT RETARG EVERY BLOCK. This cannot produce a TRC yoyo-diff effect, TRC has static value for all diffs, so gaming it works.

Actually, every block wouldnt be ideal not because of hashpower on the network, but because of random luck of small #s of miners. Statistical variations could cause block diff to shoot up very high. That indicates a max multiplier/divider (4x higher or lower in most coins, and ELC now) is required, but I worry this allows hopping in with giant rig as the diff wont climb fast enough.

Need some way to seperate luck from hashpower on the coin, but I dont think that is possible. All I know is that 3 days is too long for a retarg. Perhaps, asymetric climb/decay mutlipliers like
other coins have would be good? Not sure. Need more brains thinking on this. What's the ideal retarg interval, and multiplier? Trying to avoid the TRC effect here. Maybe every block, but with a bigger max increase (16x would be fine, if the next block is too long, then itll drop back down 16x...). Gives opportunities to bounce the coin off a 1.0 diff and score high rewards (as the coin is worth at least 1.0 base), but that also encourages many to mine, destroying the opportunity for a soloist to enjoy such raquetball).

Yes, another damn fork would probably make people start calling this SchizoCoin. Fixing this properly once and for all without destroying the work of 10-15 people's efforts by just making yet another new alcoin would be best, as it would be a clone of ELC anyway. So let's fix ELC itself.

(The only other thing that also should be fixed was the accidental implicity floor(diff) casting in the reward code, which does produce some discrepancy in value, which is why it's 0.90 instead of 1.11 or so right now, which is unfortunate. The code was floated many blocks/hours before the fork, and no one caught the bug, so we're all to blame? heh. It's all a learning experience!)

Im not sure if this helps fix problems with 51% attacks either, but i have a gut feeling that it does.

It would be good to fork this before the retarg @19440 so we dont get 500 new downloaders that all need to redownload YET again. That will hurt an alt coin that hasnt become popular for the right reasons yet.

Comments? Barwizi? WindMaster? et al?

The only changes I would make would be to multiply diff before the reward calc, then divide the end result by the same (10000? have to test we dont blow int64 in the far future with high diff values), and of course, the retarget frequency (which would amount to removing an if statement entirely, more or less), and changing the interval constant settings. Maintaining the base calc of diff = 1 for reward purpose would keep interest in the coin as well, as is alreeady the case in the code (ie leave that part as is).

 Main

[barwizi]

From the coin i released today i can safely say that 2 min times are viable if difficulty adjusts quickly enough to react to changes in hash rates. This effectively discouraged the guys with farms from trying to rape it. Stability in that sense was acheived. I support you idea though per block difficulty change is something i have limited knowledge on. If you look at bitgem, it's based on that model i think, but everytime i've tried it, i am unsatisfied with the results. Perhaps every 5 blocks would work, esp in the beginning were the initial hash spikes.

[mat5x]

From the coin i released today i can safely say that 2 min times are viable if difficulty adjusts quickly enough to react to changes in hash rates. This effectively discouraged the guys with farms from trying to rape it. Stability in that sense was acheived. I support you idea though per block difficulty change is something i have limited knowledge on. If you look at bitgem, it's based on that model i think, but everytime i've tried it, i am unsatisfied with the results. Perhaps every 5 blocks would work, esp in the beginning were the initial hash spikes.

modified my original post idea there above, reread and comment.

5 might be good, but why 5? seems to me that number should be dynamic, contingent on some behaviour in the last N blocks, where the retarg is calculated to be on f(N) blocks instead.

I need to sleep on this. WindMaster needs to wake to it!

brainstorm people!

I feel the biggest problem is seperating luck from wild swings in hashpower, to determine what the cause is. Otherwise we might still have a TRC situation, if we limit the incr/decr in diff to x4//4 (could be higher, but then we also risk having it swing around too much when there's few # of nodes in the system, which means averaging of luck on the block is much less fine).

[mat5x]

ha. i think i know.

might be hard to do tho - if the diff goes up by N, then the block time should go down to compensate, to ensure we've not committed to a high diff for no reason (or same, a low diff).

so after a wild swing, the block time drops. interesting. then theres no benefit to swinging up the block by diff 16 (say thats our max factor), to let it drop back down suddenly by x16 so you get
to hash into it at alow diff. the block would be worth less too of course,  if its a shorter-time block. course, we cant go too short or we run into orphan problems. even a blocktime of 15s results in the odd 1-2s blocks, or shorter, which causes reorgs :/

30s might be a good lower bound, though thats only a factor of 4. but a multiplier of x16 or /16  with a time factor incr/decr of /4 or x4 respectively would counteract the impact of a sudden swing that large. decreases gamability of hopping in and out, as you get 1/4 of the benefit of the swing you cause if you are a big rigfarm. averaging over the last 2 blocks would further mitigate hash power swings, as its harder for people to throw power in and out on that short a scale, where as luck does work the same at all scales (and there we have our filter of luck vs hopping)

WindMaster, help us nail this idea down.

btw, does anyone have the distribution curve handy for 'luck' on scrypt mining? is it a normal distribution? (no it cant be. lower bound is closed at 0, upper is infinite.)

what's the probability of a 1/15th time block for scrypt?

[barwizi]

i've never tried dynamic difficulty adjustment due to coding issues. If it can be done clean then it would be perfect.

[D35TR0Y3R]

Can I buy some elacoin?

[nonameo]

Can I buy some elacoin?

elacoin is pretty cheap on cryptsy right now(well, depends on whether you think the coin has a future or not I guess?)

if you don't want to use the exchange, I'll sell some to you but my sell price is more than twice the cryptsy buy price at 0.0015btc/ELC. If anyone cares to outbid me, have at it

I'll take LTC or BTC.

[D35TR0Y3R]

sure I only have BTC now. I am also buying LTC.

I'd like 100 ELC. Pm me please

[nonameo]

sure I only have BTC now. I am also buying LTC.

I'd like 100 ELC. Pm me please

ok, I pm'd you

[mat5x]

checkpoints.cpp for #20940 pushed to git.

please update your clients as usual.

[WindMaster]

WindMaster, help us nail this idea down.

Sorry, real busy at the moment.  I'll weigh in when I can though.  I've been leaving an IRC window open on #elacoin so I can occasionally read back through what's been discussed when I have a free moment here and there.

Yes, another damn fork would probably make people start calling this SchizoCoin. Fixing this properly once and for all without destroying the work of 10-15 people's efforts by just making yet another new alcoin would be best, as it would be a clone of ELC anyway. So let's fix ELC itself.

Yeah, I think the "SchizoCoin" comment would be apt.  Hard forks and incompatible client changes are an absolute last resort to fix something fundamentally wrong with a coin that it simply won't survive without fixing.  It's not really a tool for trying out random experiments in tweaking coin parameters without carefully contemplating what types of unintended consequences could occur, since there are many people who hold ELC with a certain understanding of what the coin parameters are/were.  Remember our IRC conversation the other night where multiple potentially exploitable issues surrounding the changes to the retarget calculations made in the last hard fork a little over a week ago were uncovered?  Fortunately they don't appear to have been exploited, and the window of opportunity for them to be exploited has now passed.

A healthy coin isn't one that needs to hard fork twice in just over a week's time!  I would say, "slow down, think carefully, the world isn't going to end tomorrow if the latest experimental coin parameters aren't implemented immediately, be sure all unintended consequences have been thought of, and that the changes are actually absolutely necessary to fix a fundamental flaw that dooms the coin otherwise."

[mat5x]

Yeah, I think the "SchizoCoin" comment would be apt.  Hard forks and incompatible client changes are an absolute last resort to fix something fundamentally wrong with a coin that it simply won't survive without fixing.  It's not really a tool for trying out random experiments in tweaking coin parameters without carefully contemplating what types of unintended consequences could occur, since there are many people who hold ELC with a certain understanding of what the coin parameters are/were.  Remember our IRC conversation the other night where multiple potentially exploitable issues surrounding the changes to the retarget calculations made in the last hard fork a little over a week ago were uncovered?  Fortunately they don't appear to have been exploited, and the window of opportunity for them to be exploited has now passed.

A healthy coin isn't one that needs to hard fork twice in just over a week's time!  I would say, "slow down, think carefully, the world isn't going to end tomorrow if the latest experimental coin parameters aren't implemented immediately, be sure all unintended consequences have been thought of, and that the changes are actually absolutely necessary to fix a fundamental flaw that dooms the coin otherwise."

Wise words, but we're slowly dying here. A checkpoint cant hurt to start.

The valuation of the coin to date will largely remain the same - anyone who invested in it isnt going to be too upset that the coin survives with SOME value, vs not surviving at ALL.

The spirit of the valuation will be the same, we just need to retarg difficulty better/faster. Perhaps people DID invest into ELC gaming on the fact that the difficulty would get messedup by a CoinChoose wave, and thats how they made their profit (i would posit those people are no longer holders of ELC!). Anyone else who is holding i dont think is betting too heavily on the block rate
being once/12 hrs :/ except the AWS-miner guy who reorg'd 168 blocks as you say...

I dont want to put all my experimental ideas into Elacoin right now, its not the right coin for it. People need a coin to be stable/remain the same as you say, tho the threat of total death gives us some wiggle room to improve it back into life. The coin as is and its reward are just FINE, just need to recalc difficulty more frequently (or semi dynamically, as we dont want 0.1s blocktimes if/when the CC wave comes back).

For other ideas id love to talk to you in more detail about some other stuff, but right now i have it on hold mostly in my head as i deal with real life stuff. But id like to get thinking. Find me in PMs or irc..