Author

Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 228. (Read 450523 times)

hero member
Activity: 994
Merit: 513
Another problem with the work-based target value.

If we have one work with a target value that has converged. And a second job gets added to the system which is equally lucrative, then it might happen that numerous miners switch to the new job. Let's say half of the miners switch, then the other remaining half in the first job will submit PoW submissions only at the half rate until the target value heals itself.

I more and more get the feeling that we need to have a global target value. Somehow!
Let us sort this out until not later than sunday ... So that we can start with the final remaining fixes.

If I recall correctly, the primary concern with a global target was that miners working on complex jobs would only get POW rewards a fraction of the time miners on easy jobs get rewards.  This can be easily mitigated by the POW reward set by the author, (i.e. if you job is 10x harder than average, then your reward should be 10x larger than average).

Maybe for now we just proceed with this approach to keep things moving.  And eventually (much later) enhance the UI to help the author set a better reward (i.e. recommend a POW reward based on historical averages, etc)

Ok, I'm going to say Jehova here:

Why is it so bad to have the network mine on one job at a time? A Job gets processed by the whole network, then the next, then the next? If we either set a fixed PoW reward, or we could implement a function for miners to reject a job, and if enough miners reject a job, it gets terminated, I don't see that much of a problem. I mean, if we have a fifth of the network each working on five different jobs, or if those five jobs get worked on one after another is in a general sense not important, is it? If we want job authors with big funds to "cut line", maybe they can buy a premium spot in the line by having higher PoW rewards?
sr. member
Activity: 464
Merit: 260
Another problem with the work-based target value.

If we have one work with a target value that has converged. And a second job gets added to the system which is equally lucrative, then it might happen that numerous miners switch to the new job. Let's say half of the miners switch, then the other remaining half in the first job will submit PoW submissions only at the half rate until the target value heals itself.

I more and more get the feeling that we need to have a global target value. Somehow!
Let us sort this out until not later than sunday ... So that we can start with the final remaining fixes.

If I recall correctly, the primary concern with a global target was that miners working on complex jobs would only get POW rewards a fraction of the time miners on easy jobs get rewards.  This can be easily mitigated by the POW reward set by the author, (i.e. if you job is 10x harder than average, then your reward should be 10x larger than average).

Maybe for now we just proceed with this approach to keep things moving.  And eventually (much later) enhance the UI to help the author set a better reward (i.e. recommend a POW reward based on historical averages, etc)
legendary
Activity: 1260
Merit: 1168
Another problem with the work-based target value.

If we have one work with a target value that has converged. And a second job gets added to the system which is equally lucrative, then it might happen that numerous miners switch to the new job. Let's say half of the miners switch, then the other remaining half in the first job will submit PoW submissions only at the half rate until the target value heals itself.

I more and more get the feeling that we need to have a global target value. Somehow!
Let us sort this out until not later than sunday ... So that we can start with the final remaining fixes.
legendary
Activity: 1260
Merit: 1168
It seems to me Evil-Knievel making everything to help the project. I've never heard about lannistor. It's not good really.

Well, many people here are doing what they can do make this project happen, take a look at hunterminercrafter for all the security research, at ttookk for all his ideas, at coralreefer for the highly efficient C miner, at me for all the wallet and backend work.

We are working our asses off. I for example am spending day (and sometimes night) to work on this while I could as well just go ahead and find some nice lovely daytime job. We have no contract here. I think it's unfair to say that (which of course includes us all) this is "not good"  Undecided.
copper member
Activity: 2324
Merit: 1348
I bought into XEL before the disclaimer that "THESE ARE DONATIONS ONLY" were put on the ICO page, as well as the restrictions from US based individuals from "donating" (I am from US). Should I be concerned?
Does that mean that I wouldn't get my xel coins? I've invested more than 2 btc

Everybody who sent BTC will get their share, no matter when the investment was. The question at hand is when this is  going to happen, since there is no fixed ETA, no dev team to push and so on. I think this is jeffthebakers main concern. Right?
It seems to me Evil-Knievel making everything to help the project. I've never heard about lannistor. It's not good really.

Lannistor is active, he had sent my a pm about the project website.
legendary
Activity: 868
Merit: 1000
I bought into XEL before the disclaimer that "THESE ARE DONATIONS ONLY" were put on the ICO page, as well as the restrictions from US based individuals from "donating" (I am from US). Should I be concerned?
Does that mean that I wouldn't get my xel coins? I've invested more than 2 btc

Everybody who sent BTC will get their share, no matter when the investment was. The question at hand is when this is  going to happen, since there is no fixed ETA, no dev team to push and so on. I think this is jeffthebakers main concern. Right?
It seems to me Evil-Knievel making everything to help the project. I've never heard about lannistor. It's not good really.
hero member
Activity: 994
Merit: 513
I bought into XEL before the disclaimer that "THESE ARE DONATIONS ONLY" were put on the ICO page, as well as the restrictions from US based individuals from "donating" (I am from US). Should I be concerned?
Does that mean that I wouldn't get my xel coins? I've invested more than 2 btc

