[ANN][XEL] Elastic Project - The Decentralized Supercomputer

[fast2fix]

EK, I like it.  It looks clean an intuitive to me.

Thanks 

How do I throw my bitcoin your way please?

http://www.elastic.pro/donations

[1714151412]

1714151412

[1714151412]

1714151412

[1714151412]

1714151412

[1714151412]

1714151412

[Evil-Knievel]

I have spent my evening designing the job details page. It just shows some placeholder values (so please don't get confused), will link it to the real data this weekend.
Just wanted to show you how it looks like at the moment, and maybe get some input from the community:

Do you see that something very obvious is missing?
Imagine you have submitted your job to the blockchain ... is there something you would want to "monitor" on such an overview page?

[nihilnegativum]

It think that my offer of XEL per gigaflops, and my offer of XEL per gigaflops compared to other jobs would be needed, both for POW and bounties.

[Evil-Knievel]

It think that my offer of XEL per gigaflops, and my offer of XEL per gigaflops compared to other jobs would be needed, both for POW and bounties.

This is a very good point. Ideally with a convenient and easy way to quickly adjust it directly from the user interface ;-)

[nihilnegativum]

It think that my offer of XEL per gigaflops, and my offer of XEL per gigaflops compared to other jobs would be needed, both for POW and bounties.

This is a very good point. Ideally with a convenient and easy way to quickly adjust it directly from the user interface ;-)

Oh yes, that would be very handy, so you can gradually increase pay to see if it attracts more power, I thought this would be fixed per job.

[Evil-Knievel]

It think that my offer of XEL per gigaflops, and my offer of XEL per gigaflops compared to other jobs would be needed, both for POW and bounties.

This is a very good point. Ideally with a convenient and easy way to quickly adjust it directly from the user interface ;-)

Oh yes, that would be very handy, so you can gradually increase pay to see if it attracts more power, I thought this would be fixed per job.

Actually, I am not yet sure what would be the best way to go. There are currently three schemes on the table:

- Users set the rewards themselves, so the whole thing behaves like an auction where people outbid each other ... offering more if the job is urgent
- All rewards are fixed for all jobs. One GFlop has one associated value in XEL and this never changes.
- We have an automatic adaption of the price per Gflop depending on how many competing jobs existed in the past X blocks and so how much demand was there. Similar to the difficulty adjustment in Bitcoin. The more people try to get their jobs on the Elastic blockchain the more expensive one GFlop becomes.

I think this is something we will have to decide on together, but we have plenty of time left for that as it can be swapped out last-minute if necessary.

 

[bspus]

- Users set the rewards themselves, so the whole thing behaves like an auction where people outbid each other ... offering more if the job is urgent
- All rewards are fixed for all jobs. One GFlop has one associated value in XEL and this never changes.
- We have an automatic adaption of the price per Gflop depending on how many competing jobs existed in the past X blocks and so how much demand was there. Similar to the difficulty adjustment in Bitcoin. The more people try to get their jobs on the Elastic blockchain the more expensive one GFlop becomes.

I think this is something we will have to decide on together, but we have plenty of time left for that as it can be swapped out last-minute if necessary.

I think automatic is the best of the 3 listed. I dont think (2) makes much sense when the supply of XEL is fixed .
But (1) should also be included. Perhaps have price auto adjusted and set that as the minimum but allow the job setter to increase his reward to attract workers.Perhaps only by a fixed amount (5 or 10%).
Might even have different price levels. "Normal" for the default auto-adjusted, "Value" (say 10% less) for people with non-urgent jobs who want to take advantage of times when there is little work available and much supply of processing.
And of course "Premium" for the opposite

[Evil-Knievel]

Also, for the bounties I thought about the following scheme:

Idea: There is a deposit with the job of which a fixed ratio of 60% goes to Proof-of-Works and 40% go to solution bounties. The job is finished when it runs out of money, so if the proof-of-works have collected all of the 60% deposit.

Problem: Not all solutions bounties are necessarily collected before the 60% Proof-of-Work deposit is spent entirely. In this case the remainder of the 40% bounty would be just refunded. Users might be discouraged to look for real solutions at all, if they suspect that bounties are very hard to find (maybe they have some heuristic to estimate this based on the statistics only). This could be possible with a variant of the FAA attack described in the paper.
Working on the function and never intending to submit any useful solution cannot be in the interest of the job author, so we have to save him from that.

Solution?: What if we force that the 40% have to be paid out. Let us say, solution submissions are first collected and they are at first in a "pending state". Then either when the Proof-of-Work money is paid out entirely and so the job is finished or the job is simply cancelled, the bounty (the 40% of the deposit) gets shared among all solution submissions. In the case of a cancellation, maybe only a portion of it.

This way we could enforce that the author of such job pays special attention to the design of his "useful solution space" (means, he makes sure that bounties actually can be found easily enough, otherwise he pays 40% for too few solutions) and meanwhile others (the workers) are fully encouraged to go for the bounties (instead only for the steady PoW payments).

