Are disabled OpCodes considered invalid or are they treated as NOP?

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: gmaxwell on March 20, 2015, 03:34:47 PM

They're handled in a slightly different way than generic unhandled opcodes, so they can't be completely removed (they are tested even when the machine is not executing due to an untaken branch).

Oh cludge. Really? I need to take a closer look at the unexecuted branch portion of the script validator then. That would make it tough to remove them from the code. One way would be a soft fork tests for any undefined opcode in untaken branch. Then the disabled ones could be undefined without any change in behavior.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: gmaxwell on March 20, 2015, 04:27:16 PM

Quote from: CIYAM on March 20, 2015, 03:41:30 PM

XOR could allocate memory?

Yes, the inputs first had to be coerced to the same size before they could be xored. (I suppose OP_XOR could have been defined as narrowing instead of widening, but it wasn't).

Thanks for the insight gmaxwell. The simplest solution would have been to require that both values being XORed are the same byte length. It would be easy to enforce have no edge cases, easy to test, and would have still preserved most use cases.

gmaxwell

staff

Activity: 4172

Merit: 8419

Quote from: CIYAM on March 20, 2015, 03:41:30 PM

XOR could allocate memory?

Yes, the inputs first had to be coerced to the same size before they could be xored. (I suppose OP_XOR could have been defined as narrowing instead of widening, but it wasn't).

CIYAM

legendary

Activity: 1890

Merit: 1072

Ian Knowles - CIYAM Lead Developer

Quote from: gmaxwell on March 20, 2015, 03:34:47 PM

It was insecure. Pretty much any of the operations which could allocate memory were.

XOR could allocate memory?

(that seems odd to me)

gmaxwell

staff

Activity: 4172

Merit: 8419

Quote from: CIYAM on March 20, 2015, 01:32:33 PM

It does seem strange to disable XOR - was there any reasoning stated for that?

It was insecure. Pretty much any of the operations which could allocate memory were.

They're handled in a slightly different way than generic unhandled opcodes, so they can't be completely removed (they are tested even when the machine is not executing due to an untaken branch). But they're 99.99% removed, I suppose the labels could be removed too.

cr1776

legendary

Activity: 4018

Merit: 1299

Quote from: CIYAM on March 20, 2015, 01:32:33 PM

Quote from: DeathAndTaxes on March 20, 2015, 01:29:24 PM

I am still bummed that XOR is disabled. It has a lot of potential uses and no security implications.

It does seem strange to disable XOR - was there any reasoning stated for that?

My digest version is that while they seemed to not have security implications, without extensive testing and documentation it was safer to disable them than not.

I think this deals with it a bit:
https://bitcointalksearch.org/topic/m.363775

And these two threads:

https://bitcointalksearch.org/topic/reliance-upon-transactions-vs-reactions-to-incidents-28861
https://bitcointalksearch.org/topic/why-so-many-op-codes-are-disabled-37157
https://bitcointalksearch.org/topic/testing-so-that-opcodes-can-be-re-enabled-255110

They were just disabled without much information:
https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#script.cpp

CIYAM

legendary

Activity: 1890

Merit: 1072

Ian Knowles - CIYAM Lead Developer

Quote from: DeathAndTaxes on March 20, 2015, 01:29:24 PM

I am still bummed that XOR is disabled. It has a lot of potential uses and no security implications.

It does seem strange to disable XOR - was there any reasoning stated for that?

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: TierNolan on March 20, 2015, 12:12:11 PM

The only way to re-enable them is to hard-fork. At this point their only purpose is to taunt people

.

So why not remove them from the code and documentation? Sure a hard fork could enable them but it could also enable any other new functionality one could think of. Why not simplify the code. I am still bummed that XOR is disabled. It has a lot of potential uses and no security implications.

TierNolan

legendary

Activity: 1232

Merit: 1083

The only way to re-enable them is to hard-fork. At this point their only purpose is to taunt people

.

CIYAM

legendary

Activity: 1890

Merit: 1072

Ian Knowles - CIYAM Lead Developer

Although not the latest source I see this:

Code:

if (opcode == OP_CAT ||
    opcode == OP_SUBSTR ||
    opcode == OP_LEFT ||
    opcode == OP_RIGHT ||
    opcode == OP_INVERT ||
    opcode == OP_AND ||
    opcode == OP_OR ||
    opcode == OP_XOR ||
    opcode == OP_2MUL ||
    opcode == OP_2DIV ||
    opcode == OP_MUL ||
    opcode == OP_DIV ||
    opcode == OP_MOD ||
    opcode == OP_LSHIFT ||
    opcode == OP_RSHIFT)
    return false; // Disabled opcodes.

in EvalScript (so assuming the return value is whether the script is valid then I guess not).

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Are disabled OpCodes considered invalid or are they treated as NOP? Link to where that is enforced in the code would be appreciated.

Topic: Are disabled OpCodes considered invalid or are they treated as NOP? (Read 1646 times)