Topic: [ANN] ELACOIN fork: retarg @19440 diff .3 |interval calc change? see page 11+ - page 2. (Read 10053 times)

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.

Can I buy some elacoin?

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

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?

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

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.

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

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

mac client not updated yet, please standby.

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

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.

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

checkpoints.cpp  updated.

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

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.

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.

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

I donated 10 to the cause.

I just wanted to give a quick shout out to Nearmiss, we discussed the fact that the pool was not paying out when it was finding blocks because of the bug in the reward numbers and he happily paid me out of pocket to make things right.  Great service from a pool owner and one that I would be happy to point my hashes at whenever I can.

One block, like power cost? Power cost is different values in different markets. hmm. odd. depth of market is kinda already ignored, since you take an abitrary .5BTC sizing regardless of the sizing of the market - sometimes there's not enuf to satisfy a .5BTC value, othertimes thats just a 100th of the total bid values.

1 block instead would be another abitrary valuation, and interesting in ELC's case with low reward (high value_) coins.

All of the orders are averaged.

Honestly, I am debating whether I just want the price for one block of the cryptocurrency.  That would be smaller, but more accurately reflects what the market will have for a minor.   But I am getting constant pressure to "under" report profitability from the users.  Hard to balance.

Sounds fair in some ways I spose...

it's a tricky thing to value - you say it values on a significant BTC equiv order, what if the market is too small to meet the minimum total BTC value on the buy side, how is that handled?