Could this be a scheme that is superior to a fixed bounty per solution no matter how hard it was to get it?

[nihilnegativum]

It think that my offer of XEL per gigaflops, and my offer of XEL per gigaflops compared to other jobs would be needed, both for POW and bounties.

This is a very good point. Ideally with a convenient and easy way to quickly adjust it directly from the user interface ;-)

Oh yes, that would be very handy, so you can gradually increase pay to see if it attracts more power, I thought this would be fixed per job.

Actually, I am not yet sure what would be the best way to go. There are currently three schemes on the table:

- Users set the rewards themselves, so the whole thing behaves like an auction where people outbid each other ... offering more if the job is urgent
- All rewards are fixed for all jobs. One GFlop has one associated value in XEL and this never changes.
- We have an automatic adaption of the price per Gflop depending on how many competing jobs existed in the past X blocks and so how much demand was there. Similar to the difficulty adjustment in Bitcoin.

I think this is something we will have to decide on together, but we have plenty of time left for that as it can be swapped out last-minute if necessary.

 

This is an issue of computational profitabillity, that must be considered very carefully because it has immediate systemic effects.

First has thepositive that you can buy time, the negative is that non-profit research directly competes with profitable computation and is either more expensive than it would be or never gets done, or less profitable computation loses to more profitable (so Elastic becomes just an ether pool)
Second  makes XEL representative money, and its value tied to the value of a gflop, this would in time decrease the value as technology improves, but it makes it cheaper to get jobs done.
Third would be computational demand difficulty, this would increase payments with more jobs, so the more successful Elastic is, the more it would cost to use it, but it would attract miners until the price would be too high for jobs. (this has similar effects as the first option)

I think that the first and third aren't viable for Elastic, the second isn't optimal as well.
I have two ideas, but not really thought them through first a correction to the third option, adjustable algo based on two difficulties one determined by # of jobs one by # of computation, (small ammount of jobs = lower payouts (less competition cost), small ammount of computation = bigger payouts (to attract miners), so you get the market flexibility but don't increase costs as much. And second, perhaps some combination could be made, you compute on the higher-pay with higher frequency, but still compute the lesser (randomly so you can't switch it off at the times you're computing for lower pay, if thats possible at all to prevent). In any case, if it is done as generalized payout, a minimum should always be determined (or people will just tag along for free).

[Selsonblue]

Also, for the bounties I thought about the following scheme:

Idea: There is a deposit with the job of which a fixed ratio of 60% goes to Proof-of-Works and 40% go to solution bounties. The job is finished when it runs out of money, so if the proof-of-works have collected all of the 60% deposit.

Problem: Not all solutions bounties are necessarily collected before the 60% Proof-of-Work deposit is spent entirely. In this case the remainder of the 40% bounty would be just refunded. Users might be discouraged to look for real solutions at all, if they suspect that bounties are very hard to find (maybe they have some heuristic to estimate this based on the statistics only). This could be possible with a variant of the FAA attack described in the paper.
Working on the function and never intending to submit any useful solution cannot be in the interest of the job author, so we have to save him from that.

Solution?: What if we force that the 40% have to be paid out. Let us say, solution submissions are first collected and they are at first in a "pending state". Then either when the Proof-of-Work money is paid out entirely and so the job is finished or the job is simply cancelled, the bounty (the 40% of the deposit) gets shared among all solution submissions. In the case of a cancellation, maybe only a portion of it.

This way we could enforce that the author of such job pays special attention to the design of his "useful solution space" (means, he makes sure that bounties actually can be found easily enough, otherwise he pays 40% for too few solutions) and meanwhile others (the workers) are fully encouraged to go for the bounties (instead only for the steady PoW payments).

Could this be a scheme that is superior to a fixed bounty per solution no matter how hard it was to get it?

Easiest and fairest is a fixed cost per job, paid entirely upfront but should prob be released as the job progresses. Work on the variable rate and or auction systems later on after ironing out the initial batch of defects you will uncover when people start using the software.

Just an opinion.

BTW, awesome work on this UI. I really like it

[Abiky]

I like the idea of the Elastic supercomputer. It is a great way of making the blockchain even more useful than before. Can't wait for its official release. I have the feeling that this is going to be huge. 

[nihilnegativum]

Also, for the bounties I thought about the following scheme:

Idea: There is a deposit with the job of which a fixed ratio of 60% goes to Proof-of-Works and 40% go to solution bounties. The job is finished when it runs out of money, so if the proof-of-works have collected all of the 60% deposit.

Problem: Not all solutions bounties are necessarily collected before the 60% Proof-of-Work deposit is spent entirely. In this case the remainder of the 40% bounty would be just refunded. Users might be discouraged to look for real solutions at all, if they suspect that bounties are very hard to find (maybe they have some heuristic to estimate this based on the statistics only). This could be possible with a variant of the FAA attack described in the paper.
Working on the function and never intending to submit any useful solution cannot be in the interest of the job author, so we have to save him from that.

