Why so many OP codes are disabled?

[jackjack]

All I could find to explain that is 3 lines:

LSHIFT and RETURN bugs

On July 28 2010 two bugs were discovered and demonstrated on the test network. The first caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT. The second exploited another bug in the transaction handling code and allowed an attacker to spend coins that they did not own. Neither were exploited on the main network, and both were fixed by Bitcoin version 0.3.5.

After these bugs were discovered, many currently-unused script words were disabled for safety.

Are there any more details about this?
Is it possible that the official client accept them again in the near future? (at least INVERT, OR, AND, XOR and arithmetic ones)

[Maged]

This thread answers some of your questions:
https://bitcointalk.org/index.php?topic=28861.0

[jackjack]

Thanks for that

My second question is still unanswered though, and I can't find any information about that

[Maged]

gmaxwell's post addresses that point.

[jackjack]

If I understand correctly: if I want an OP code to be re-enabled, I'll have to make it secure

[Maged]

If I understand correctly: if I want an OP code to be re-enabled, I'll have to make it secure

You'll also have to mathematically prove it.

[Mike Hearn]

Seeing use cases for the disabled opcodes would definitely help.

[ByteCoin]

Does it seem reasonable to everyone that there is very little distinction between enabling an existing but disabled opcode and creating a completely new opcode to facilitate some desired functionality?

Many of the existing but disabled opcodes (especially the stack manipulation ones) seem rather pointless and it would be better to work towards opcodes that facilitate desired functionality such as Rivest and Shamir's  Paywords scheme as mentioned by hashcoin.

Scripting is a great idea but parts of the current (but disabled) implementation seem to have been rushed out with insufficient thought.

ByteCoin

[Gavin Andresen]

I'd say the short answer to "is it possible to accept them again in the near future" is no (where "near" is in the next six months).

I agree with Maged-- before enabling new opcodes, I'd like to see a peer-reviewed academic-style paper that works through the security implications of the existing set of opcodes and gives a nice framework for thinking about new (or disabled old) opcodes. Doing that is way outside my own personal level of expertise; I know only enough about designing secure algorithms to know that I  have no idea whether or not re-enabling OP_XOR would have security implications for bitcoin.

Same goes for enabling nLockTime / transaction replacement, although I suspect that proving that transaction replacement doesn't open up any subtle attacks may be harder than proving security properties of opcodes.

[jackjack]

Ok thanks for the explanations