[ANN][XEL] Elastic Project - The Decentralized Supercomputer

[Evil-Knievel]

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

Nice one! I will have a look at it now!

[1713968733]

1713968733

[1713968733]

1713968733

[Evil-Knievel]

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?

I'll answer immediately. But could you explain what exactly you mean by a "job block"?

[ttookk]

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?

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?

[Evil-Knievel]

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?

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.

[ttookk]

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?

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?

[coralreefer]

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.

[ttookk]

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?

[HomoHenning]

I am very happy to have invested in this project. Thanks to anybody who is contributing to it!

[Jayjay04]

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 !

[Evil-Knievel]

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!

[Evil-Knievel]

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. 

[ttookk]

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!

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.

[ImI]

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!

[ttookk]

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

[klintay]

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?

[ttookk]

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!

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?

[Evil-Knievel]

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

[coralreefer]

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.

[Evil-Knievel]

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.

Also thought about this one, but I think it's really hard to accurately calculate the WCET ...
No only because of the complex functions like hashes or EC maths, but also because the C compiler would highly optimize the generated assembly, not knowing what operations were actually left in tact, what operations were replaced by others and what operations were stripped out.

You could easily generate a program which on the first sight has a WCET of 10000000 but which can be executed with only a few CPU instructions after being compiled with -O3.

[Evil-Knievel]

I even thought that it could be possible to "force" everyone to work on new work for x blocks to measure the "network performance on that particular job" for the initial difficulty and just leaving it adjust normally from there.
But this again sucks because it could be used to DOS other works by repeatedly creating new jobs!