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

not going to happen as it would be a breach of contract. but if funds are needed we can easily put up some voluntary fund that gets BTC/XEL.

Indeed they are. Plus, 30% are a lot in the hands of what will be a small group of people. I don't like the idea very much.

@Evil-Knievel: sorry to hear about the flu, get well soon! You idea proposed sounds good, as far as I understand it. How do you feel towards the "one PoW job at a time" discussion?

Isn't that what the donated BTC are for?

Sorry ttookk, I had the flu and was pretty knocked out in the last 3 days.
I will catch up with all posts now,
but here is a silly idea that I got while spending days in the bed:

What if we just use the minimum target value over the last X jobs, and use a very fast retargeting mechanism to quickly adapt to a "good" value per job.
There is some natural lower bound in execution time (due to the hashing and pseudorandom number generation overhead) and most jobs (if not totally exaggerated) will be close to that execution value. So in most cases this could be a good first estimate. More complex jobs would be estimated wrong (and hence receive the full 20pow/sec limit) but only for a short time until the fast retargeting kicks in.

Not sure if this is usable? At least there wont be any "too optimistic" estimations causing the difficulty to be too high for the job to receive any PoW.

…Thinking about it a little more, jobs that need bruteforcing can be assessed quite easily. That can be done by any instance on the network, but in the end, I think this is the miners job to figure it out, whether they are willing to work on a job for the reward offered. It may be handy to have a warning label in the client, warning a job author that the reward is under a certain threshold, but since this threshold could vary greatly, I don't see much use in an "official" weighting.

Hi man,good things worth waiting.

I am not sure whether there is a way to objectively weight a work before it is executed in a similar way as assessing the difficulty of a regular PoW job, but in case the job is considered undervalued, miners won't work on it, leading to the job author adjusting the price (or waiting really long for execution). This would be a kind of "weighting" and we would need this kind of weighting anyway, because with XELs worth changing, the reward has to change, too. Otherwise, the Elastic network runs the risk of becoming unprofitable, if the worth of its tokens drops too much.

I have to say that i really appreciate your contribution to this project guys . I cannot contribute as i'm limited by the language barrier and tech knowledge . Watching closely this thread and i hope you will make it till the end .
By the way , where is hunterminercrafter ? Haven't seen him posting for quite a time .

Edit . I'm not sure if it is mentioned by ttookk or coralreefer , every work should be "weighted" , not sure how - and if - this can be done . It should not only be based by reward but also by the amount of work that has to be done .

So what you are saying is, we could create a PoW reward order, but not a working on job order. Still looks ok, doesn't it? But what would happen is a job in qeue gets finished before it is its turn? The PoW block must be mined anyway, because they are payment to get a spot on the list, right?

How do we let the community decide? Vote? Or by "general positive feeling towards a solution displayed in this thread"?
I would like to hear E-Ks opinion on having an order, too.


No, not yet. You can claim them when the mainnet starts and there is no ETA on that yet.
Is there a really easy way to create an email signup system? If yes, somone(or I…) could create one, people can sign up and it would be only used to say "mainnet starts in X days". Or maybe "we have this decision and want you to vote on it", too. Although I wouldn't want to let it become a newsletter…

Is there anyway to get in posesion of my coins ? Sorry i don't have enough time to follow anymore but i love u guys .

Well done.

Not sure.  Just keep in mind...any miner can mine any job they want any time.  There won't ever be a restriction on this.  All we are debating are POW rewards...which I've always said, I don't think are going to be too relevant if this takes off.  Nothing stops you from mining any job you feel like.

Edit:  Anyway, I've rambled on about this long enough.  As EK said, it's time for the community to make a decision by Sunday.  I'll modify the miner I posted for whatever approach we take.  I'll just be happy if we can move past this.

But couldn't you create a job that takes ages and drive off other job authors? Or otherwise stall the PoW jobs? That could be an attack vector – not even an attack vector, and I think I understand why parallel jobs or a rotation system would be desirable now: There may be jobs that don't really have a "bottom" and that could go on really long. You'd have to have some mechanism to cap job size, otherwise job authors might lose interest, once a really big job comes along and occupies the system for a long time.
But if you'd cap the "job size" somehow, it would be kind of like a "big" rotation system, since the job author could resubmit the job.
But what would be a "long time"? Are we talking about minutes, hours, days?

I think "one job at a time" simplifies retargetting for 2 reasons.  1) The initial target for the job would be that last target this job had...it wouldn't start from where the job that just ended left off.  2) It wouldn't be as likely (at least I don't see any incentive to do so) for the authors to try to "game the system" or "sabotage" other jobs by messing with the POW, where in the current design I believe this is a concern (i.e. create "dummy" jobs to draw miners away from other jobs...the elastic version of ddos'ing)