Solution?: What if we force that the 40% have to be paid out. Let us say, solution submissions are first collected and they are at first in a "pending state". Then either when the Proof-of-Work money is paid out entirely and so the job is finished or the job is simply cancelled, the bounty (the 40% of the deposit) gets shared among all solution submissions. In the case of a cancellation, maybe only a portion of it.

This way we could enforce that the author of such job pays special attention to the design of his "useful solution space" (means, he makes sure that bounties actually can be found easily enough, otherwise he pays 40% for too few solutions) and meanwhile others (the workers) are fully encouraged to go for the bounties (instead only for the steady PoW payments).

Could this be a scheme that is superior to a fixed bounty per solution no matter how hard it was to get it?

I think this idea would be great as a minimum requirement, so that the network decides the lowest pay per job price with 60/40 proportion, but after you can pay extra to get your work done faster.

I think its important to view Elastic as a supercomputer, that is as a whole so I'd much prefer that jobs are made to the network, and that the network pays miners not in individual case by case. With this in mind I have an idea for a scheme of job-network-miner interaction.

When you create a job you have a minimum of XEL per job determined by the network (60/40), and add extra to bounties if you want. Together you get your XEL/FLOP score. All the active XEL/FLOP scores together are 100% share of the computation of the network and are distributed on a Gauss curve, as a probability of being computated. Miner starts mining on the low XEL/FLOP scores and gradually move towards higher, then continue towards lower, and repeat the cycle in a way that keeps them focused on higher paid jobs.

Pro: You're not buying some computational power, you're hiring a supercomputer. All jobs that are above the required threshold are done. Surplus value comes from bounties while keeping the pow price as low as possible.

Problems: Miners could switch off when computing lower XEL/FLOP scores.
Solution 1: Job obfuscation
Solution 2: Disconect Hell: miners that connect are first stuck computing lower scores.

Tell me if you see more problems and why/how its a bad/unfeasable idea.

[andrepierre]

I like the idea of the Elastic supercomputer. It is a great way of making the blockchain even more useful than before. Can't wait for its official release. I have the feeling that this is going to be huge. 

Invested in this project already, considering to invest more now

[GTTIGER]

Interesting concept and interesting execution so far. I can't say that I like that escrow wasn't accepted but it seems that you have reasons. Also, as an investor, I don't mind the added risk because it keeps out others.

[Nomad88]

There is one think i am trying to understand, there is a mixer involved for every donation above 0,5btc which makes them very suspicious. Am i missing something here or is it just a coincides?

[cryptoheadd]

There is one think i am trying to understand, there is a mixer involved for every donation above 0,5btc which makes them very suspicious. Am i missing something here or is it just a coincides?

What do you mean?

[mentalpanda]

There is one think i am trying to understand, there is a mixer involved for every donation above 0,5btc which makes them very suspicious. Am i missing something here or is it just a coincides?

yes mostly mixing
https://blockchain.info/tr/address/1BeyK8UPBAuvKahaeLbdDBwuqu1WJRdnca
https://blockchain.info/tr/address/1C1ZXeQUJQGi8GL7iyjoi6zfGd4EC25981
https://blockchain.info/tr/address/1K4iZ9FFDx5CyAWKgfTH3hSCnVRtrmm1eS
https://blockchain.info/tr/address/1Gx4nmEt8VyNeSjn675o3bHZ7VSaZjS5yk
https://blockchain.info/tr/address/1Q4Z1fueBbhL3Jcgv8SssLPUt8HgmCntCA
https://blockchain.info/tr/address/13ckSm9CJL2SPqiQVrDC2C1UxLBUV2Y1Xe
https://blockchain.info/tr/address/14MKronX9pQJui5vVENveDqwKFE6bxWVk4
https://blockchain.info/tr/address/1BrKwsVmHvHxnbgGnnQ4U2KC4rV1a2nUS3

[Nomad88]

There is one think i am trying to understand, there is a mixer involved for every donation above 0,5btc which makes them very suspicious. Am i missing something here or is it just a coincides?

What do you mean?

Simple enough, all donations above 0,5btc are untraceable due to mixing. Is it just a coincidence? I have a feeling that those donations are made by the project owners. Do i need to be more clear?

[bitbitch]

There is one think i am trying to understand, there is a mixer involved for every donation above 0,5btc which makes them very suspicious. Am i missing something here or is it just a coincides?

What do you mean?

Simple enough, all donations above 0,5btc are untraceable due to mixing. Is it just a coincidence? I have a feeling that those donations are made by the project owners. Do i need to be more clear?

to be clear, you are saying that every donation that has been made that is greater in value than 0.5 btc went through a mixer before being donated?

[Nomad88]

There is one think i am trying to understand, there is a mixer involved for every donation above 0,5btc which makes them very suspicious. Am i missing something here or is it just a coincides?

What do you mean?

Simple enough, all donations above 0,5btc are untraceable due to mixing. Is it just a coincidence? I have a feeling that those donations are made by the project owners. Do i need to be more clear?

to be clear, you are saying that every donation that has been made that is greater in value than 0.5 btc went through a mixer before being donated?

That`s correct. Is there an explanation for that?