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

[xxxgoodgirls]

Very good point. You're right, bug bounties would strenght the project enough if not way more than hiring random programmers and reviewers from the internets.
When XEL will gain resonance th3 very open source nature of the project will eventually make programmers committ to the cause by themselves. No need to rush yet.
So, yeah, I believe that a well organized bug bounties system is enough good at this time.

[1714223603]

1714223603

[1714223603]

1714223603

[1714223603]

1714223603

[darlidada]

Anyone wants out of elastic? I'm interested in buying OTC. I know some guy did sold his position early in this thread

[igorokavg13]

EK is really good. Hope everything will be ok with project. Gonna invest some money.

[palawan]

Anyone wants out of elastic? I'm interested in buying OTC. I know some guy did sold his position early in this thread

Hello, I'm willing to sell some of my XEL.  I invested using different public keys.

I can sell much as 1 BTC's worth of XEL only.  I wouldn't know how to transfer ownership.  I can sign using any of the public keys that I used to invest with.  We'll probably need Lannister to change the public key entry(ies).

[GTTIGER]

This is one of those coins with a high risk to reward ratio. The team is doing a better job than I expected. I initially didn't know what to think.. but now I think it's a cool project. I hope evil can come up with some cool tech I like that you are into the project because you want the tech for your own research - that's cool. Best of luck team!

[Evil-Knievel]

This is one of those coins with a high risk to reward ratio. The team is doing a better job than I expected. I initially didn't know what to think.. but now I think it's a cool project. I hope evil can come up with some cool tech I am like that you are into the project because you want the tech for your own research - that's cool. Best of luck team!

Thank you very much for your kind words. Yeah, I feel like I cannot finish my PhD thesis without huge amounts of computational power. My infiniband cluster does not work at all, and renting computational power at EC2 is too expensive. That's why I (in my own interest) was so excited about this project and I will get this thing up and running no matter what ;-)

[devking]

This is one of those coins with a high risk to reward ratio. The team is doing a better job than I expected. I initially didn't know what to think.. but now I think it's a cool project. I hope evil can come up with some cool tech I am like that you are into the project because you want the tech for your own research - that's cool. Best of luck team!

Thank you very much for your kind words. Yeah, I feel like I cannot finish my PhD thesis without huge amounts of computational power. My infiniband cluster does not work at all, and renting computational power at EC2 is too expensive. That's why I (in my own interest) was so excited about this project and I will get this thing up and running no matter what ;-)

EK, this one looks interesting , http://research.microsoft.com/pubs/180286/pinocchio.pdf. It proposes 288 byte proofs for verification?.

http://research.microsoft.com/en-us/projects/verifcomp/

[twistelaar]

Anyone wants out of elastic? I'm interested in buying OTC. I know some guy did sold his position early in this thread

Hello, I'm willing to sell some of my XEL.  I invested using different public keys.

I can sell much as 1 BTC's worth of XEL only.  I wouldn't know how to transfer ownership.  I can sign using any of the public keys that I used to invest with.  We'll probably need Lannister to change the public key entry(ies).

How much XEL is it?

[palawan]

Anyone wants out of elastic? I'm interested in buying OTC. I know some guy did sold his position early in this thread

Hello, I'm willing to sell some of my XEL.  I invested using different public keys.

I can sell much as 1 BTC's worth of XEL only.  I wouldn't know how to transfer ownership.  I can sign using any of the public keys that I used to invest with.  We'll probably need Lannister to change the public key entry(ies).

How much XEL is it?

I bought at different times so different rates.  Let me check...

See below:

https://raw.githubusercontent.com/elastic-project/genesis-block/master/genesis-block.json

pubkey:   0217e6fb61c54b5e8c9e81d99230bae79edb0430cbaa05f5d73382347f727d84b4

1.   2,493.20 xel   .368 btc
2.   1,870.64 xel   .28  btc
3.   2,958.12 xel   .45  btc

Total   7,321.96 xel   1.098 btc


or:


pubkey:   02d2e7180985affa7cc2f2371e8e2d46b61d46ccba22f357107fdfa8f64bfaa6fc

   2,912.52 xel   .43 btc


pubkey:   0297a32e5a4adb34a97fb9ade48e2b328e2b1b1b915febff1f4bca1b611217e040

   3,180.53 xel   .49 btc

[Evil-Knievel]

EK, this one looks interesting , http://research.microsoft.com/pubs/180286/pinocchio.pdf. It proposes 288 byte proofs for verification?.

http://research.microsoft.com/en-us/projects/verifcomp/

