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

I've been waiting for a year, but then I like to test everything and test)

Thank you for explaining. I heard " overhead".... I probably misunderstood.

Hardware requirements for a SN are not that high.  I don't speak for EK, but there is practical certainty he has it totally covered.

@EK - thanks for the update, let us know when we can join testing.

Good decision to drop the separate SN process and incorporate it in to the main client.

Not too much info out there, but you can find something here http://www.elastic-project.com.

There're 100M coins, and it's based on NXT so no inflation here.

If you want to buy before mainnet, then you could try with escrow - here are some offers
https://bitcointalksearch.org/topic/elastic-xel-price-speculation-added-to-bittrex-1589333, but you will need to wait anyway since there's no way for anyone to control their coins at the moment.

you guys shill to damn much
lol
but still the project is interesting

where can i get info on the coinage/buy some.

Hi EK, always good to hear from you. Thanks for the updates.
Maybe I misunderstood, please forgive me in advance. Do we need any funding for any equipment you need to test the SN ?

Small update from my side. The last 5 days I have spent implementing the SN logic into the mining application itself and I think it's time to press the delete button and implement the SN logic into the core client itself.

Problems, that came up:
- Getting a stable and high available JSON RPC server running, I have one based on libevent but its highly experimental and well unter-tested
- With this approach we have additional overhead regarding the communication between the SN program and the core client in terms of signing transactions, verifying them, etc. This is one additional point of failure.
- Also, the SN would run on an extra port causing more overhead to SN operators since they have to open yet another port in their firewalls.

So, why reinvent the wheel when SN run the core client anyway and have all networking stuff on bord already:
I am right now doing the SN logic in the core client itself. Here, we have the entire networking part (incl. blacklisting) already running and well tested. All signing functions are already there and the only thing that we need is the uplink to the mining application for the code evaluation itself.

Good news: For massive testing, it's enough to have a pseudo SN, who does some very light checks on the work (code correctness, WCET, ...). This will be done today and if you like you can start right into the testnet this evening.


PS: Whoever likes to have a libevent based JSON-RPC server written in C for his own project, just tell me. You can have the SN stuff that was done in the last 5 days.

When we update the core client to do the real work checks on the SN side, this will not cause any soft/hardfork. The "SN only" have to update their clients themselves.

Many people has waited for the launch for half year, you know the price will be very high if the XEL has a successful and smooth launch.

something strange and funny about this post !

this project is promising, looking forward to the release.

hope this project will be released in 2 months.

+1

Been a lurker since ICO, clearly the man is trustworthy and dedicated. It could be a great choice if he is willing?

i vote for this.

and the majority of fund shall be rewards to devs. 

I don't think EK would want to do that. He stated that his love is coding, he must be burnt out already. Maybe an escrow manager might be more ideal.

Updates please !

IMO, We need to know the date that Elastic will be completely ready then we can organise the PR process.

I don't think we've got to worry about a fund for pre-launch PR, since there's a lot of very willing people to help out with that.

One thing I don't understand though, is that no one seems to be able to tell me exactly what it is that Elastic can do.

Nor can I find any reference to anyone actually testing the core units to see that they can actually solve problems and what those types of problems are.

Based on prior posts of his, I think he would be disappointed that not everyone has noticed he does not want to manage funds.

I agree he would be the perfect candidate for trustworthiness if he was willing, but he has emphasized not wanting to become personally responsible for handling funds.  And that, of course, is his right to choose.  If others step up, that aids the semi-decentralized aspect of the project in a way.  For others, there may be options like a 2-of-3 multisignature wallet with 3 holders, in case one person is away at a given time.

Bob, what do you think if we vote for EK to be in charge of the funds ? He's trustworthy, he's been with this project from the beginning. He is not greedy . What do you guys think ?

All good points . I think we have to do whatever it takes ( Elastic Foundation) to keep our devs ( EK, Coralreefer,...) while attracting more .