Is the bounty program officially started yet? What are the criteria?
I have a (growing) laundry list of problems that I see in the implementation...
Let's start with four "easy" bugs in the language parser and vm. I'd like to see these cleaned up to make other analysis easier.
Starting from most simple:
1) Conditionals must always have "else" statement.
The parser allows:
but the worstWeight and interpreter will throw ArrayIndexOutOfBounds.
This works:
so you need to check the size of conditional statements' children nodes in the vm!
2) Expressions allow mixed bool/int in parser but fail to cast in vm.
For example:
throws a "ClassCastException: java.lang.Integer cannot be cast to java.lang.Boolean" in interpreter and:
fails similarly in trying to cast bool to int.
Either you need to separate bool/int valued expressions in the grammar, or handle casting!
I'm assuming the intent was to mimic C style int/bool implicit conversion, but this conflicts with the arguably silly Java semantics underlying the VM.
3) Expressions are not IDs...
However they are treated as such by the parser, which confuses the interpreter.
is a nonsense statement allowed by the parser, but resulting (for good reason) in a "ClassCastException: ElasticPL.ASTEQNode cannot be cast to ElasticPL.ASTId" in the interpeter. This seems to be a general problem in the grammar, which does not correctly distinguish Expressions, PrimitiveExpressions, and IDs. Statements such as this should be rejected in parse.
4) Parser allows for arbitrarily large but "0 WCET" programs.
There seem to be a few problems with the WCET, but this one is by far the "simplest" that I've seen so far. For example, the statement:
input 8;
if(true) {
repeat(2147483647) {
SHA256 3 3;
};
} else {};
verify true;
is obviously a "very expensive" program, well above the statement limit constant, which implies that it should be rejected. However, the WCET is calculated as 0, and I doubt anyone will ever find the bounty. (Worse is what happens to the peer nodes if someone does "find" some work/bounty inputs and publishes a PoW/PoB, turning all peer nodes instantly into nothing more than hot/noisy sha mining rig running on a forked chain, hehe...)
(EDIT: Bug #4 is particularly problematic in that with "seemingly" no execution cost, all instances of the reference miner will immediately jump onto this work as the "most profitable." Once you've knocked out all competition like this, you can proceed to claim all legitimate work/bounties for yourself.)
These bugs can be trivially used to disable peer nodes and/or miners. I have more complete examples ready for each if you'd like to see a more detailed confirmation of any.
Let me know when you are ready for more...?
Also, I notice that you see now "some of" the problems with your PoW difficulty mechanism. One or two of our problems "for later" are related to this. One thing which I can say for sure is that the difficulty calculation will need to be made entirely per work order job, as some programs will execute at 200k evals/sec/cpu and some will be 2k evals/sec/cpu and (as things stand right now) some might be 0.0002 evals/sec/cpu. ;-) (I don't have a "workable solution" for how to fix this PoW calculation aspects of your design.)
These are all the least "interesting" (and least fun) of the problems. There seem to be several more, which I'll present in increasing order of "interestingness" assuming that they stick around, but let's see how handling these few easy issues goes first...
(Hey, at least it's not quite as badly broken as when your plan was "Python or Lua" eh?)
(Disclosure: I hold 0 XEL tokens on testnet or genesis roster.)