I know, but it requires an infeasibly complex pre-computation phase which would have to be carried out on each node unless we trust a "central authority" ... which we don't  
I think for now it's best to stick to the verification scheme by Dazza, I will try to finish the (very) few missing pieces as soon as I can so we can roll out a testnet and let Lannister set up some bug bounties. Meanwhile, we can find a formal proof for the "amount of confidence" in our scheme and based on that give hard bounds for the false positive rate of malicious proof of works. It should then quickly become clear if we need to adjust this scheme or if its acceptable.

[Evil-Knievel]

This is the current work flow / payment flow. What do you think, does that make sense?
Also, I need some input on the red line ;-) Thanks

1. User creates a job and attaches a certain amount of money M.
2. This money M is split into two piles, 60% go to the pow fund P and 40% go to the bounty fund B.
3. Users periodically send proof of work packets which are themselves rate limited by an automatically adjusted difficulty. Based on that difficulty, users are credited a variable amount V from the pow fund P.
4. Users periodically send bounties (that is, no proof of works but rather those results that the author of the job is looking for), these are included in the blockchain but do not yet pay anything.
5. To avoid DOS with a huge amount of bounty submissions which are not rate limited, we have to limit the number of allowed bounties. (here I need the community's opinion ... should we go for a hard limit or a variable limit which can be increased by higher fees maybe?)
6. Once the pow fund P runs out of money, the job is cancelled or timed out or the job has received the maximum number of bounties these two things happen:
- The author of the job gets credited the remaining funds in the pow fund P
- The bounty fund B gets evenly distributed among all bounty submissions - so if there were 10 submission, each one of them gets 1/10 of the bounty fund B.

Note: This means that the total money (P+B) is only refundable as long as no bounty has been submitted. If one has been submitted a job the refund after a cancellation or timeout is at most what was in pow fund P.

[benyate]

This is the current work flow / payment flow. What do you think, does that make sense?
Also, I need some input on the red line ;-) Thanks

1. User creates a job and attaches a certain amount of money M.
2. This money M is split into two piles, 60% go to the pow fund P and 40% go to the bounty fund B.
3. Users periodically send proof of work packets which are themselves rate limited by an automatically adjusted difficulty. Based on that difficulty, users are credited a variable amount V from the pow fund P.
4. Users periodically send bounties (that is, no proof of works but rather those results that the author of the job is looking for), these are included in the blockchain but do not yet pay anything.
5. To avoid DOS with a huge amount of bounty submissions which are not rate limited, we have to limit the number of allowed bounties. (here I need the community's opinion ... should we go for a hard limit or a variable limit which can be increased by higher fees maybe?)
6. Once the pow fund P runs out of money, the job is cancelled or timed out or the job has received the maximum number of bounties these two things happen:
- The author of the job gets credited the remaining funds in the pow fund P
- The bounty fund B gets evenly distributed among all bounty submissions - so if there were 10 submission, each one of them gets 1/10 of the bounty fund B.

Note: This means that the total money (P+B) is only refundable as long as no bounty has been submitted. If one has been submitted a job the refund after a cancellation or timeout is at most what was in pow fund P.

A variable limit , and can be increased by higher fees.

[Wesiematic]

Decentralized supercomputer sounds interesting, will investigate this one.

[Evil-Knievel]

I am still thinking about how to nicely display this complex refund of pow / bounty things that I have explained a few posts above. This is my latest suggestion ... hope its easily understandable?

[trader19]

I am still thinking about how to nicely display this complex refund of pow / bounty things that I have explained a few posts above. This is my latest suggestion ... hope its easily understandable?

for such komplex product it looks pretty understandable, good job. I would say its a go..

[boltz]

You're doing a great job guys . So happy that I've found you on the first days <3 .

[nihilnegativum]

UI looks great, I'm in favor of the variable bounty scheme.

One question: could the bounty refund be exploitable. For example could someone set up the job in a way to search for decoy results, while getting his desired results without paying the bounty?

[Evil-Knievel]

UI looks great, I'm in favor of the variable bounty scheme.

One question: could the bounty refund be exploitable. For example could someone set up the job in a way to search for decoy results, while getting his desired results without paying the bounty?

I don't think so, because:
1.) The POW work packages are absolutely useless for the job author. They hash the current state, the last block's hash, the input variables and some other stuff that the author cannot use for anything useful.
2.) This leaves only the bounties. What the job author indeed could do is to push a "bounty check function" that never evaluates to TRUE so no bounty is found at all. But in this case, nothing will be transmitted by the "miners" except those useless POW from pt.1. This also means, that the attacker does not profit in any form from what is calculated on the users computers - it just stays there and never leaves it unless the bounty check function evaluates to TRUE.
3.) A useless "bounty check function" will cost the job author money - the funds in the POW fund. So there is no incentive to do that "just for fun".

[robdark]

How many coins will be distributed to donators and how many will be held back by devs?

[ImI]

afaik 5.000.000 = coinsupply and no coins being held back