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

[nihilnegativum]

Well the deadline is something different than the ETA  
Sometimes, when you have time critical tasks (like for example you need a result in the next hour otherwise you are not interested anymore) you can set a deadline of just a few blocks to have the remaining XEL refunded to you automatically. This functionality could become handy for those who use Elastic to mine other coins, even though there is the manual "Cancel & Refund" function as a backup.

The ETA on the other hand is just showing you how far you can get with the amount you specify ;-) The ETA should be maybe called "Estimated Time of Running Out Of Funds".

Not sure if the "ETROOF" could be replaced/supplemented by some other values? Any ideas are welcome  

Ah, I get it, that is handy, yes. Something else deadline related, that could be of use is to have it give up if your efficiency is too low, or something like that, so you don't waste all your XEL on your badly designed job? The problem with "Cancel and Refund" is that you have to monitor it ...

[1714111781]

1714111781

[1714111781]

1714111781

[1714111781]

1714111781

[1714111781]

1714111781

[1714111781]

1714111781

[boltz]

Just donated some more guys , nice project ! :d

[bitbitch]

when will this be launched?

[Evil-Knievel]

ABSTRACT:
This is a first proof of concept miner producing Proof-of-Work and Bounty blocks based on a user provided LUA file.
Sorry for the low quality post, I am working 24 hours straight on this now. Need some rest.


A small update for today. Today, it is not a visual update but an update showing the progress with the user-provided proof of work functions itself.
Please note that this is the first shot and just reflecting the work of 24 hours. It it far from perfect and does not meet the security requirements ... yet!  

The reason why I'm publishing it is to encourage people to think with me, develop with me, and test with me. If you have the time and you like "hacking" around, please join.

LUA Work/Bounty Functions
Users create a "task" that they want to have solved by the Elastic community. The work, as described in the white paper, consists of two functions.
One function is the so called "work" function that takes a number of integer inputs, does some work, and outputs a different number of integer values as the result.
The other function is the so called "bounty" function which checks the output of the "work" function for "interestingness", that means if the output can be thrown away or if it should be submitted to the "task author" because it meaningful to him.

Here is a very simple function that does NONSENSE but is a valid work/bounty function.

Code:

local tickcount = 1;

function isPrime(n)
	primes={}
	if n<=0 then return false end
	if n<=2 then return true end
	if (n%2==0) then return false end
	for i=3,n/2,2 do
		if (n%i==0) then return false end
	end
	return true
end

function work(input1)
  local_state=input1
  while tickcount<1000 do
    tickcount = tickcount +1;
    local_state = input1+tickcount;
  end
  return local_state%9086;
end

function bounty(input1)
  if(isPrime(input1))
  then
    return true
  else
    return false
  end
end

the work function does some stupid calculations (takes one input and gives one output). Calculations make no sense but they are a valid work function.
The bounty function tells the network that the author is only interested in the inputs to the work function, that cause the output to be a prime number.


Execution of the LUA script by the Elastic Network

The elastic network then takes this LUA, starts working on it and then does two things:

- If the work function produces an output that has a hash value that is lower than a target value, it has found a proof of work. Those proof of works are needed for periodic payouts and to proove that users are actually working of the function.
- If the work function produces an output that causes the "bounty()" function to return true, it submits the related input to the blockchain and collects a different type of payout called a "bounty". This is required to eliminate the incentive to cheat (see Faster Algorithm Attack)

The code is itself executed in a hardended LUA interpreter which was stripped so that it does not allow to interact with the users' systems at all.

We have decided that the proof of work function can run forever as long as the job has enough money in the deposit. This deposit gets smaller and smaller the more proof-of-works are uploaded to the blockchain. If the job runs out of cash, it gets stopped no matter whether it terminated or not.

This is different for bounty functions. To avoid a DOS attack with a bounty function that runs forever, it has a hard limit on allowed instructions.


Current flaws

Many ... The biggest flaw in this demo is that the POW hashes are calculated after every whole iteration of the work() function and not after every 10ms block (here, every 500 instructions). Should be easily adjustable, but I have worked day and night already and need a weekend off!

