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

The problem could be that Elastic-flops could be too expensive in comparison to its competitors. I'm not sure if its an actual issue, but mining can give really big profit percentages and miners, or rather people who hire them, are willing to pay a lot to get them at the right time... so at the time of hype of some coin, if we can judge by the mining rental sites, Elastic would be hired to mine, while all the other jobs would wait or pay a lot more.

I'm not sure how this would be a problem.  If creator agrees to pay a higher price, then he expects a higher yield and, if he's correct in his assumptions - he'll profit.  If he's wrong - he'll incure loss.  Pure economics.

Not that I couldn't use loads of cheap computational power to run my quantum chemistry jobs, but if mining a crypto to seel or folding proteins to pharma gives higher yield - why should I get flops cheaper?

Development try an altcoin that has fallen out of popularity and have low difficulty.  Sample basecoin, dimecoin, qubitcoin, auroracoin, coinyecoin, sharecoin, quarkcoin  I'm unsure these all have low difficulty or even work any more, but worth checking.  Alternatively use a testnet.

Practice I will be mining something with an alternative proof-of-work that is faster on CPU, such as riecoin, primecoin, picoin.  It is surprising these cryptocurrencies are not more popular as true alternatives since their POW are not based on cryptographic hashes.

Another idea could be mining a CPU altcoin like XMR or its many variants.

Anyone have other recommendations?

i doubt that XEL could end up just being used as mining coin. mining other CCs with XEL means we mine them with CPUs against (usually) GPU-mined CCs. that leads to a rather small output for your computational work. i think it should be no problem for whoever wants the network to do a certain task to outbid that profit that is possible with CPU-mining.

I thought current flops per current XEL would be elastic, because this is not a determination of value, but of use (or rather a representation of possible use), and its value would be adjusted on XEL to BTC markets accordingly, but its a bigger issue than I had thought, this is crypto and the adjustment could take years; in the mean time everyone would pay excessively for any job done. Job auctions, could solve this problem with direct value determination, but they could not if the lower paid jobs would never get their turn at all (this could again mean that jobs would be too expensive, because the standard would be set by the highest yield, Elastic could become just a tool to mine the current most profitable alt without any other use possible). Job creators want cheap computation, miners want expensive computation, this is a fundamental division within Elastic system that needs a lot of attention if it is to be useful.

i would go with the fixed order, as i dont see any non-profit participants anytime soon in this early stage of cryptos. the whole scene is basically based on economical impulse.

but we could kind of dampen the effect of price a little bit through some kind of additional "weighting" if we use a combination of price AND waiting-time. that means that a job gets more important and higher up in the queue the longer he is in the queue and eventually even comes in front with the lowest bid but a very long waiting time.

edit: this effect would most likely have to be capped, cause otherwise you could just flood the network minimum bid jobs and at a certain amount in time all Flops would go to those jobs.

edit 2: i am thinking about the economics of XEL at the moment, you are right that it has to be thought through.

Random thoughts:

The Price per Flop (PPF) will always be somehow capped on the US$-PPF of our competition. Our competition is Amazon etc. The reason is obv, nobody will pay lets say 3x the US$-PPF of Amazon to get his work done by XEL. Some may like that we are decentralized and willing to pay a premium etc but in the end we will most likely be capped around the price of our US$ competition. Obv we can be cheaper, which will attract demand.

With a rising price of XEL the XEL-PPF will obv go lower.

Price of XEL rises as the network grows cause we have a.) speculation and b.) more jobs equal more XEL needed, even if XEL-PPF is lower

Yeah, maybe we go with both solutions ... and the user can toggle between time estimated or absolute, precise numbers (like 1022 jobs are there and you are cheaper than 400, that mens 622 are in front of you).

Just the last thing, that we have to think about: fixed order, or let the miners decide what they work on?
The fixed order could cause some "price rallies" where people outbid each other to get their job done quickly.
In the free scheme, we very well can have altruistic miners who always work on everything, randomly, without taking a look at the price (maybe some non profit organisations or so)? In the strict order scheme you MUST increase your bid to the max, if you wanna get your work done now.

