So thinking through the retargeting a bit more, in general it would seem that miners will move from job to job as a group.  For example, if there are 10 miners total and X number jobs total with similar WCET / rewards, there's a good possibility that they will all determine that job Y is the most profitable and move over there (yes there could be variation in this logic, but in general, they probably gravitate towards the same job).  After a few blocks, the target for this job Y will change enough that it's not as profitable as job Z, and everyone will then move over to job Z driving up it's difficulty while job Y's difficulty begins to drop....then they move on to the next job, etc.

I'm not saying anything is wrong with this, and maybe this is a good thing, but we should just be aware that this model may encourage miners to hop from job to job as a group rather than find some sort of distribution across jobs.  So if the 2 most profitable jobs have similar rewards and WCET, it would seem that the group of miners would just bounce between the two jobs which may be the best outcome we could hope for.  I was just trying to think if there was any way to keep the miners more distributed and less hoping which helps with the retargeting.

And just to finish the thought...if there is one profitable job, and 2 low profit jobs, I believe this model would still encourage the miners to migrate to the profitable job regardless of the difficulty as they still get to compete for 10 POW rewards of the profitable job regardless, which is what we want.

Hi EK, nice work as usual.   Here are a couple questions / comments:

1) Can you clarify whether this logic is setting a global target, or a target per job?  (I'm assuming this is per job)
2) If it's per job, will the network accept 10 POW per job / block, or just 10 POW total across all jobs?
3) Will the network reject all POW submissions > 10 per block, or will it accept them all with the understanding (based on retargettting) that over time the average will be 10 POW per block?  I'm just trying to understand how the scenario where a farm come online, etc where we get a burst of POW...it could be hundreds of submissions...and we don't want this high powered user to get blacklisted.


I see where you are getting a minimum difficulty.  I may have missed it, but I didn't see where you are ensuring the 5% & 20% reduction doesn't drop the targeting below the minimum.  I still think we need to maintain the minimum even if its giving less than 10 POW per block as even my pi can produce 10 POW per block at the minimum.

Take your time on the retargetting updates.  In my opinion this is still the number one open issue we need to get nailed down right now so no need to rush.  The Donna64 extension worked great...thx for the tip!  Also, I redid my crypto logic so now I have a single build for the miner and crypto lib.  Unless you have any suggestions on an alternate approach for the alogs, I'll move forward incorporating them into this design.  Either way, it won't be hard to change it later.

Hi EK, if you post your updates to a branch I'll test the retargetting this weekend when I'm working on the miner.

Thanks for the feedback EK.   I'm away from my dev computer for a few days so I'll look into it more this weekend.

Evil-Knievel, I added the sha256 algo back into the C miner to try to figure out the best approach now that we are compiling the ElasticPL into C.  Right now, my plan was to create a static crypto library that has the wrappers and algos.  It seems to complicate things a bit, but works fine.  If you get some time, can you take a look at what I've posted on my github to see if you have a better approach that you'd recommend.

The main issue I see is what you tried to address earlier, that there are numerous types of compilers / hardware that need to be accounted for.

Hi EK,

Just wanted to touch base on a couple open items as you wrap up your latest changes:

1) I added WCET to my miner, so I don't think its necessary to include this in the response message anymore unless you want to make it available to other miners.  But to your earlier point, different miners will get different WCET based on hardware, etc.

2) You may want to change the order of the private int stream from Multiplicator,PK,WorkID,BlockID to PK,WorkID,BlockID,Multiplicator.  This may allow a bit more optimization of the private int stream logic to speed things up.

3) A reminder to enhance the response messages to indicate if no additonal POW or Bounties are being accepted.  Also, when I was testing my logic was failing because even though I had confirmed bounties (and could see them in the wallet) it wasn't until several minutes later that the work package reflected these...so my calcs were off.  I was expecting the work packages to reflect these changes immediately, but if not, let me know and I'll come up with a different approach.

4) If you know of any C implementations for the Elliptic Curve and Prime calcs that matches what you are using in Java please send a link so these can get wired in.

Hi Lannister, glad to hear you are still around, but sorry to hear about any health issues.  There's nothing crypto related that's worth jeopardizing your health over, so hope you get better soon.  And, yes my BTC address is still current.

I'm not sure what the plan is for the BTC, but it doesn't appear to be for dev bounties.  I spent 2 months working on my miner for XEL and have tried to contact Lannister for several weeks asking about a bounties for the miner with no response.  Not really much incentive to keep working on it at this point.

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.

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)

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.

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.

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)

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.

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.

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.

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.

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.

I didn't realize you'd be able to do that.  Yeah that would be great...hope you can pull it off.

I've made a pretty big change to my parser now to handle parameters being passed to crypto functions (hopefully I didn't break anything).  So at this point it should now just be a matter of tracking down the crypto source and creating wrappers for the crypto functions (to correct for endianess).  And of course the parser needs a lot more error handling...just not sure how much effort to put into it as the elastic-core should have already done a more thorough syntax check before the miner ever gets the work.

just an fyi...right now for testing purposes, I have all the crypto functions included in the parser, so they will get into the C source file.  However, the compile step will obviously fail as the source code for the crypt functions is not there yet.