OP_EVAL doesn't stop recursion

[roconnor]

Currently in the OP_EVAL processing code you have:

if (!EvalScriptInner(stack, subscript, txTo, nIn, nHashType, pbegincodehash, pendcodehash, nOpCount, nSigOpCount, fStrictOpEval, nRecurseDepth++))

The postfix ++ operator returns the unincremented value of the variable.

So my understanding is that (1) this doesn't limit the depth of recursive calls and (2) this does limit the number of non-recursive calls you OP_EVAL you have in one script.

In particular (1) implies that that Gavin's example (why wasn't this tested) of "OP_PUSHDATA {OP_DUP OP_EVAL} OP_DUP OP_EVAL" should run in an infinite loop (though I haven't tested this).

<rant>
More generally, this OP_EVAL is a very large change that clearly hasn't been vetted nearly enough. It took me all of 70 minutes of looking to find this bug. You guys are not ready to implement this. OP_EVAL turns a fundamentally Turing-incomplete langauge with clear termination conditions into what I believe an "in-principle" Turing complete language that is only held in check by hacks (which haven't even been implemented properly).

You guys need to stop what you are doing and really understand Bitcoin. In particular you should make a proper specification of the existing scripting language, ideally by creating a formal model of the scripting language. Prove upper bound on the space and time usage of scripts. Decide what bounds you want to maintain, and only then start defining OP_EVAL, proving that it preserves whatever properties you want your scripting system to have. OP_IF, OP_CODESEPARATOR, OP_EVAL all have the possibility of interacting complicated ways and you can't just hack the scripting language arbitrarily.
</rant>

[luke-jr]

I am posting a comment here solely to be notified of other replies. Blame GitHub.

[TheBlueMatt]

You could just "follow" bitcoin/bitcoin and then get all new pulls/comments/issues in a nice RSS feed (though this post is largely because I want comments to this issue in email too...)

[laanwj]

Yeah I'd suggest against using ++ in a parameter to a function call, if only because it is unclear when reading the code.

I tend to agree with you about OP_EVAL not being thoroughly enough vetted. The code is new and there's already been one last-minute almost fatal vulnerability. I'm inclined to think that it will bring more trouble.

[gavinandresen]

I'm open to suggestions on how to get code more thoroughly vetted BEFORE being pulled into mainline. In my experience, most people ignore changes until they are part of git HEAD.

RE: roconner's rant: Proving the time and space bounds of Script is a great idea-- roconner, can you make that happen? I have no idea how to do that, I have no experience with provably correct specifications/code/etc.

However, even if Script (and OP_EVAL) was proven correct, that would not stop me from writing "++" when I meant "+1".

The larger issue is "are the benefits of OP_EVAL (eventually, safer wallets, escrow, etc) worth the risks?" I think the benefits are large and the risks are manageable, and delaying the rollout by six months would just push almost exactly the same risks six months away. And we'd be six months farther from having more secure wallets and transactions.

[laanwj]

Agreed @gavinandresen I don't think simply delaying the change would have won much. People hardly look at "non-official" branches.

Somehow we should encourage more people to take a look at the source carefully, and attack it from any angle possible. Thanks a lot @roconnor.

[roconnor]

@gavinandresen can you (or someone else) clearly document all the desired functionality that you want from OP_EVAL, giving examples of how it would work, either in the BIP_0012 wiki page or linked from the wiki page? Maybe we can find an alternative way of getting all this functionality without such a fundamental change as OP_EVAL? OP_EVAL destroys all sorts of nice properties of the scripting system. As I said before OP_EVAL (probably) makes the language "in-principle" Turing complete. Also miners now have the ability to review the entire script before execution. These will go away when OP_EVAL is introduced. This is what I mean by a fundamental change.

[luke-jr]

I think a good compromise would be delaying OP_EVAL on the client end, and enabling it fully on the miner end. This basically has the same net effect except that OP_EVAL transactions need a couple more confirmations before they can be trusted.

The problem with poor review of other clients/branches can be addressed by largely revamping the download on Bitcoin.org. IMO, Bitcoin.org needs to list 3 categories of clients: "well-tested for production server deployments" (currently bitcoind 0.4.x), "no major problems, safe for everyday users" (Bitcoin-Qt + bitcoind 0.5.x), "testing, please help if you can" (Bitcoin-Qt + bitcoind 0.6.x beta/rc, and MultiBit 0.2.0), and finally "experimental, it compiled, maybe it works" (Bitcoin-Qt + bitcoind "next"); giving users these options enables them to more easily provide input.

Regarding code coverage testing, I think someone really should look into LLVM's KLEE before a bad guy does, since it's pretty much guaranteed to find some bug.

As far as the code review process in general, I think it is too slow already. Protocol-level changes probably need a lot more review, but high-level ones are stagnating and wasting way too much developer time on rebasing/merging due to the slow rate of merges.

[ByteCoin]

@roconnor Go into more detail about these "nice properties" of the scripting system that OP_EVAL destroys and then we can talk about how important these properties are and how to preserve them.

It seems easy in principle to limit the evaluation time of scripts and forbid looping constructs by preventing recursive OP_EVALs. It's possible that in this instance it was not implemented correctly but I think it indicates a lack of resources devoted to testing rather than a more fundamental flaw.

If you felt strongly that OP_EVAL was undesirable, you should have made a bit more noise before a lot of engineering and political effort was expended traveling down this path.

Taking your words literally, you say that miners won't be able to review the entire script before execution once OP_EVAL is introduced. This is plainly false. I know the change you actually meant and it was mentioned the very first time OP_EVAL was proposed.
With OP_EVAL, it becomes practically impossible to work out what sort of script or whether a valid script exists which can redeem the proposed "standard" OP_EVAL transactions. I think this is a desirable feature rather than an unfortunate consequence.

[luke-jr]

No, I'm pretty sure he means reviewing the entire script before execution. This is not false.

[gavinandresen]

@roconnor: reasons for, and advantages/disadvantages of, OP_EVAL were discussed pretty extensively in this forum thread three months ago: https://bitcointalk.org/index.php?topic=46538.0

Initial implementation was available for code review on October 19'th, over three months ago. I know everybody is busy, but I don't think 4 or 5 months to get a new feature out is unreasonable.

[luke-jr]

IMO, new protocol-level features probably should have at a minimum 6 months - maybe a whole year - of testing/review, with ideally at least 3 or 4 competent developers signing off as having actually read the code and given it some thought. On the other hand, new features that don't affect the protocol or implementation thereof, should be included ASAP as soon as the next merge window opens, with at least 1 other developer giving it a look over or numerous users testing and using it. In reality, many of the latter class (non-protocol-related) have been ready to this level and waiting for merging since before 0.5, some even before 0.3.24, and still aren't in git HEAD. The main difference for OP_EVAL is that Gavin is personally behind it. I understand that Gavin et al have a right to pick their priorities, but it does appear to have a bit of an extreme slant in a lot of cases.

[TheBlueMatt]

I have no idea how much such a thing would cost, or if there is remotely the budget to get such a thing done, but what would people think of asking large pools, exchanges, and other interested companies to contribute to get a professional code review of new major bitcoin releases, or maybe every other release or something?

[TheBlueMatt]

Also, I agree that we need a more strict set or pre-pull ACKing rules, maybe not 6 months of review, but ie a minimum of 3 ACKs from official developers before pulling, and not just I read this acks, but I at least compiled this and read it very carefully.

[luke-jr]

An important point of my comment was the distinction between protocol-level changes and other changes.