i think that we might let the idea of time estimations go or we declare it just at what it is: an estimation that could be wrong.

so basically one could say that, looking the past 24h your job costs xyz and is done in xyz but actual results and prices may vary.

I would bid 999.999XEL and then turn on all my computers that I own to work on the 1.000.000 XEL job   Then I would revoke my job (which would be only second in line) when ~80% of the first job's XEL have been drained  

Also, in this scheme (if we go for a true auction scheme) we would have a strict order in which jobs are processed. This would allow for a so-so precise estimation when jobs are estimated to be finished. Alternatively we could let the miners chose which jobs they process. Most would of course process the most expensive first, but not necessarily all of them: so large universities could use their clusters to work on their own problem using the Elastic network, and then hope that miners will join if the price is fair enough.

This is also one point that we have to decide: Strict order or let it all be free. If anyone can decide which job to process, I think we can forget about any absolute time estimations though. What do you think?

maybe some kind of "lowest price needed to get job done in xxx" or "with this price there are xxx in front of you"

or "at the moment the average price of all jobs done = xxx"

or "last 24h average price was xxx"

i don't see any harm being done by someone bidding a large amount of XEL per flop. also keep in mind if someone bids 1mio XEL per FLOP that doesnt mean the price equals 1Mio as long as nobody bids 999.999XEL  to achieve a certain price you always need TWO participants bidding a certain price, whereas one bidder outbids the other bidder just marginally.

I have already written it in the reply to ImI, but I felt I should specifically comment on your suggestion.
My concern would be, what do we do if some commercial computing cloud is cheaper than "current flops / current money supply"?

Still, also to ImI, we will need some kind of indication of a fair price, otherwise users would not know what price to put in. Should we just give a minimum bound, and then maybe show the users "1000 other jobs are queued for that price, increase by X to get to the top?" and then let the user use a slider to set his price? And also here, should we limit the price to some value? Maybe +20% of the highest one just to avoid accidental waste of XEL? I am thinking this both from the economic view as well as from the user experience point of view. It must make sense, just work, scale with increasing computing power and with decreasing competitor prices, and be easily to operate.

That's what i wanted to hear. ;-)

I don't think that the size of the job matters that much. A job could very well run forever in an infinite loop, the trick is that the miners have a chance to submit a proof of work after every X instructions (this is that we referred to as the 10ms blocks, in fact the program is split into fixed-sized instruction blocks). The number of XEL in the work pool then basically determines how long the job will run by approximating how many fixed sized instruction blocks on-average will meet a certain hash target value.

This was Dazzas point back then ... let us come up with a scheme that would also work with infinite loops or never-terminating programs.

But your point is still absolutely true ... What if we set a fixed price and commercial applications start getting cheaper and cheaper? Eventually, nobody would use elastic anymore. An auction based approach would always self-adapt to a fair market price ;-)

So also to me, the auction model is the way to go.

In that case it could happen that we have one really big job incoming and not enough Flops. Then what happens? In a fixed model we won't be able to handle such a request in a timely manner. If we have a auction market the price per flop rises and so we attract more computational power and are able to fullfill the job in time.

To me auction model is superior to fixed rate model.

What do you think about the "current flops/current money supply = price for 1 flops always determined by Elastic network" economic model? I think Elastic would benefit from a flat model where the price for a job is always directly determined by the current use of the network and its valuation by the market. I don't see real benefits of the auction house jobs model, where jobs would compete for priority.

Would be feathercoin a nice try?

I will definitely make a demo for it. That is indeed the most natural first usecase.
Do you have any specific coin in mind?
It's best if we use a coin where you can actually "see" that it is working. Immediately. Mining Bitcoin (even when on P2Pool) using our CPUs will not be that efficient, i think we will neither find a block nor any sort of reduced-difficulty proof-of-work ... at least not in a reasonable time so that users can immediately see the outcome.

Can't wait to start POW mining other altcoins with XEL.  That should be the most natural and easiest first application for me.

I think Elastic will be a great project in time . I see a great community with hard working guys and this is always a good sign 

Thanks.