Use cases for SegWit script versioning

cr1776

legendary

Activity: 4130

Merit: 1307

Quote from: JackH on May 11, 2017, 12:10:29 PM

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.)

JackH

sr. member

Activity: 381

Merit: 255

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

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

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.

tomtomtom7

jr. member

Activity: 38

Merit: 18

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.

Topic: Use cases for SegWit script versioning (Read 855 times)