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

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?

Good old Times.... 

Devs Today say 1000 is minimum 

700

How many Bitcoins did the ICO raise?

@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.

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

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?

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.

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.

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

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.

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

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

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.

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

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.

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.

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.

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.

Yes.

NXT works with transaction fees alone. You probably have fewer people staking, but I think, that…

a) …going with a fixed amount works better for a single purpose blockchain.

b) …you'd have people staking at almost any reward size. You may have fewer people on the job, but probably enough to keep the chain going.

c) …in the end, miners would have incentive to keep XELs blockchain going, otherwise, they wouldn't be able to cash out. That alone may be a strong enough point.

EDIT: forgot the most important point, I think:

d)…this is not a "get rich coin". The value of XEL should not be determined by stakers, that have no interest in Elastics actual usability. XELs price should be determined by its usability, not by people trying to accumulate as many as possible. With that in mind, having a system in place, which gives staking incentive mostly to those who have a vested interest in Elastic Networks health, seems just right to me.

EDIT 2:
I just read the second line now. Changing to full PoS is absolutely pointless, since it defeats the whole idea of Elastic.