EK, can you check the following function, I don't think it's doing what you intended:

       for(int i=0;i<12;++i){
          int got = toInt(digest,i*4 % ln) ;
          if(i>4){
             got = got ^ stream[i-3];
          }
          stream = got;
       }

When I dump the stream, I'm not seeing any randomization.  To me, it looks like its just pushing the first 4 bytes of the digest to stream ids 0,1,2,3,4, 8,9,10 and zeros to the others.

Also, when you get a few minutes, please post the updated ElasticPL to github.

will do.  it will be a little while until I get to this, but I'm encouraged by the results you are seeing.  I'll incorporate the changes later today.

That's great news.  Please update the development branch of the miner with these changes and I'll try them out.

I think that could work.  Once implemented, we just need to make sure that it doesn't penalize the work package execution time by any material amount.

Also, I had mentioned previously about adding WCET to the response message.  I don't see the need for miners to calculate this every 15 sec for each package, when it could easily be calculated once when the work package is created and included in the work package.

And finally, yesterday you mentioned the personalized int stream which also does 12 rounds of sha256.  If we can find a simpler way to randomize the inputs using workid, blockid, pk, and multiplicator then I think we will have hit all the main points of overhead for the miner.

Also, I just throw out the "last resort" option.  If we really can't solve for keeping miners around when there are few to no work packages, maybe we should just go the other extreme and get rid of POW.  Miners get paid the same when no package is available...nothing.  When I comment POW out of my code, the ElasticPL parser runs great.  It just seems that there is a need for a lot of overhead on the POW piece to ensure mining is fair.  Honestly, if I was mining a package at this point I would just turn off the POW myself even if we decide to keep it.

I guess I've come around to your original comments that the bounty reward is what will really draw miners.

I didn't mean to imply getting rid of POS.  What I was trying to solve for is that, regardless of reputation, efficiency, etc, we need a way to encourage miners to be on the network and readily available for when work packages are submitted.  It won't do the work owner much good if he submits the first package in a week and no POW miners are on the network...his work will just stagnate.