Please find the source code here: (I hope I commented it sufficiently)
https://github.com/OrdinaryDude/test-lua-engine

How to run the example:

Code:

git clone https://github.com/OrdinaryDude/test-lua-engine

THEN IMPORTANT (!!) Find the hard-coded Path ("/home/anonymous/Development/elastic/src/java/nxt/execution/md5_miner_test.lua") in the nxt/execution/PowLogic.java file and replace it by the correct path to the LUA file you just checked out. Then ...

Code:

sh compile.sh
sh run.sh

How does it look like:

YOU CAN SEE THAT ALL BOUNTIES ARE PRIME NUMBERS
AND ALL PROOF-OF-WORK HASHES MEET THE TARGET VALUE <0x00ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

[Sam123]

EK, good job 
Dazza is he still around? Hopefully his family are fine

[Evil-Knievel]

EK, good job 
Dazza is he still around? Hopefully his family are fine

I hope so, we will need him to make everything rock solid. He is one of the brightest persons that I have seen so far. 

[jupiter00000]

'ICO' has become a standard and generic term when referring to any project announced here where btc or other coins are exchanged for tokens (XEL).

Yes, but we are not doing that here either. From the legal perspective, exchanging one coin for another implies a contract for the exchange of virtual goods (XEL, BTC) between me and a buyer. That also means that I have to decide what one XEL is worth arbitrarily. Let's face it, a XEL is worth nothing. We are not selling anything here, we do not want to be tied up in any contracts and we do not give any guarantee of success. You donate and our way to thank you is to give you a few worthless XEL that can be understood as a complimentary "early access" to our software, all without any sort of obligations from either party.

if thats not strait up honest truth with no frillz, then I can't find the sky.

[boltz]

Go go elastic . I will invest some more btcs next month for sure

[Evil-Knievel]

I have no idea who came up with the deadlines in the original post  , but I give my best to meet the "end of month" deadline and give you something you can actually play with, give feedback to it, maybe start implementing first changes or new features that you think might be necessary, and so on. Working day and night at the moment.

[jupiter00000]

I have no idea who came up with the deadlines in the original post  , but I give my best to meet the "end of month" deadline and give you something you can actually play with, give feedback to it, maybe start implementing first changes or new features that you think might be necessary, and so on. Working day and night at the moment.

People like you make people like me more confident about crypto. Thanks for investing your talent into something fantastic we can all be a part of.

[coralreefer]

Small update!

I try to keep things as simple as possible. What do you think about this "create new work dialog"?
I think that it has all neccessary features without looking "cluttered".

- The source code must be developed externally (with the SDK or a standalone text editor).
The source code is automatically checked for the correct syntax and semantics when uploaded.
- When you enter an amount, it will automatically tell you how many iterations of your program you can expect for the amount of XEL you are willing to spend and how long it will take for the job to complete.


Did I miss something obvious in this dialog? Feedback appreciated!

EK as usual, looks great.  Couple of questions.  Is there any sort of pre-processor built in (or readily available externally) to ensure the uploaded code doesn't have syntax errors or at least is even code of some sort an not random spam?  Also, I can't tell from the screen shot, does this allow for multiple modules, or is there only one module per project?  Is there any size restriction?  if so, maybe show the size on the UI.

Also, I'm still a bit unclear on how you would designate what constitutes that someone earned a bounty.  Is that embedded in the code?  or should it be something designated on the UI?

Overall...great job.

[Enkidu13]

Hey. I am currently in Quebec Canada and am trying to buy into ico. However on http://www.elastic.pro/donations it says I am not permited based on my Ip Address... how can I fix this problem? was it because I was using a vpn?? I really wanna be part of this!

[Evil-Knievel]

EK as usual, looks great.  Couple of questions.  Is there any sort of pre-processor built in (or readily available externally) to ensure the uploaded code doesn't have syntax errors or at least is even code of some sort an not random spam?  Also, I can't tell from the screen shot, does this allow for multiple modules, or is there only one module per project?  Is there any size restriction?  if so, maybe show the size on the UI.

