To me Augur is no positive example, since they launched at exchanges their price went nowhere but down. I would much prefer the opposite, start small and get a better valuation step by step.
I completely agree. I don't have much invested so whether the price goes up or down doesn't really affect me. But this isn't about making a profit. Elastic is a very complicated system. EK and I will do our best to deliver a fully functional bug free system, but we all know how software development is...there will always be something that got overlooked, etc. Starting small means we can work through these growing pains without getting caught up in all this P&D madness....there are plenty of other coins for people to play that game with....let's leave Elastic out of that. |
|
|
|
From the perspective of a miner: - Where can I download the software to mine Elastic?
- How will I get paid?
- How will I know if it is cost effective for me to mine Elastic?
We now need to start looking at Elastic from an end user perspective and I'm sure the questions above only scratch the surface of what the end users (research scientists and miners) will want to know and what needs to be put up on the website. there is an elastic miner already in progress. You would be paid in XEL. So do we know if it will be as simple as with the SETI software from years ago, where you just download it and it chugs away in the background? Also will the wallet for the miner's XEL be online or incorporated into the Elastic software that they download? The miner that I wrote needs to be built / installed the same as sgminer, cpuminer, etc...you clone it from github, then build it. It does not chug along in the background, it runs as fast as it can to solve the work problems (of course you can limit the # of threads). This goes back to my earlier point...you can have a miner that works exactly like the SETI software...you just need to write it. This is the only miner I plan on writing and honestly, I really can only put another week or two into it...I've spent way too much time on this already...time for me to move on to other things. |
|
|
|
|
clivemy, if you have some ideas of the type of things you want to write about that would help in determining if anyone can help point you in the right direction (i.e. if you have questions about mining/solving work packages or the ElasticPL language, I can help answer....just PM me).
But I think there is a mis-conception about a roadmap. This project is open-source and will move in whatever direction contributors take it....what EK and I deliver is fully functional...it can solve a variety of complex scientific problems using XEL to provide incentive to users to run nodes to solve these these problems. But that doesn't mean some talented people can't step in to greatly enhance the capability of this system, or take the project in a completely new direction. It just depends on what people contribute to it...
|
|
|
|
|
I continue to put quite a bit of time into the miner. I can't speak for EK, but I imagine he puts in about 10x the effort I do.
From my perspective, we are identifying areas of the design that need improvement and we are working hard to not just correct the issue, but to do it in a way that will minimize the need for major rework / forks at a later date.
And as was pointed out a few post back, I do this because I enjoy it, I do not get paid and I have a family and full time job that is my priority.
|
|
|
|
You're probably right. Last we heard from him he was dealing with health issues, so I hope he's okay. I think people get too caught up in this crypto stuff and forget these are real people with families and other priorities...none of which is worth sacrificing for any of these projects. |
|
|
|
More specifically, contests on Kaggle provide the data, and we can try to produce solution using distributed computing resources through XEL: https://www.kaggle.com/competitionsThere's no reason XEL couldn't be used to solve Kaggle problems. But regardless of XEL, to come up with a solution someone has to code it in whatever language. I agree that this would be a great way to test out XEL, but unless someone steps up and helps out, it won't happen any time soon. I don't mind stepping in. But I know nothing about the language. I could program some solutions using some of the already existing libraries out there in Python/Java/etc. Remember it doesn't have to be the best solution, I'd be happy to see it being useful, not necessarily providing the best solution (for now). ElasticPL is very much like C...just has 64,000 predefined ints (m[0] through m[63999]), 1,000 floats (f[0] through f[999]) and a different looping mechanism, but other than that if you can write a Kaggle solution in C, I'm sure we could get it ported over to ElasticPL pretty easily. |
|
|
|
More specifically, contests on Kaggle provide the data, and we can try to produce solution using distributed computing resources through XEL: https://www.kaggle.com/competitionsThere's no reason XEL couldn't be used to solve Kaggle problems. But regardless of XEL, to come up with a solution someone has to code it in whatever language. I agree that this would be a great way to test out XEL, but unless someone steps up and helps out, it won't happen any time soon. |
|
|
|
I'm not sure whether this needs to be implemented directly. I guess C uses libraries just as C++ does? I don't see #includes in the screeshot, is ElasticPL supposed to have libraries? If yes, the easiest may be to simply "outsorce" it to a library?
Whether or not it's in a header file, someone has to write and test it. Unless we get more help, I'm hoping we limit the number of changes at this point. The miner is already way behind all the new ElasticPL changes as it is. It will probably be at least a week or two before I can get caught up with EK's changes. |
|
|
|
Will u compile it for Win64?
Pretty much everything EK does is java based, so it should run on all platforms...the miner is a different story. |
|
|
|
Our SDK Editor just got one tad sexier ;-)
(picture)
... just to get a feel how fast we are proceeding. A few months ago, our editor looked like this fella here:
(picture)
Hey, don't know if you already thought about that, but I think it would be cool if you could "name" parts of the arrays, so you could use them pretty much like variables (or smaller arrays). This would help distinguish parts of the arrays and what they are supposed to do (i.e. using descriptive variable names). The names would be dismissed by the compiler, just like comments. You cold probably simply use the "search and replace" tool to achieve that, but having it built in would be nice either way. I'm guessing you wouldn't have liked the early days of computers when all we had was assembly & machine code  Anything can be added, but every change takes time to code / test. I think it would be best (and I think it was mentioned before) that someone keep a running list of suggested enhancements. |
|
|
|
Yeah, I think we need additional mathematical operators.
EDIT: SQRT on integers sucks a bit, we might need to think about the design! What do you think?
Nice job with the SDK. I had thought about this float issue during my original miner design. Having an integer based design allows us to run at the best speeds and I'd prefer not to move to a float based design. However, if we create a small chunk of memory (maybe 1000 floats) that can be used to store this type of data if needed, we may get the best of both worlds. It would be available if needed, and if not, I don't think we'd see any decrease in performance. Or am I oversimplifying this? |
|
|
|
|
EK, starting to look at fitting the traveling salesman problem into elastic. Obviously, this problem requires distances to be calculated. Is the expectation that the author takes care of these calculations outside of elastic and provides this as part of the raw data, or do you think we need to add some additional math functions to ElasticPL such as sqrt (and I'm sure there are others)?
|
|
|
|
I think, the traveling salesman problem is perfect for testing, because it is extremely scalable: You could either generate millions of random combinations or very few, very optimized solutions.
I still like the idea of two job authors playing chess against each other, using nothing but Elastic. Bruteforcing moves might not be the most promising approach to playing chess, but it sounds doable to me.
Ok, I'll spend some time looking at the annealing or traveling salesman problem to see if I can get a real-world example in elastic. EK, I'm sure I'll have some questions for you  Maybe ttookk, you can create your chess example as your final exam for your newly aquired coding skills  |
|
|
|
What we still have to think about, input might be larger than 12 integers
Maybe we implement a randomize function that authors can use to use the 12 inputs to randomize as many inputs as they need. Do you think it might be wise to have at least some sort of persistent distributed storage?
I could definitely see a use case for this...not sure how to implement efficiently but should probably be on the roadmap. And what a out "job updating"? We could allow jobs to be updated while running?
I thought about this when I first wrote the miner...right now it doesn't account for this. However, if the UI allows an update, and submits it with a different work ID, then the miner would run as currently designed. I was trying to avoid having to reparse the ElasticPL every 60 sec or so to see if it changed....as long as the update cancels the old work ID and creates a new one, it should work seamlessly. |
|
|
|
Not sure yet how this might exactly work. Imagine this algorithm:
Genetic Algorithm to solve the travelling salesman problem.
The order in which cities are visited are encoded on out chromosome.
In each iteration we generate millions of random solution candidates ... we want to take the best 1000 solutions. These are stored as a intermediate bounty (not sure how to store 1000 bounties lol)
Then, in the second generation, we take those 1000 bounties and again "mutate" those millions of times in the hope to get even better solutions. Again, 1000 (hopefully better) solution candidates are taken into the next generation.
We repeat that until we find no more better solutions.
I am right now thinking how we could model that in Elastic. If those 1000 candidates need to stored in the block chain at all. And what changes it would take to make it possible to implement such simple optimization algorithm.
At the moment, we could just "roll the dice" over and over again ... basically a primitive search.
Okay, I guess this is where I'm the non-conformist to the blockchain movement. I would think the author should have some accountability here (i.e. run a client, or at least check in regularly)...the results should be saved locally on their workstation and sent back as an updated job via RPC. To me, the blockchain is the engine performing the work...but I don't see why the author can't have a client that helps then analyze / prepare / submit jobs as and when they want. Yes, the client would need to be coded to handle that logic, but does it really need to be part of the blockchain? |
|
|
|
Maybe we could collect some common problems and think if they can be implemented now, or - if not - what it would take.
Travelling Salesman, Monte Carlo Experiments, GA optimization, Simulated Annealing, linear or non-linear optimization problems, just to name a few.
Actually this looks interesting to me. I might need some help getting pointed in the right direction, but I'd like to take on one or two of these simulations...I agree...other than general testing, putting the elastic network up against some real-world scenarios is probably the most beneficial thing we can do right now to prove the design works. Maybe I'll start with simulated annealing...reminds me of my material science classes from decades past |
|
|
|
I think it is not far away, we can use it for any kind of search space to search it in a bruteforce manner. I think to make it perfect, we need some "synchronization" feature.
Makes sense. Just thinking through this...so we would display the solved Bounties to the author, with some sort of cut/paste feature of the outputs to ease setup of the next job? Or is there a way to automate this even further? |
|
|
|
In my personal opinion ... this is doomed to fail BIG WILLY STYLE!
LOL...I always enjoy hearing your input...informative, and it always makes me laugh  If I recall, some of your early interest in this project was from an academic perspective (i.e. research). Do you think the system "as-is" is marketable to researchers, or do we need this additional level of security? Seems like HE is still in its infancy, so I'd hate to lose out on on our advantage, but if there is limited market w/o HE, then we need to pursue it. |
|
|
|
I'll start taking a look as well. If something doesn't stand out, we may be better served by creating a roadmap with this on it and moving forward "as-is". I think we just need to stay ahead of the other blockchains exploring this distributed computing space, which I'm confident we already are.
HELib: 33 ms for encryption and up to 5 seconds for decryption  A bummer. Unless we only allow "operations" on the encrypted big integers, and encryption and decryption is entirely up to the user alone. Also, not sure how effective the "verify" routine can be made. Does any cryptosystem have some useable operations that would be suitable for the verify routine? Maybe another way to look at this is to target specific use cases. For example, someone mentioned video renedering...what functions are required for that? Maybe the partial homomorphic encryption systems are good enough for some of the mainstream use cases. |
|
|
|
I'll start taking a look as well. If something doesn't stand out, we may be better served by creating a roadmap with this on it and moving forward "as-is". I think we just need to stay ahead of the other blockchains exploring this distributed computing space, which I'm confident we already are.
HELib: 33 ms for encryption and up to 5 seconds for decryption A bummer. Yep, saw that. I'll keep looking though. Wonder if there is a way to leverage FPGAs for this...I might have a bit of experience there ;-) |
|
|
|
|
Show Posts
