Quick update...I've been overhauling the ElasticPL engine in order to incorporate a few suggestions for additional functionality and to correct the memory issue.  I have written down some notes about the ElasticPL language and how it works and posted on my github.

        https://github.com/sprocket-fpga/xel_miner/blob/master/ElasticPL/ElasticPL%20Language%20Notes.txt

I have a POC working that can perform what is listed in the notes above, but it will still be several weeks away before my changes are final...I'm only working on this in my spare time, which is fairly limited.  But I figured I share this here in case anyone sees any glaring issues.  Rewritting this engine is very difficult and time consuming so I'd like to get all the fixes in at one time.

Just to be clear...these are just the changes to ElasticPL...there is still a ton of work to be done on the rest of the components.

lda1000, yes those are the type of concerns we are working through.  They are complex issues which are requiring parts of the workflow to be redesigned.

Although the conversation has again shifted back to a vote about a lite wallet, I'm still not sure what I perceive as the main issue is being addressed....how do we get more devs to help with the coding? 

I just don't want people to go vote for a lite wallet, and we still end up with the same issue.  Having BTC/XEL in a fund won't speed up my progress...I only work on this in my free time when I have nothing else going on...funding won't change that.

So whatever you vote for, the question still remains...how do you get a C programmer (experienced w/ high volume networking...which I'm not) to work on the ElasticPL engine.  Of course they can code in a different language, but that would require porting over everything I've done.

Well, I don't know what to say....

I tried to post a while back that I need help coding the ElasticPL engine...but it go buried under 2 pages of pure crap.....then they deleted the crap...

I just don't understand this project...I personally don't care if it goes to mainnet or not...I have asked for months to find a way to get more devs involved...

It's like people here just can't understand what is posted....you just read what you want to read....whether or not EK needs help coding....I need help with the ElasticPL engine....I don't get paid to work on this....there is a ton of coding to be done...

So maybe EK is your satoshi, whatever...it's my code that is holding things up...and as of now...I don't see it being done any time before December (you pick the year)

I can only state what I've read in the thread...EK does not want to be a part of running a project, especially the funding part of one...

This project used to be about working on an innovative project doing something unique...for me, it didn't (and still doesn't matter) if it ever goes to mainnet...I have no stake in this project, I simply found it interesting to work on.  

There is still so much work to make this project a reality...but the focus is still around how soon we launch.  In my view we need more talented devs...there is a lot of coding to be done, I really don't want to spend more than a few hours a week on this (and right now I have a ton of work ahead of me), and if you just wait for EK to do it by himself it will be ages until it's done.

I wrote the ElasticPL engine (it is used by all SN's and miners...without it...there is no Elastic) and it still needs a lot of work.  So maybe EK doesn't need any help, but I could use help with the ElasticPL engine...it is incredibly complicated, and I'm trying to enhance it to take it make it more usable / marketable.

I'm not trying to influence any decision here...this is just the state of where we are at as I see it.

I'm not sure why you are attacking someone who is offering to help.  You can simply decline his offer, or come up with a better solution.

I personally like twistelaar's suggestion, but I must qualify that I don't have any BTC to donate to a foundation, and even though right now I'm currently helping to recode the ElasticPL engine, I don't personally want to be part of running a foundation...I'm just in the background and may help out as / when I have time and the interest to do so.

The idea of a foundation has been around for a while and hasn't gotten any traction, but it's very clear that this project needs some sort of leadership.  I don't think EK can be any clearer about his stance on this issue, but it seems everyone keeps looking to him to run this project.

I will help out with this in order to keep things moving along.  But like everything in "Elastic" there are various solutions with varying levels of complexity.  I know how I'd like to fix it, but it would take a major rewrite of the vm memory model...and that is what I want to avoid right now.  But at least all ElasticPL logic is housed in the miner code so maybe it can be released in phases without impacting the core server.

EK, please send me the details of what the original problem was that you encountered (I think I have an idea of what it was), but I'd like to make sure I fully understand it.

This is my fear and why I am for getting getting something deployed.  I believe the more we test, the more we realize better ways to provide more flexibility / value to xel job authors and it becomes a never ending cycle.  Ideally, I think it would be best if a solid version that includes basic ElasticPL functionality is deployed...but even with that we now have a couple question...do we stick with the POW model we have?, EK identified some issues with the underlying memory model so we need to determine if changes are needed there, etc...and this was just in the last 24 hours.

Hopefully, people won't make their decision based on the bubble crypto is currently in...not sure how much longer it will be but I've got to believe this bubbles going to crash and we'll be right in the middle of that...so you won't see the huge influx of buyers.  I base what I recommended to do solely on what I feel may help us get more devs to pick up some of the more mundane code fixes while EK continues to explore new use-cases.  But I could be completely wrong  

bspus, that's a great analogy...(but there is actually no reason XEL can't have pools, it would just require completely new pool logic).  However, here's the main issue with just abandoning POW (even though as I've stated all all for getting rid of it)...