Hmm, yes, you point out valid things I didn't think of. Still, wouldn't a rotation system make matters even worse? I mean, if you work at one job after another, you could use the difficulty retargetting system proposed by E-K and when the job is done, you start the next one, do the retargetting, work the job and so on. In a rotation system, the difficulty would change all the time, wouldn't it?
Maybe I just don't get it, though…

Anyway, I think it's safe to say that a "one job at a time" system would make a lot of things easier, while the advantages of an "all in" system don't look that big to me.

Yes, my suggestion was a rotation, and as you pointed out, there are a lot of ways to accomplish a similar scheme...but, either way, there would only be one job per block eligible for for POW rewards and that sets the global difficulty.

But in your suggestion you pointed out a main issue EK is struggling with right now.  First, even though we call this POW it has nothing to do with moving the blockchain like a traditional coin, only POS does that.  It's simply proof that the miner is actually working to solve on of the available bounties.  And also unlike other coins, these jobs don't have a fixed complexity (i.e. bitcoin is always sha256d).  In elastic you could have a job that is very complex...miners only getting 1 Evals/sec which suddenly get ends, now all of them jump over to a super simple job that runs at 1M Evals/s...all within the same block.  This is very difficult to account for as now the network is now going to get flooded with POW submissions until the retargetting takes place.  Remember this all happens between blocks where in a traditional coin, the retargetting is done after the block is solved.

The issue we are encountering is probably more similar to what multi-algo coins like Myriad encounter, but still they only juggle 4 algos...we have to juggle an infinite # of possible algos.

But I think we just need to pick any direction at this point and move forward.  I personally like having only one package eligible for POW per block (regardless of how you pick which one is the eligible one), but I'm not the one coding that piece, so I'll be happy with whatever the group decides.

Your thought was more about a rotation system, though, right? Where, wenn for example there are three jobs, the order would be block from 1, then 2, then 3, then 1, 2, 3, 1, 2, 3,… right? At least I thought it was meant that way.
I'm thinking of a different idea:

Every X blocks there is a fixed number of PoW jobs that can be used, let's say 1,2,3,4,5.

Job authors can bid on those spots, as if they were in an auction(although I'm not sure whether readjusting of bids wouldn't be too complicated or necessary, so it wouldn't be a "real" auction, just that whoever paid most, "wins"). The one who pays the most (as in PoW reward per block) gets the first spot, second and so on. The auction ends at a certain block and the resulting number and order of jobs is fixed. If you want a premium spot in the next round, you'll have to pay for it.

Obviously, this idea still has flaws, here are the ones I see with my underfed brain at the moment:

You could fuck the whole network, by sneaking in a bid with a lot of work for a very low reward. Most miners would turn their machines elsewhere, the network would stall even more, deadly spiral. The most obvious solution would be to have a minimum award per block (which we would probably have anyway), but that would vary depending on XELs worth. Another solution could be to have a minimum price based on the average price submitted, as in jobs with a PoW reward that's lower than 2/3 of the prices already submitted are denied. Problem would be that it would be either possible to kick out reasonably priced submissions by setting a ridiculously high price, or, if previous submissions can't be denied, to get at least some jobs at minimum prizing.

How exactly do you correlate PoS blocklength and -time to nuber and complexity of PoW packages? Since their blocktime isn't fixed, you can't really determine the number of possible spot beforehand, can you? You could probably "sell" a fixed number of PoW packages and auction off the new ones, once this group of work packages starts do be mined.
And what happens if miners work on jobs that are very fas along in the qeue? Once it's their time, they'd have a bunch of packages ready to throw on the market, unless the hash of the previously mined block needs to be included somehow. This however might divert computing power from the network, wouldn't it?

Still, I like the auction idea and I think having one job being worked at at a time(whether until the job is done or in a rotation system) is the way to go.

Crazy idea time: you might even fork XEL a couple of times and have XEL1, XEL2 and XEL3, this way, you could still work on different jobs at the same time. But that is obviously neither here nor there


I forgot some stuff I thought about, because I'm too hungry to think dtraight at the moment, but that's about it.

Where is Hunterminercrafter by the way? Haven't read from him for quite some time…

Okay gotcha, that makes sense. I just threw a bit of BTC in without really doing much research. Good to know there are still people working on getting XEL to mainnet, however.

In my humble opinion the global target value is the right way to go about this. It's kind of like mining difficulty..
It needs to be adjust/retargeted automatically based on a combination of factors eg. miner participation, jobs submitted etc...

That was my suggestion as well the other day.  I suggested we rotate through the work packages each block.  Keep in mind with Elastic, any miner can mine any package they want at any time to get bounties.  We are just discussing POW rewards.  I still feel the reality of this is that if an author really wants miners to work on their package, they will set the bounty accordingly and this POW discussion is moot.  POW really just needs to cover the electricity, Bounties are what you really want.

Edit: As I've said before, If I was mining I'd probably go after jobs with the best bounties and turn off POW on my miner altogether.