Also, I'm still a bit unclear on how you would designate what constitutes that someone earned a bounty.  Is that embedded in the code?  or should it be something designated on the UI?

Overall...great job.

Thanks ;-)

Well, I tried to discuss that here: https://bitcointalk.org/index.php?topic=1396233.msg14911193#msg14911193
Well, currently there is a syntax check, an instruction limit check (wherever it applies) and a check that ensures that you provide both a work and a bounty function with your code. Also, the software finds out how many inputs and outputs the functions take (miners need to know that to decide how many random inputs to shuffle) and makes that easily accessible thorough the API (so miners can rely on those values and do not need to parse the code themselves).

In the code itself, multiple modules are of course possible as long as you fit them into one file. Also, multiple functions are perfectly fine. In the quoted post I have use this example, which uses an external function isPrime(), where work() does some stupid calculation and bounty() checks if the result of the stupid calculation is a prime using the isPrime() function. You can "theoretically" make these programs as complex as possible.

Code:

local tickcount = 1;

function isPrime(n)
	primes={}
	if n<=0 then return false end
	if n<=2 then return true end
	if (n%2==0) then return false end
	for i=3,n/2,2 do
		if (n%i==0) then return false end
	end
	return true
end

function work(input1)
  local_state=input1
  while tickcount<1000 do
    tickcount = tickcount +1;
    local_state = input1+tickcount;
  end
  return local_state%9086;
end

function bounty(input1)
  if(isPrime(input1))
  then
    return true
  else
    return false
  end
end

There is, at least in the current proposal, no size constraint. It is just that larger programs are more expensive and cause more fees. The only size (and instruction limit) lies on the bounty() function to avoid a certain types of DOS attacks (long running bounty() function which of course has to be executed by others that verify the transaction validity). So the inherent size limit for a source code file results from your balance.

You are right that is may happen that the program outputs crap, crashes, or gives back invalid values (like strings instead of integers). It is impossible to parse the program and prove that it ALWAYS outputs correct output. I would suggest to give the "developer" many tools to verify and test his code. If he fails to write 100% working code, we are ready to handle that case: in case the function crashes of produces invalid results we just assume that it gives back an array of 0 values. Since we hash (the Proof-of-work hash) the input and the state along with the functions output, i think (please shout if I am wrong) that we still have a cryptographically random and unpredictable hash, equally distributed. The developer of wrong code is the only one having a disadvantage here.

For those who are interested, we are using a hardened variant of LUA here which prevents some vulnarabilities using handmanipulated bytecode (we do not allow the execution of bytecode), we prevent creating an instructions low loop, that creates extremly large objects, we have an upper bound for the RAM used, we prohibit jvm object interoperability, as this is nearly impossible to saveguard, and also any other means to execute files is removed (require, cmd, ...)


EDIT: Just as a marker for Dazza ;-) I am aware of the fact that a crashing function might open new FAA (Faster Algorithm Attrack) possibilities. We can either live with it (that a 10ms block may actually be shorter when the function crashes in the middle of such block), or we can "pseudorandomly" top up pseudo instructions to ensure the miners have invested the the same amount of instructions as in any other fixed size 10ms block (right now they are rather 10 instruction blocks). We do not lose any security here as the worst thing that may happen with a crashing function is that malicious miners collect the developer's entire reward while investing less work then honest miners. Still, we will have to decide whether to "top up" or not.

[by rallier]

Do you still work alone? Do you have any backup for yourself ?
And When will we try on testnet ?

[jamboy34]

wow... i will definitely donate some to this project! Good luck! 

[bitbitch]

has this project published its refined economic model of resource distribution?

[Mrboot]

This project starting to look better and better, great job team !

Im actually happy i did donate a small bit early on, hope everything succeed this great.

[Bgjjj2016]

EK as usual, looks great.  Couple of questions.  Is there any sort of pre-processor built in (or readily available externally) to ensure the uploaded code doesn't have syntax errors or at least is even code of some sort an not random spam?  Also, I can't tell from the screen shot, does this allow for multiple modules, or is there only one module per project?  Is there any size restriction?  if so, maybe show the size on the UI.

Also, I'm still a bit unclear on how you would designate what constitutes that someone earned a bounty.  Is that embedded in the code?  or should it be something designated on the UI?

Overall...great job.

Thanks ;-)

Well, I tried to discuss that here: https://bitcointalk.org/index.php?topic=1396233.msg14911193#msg14911193
Well, currently there is a syntax check, an instruction limit check (wherever it applies) and a check that ensures that you provide both a work and a bounty function with your code. Also, the software finds out how many inputs and outputs the functions take (miners need to know that to decide how many random inputs to shuffle) and makes that easily accessible thorough the API (so miners can rely on those values and do not need to parse the code themselves).

In the code itself, multiple modules are of course possible as long as you fit them into one file. Also, multiple functions are perfectly fine. In the quoted post I have use this example, which uses an external function isPrime(), where work() does some stupid calculation and bounty() checks if the result of the stupid calculation is a prime using the isPrime() function. You can "theoretically" make these programs as complex as possible.

Code:

local tickcount = 1;

function isPrime(n)
	primes={}
	if n<=0 then return false end
	if n<=2 then return true end
	if (n%2==0) then return false end
	for i=3,n/2,2 do
		if (n%i==0) then return false end
	end
	return true
end

function work(input1)
  local_state=input1
  while tickcount<1000 do
    tickcount = tickcount +1;
    local_state = input1+tickcount;
  end
  return local_state%9086;
end

function bounty(input1)
  if(isPrime(input1))
  then
    return true
  else
    return false
  end
end

There is, at least in the current proposal, no size constraint. It is just that larger programs are more expensive and cause more fees. The only size (and instruction limit) lies on the bounty() function to avoid a certain types of DOS attacks (long running bounty() function which of course has to be executed by others that verify the transaction validity). So the inherent size limit for a source code file results from your balance.

You are right that is may happen that the program outputs crap, crashes, or gives back invalid values (like strings instead of integers). It is impossible to parse the program and prove that it ALWAYS outputs correct output. I would suggest to give the "developer" many tools to verify and test his code. If he fails to write 100% working code, we are ready to handle that case: in case the function crashes of produces invalid results we just assume that it gives back an array of 0 values. Since we hash (the Proof-of-work hash) the input and the state along with the functions output, i think (please shout if I am wrong) that we still have a cryptographically random and unpredictable hash, equally distributed. The developer of wrong code is the only one having a disadvantage here.

For those who are interested, we are using a hardened variant of LUA here which prevents some vulnarabilities using handmanipulated bytecode (we do not allow the execution of bytecode), we prevent creating an instructions low loop, that creates extremly large objects, we have an upper bound for the RAM used, we prohibit jvm object interoperability, as this is nearly impossible to saveguard, and also any other means to execute files is removed (require, cmd, ...)


EDIT: Just as a marker for Dazza ;-) I am aware of the fact that a crashing function might open new FAA (Faster Algorithm Attrack) possibilities. We can either live with it (that a 10ms block may actually be shorter when the function crashes in the middle of such block), or we can "pseudorandomly" top up pseudo instructions to ensure the miners have invested the the same amount of instructions as in any other fixed size 10ms block (right now they are rather 10 instruction blocks). We do not lose any security here as the worst thing that may happen with a crashing function is that malicious miners collect the developer's entire reward while investing less work then honest miners. Still, we will have to decide whether to "top up" or not.

hi EK , great progress. I'm so happy I am invested in Elastic project !

[cryptoheadd]

Hey guys,

2 days to go for the working coin.
Nice to see the updates.

[Evil-Knievel]

Hey guys,

2 days to go for the working coin.
Nice to see the updates.

Thanks! Its 3 days ... and for a working coin without any security (regarding the verifiable computation) but one that people can play with. Security will be step 2 where we have to tackle all problems related to the FAA. I give my best to stay withing this deadline.