Use cases for SegWit script versioning

[tomtomtom7]

I would like to understand the advantages of the script versioning introduced in SegWit.

As I understand, script versioning allows you to change the meaning of existing opcodes, where currently we can only add opcodes.

Why is this needed? Isn't the power of this simple stack based language that you can add *any* functionality simply by adding new opcodes, (and can do so indefinitely with an OP_EXT), without the need for versioning?

Isn't that a very clean mechanism to update this language while retaining backwards compatibility? Especially because due to the immutability you can never deprecate old functionality.

[achow101]

Script versioning is required in order to redefine opcodes or just even add new ones. Added new opcodes cannot be done through a soft fork (except by redefining the OP_NOPX opcodes) since old software will not know what an opcode is and fail to verify the program. With script versioning, the old software can just ignore newly versioned scripts and assume that they are true so new opcodes and opcode redefinitions can be done through soft forks.

[JackH]

So what opcodes are on the plate? Any new ones being proposed yet?

[cr1776]

So what opcodes are on the plate? Any new ones being proposed yet?

If you look at this page:
https://bitcoincore.org/en/2016/06/24/segwit-next-steps/

Right after this "Some ideas for future upgrades using this mechanism are described below:" you will see some uses.

(Just above that in the "Future upgrades made easier by segwit" section it describes some improvements to opcodes included with SegWit.)