In coin mining, you know there is a solution, and you can calculate the estimated time for you to find a solution based on  your hashrate.  With XEL, the job author can code unsolvable problems...either by mistake, or on purpose to disrupt the network.  So you could technically mine something where it's not actually possible to find a bounty.

There are of course other alternatives to POW...one that I suggested to EK many months back (which I personally think is the best approach) is that we could have 2 types of Bounties, with 2 different payouts.  So back to your Pool analogy, the author could set a bounty for intermediate results (equivalent of a share in a mining pool) that have a lower threshold, then a different bounty amount for final solutions (equivalent of finding a block).  The advantage of a solution like this instead of the POW logic that already coded in elastic is that in the existing logic, POW is 100% overhead...it has nothing to do with finding solutions to the submitted job...A threshold approach would mean all the computational power is looking for solutions.

So using a more realistic example than mining coins, let say the author is using Elastic to find the optimum layout on an ASIC board they are designing...their final bounty target is a design that runs at 200Mhz.  They could set intermediate bounties for any solution over 100Mhz, or 150Mhz, etc.  So people could get rewarded for their work even if a 200Mhz solution is never found, the author could still use the next highest solution they got.

Of course, logic like this takes quite a bit of time and effort to code...and I'm with the group that feels Elastic should launch sooner than later (even without the ElasticPL logic) in order to bring new talent to the project.

I should probably have clarified my original comment...I meant that the original intent no longer worked.  I didn't mean to imply what you wrote doesn't work.  Back when we put the language together, my understanding was that if a specialized routine was needed (i.e. sha256) it would be coded a new function in ElasticPL which would not have any of the limitation of the language.  What you wrote is perfectly fine, it just may limit certain use-cases.  Ultimately, the language probably needs to go one step further and allow arrays of variables of each main type to be declared and used (within a limited range) rather than the generic memory model we have now.)


I'm sure your BTC example made the overhead crystal clear...that is why I have always pushed against the POW logic.  But this would have to be a community decision...it would basically mean miners would only earn XEL if a bounty was found (which I believe is the correct approach)...but that means you could run your miner for days on end with no immediate return.  this is a complete paradigm shift from what people think of as mining, so I'm not sure the community would be interested.

I would strongly suggest this BTC mining use-case not be pursued.  1000 CPUs/GPUS simply mining BTC on a pool would be way more efficient that doing the same in Elastic due to all the overhead to create the Elastic infrastructure.  I don't see how showing Elastic would be slower than mining on a regular pool shows anything of value.

EK, fyi...I believe you broke ElasticPL with your recent commit to remove negative #s.  I coded those as ints vs unsigned ints to allow for greater flexibility.

I wish they'd dump, this price is still almost double what I was able to buy them at a couple weeks ago 

Thx, that's what I figured.  I don't have a GPU, and I'm not familiar with these exchanges it's listed on so I'll just have to wait...

I too see it retracing back to the 1200 range...

I see that there is a CPU miner for this coin, but is that even profitable anymore?  Or is this pretty much for GPU mining now?

I just have a several different fpga's running right now.  I had a couple of different asics (i.e. S7, etc) running there but I sold those and I've been looking for something else.  I was looking at the x11 baikal miners but right now ordering them is a pain, so I am just looking to see what else is out there.

For me personally...I live in a high humidity area and corrosion on the electronics so far has not been an issue (maybe due to the higher temperature around the miner lowering the humidity in it's immediate area), heat has not been an issue as you are just looking for a delta...as long as the garage is significantly cooler than the miner (which it should be) it will cool (of course not as well as in a cool house).  But dust...I get lots of dust...haven't had an issue yet, but this could be an issue over time...I need to keep an eye on it.

Wow, that must be a pretty loud miner if it can't reside in the garage.  I moved my miners to the garage because they were too loud to be inside...but getting booted out of the garage

I sent a couple email, but they never responded...just too many issues dealing with them right now so I'm going to pass at this time...maybe if the group buy works out eventually I can jump in there.