Ok thanks for the explanations
Topic: Why so many OP codes are disabled? (Read 2012 times)
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.
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.
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
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
Seeing use cases for the disabled opcodes would definitely help.
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.
If I understand correctly: if I want an OP code to be re-enabled, I'll have to make it secure
gmaxwell's post addresses that point.
Thanks for that
My second question is still unanswered though, and I can't find any information about that
My second question is still unanswered though, and I can't find any information about that
This thread answers some of your questions:
https://bitcointalksearch.org/topic/reliance-upon-transactions-vs-reactions-to-incidents-28861
https://bitcointalksearch.org/topic/reliance-upon-transactions-vs-reactions-to-incidents-28861
All I could find to explain that is 3 lines:
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)
Quote
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.
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)
Jump to: