Topic: [ANN] [XEL] :: XEL - The Decentralized Supercomputer :: - page 180. (Read 253624 times)

So Is there some kind of swap from old xel to new xel?

Xtester has control on it. https://bitcointalksearch.org/user/xtester-197542 .
If somebody will be more social, You can take it control.

Looks good, ImI. 

This thing is exploding with interest. Good times ahead. 

Nice. We have a twitter btw. It's https://twitter.com/elastic_coin. I just don't remember who is in control of it.

I promise to catch up with all those nice and brilliant ideas regarding the payout model as well as all unanswered private messages this weekend. Starting tomorrow

only 1 day to get 6 page
very well project

Not sure if anyone is more important than anyone else...maybe instead it could be more like a list of items delivered or in progress and who worked on them.

I now applied @xtester's OP proposal. I hope the "important contributors" part with the profile-links is OK. Otherwise say something and i delete it.

True,
Also add something to the title like
'ReLaunch or Rebirth'
to avoid a new member asking for free XEL and repetitive question.
Plus it'll be better if we can see a beautiful ann thread.
 

You should also add in the OP:

• The mainnet is not launched
• There is no place to purchase/trade token yet
• Release will be in 1-2 weeks if all goes well

That will help cut down on these repetitive questions in this thread.

@coralreefer - no worries.  I remember the discussions from a long ways back that elastic is not suitable for mining purposes and I shall emphasis that the video is purely to demonstrate the capabilities of Elastic and not a suitable use case.

Right, this is one of the reasons for the small/subtle changes in the payouts model.  Under the model I propose, the attacker would need to re-submit his complex job after each solution he issued to himself.  (His job would also have to be "actually" complex, and not just be full of "meaningless" busy-loops which do not contribute to output value, mind you.)  This creates an opportunity at each solution found for miners to reject his new jobs (or up tx fee for them) if they feel the network becomes too loaded.  At that point the problem becomes no different from an attacker trying to stuff up the btc network with dust transactions filling up the block limit - he can still try to do it but miners can just make it ever more costly for him until he is broke and must just stop because he can no longer afford it.

When you write the content...please put it in perspective.  You cannot realistically mine BTC or any other coin with Elastic.  Even if you disregard all the overhead in Elastic to create the specialized network it runs in...updates to the block to mine would need to propogate through our blockchain...so it may take a minute or more just for an Elastic miner to know to move on to a new block.

I believe the demo he put together is good to show how to integrate external apps to the Elastic Network...but it should not lead anyone to believe that Elastic can be used to mine other blockchains of any type.

On it.  :-)

I posted my last comment before I saw this.  These are great ideas and definitely worth exploring further...

done

From my understanding the plan would be:
a) lite wallet for (1) increase awareness from outside world - specifically more developers and other specialists incentivized by a possibility of having XEL stake, (2) XEL internal fundraising possibilities, (3) distribution from early donors to an outer space, which is now not possible even with OTC trading
b) a series of hard forks towards fully functional system - I think it means there wouldn't be new distinct network, but the initial one would rather evolve and expand.

There was no plan to change current SN-based model - that's just my personal doubts caused by aversion to complexity, but perhaps it's worth discussing before we go too far with too much intricacy in the system.

HunterMinerCrafter, the SuperNode (or whatever we decide to call it) logic has not been coded yet and has no ties to the Lite Wallet being released soon.  I have coded the logic to perform the validation of POW / Bounty submissions, but EK has not had time yet to interface this logic into the Core Server, so we may have some time to refine the approach here...

Originally, I think EK's plan was to have all nodes (the Core Server) run the validation logic; however, the algorithms written in ElasticPL can potentially take quite a bit of time and memory to solve (i.e. seconds...depending on the complexity), so the validation logic could easily be used to attack the network (i.e. submit a complex job and throw 100's of solutions to the nodes to validate).

The next thought was to just have nodes running on higher performance hardware run the validation logic...but you'd still have to have all these nodes perform the validation so there was still too much traffic and overhead on the network, so at that point we looked at just having a small number of nodes to the validation, but then you'd still have the issue of a job author running their own malicious node.  So I believe this is when EK added the 250K XEL requirement...to deter anyone from creating a malicious node...basically, the network would trust the decision of a single node....which leads us to where we are today.

Clearly this idea can be improved upon (I have concerns over the 250K requirement as well as relying on a single SN's decision), but I am just coding the logic for the validation, so I can't really say what the best approach....and EK has been so busy I don't think he's had much time if any to think about it.

So as I posted earlier, I think its work discussing again...

Even shorter version:  Instead of giving a machine and getting an input/output pair, you give a model of a machine's behavior, and get back an input/output pair's relationship to that machine.  Instead of having a chance to find a PoW certificate at the end of each work attempt (effort of which varies run to run) there is chance to find a PoW certificate for each individual value propagation in the program, which would be uniform both run-to-run and job-to-job.  A job requiring on average twice as many assignments per attempt would generate twice as many work proofs on average for the same number of attempts run.

is there place to buy XEL?