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

[lda1000]

Friends, let me help, as might have been, or may even now it can be done, how you can get Elactic tokens, my friend told me that the projects on the supercomputer technologies are gaining in popularity, and I would like to have a share, too Elactic

The ICO ended and we're all waiting for the development to finish and main net to start (hopefully no too long?).
Once the main net starts the XEL is going to be available on exchanges and people can trade it.

[lda1000]

I have few questions, hope you guys don't mind answering:

1) What's the current state of the code base?
2) How far are we from minimum viable product?
3) When testing starts?
4) What is your estimate on the main net release date?

Thanks.

[Evil-Knievel]

I have few questions, hope you guys don't mind answering:

1) What's the current state of the code base?
2) How far are we from minimum viable product?
3) When testing starts?
4) What is your estimate on the main net release date?

Thanks.

I will answer all your questions in about 4 hours.
I had only limited internet access because I moved to a different town in the last 2 days, now everything is working fine again.

I'll update you this evening with a small roadmap divided into all milestones (really, it's not that much) that I believe are left.
Sure, the last-minute idea that we had (the supernodes) delayed things by a few days due to the extra implementation work, but on my side it's all done by now.

But more in a few hours.

[altcoin_investor101]

interesting project, anyone selling at good price in escrow? dm me plz

[Thefrolly]

interesting project, anyone selling at good price in escrow? dm me plz

the xel are pegged to the priv. key of the btc address funds were send from, so you cant buy any even with escrow atm.

[cryptoboy.architect]

interesting project, anyone selling at good price in escrow? dm me plz

the xel are pegged to the priv. key of the btc address funds were send from, so you cant buy any even with escrow atm.

He could, if the BTC is locked in the Escrow until launch.

[haggis]

interesting project, anyone selling at good price in escrow? dm me plz

the xel are pegged to the priv. key of the btc address funds were send from, so you cant buy any even with escrow atm.

He could, if the BTC is locked in the Escrow until launch.

How could the seller proof it was not him who claimed the XEL in case the buyer alleges this?

[ImI]

interesting project, anyone selling at good price in escrow? dm me plz

the xel are pegged to the priv. key of the btc address funds were send from, so you cant buy any even with escrow atm.

He could, if the BTC is locked in the Escrow until launch.

How could the seller proof it was not him who claimed the XEL in case the buyer alleges this?

Escrow would have to hold both: The BTCs and the priv-key. So he could claim the XEL and then send them to the buyer and the BTC to the seller. If he cant, cause the seller did before him, he would just send the BTC back to the buyer.

[cryptoboy.architect]

interesting project, anyone selling at good price in escrow? dm me plz

the xel are pegged to the priv. key of the btc address funds were send from, so you cant buy any even with escrow atm.

He could, if the BTC is locked in the Escrow until launch.

How could the seller proof it was not him who claimed the XEL in case the buyer alleges this?

Escrow would have to hold both: The BTCs and the priv-key. So he could claim the XEL and then send them to the buyer and the BTC to the seller. If he cant, cause the seller did before him, he would just send the BTC back to the buyer.

Escrow will hold the BTC, until XEL is live and asset transferred to buyer's address.

[ttookk]

Having more people staking Elastic is important to secure the blockchain, make sure it is stable and prevent all kinds of attacks and forks.

So people should have tangible incentive to stake, the more people, the better. If only few stake due to low rewards, that is dangerous.

Actually, it all depends on how big would be the fees.

I disagree that it depends on fees. Quite the opposite actually.

There are people who DO have a vested interest in keeping XELs blockchain healthy: those who want to use it, be it as job authors or miners. And I personally would want those people to secure the blockchain, instead of pump and dump vultures.

Therefore, I actually think that having as low as possible block rewards are good for XEL. It keeps speculators away.

[Evil-Knievel]

Hi Community,

I am writing you to give you a short overview of what we have done so far, why we have done it, and what (from our point of view) still has to be done - and when. I have been moving to a new town in the last days, so

First of all, we had a last-minute idea - the idea of introducing so called super nodes. The reasons were:

1. Since earlier everyone had to verify work, we were very limited: we had very strict constraints regarding the complexity and memory requirement of work packages, simply due to the reason that the weakest node still has to be able to verify everything in a reasonable amount of time. Otherwise, netsplits or node shootdowns would be possible with complex long running tasks. With super nodes we are more flexible: we can set strict requirements that a super node's hardware has to meet and so can allow programs that run longer and use more memory.
Supernodes are basically nodes that do the verification and have no incentive to cheat due to a huge deposit. Contrary to other "well hyped solutions" we do not rely on trust at all ... all calculations and decisions that the super nodes perform can be publicly verified by anyone. For example by the so called guard nodes. These are nodes that randomly cross-check a small fraction of jobs. If they detect that a super node lied, its deposit gets forfeited.

2. Also, earlier a bug in the implementation (causing an infinite loop for example) could halt the whole network since every node is execution the task. Now, the network is safe from this. Also, the super node software will have emergency stop mechanisms that would prevent bugs to crash anything. Again, this design has several benefits here. It's better if one supernode freezes for 15 seconds before it detects the anomaly than if every node in the network freezes for 15 seconds.

