I'll throw this out there even though it has potential for issues. Maybe we incorporate WCET into the targetting calc. So for example, internally to the network there is a global difficulty to maintain 10 POW submissions per block, but at the work package level, that global difficulty is adjusted based on WCET, so simple jobs will have a much harder difficulty than a complex job. This way, they all change at the same time based on the global network difficulty...not on who is mining that particular job.
To me the main issue would be how accurate the WCET calc is.
Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 229. (Read 450523 times)
October 25, 2016, 09:23:05 AM
October 25, 2016, 08:08:08 AM
What would speak against adjusting minimum difficulty based on network activity?
This was the case before ... at least somehow!
Isn't it that this is equivalent to a "global target value"?
October 25, 2016, 05:53:29 AM
After some excessive testing I found a flaw in our new retargeting mechanism.
What if two jobs are online, one being far more lucrative than the other one.
Since we now have independent target values for both of them, with the "inverse slowstart" which drastically reduces the difficulty for jobs that get started but do not receive any POW in the first three blocks, the following happens:
1.) Miners mine the lucrative job only
2.) The second (less lucrative job) gets no PoW packages at all
3.) The difficulty starts dropping fast for the second job because it thinks that no potent miners are online anymore. This continues until it reaches the minimum possible value
4.) When the first job is over, miners all switch at once to the second job with the easiest possible difficulty.
5.) FAIL!
What if two jobs are online, one being far more lucrative than the other one.
Since we now have independent target values for both of them, with the "inverse slowstart" which drastically reduces the difficulty for jobs that get started but do not receive any POW in the first three blocks, the following happens:
1.) Miners mine the lucrative job only
2.) The second (less lucrative job) gets no PoW packages at all
3.) The difficulty starts dropping fast for the second job because it thinks that no potent miners are online anymore. This continues until it reaches the minimum possible value
4.) When the first job is over, miners all switch at once to the second job with the easiest possible difficulty.
5.) FAIL!
Hmmm, but wouldn't that mean once the difficulty is low and miners jump on it, that the difficulty would rise again?
A possible solution might be some kind of monitoring, that sets a minimum difficulty based on overall network activity. Worst case would be, that no one would jump on it, because the payout would be too low compared to the difficulty, but that would be the job authors problem.
Quote for visibility.
What would speak against adjusting minimum difficulty based on network activity?
October 24, 2016, 11:48:06 PM
Quote
If I remember correctly, you mentioned that you work at a university
Not anymore, I'm finished with my PhD now! But it was a pain in the ass to carry out all these optimization tasks on shitty hardware! Hopefully the guys that come after me won't have these problems. 
Congrats bro! What kind of hardware do you need?
October 24, 2016, 04:49:09 PM
Quote
If I remember correctly, you mentioned that you work at a university
Not anymore, I'm finished with my PhD now! But it was a pain in the ass to carry out all these optimization tasks on shitty hardware! Hopefully the guys that come after me won't have these problems. grats!
Indeed
October 24, 2016, 04:43:46 PM
Quote
If I remember correctly, you mentioned that you work at a university
Not anymore, I'm finished with my PhD now! But it was a pain in the ass to carry out all these optimization tasks on shitty hardware! Hopefully the guys that come after me won't have these problems. grats!
October 24, 2016, 02:26:53 PM
After some excessive testing I found a flaw in our new retargeting mechanism.
What if two jobs are online, one being far more lucrative than the other one.
Since we now have independent target values for both of them, with the "inverse slowstart" which drastically reduces the difficulty for jobs that get started but do not receive any POW in the first three blocks, the following happens:
1.) Miners mine the lucrative job only
2.) The second (less lucrative job) gets no PoW packages at all
3.) The difficulty starts dropping fast for the second job because it thinks that no potent miners are online anymore. This continues until it reaches the minimum possible value
4.) When the first job is over, miners all switch at once to the second job with the easiest possible difficulty.
5.) FAIL!
What if two jobs are online, one being far more lucrative than the other one.
Since we now have independent target values for both of them, with the "inverse slowstart" which drastically reduces the difficulty for jobs that get started but do not receive any POW in the first three blocks, the following happens:
1.) Miners mine the lucrative job only
2.) The second (less lucrative job) gets no PoW packages at all
3.) The difficulty starts dropping fast for the second job because it thinks that no potent miners are online anymore. This continues until it reaches the minimum possible value
4.) When the first job is over, miners all switch at once to the second job with the easiest possible difficulty.
5.) FAIL!
Hmmm, but wouldn't that mean once the difficulty is low and miners jump on it, that the difficulty would rise again?
A possible solution might be some kind of monitoring, that sets a minimum difficulty based on overall network activity. Worst case would be, that no one would jump on it, because the payout would be too low compared to the difficulty, but that would be the job authors problem.
October 24, 2016, 12:42:12 PM
Quote
If I remember correctly, you mentioned that you work at a university
Not anymore, I'm finished with my PhD now! But it was a pain in the ass to carry out all these optimization tasks on shitty hardware! Hopefully the guys that come after me won't have these problems. October 24, 2016, 12:33:30 PM
After some excessive testing I found a flaw in our new retargeting mechanism.
What if two jobs are online, one being far more lucrative than the other one.
Since we now have independent target values for both of them, with the "inverse slowstart" which drastically reduces the difficulty for jobs that get started but do not receive any POW in the first three blocks, the following happens:
1.) Miners mine the lucrative job only
2.) The second (less lucrative job) gets no PoW packages at all
3.) The difficulty starts dropping fast for the second job because it thinks that no potent miners are online anymore. This continues until it reaches the minimum possible value
4.) When the first job is over, miners all switch at once to the second job with the easiest possible difficulty.
5.) FAIL!
What if two jobs are online, one being far more lucrative than the other one.
Since we now have independent target values for both of them, with the "inverse slowstart" which drastically reduces the difficulty for jobs that get started but do not receive any POW in the first three blocks, the following happens:
1.) Miners mine the lucrative job only
2.) The second (less lucrative job) gets no PoW packages at all
3.) The difficulty starts dropping fast for the second job because it thinks that no potent miners are online anymore. This continues until it reaches the minimum possible value
4.) When the first job is over, miners all switch at once to the second job with the easiest possible difficulty.
5.) FAIL!
October 24, 2016, 10:48:39 AM
I am very happy to have invested in this project. Thanks to anybody who is contributing to it!
I am too, even though I do not understand much of what your are discussing, I see great potential here !
Keep up the good work guys !
October 23, 2016, 06:59:23 PM
I am very happy to have invested in this project. Thanks to anybody who is contributing to it!
October 22, 2016, 03:52:21 PM
Although, is there a risk of miners specializing on this, grabbing it, then stop mining?
That's the risk I've observed since the beginning; however, I'm come around to the point of view that if the bounty rewards are set correctly, there would not be any incentive for miners to jump around for POW rewards as this may result in them mining packages with undervalued bounty rewards.
Yeah, I guess one way or another, that's the best we can hope for. But I think it's possible, provided Elastic has at least some amount of traction. As with other things, this is a make or brake based on the popularity of Elastic, which is why I think it would be good to use at least some amount of the BTC collected for promotion.
Evil-Knievel, if I remember correctly, you mentioned that you work at a university and would like to use the Elastic network yourself, right? You sound like the main targeted group, then. Do you have an idea, how we could reach other people in that group, e.g. by promotion on certain sites, events or similar?
October 22, 2016, 12:46:34 PM
Although, is there a risk of miners specializing on this, grabbing it, then stop mining?
That's the risk I've observed since the beginning; however, I'm come around to the point of view that if the bounty rewards are set correctly, there would not be any incentive for miners to jump around for POW rewards as this may result in them mining packages with undervalued bounty rewards.
October 22, 2016, 11:04:35 AM
Here is a question I have since a while back, it's probably answered somewhere:
How is the size of a "job-block" determined? I mean, I guess job authors could chop the work they want to be done in multiple ways (e.g. 5x2/10, 10x1/10…). How is this determined? And wouldn't this work towards or against the retargeting issues?
How is the size of a "job-block" determined? I mean, I guess job authors could chop the work they want to be done in multiple ways (e.g. 5x2/10, 10x1/10…). How is this determined? And wouldn't this work towards or against the retargeting issues?
I'll answer immediately. But could you explain what exactly you mean by a "job block"?
Well, not exactly, to be honest. The way I understand it, the job is chopped into smaller chunks, which are to be solved by the miners. I meant those chunks. How is their size determined? By the job authors, I assume?
Actually, right now the jobs are not chopped down! They can reach from 1 to MAX_WCET regarding the complexity and the requirement for computational effort. That is the reason why we need to differ between jobs and give every job its own target value. Otherwise small (easy) jobs would get far more PoW submissions than those who take longer to execute.
Gotcha. You probably can't chop every job anyway, so that idea would not work.
Doesn't matter, fast difficulty retargeting with an unstoppable PoS chain looks brilliant, actually. I wouldn't even mind when miners max out the PoW submissions possible, It should be seen as part of the game. Although, is there a risk of miners specializing on this, grabbing it, then stop mining?
October 22, 2016, 09:24:01 AM
Here is a question I have since a while back, it's probably answered somewhere:
How is the size of a "job-block" determined? I mean, I guess job authors could chop the work they want to be done in multiple ways (e.g. 5x2/10, 10x1/10…). How is this determined? And wouldn't this work towards or against the retargeting issues?
How is the size of a "job-block" determined? I mean, I guess job authors could chop the work they want to be done in multiple ways (e.g. 5x2/10, 10x1/10…). How is this determined? And wouldn't this work towards or against the retargeting issues?
I'll answer immediately. But could you explain what exactly you mean by a "job block"?
Well, not exactly, to be honest. The way I understand it, the job is chopped into smaller chunks, which are to be solved by the miners. I meant those chunks. How is their size determined? By the job authors, I assume?
Actually, right now the jobs are not chopped down! They can reach from 1 to MAX_WCET regarding the complexity and the requirement for computational effort. That is the reason why we need to differ between jobs and give every job its own target value. Otherwise small (easy) jobs would get far more PoW submissions than those who take longer to execute.
October 22, 2016, 08:58:43 AM
Here is a question I have since a while back, it's probably answered somewhere:
How is the size of a "job-block" determined? I mean, I guess job authors could chop the work they want to be done in multiple ways (e.g. 5x2/10, 10x1/10…). How is this determined? And wouldn't this work towards or against the retargeting issues?
How is the size of a "job-block" determined? I mean, I guess job authors could chop the work they want to be done in multiple ways (e.g. 5x2/10, 10x1/10…). How is this determined? And wouldn't this work towards or against the retargeting issues?
I'll answer immediately. But could you explain what exactly you mean by a "job block"?
Well, not exactly, to be honest. The way I understand it, the job is chopped into smaller chunks, which are to be solved by the miners. I meant those chunks. How is their size determined? By the job authors, I assume?
October 22, 2016, 08:52:00 AM
Here is a question I have since a while back, it's probably answered somewhere:
How is the size of a "job-block" determined? I mean, I guess job authors could chop the work they want to be done in multiple ways (e.g. 5x2/10, 10x1/10…). How is this determined? And wouldn't this work towards or against the retargeting issues?
How is the size of a "job-block" determined? I mean, I guess job authors could chop the work they want to be done in multiple ways (e.g. 5x2/10, 10x1/10…). How is this determined? And wouldn't this work towards or against the retargeting issues?
I'll answer immediately. But could you explain what exactly you mean by a "job block"?
October 22, 2016, 08:48:56 AM
That is great... you can take my new "Dual KGW3 with Bitbreak". It is similar to DGW but better. After 6h reduce the wallet the diff. This works currently in Europecoin and Bitsend.
https://github.com/LIMXTEC/BitSend/blob/master/src/diff_bitsend.h#L18
https://github.com/LIMXTEC/BitSend/blob/master/src/diff_bitsend.h#L18
Nice one! I will have a look at it now!
October 22, 2016, 08:47:24 AM
I have almost finished the only matured idea for the retargeting mechanism so far for the next testnet iteration.
Sounds good, looking forward to trying it out.
I do have one request. When the network has already received the map POW submissions for the block, please send a response that more clearly identifies this condition instead of "duplicate". This way the miner can clearly identify if they truly did send a duplicate vs when the network is no longer accepting POW
Also, when you make this change, I'm still hoping you'll put the WCET value in the work package so the miner doesn't need to recalculate every few seconds to determine the best work package.
Will do both today ;-)
October 22, 2016, 08:39:36 AM
Someone from XEL team in thread, say me pls. how obtain XEL for ICO.
1.: There is no "XEL Team". There are just a bunch of guys working on it.
2.: You can't claim XEL right now. You can when the mainnet goes live. There is no ETA on that, yet.
3.: If you want it to go faster, help Elastic Project with your ideas
Jump to: