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.
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://bitcointalksearch.org/topic/m.14911193
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
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.
, 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.
