Topic: OP_EVAL proposal - page 4. (Read 13117 times)

RE: be wary of OP_EVAL:

Agreed, we need to think hard about whether or not attackers could Do Evil Things like create an innocuous little script that pushed an infinite amount of data onto the stack or something  (lets see... Serialized() OP_DUP OP_EVAL would do that...).  Disallowing recursion (no OP_EVALs allowed in the OP_EVAL data) would, I think, prevent all of that mischief.

RE: OP_EVAL means no more IsStandard:  I agree with ByteCoin.  A ScriptSig would be IsStandard if it's ScriptPubKey was IsStandard, and if it's ScriptPubKey was the generic OP_EVAL form then the last value pushed by the ScriptSig would also have to pass the IsStandard test (deserialized into a Script).

RE: data should always be protected by a hash script:  I think the answer is "don't be an idiot" and "use standard transaction types that have been banged on / thought through."

RE: sender/recipient negotiating a transaction: I think that may become the most common way of creating a transaction, but I don't think it will ever be the only way.

It seems I misunderstood part of the original suggestion.

Still, a few remarks:

• OP_EVAL sounds like a very elegant way of increasing the script language's power, with some nice possibilities like explained above.
• I agree we need to be extremely careful about this - the data accepted by a txout script being evaluates should always be protected by some form of hash script. One can argue that this is the responsibility of the sender to create a good script, though.
• Enabling an operation like OP_EVAL implies removing the IsStandard() test, as it essentially allows any script to bypass the test anyway. I'm in favor of relaxing IsStandard() and enabling more operations, but we need solid unit tests to verify that all involved scripts/operations verify fine.
• I do like the fact that using a hash-protected eval()ed script is not encouraged without the payee asking so (even if I know you have addresses A and B, there is no reason for me to expect that an OP_EVAL script with hash equal to the hash of script that checks for A AND B will be detected by your client as a spend to you
• I don't like the fact that we're using a static string for even more complex txout templates, it risks accidental reuse, is impossible to refuse once the string is published, and is hard to track. IMHO, the right solution for cases were more complex scripts are wanted is directly negotiating them with the receiver.

I am 100% for DIGEST160 stuff. (Along a similar vein, CHECKSIG should have been four opcodes from the start: LOADTX (to stack), DIGEST, SIGN, and VERIFY, and we could use better escaping than CODESEPARATOR provides.) It would solve problems now while a better, more general solution is being hashed (hah!) out.


But be very wary of an OP_EVAL. Allowing execution of data is extraordinarily powerful, and extraordinarily difficult to secure. Attackers could do things like cause infinite loops, or rewrite a TX script to always pass. The semantics of eval() are notoriously difficult to pin down.

That said, my company is implementing a bitcoin-like crypto-token system featuring Lisp as the scripting language (with eval, lambdas, macros, and all), and I was primarily responsible for the decision to do so. So I both speak from experience in warning of its danger and difficulty, and simultaneously as a strong advocate for it, if done right.

There's no need to fast-track it, but it's one of several things that should be included next time the block chain needs to be forked (which could very well be years from now).

What's messy is having senders worry about new transaction types that recipients want to use. This seems pretty elegant to me.

Ya joking?

A scripting system inside a scripting system. Hacks on hacks on hacks will lead to a messier protocol than FTP is now.

Well, it seems good at first glance. But fast-tracking this into the block-chain is probably not a wise idea. There's no rush so it might be prudent to think of this as something for 2 years time or later. Bitcoin is not exploding tomorrow, so there's no big loss from holding off on momentous changes like these.

https://en.bitcoin.it/wiki/BIP_0001

That's a good place to start. Re-enabling parts of the old scripting system in a controlled manner is a good idea. Adding new operations- not so much *right* now.

I will join the bandwagon and say OP_EVAL is good.  I'm not concerned about being credited for it - I will be far more thrilled to see it happen, and I am pleased that a consensus is building around implementing something that will ultimately achieve the originally stated goal: automatically multi-sig safe transactions without changing the format of the bitcoin address.  This is big, because it ultimately will lead to a scenario where we can offer real Bitcoin security with a straight face.

True. The fact that it uses the existing scripting system probably makes it easier to implement and considerably reduce the number of test cases to provide code coverage. I am happy to disclaim any credit for the idea if that is desired.

You are right in that OP_CHECKSIG could just be reimplemented so that it effectively does OP_EVAL and appends a OP_CHECKSIG (see postscript) to the decoded script. It would have the advantage of being instantly compatible. I finally understand what you were talking about. In my defense, when you talked about redefining OP_CHECKSIG it sounded very sketchy. I will read your posts more carefully in future.


IsStandard() will probably ensure that OP_EVAL'ed scripts match known whitelisted types with at least one SigOp. So it's not open season on non-standard transaction types yet.  

One disadvantage is that the IsStandard() check will now apply when you're trying to redeem the coins rather than when you're trying to send them. Unfortunately, this means that if IsStandard fails, you probably can't redeem them (short of breaking the hash) until IsStandard is changed. This could result in some distress.

ByteCoin

PS. Obviously the appended OP_CHECKSIG would have to be renamed something else to avoid recursion! This is merely a matter of giving your version of OP_EVAL the number of OP_CHECKSIG and having a new opcode which really just evaluates a sig against a pubkey.

PPS Nope, you're right again. It's no good always having OP_EVAL append an OP_REALCHECKSIG to the decoded script. The case when the decoded script is just a pubKey needs to be recognized and an OP_REALCHECKSIG needs to be appended only in that case for back-compatibility purposes. The special behaviour and the reasons for it would take quite a bit of explaining in the code comments.

I also like OP_EVAL the best. This concept is a really fantastic idea.

I'm still bothered by the fact that this will make brute-force attacks much easier (though probably still impossible). It might be a good idea to require OP_EVALed scripts to contain at least one SigOp or add another parameter to OP_EVAL that allows the sender to state the number of required SigOps.

I don't see the difference between this and my proposal, except for using the symbol name OP_EVAL and saying it's a new opcode, rather than simply a rename of the OP_CHECKSIG opcode, and the use of the full scripting system rather than a boolean subset.  It is otherwise pretty much identical.

If the opcode were renamed, and a