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.

On it.  :-)

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.

Yes, I just use the generic, age-old p2p terminology for any form of systematic recentralization, regardless of the trendy term-of-the-day for it.  (... which seems to vary month-to-month anymore.)


I doubt it is something that would get sorted out before you guys proceed with the lite wallet launch.  It isn't entirely clear to me what the XEL transition plan is from there, though.... so maybe it is something that could be done after or maybe it is something where we'd be talking about a new, distinct network.

I'm talking about the algorithm

I guess with masternodes you mean so called SNs (supernodes), right? Well, I didn't like them too. Not sure if it's possible at all at this stage, but perhaps with your support, it could be possible to think it over again, and get rid of those special nodes.

Guys. Last N pages I only see "good investment, I'll sell at Y, I'll not sell at Z". Do we really have here only people that want to earn some money on XEL?

When litewallet mainnet will be live, please sell and leave room for people that want to join and believe in this project.

We are searching for people that believe in our idea about making decentralized supercomputer. If you're in deep need for money and you want to buy some useless car (useless in a meaning that every car can bring you from point A to point B) just sell XEL and buy your car. I want to be part of this project and I want to create decentralized supercomputer with you.
I hope that many of you will exit XEL just to make room for people that also want to create something useful with us.

And Ethereum is not even Turing complete like XEL is.

Someome on slack channel ask this question, can someone provide a good answer

--
just read about Elastic being able to run on GPU
anyone knows if it will it be possible to code deep learning modules in it?
if it possible to build a neural network with thousands of nodes it will be a killer use case, competing with Google level infrastructure
--

Well, I didn't have a specific question per se, I was just thinking aloud, especially that e part about memory. A computer consists of a processor and data storage. We are focussing on the processing part, which is cool, but there is the memory part as well, which needs attention.

the simplest solution would be to make it the job authors responsibility to somehow provide the needed data, essentially working as a kind of RAM in which miners can check for relevant data.

However, even with a memory system in place, there may be scenarios, in which miners have little to no incentive to use this memory.

Let's take a look at the bruteforcing a password job. I'm not saying that this is something, Elastic should be used for, and you are welcome to provide a different example, but this specific job shows Elastics shortcomings pretty well:

It is pretty much throwing random input into a function and running it until a single solution is found. There aren't multiple solutions, just one. This greatly affects how miners behave:

Miners have no incentive to share information about which inputs they already tested, because they don't want to give other miners an edge. This means, that in a worst-case scenario, many inputs are tested by multiple miners, effectively lessening Elastics power.

I'm sorry that I'm rambling.

Elastic and memory

This is mostly me thinking aloud, to figure this out. It's very possible that questions raised here already have answers I'm unaware of.

I've been thinking about this for a little while now, maybe someone who has a little mor insight in this can give some input on that matter. As far as i know, at the moment, elastic is essentially memory-less. This means, there are only two possible job scenarios at the moment:

Job 01 is issued. Bitcoin mining is a good example, the goal is to find a magic hash, to simplify things, lets say 8 figures long, with four zeros up front.

Miners A, B, C, D, E start working on it.

A finds 00001efg
B finds 00002ghi
C finds nothing and cancels
D finds 00003ijk
E finds 00001efg, the same as miner A (in case of finding hashes, this is highly unlikely, but depending on the specific task, this is a possible scenario.

Job 02 is issued. This time, the goal is to find a specific hash. Let's say, we try to bruteforce a password (Don't, though. This is for theories sake only). The password is "abc123".

A finds nothing and cancels
B finds "abc123" first
C finds "abc123" second
D sees that the problem is solved and cancels
E sees that the problem is solved and cancels

Without memory, these are the two types of jobs possible. but both jobs suffer from lack of memory as well, while Job 02 is a prime example for it:

If we assume, that Miners A, B, C, D and E use roughly the same approach to bruteforcing, meaning, following roughly the same iterations of figures (like trying "000001", then "000002" and so on, not that this is a good way to approach this ), this means that all of them try the same iterations, until the fastest one eventually hits the right solution. This is a giant loss of computing power. Now, in the specific scenario, the solution would be to generate random inputs, instead of following a system, but in other cases, this leads to the network as a whole computing functions, which already have a (negative) solution.

Having a memory system in place, miners could in theory write iterations they already tried in there. In practice, this works against their personal goals, because getting the job bounty is essentially a race. Thus, you'd want concurrent miners to work to as many negative iterations as possible.

What looks like a solution to this problem is to pay a bounty for every iteration computed, no matter how successful it is. However, this leads to the problem, that a Miner can intentionally hold back the correct answer to keep the job open.
If the bounty for finding the right solution is not high enough, sending negative results and getting paid for them may be more profitable than sending the solution.
If the bounty for finding the right solution is too high, sending negative results and helping other miners doing so may be not as appealing as hoping to find the right solution.

This is a messy situation. Here is an idea for a solution, though:

Pools.

I miners are organized in profit-sharing pools, they have incentive to exchange negative results with each other, because they are racing against another pool, which might win the race. In this scenario, the overall computation power would still be lowered, due to different pools competing against each other, but it would be higher than in a scenario, in which every miner is on their own.

Additionally, a scenario is possible, in which "spies" are registered in multiple pools, thus seeing the results of each other. Bit where would that lead? would that lead to Miners withholding information again? Would that lead to Miners avoiding pools? Oh, game theory, thou art a heartless bitch…

To summarize my train of thought: while it would be great to have a memory function, it may be hard to incentivise miners to use them.

This is it for now, the sun is stewing my brain. Will get back at it later.

Indeed. Long time since I've seen all devs on one page at BCT thread.

Well done Coralreefer.
sha256 proof-of-work example implemented in ElasticPL language - awesome!

Did you guys think about having some kind of shared state between workers/nodes per job?
I wonder how would you divide a task of some sort between workers in the network, in such a way that they do it in parallel?
(I'm not sure if my question is perhaps to generic)

Thanks.

So, one way the SN hosts can shield themselves from attacks is by hosting their own public nodes, and have the SN only connect to their known public nodes, which will then relay the produced work to the network. This technique worked very well for the BitShares community, where there are only 101 super-delegates, and attacking them could bring the whole network down. So the witness delegate nodes, never accepted incoming connections.

I'll need to dig into the architecture more to understand all the constraints.

I totally understand the feeling. I'm a dev myself and left my cushy job to experiment with p2p and machine learning. I turned down plenty of offers exactly for that reason - so that I can focus on my ideas without anyone forcing me in a specific direction.

I don't think anyone is asking you to be their b*tch. I do want to see your work get rewarded though.

What can we help with? Is there a list of tasks that need help getting done?

I can't believe that we can't find a motivated C dev with networking experience to work on this project. How is that possible with so much talent in these forums? Did anyone put any formal ad for this somewhere?

If you have not understood yet, I don't care about this voting, I think that all this system is wrong. My opinion about lite wallet is irrelevant and I voted 'NO' only because EK told he will vote so when he was asked, as I believe that the one who do all the work should also manage or at least choose direction and crucial decisions for project they created and built WITHOUT help of very loud persons who want stuff and come with demands/accusation as people who voluntary chose to spent time on this project owns them something.
And all this demands/stuff signed usually by "we", "the people", "community" etc...  Can you understand this simple concept?

P.S.
And all those endless conversation instead of providing actual help developers NEED, But I am sure as Litewallet will come out, there will be endless/limitless donations, so it's all good:)