3. Also, and this is a PR benefit, the earlier design effectively executed foreign code on the own hardware. While it's super safe due to Elastic PL's nature (our own programming language that does not allow to program anything dangerous), managers who want to use Elastic in their commercial setting might get scared. Now, nobody but the supernodes has to execute anything.


So where are we?
--------------------

We have the code base done that incorporates the new logic into the core client. The supernode functionality is there (except one little detail still missing - the guard node logic). And we have the miner done which - since super nodes and miners execute the same code - can be used for both.

What is missing with deadline dates
----------------------------------------

The following packages are still missing and are planned (not promised) to be finished as follows (London time):

09.02.2017 - The core package with guard logic is finished and goes into code-review mode
12.02.2017 - The supernode extension was added to the miner so that it can be used to verify work of others
13.-14.02.2017 - I am offline
17.02.2017 - Guard node software is finished. Parallely, everything goes into testnet mode for heavy testing
18.02.2017 - Open discussion round here, about how things are working out and specially about the retargeting algorithm that we currently have (there were ideas how to get rid of it)
18-24.02.2017 - Grace period to fix problems that we found in the test net
26.02.2017 - I will have written all details about the system down (both technically and non technically) for those guys of you, who are responsible for the PR parts (website, video, whatever)
27.02.2017 - Last discussion here in the thread
28.02.2017 - Milestone freeze, first ready-to-use version should be finished by then. I (and all the others that work on the code) am/are just (an) interested code monkey/s who love/s fascinating tech. We will not launch anything, we just give the code to the community, so if the community thinks the system (that we suggested) is good, just launch it yourself by using it! Remember: we are doing it for you guys, and not to run a company or something by ourselves. Just do with it whatever you like.

Disclaimer
----------------------------------------
We do not run anything, we do not take responsibility for anything. We code because we love coding, and if in doubt just suggest the appropriate changes and we can figure things out. Nobody forces anyone to use anything, and nobody promises anything. We code as good as we can, ... to reduce the likelihood of bugs (which always may or may not occur) we would appreciate to get more eyes on the code. Also: if you think you can do it better ... then just do it!

After everything works out, I am sure we can think about new cool features that pop into our heads.

[ImI]

Nice update!

What about malicious guard nodes? Lets say a guard node intentionally and falsely marks a supernode as a liar and so the supernode looses his XEL?

[cryptoboy.architect]

Nice update!

What about malicious guard nodes? Lets say a guard node intentionally and falsely marks a supernode as a liar and so the supernode looses his XEL?

That's why we should run a test net and explore these issues.

[clivemy]

@Evil-Knievel

Thanks for the update EK and great work.

With regard to the PR, access to the website will be needed to send out PRESS RELEASES from the official Elastic email address and to monitor the account for any press replies to that address.

So we need to know who's going to monitor and control the email address.

I'll try to put together a list of email addresses that the PRESS RELEASE will go out to.

[HI-TEC99]

interesting project, anyone selling at good price in escrow? dm me plz

the xel are pegged to the priv. key of the btc address funds were send from, so you cant buy any even with escrow atm.

How many Bitcoins did the ICO raise?

[clivemy]

interesting project, anyone selling at good price in escrow? dm me plz

the xel are pegged to the priv. key of the btc address funds were send from, so you cant buy any even with escrow atm.

How many Bitcoins did the ICO raise?

700

[laugh2btc]

interesting project, anyone selling at good price in escrow? dm me plz

the xel are pegged to the priv. key of the btc address funds were send from, so you cant buy any even with escrow atm.

How many Bitcoins did the ICO raise?

700

Good old Times.... 

Devs Today say 1000 is minimum 

[drays]

1. Since earlier everyone had to verify work, we were very limited: we had very strict constraints regarding the complexity and memory requirement of work packages, simply due to the reason that the weakest node still has to be able to verify everything in a reasonable amount of time. Otherwise, netsplits or node shootdowns would be possible with complex long running tasks. With super nodes we are more flexible: we can set strict requirements that a super node's hardware has to meet and so can allow programs that run longer and use more memory.
Supernodes are basically nodes that do the verification and have no incentive to cheat due to a huge deposit. Contrary to other "well hyped solutions" we do not rely on trust at all ... all calculations and decisions that the super nodes perform can be publicly verified by anyone. For example by the so called guard nodes. These are nodes that randomly cross-check a small fraction of jobs. If they detect that a super node lied, its deposit gets forfeited.

3. Also, and this is a PR benefit, the earlier design effectively executed foreign code on the own hardware. While it's super safe due to Elastic PL's nature (our own programming language that does not allow to program anything dangerous), managers who want to use Elastic in their commercial setting might get scared. Now, nobody but the supernodes has to execute anything.

Three short questions on above:
1. Who and how will control the guard nodes then, so they don't cheat?
2. How the supernode deposit will be forfeited, and where the money will go to?
3. If nobody but the supernodes has to execute anything, what the other miners will do? Aren't they supposed to execute job assignments?

[RichDaniel]

Nice update, I am patient to wait for the launch, I invested 1 btc on XEL, I hope it can be trading in this year. EK, you always do the best job, thanks for your contribution. If there is an ETA, I will be more appreciated. Keep focus on development, you are first class dev.

[ImI]

Three short questions on above:
1. Who and how will control the guard nodes then, so they don't cheat?

Thats an important question, cause if everyone is able to launch a guardnode, you have automatically the sybill-attack-issue.