So I was trying to think of a way to keep miners on the network while also solving the POW efficiency issue.  I threw out letting the miners share in the fees with the POS miners, but realize there are lots of issues there as well (i.e. wrong algo and we get into the asic wars and still don't have miners for work package).

I'm just coming at this from a different angle than most.  One of building up a pool of miners ready for work packages.

The would compete for the same fees as POS mining as well Work Fees when available.

I see the same performance issues in my C miner, so it's not just java.  This is the issue I've been raising for a while that running ElasticPL is very inefficient...almost all effort is in the sha256 hashing.  I was thinking that you were hashing the 64012 integers so that the miner proved they actually ran the ElasticPL code.  If you get rid of it, how do you prove the miner actually ran the ElasticPL code and didn't just throw random numbers into the memory?

As I mentioned before, I really see the best solution as having POW participate in the block mining rather than ElasticPL...that way miners are always there regardless of whether or not there are Work Packages.  Then when Work Packages are there, they do both POW and ElasticPL submitting the bounties as currently designed.

Please send some test xel to XEL-8DES-WHKN-M6SZ-8JRP5

I think this would be a good idea.  I think the new design is far more robust than the current one, so it would be great to work with that one to test if these mining scenarios I've been thinking of are even possible.

Maybe...depends on how people define the purpose of xel.  I always thought it was about getting a group of miners to join resources to solve complex problems.  However, under the current design, if I was going to mine xel (I don't have a mining rig, so I won't be), I would probably customize my miner to focus only on POW and ignore bounty calcs until I saw a scenario that I felt it was worth going after the bounty.  So the miners can just chug along collecting POW rewards without doing any of the bounty work.

If we can't convince people that all miners are working on the bounty calcs, why would anyone invest in renting our hashpower.  Seems like they'd want some guarantee...but from the responses I've seen in earlier emails, I'm not sure this is the case.  From what I've read the thought is that they will set bounties so high that it will ensure miners work on their project.  I'm just not convinced as there are a lot of variables here to determine what is profitable to miners.

Yes, I believe that would be a viable use case...I don't have any concerns about the bounty system as proposed.  Also, I do like the idea of a reputation system; however, that doesn't solve the issues I'm seeing.  To me the main issue is the potential for miners to exploit the system...and I don't mean attacking the system, I just simply mean creating custom miners that exploit weaknesses to maximize their rewards.  Ultimately, we need to find a way to get people to want to mine xel and ensure them that dishonest miners don't get an unfair share of the rewards.

I finally got my version of a multi-threaded xel miner up and running.  I'll post it to my github in a few days.

However, while building and testing this miner, I have become convinced that the approach we are taking just isn't viable.  There just seem to be too many ways for miners to game the system while as I pointed out previously, the mining has a considerable amount of overhead which limits how much processing power can even work on the bounty solutions, which makes the system rather inefficient.

My suggestion at this point is that we should move to a standard POS/POW model where both POS & POW solve blocks.  And that anyone who has created a custom work algorithm would be required to pay a fee per block when their work is active for accepting bounty solutions.  This fee would go to the POW miner if they solve the block...and if they can't pay the feed, their work package is suspended until they can.

I realize that this also places a bunch of overhead on the miner that takes away from working on bounties; however, I can't see any real incentive for a miner to use the current approach as designed.  And if xel can get a large group of miners working on bounty solutions then it doesn't really accomplish anything.

EK,

I'm trying to get my miner / parser I wrote in C up and running, but every time I submit work, I get the error "work_id not specified".  I'm submitting the work using HTTP Post with data of "deadline=3&feeNQT=0&work_id=" + workId + "&inputs=" + strRet2 + "&is_pow=true&secretPhrase=" + secretPhrase"

Do I need to send this data in a JSON format instead?  or do you have an idea why it does not recognize work_id in my data?

EK, I also have a question regarding the personalizedIntStream.  My understanding is that m[0]-m[11] are made up of hashes of the workid, multiplier, pubkey, and blockid.  However, I'm a little unclear how to make this work efficiently for a multi-threaded miner as well as this appears to add a lot of over-head to the miner that is taking away from scanning the work for bounties.

Maybe we could tweak it this way:

  - Leave m[0] available for the miner to assign incremental values to...similar to a nonce.  This way each pass, the miner would just have to increment m[0] by whatever value instead of incurring the overhead of rehashing m[0]-m[12] every time.  If the event of multiple cpu cores, it would be up to the miner to ensure m[0] is uniquely set for each core and once all m[0] values have been checked to reset m[0]-m[11]

  - Populate m[1]-m[11] with the personalizedIntStream for each cpu core that will be mining.  I'm guessing the multiplier could be used to make sure each cpu core is working on unique values for m[1]-m[11].

I realize the risk here is that if the elasticPL coder does not use m[0] only limited processing would get done, but that should just be a given that they should use m[0] as a primary input.

My thought here along with my question of adding WCET to the response is that we really want the miner focusing on looking for bounties, and minimizing the amount of overhead outside of running the elasticPL VM.

Hi EK,

Is it possible to place a pre-calcualted WCET value in JSON "getMineableWork" response.  This will greatly simplify how the miner determines which work package is most profitable.  Otherwise, the miner would have to parse the source for each package before knowing which one give the best WCET to POW reward ratio.

Also, regarding workid in the response.  Can the miner assume that for a given workid that the elasticpl source cannot change?  This will also help out the miner only needing to re-parse the source if it changes to a different workid.

I agree that a fairly simplistic parser might work.  I've been coding an ElasticPL parser in C to use with the cpuminer fork I've been using for my FPGAs.  Even though I have no experience with coding a parser from scratch, I've already got it doing most of the basic EPL parsing correctly....and if I can code this then I'm sure you guys with more experience in this could put together something pretty robust.

Yes it's a complete hack job, but I'm really just doing it as a learning experience as I don't even have a mining rig.  I just find all the posts in this thread around ElasticPL really interesting and wanted to learn more about what it takes to build a vm.

Great overview...This clarified some of my questions.  However, you mentioned that the adding a signature wont help POB.  My understanding is that POB also included a hash of the inputs, so if this hash was simply extended to include both a miner specific signature along with the inputs would that solve this issue without changing the current logic around the use of inputs?

Edit:  I think I understand now....you are saying that the hash wont get propegated so unless the inputs are unique to me anyone can steal it....that sux :-)

I tend agree with this assessment that the POW should be per work id.

My understanding is that the owner of the slow eval/sec work is supposed to provide larger POW payouts to entice miners to mine their work; however, I could see this having the opposite affect because of what HunterMinerCrafter wrote.  Regardless of how much the POW payout is of an extremely slow eval/sec work item is, with only 10 POW payouts per block (for all work ids combined) there would be a good chance that even if you found a POW result for the slow eval/sec work you wouldn't get paid as the fast eval/sec work is going to get evaluated 10x, 100x, etc times more often than this slow work and would likely consume most of the 10 POW payouts.

The other issue I see with this disparity between slow & fast work is that it seems very likely that the fast work will end up paying out all their POW rewards, but the slow difficult work may only pay out a small fraction of it due to this disparity between slow and fast work.  It would be great if we could figure out a way that the POW rewards get paid if there are miners working on that work id.

Hi EK, can you look at how Fund Allocation and Distribution are calculated.  The display seems off, see image below:

     http://imgur.com/a/hVHEY

The actual results are correct, so this just seems to be a display issue.