Everybody who sent BTC will get their share, no matter when the investment was. The question at hand is when this is  going to happen, since there is no fixed ETA, no dev team to push and so on. I think this is jeffthebakers main concern. Right?
legendary
Activity: 868
Merit: 1000
I bought into XEL before the disclaimer that "THESE ARE DONATIONS ONLY" were put on the ICO page, as well as the restrictions from US based individuals from "donating" (I am from US). Should I be concerned?
Does that mean that I wouldn't get my xel coins? I've invested more than 2 btc
hero member
Activity: 994
Merit: 513
I bought into XEL before the disclaimer that "THESE ARE DONATIONS ONLY" were put on the ICO page, as well as the restrictions from US based individuals from "donating" (I am from US). Should I be concerned?
altcoins are high risk investments I think you are not aware of this. 100% loss is not unlikely.
Having this mindset, I am not concerned at all about this great project

Oh believe me, I understand how altcoin investing works. I am sure I have a broader experience with altcoin investing than you.

With that being said, my concern lies in disclaimers and restrictions being added to the ICO campaign AFTER I made my purchase.

It I remember correctly, the original Elastic project was abandoned at some point (at a point where the ICO already started) and Lannister took over. Don't ask me how this all happened exactly, I didn't follow Elastics development closely at that point.
I agree that there is a point of concern which could potentially need some solving, but as there is no real dev team, "someone" would have to come up with a solution and the community would have to vote on it (which is possible via the voting system used before).
legendary
Activity: 1526
Merit: 1034
I bought into XEL before the disclaimer that "THESE ARE DONATIONS ONLY" were put on the ICO page, as well as the restrictions from US based individuals from "donating" (I am from US). Should I be concerned?
altcoins are high risk investments I think you are not aware of this. 100% loss is not unlikely.
Having this mindset, I am not concerned at all about this great project

Oh believe me, I understand how altcoin investing works. I am sure I have a broader experience with altcoin investing than you.

With that being said, my concern lies in disclaimers and restrictions being added to the ICO campaign AFTER I made my purchase.
hero member
Activity: 784
Merit: 500
I bought into XEL before the disclaimer that "THESE ARE DONATIONS ONLY" were put on the ICO page, as well as the restrictions from US based individuals from "donating" (I am from US). Should I be concerned?
altcoins are high risk investments I think you are not aware of this. 100% loss is not unlikely.
Having this mindset, I am not concerned at all about this great project
legendary
Activity: 1526
Merit: 1034
I bought into XEL before the disclaimer that "THESE ARE DONATIONS ONLY" were put on the ICO page, as well as the restrictions from US based individuals from "donating" (I am from US). Should I be concerned?
hero member
Activity: 994
Merit: 513
what is the status of this project?

how soon we can play with real tokens on the mainnet?



There is no ETA on this. It's done when it's done. That's it.

Statuswise, well… Read the last ten pages Grin
sr. member
Activity: 686
Merit: 252
www.cd3d.app
what is the status of this project?

how soon we can play with real tokens on the mainnet?

hero member
Activity: 994
Merit: 513
I still don't understand, why it is not a good solution to have the planned system in place and add a system that determines a minimum difficulty based on overall network activity. The difficulty wouldn't be equal to overall network difficulty, but like half of it or something like that.

The only issue I see is that job author who set really low fees won't get miners to work on their job.

What am I missing?
sr. member
Activity: 464
Merit: 260
Here's another thought.  I'm sure it's full of holes but all other options keep leading to the same dead end so I'll keep trying.

The network would only accept POW for a specific work package each block (it would rotate through packages a new one per block).  All work packages would be available for anyone to mine at anytime, but only one one would be eligible for accepting rewards.  POW rewards would no longer be set by the work author, it would be a fixed fee per block...all the fees collected during that block get split among the 10 POW rewards for that block.  After each block, the last difficulty for that work package would be saved as the starting point for the next time that work package gets mined, and the new target would be the last difficulty for the new work package.

Even though only one package accepts POW any could be mined at any time for bounties.  So the work author could set high enough bounties that miners would decide to just mine their package regardless of the POW rewards.  It would then be up to miners if they want to focus on POW or Bounties.
legendary
Activity: 1260
Merit: 1168
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.

I haven't really thought this through, but what about using POW reward instead of WCET.   what if the POW amount the work author submits is used in the target calc.  So once again, set a global target based on 1 XEL, and if Job 1 has POW reward of 10 and Job 2 has POW reward of 100, then Job 1 should be 10x harder than job 2 (yes, due to WCET they may not submit POW at the same rate) but this empowers the work author to better control their incentives.

Classical FAA attack possible ;-) I create a job with a very high POW for which I know a very fast way to calculate it that other's dont. I collect all PoW since I am the fastest miner.
All other jobs drop significantly (since they by definition must be xxx times lower) in diffiulty and then I start working on them harvesting the hard earned XEL ludicrous style.
sr. member
Activity: 464
Merit: 260
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.

I haven't really thought this through, but what about using POW reward instead of WCET.   what if the POW amount the work author submits is used in the target calc.  So once again, set a global target based on 1 XEL, and if Job 1 has POW reward of 10 and Job 2 has POW reward of 100, then Job 1 should be 10x harder than job 2 (yes, due to WCET they may not submit POW at the same rate) but this empowers the work author to better control their incentives.
legendary
Activity: 1260
Merit: 1168
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!
legendary
Activity: 1260
Merit: 1168
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.
Jump to: