В наступающем размере блока hardfork, я хотел бы предложить, чтобы иметь относительно простого изменения пути введения нового кода OP: OP_RETURNTRUE

Когда двигатель сценарий читает OP_RETURNTRUE, он будет оценивать сценарий, как действует немедленно, независимо от того, что произойдет после этого.

OP_RETURNTRUE является "без нажима код OP" в BIP62. Ввод голой (не P2SH) OP_RETURNTRUE в scriptSig немедленно аннулирует сценарий.

Мы можем иметь OP_RETURNTRUE1, OP_RETURNTRUE2, OP_RETURNTRUE3 и т.д. до тех пор, как у нас есть достаточно неприсвоенный кода OP.

------------

OP_RETURNTRUE полезно, если мы хотим, чтобы ввести новый код OP манипулировать акции. Например, если мы хотим, чтобы вновь ввести OP_CAT, не представляется возможным сделать это с OP_NOP, поскольку он не позволяет перезапись содержимого пакета акций. В настоящее время единственным способом представить OP_CAT является новой версией P2SH.

С OP_RETURNTURE, мы можем непосредственно переопределить его как OP_CAT, и он будет инструктировать сценарий Concat 2 верхних кольев пунктов. Так как новый OP_CAT не возвращает истинное непосредственно, это должно быть softfork по определению.

Можно даже переопределить эти неиспользуемые OP_NOPs в OP_RETURNTUREs. Поскольку OP_RETURNTURE может сделать все, что OP_NOP может сделать. (Мы можем превратить OP_RETURNTURE в OP_NOP с softfork, например)

-------------

Если это OP_RETURNTURE напоминает нам кошмар CVE-2010-5141 (http://bitcoin.stackexchange.com/questions/25225/what-was-the-vulnerability-in-v0-3-4-that-allowed-an-attacker-to-steal-coins), Я хотел бы предложить, чтобы превратить эти нераспределенные коды OP в OP_NOPs (все еще в hardfork). Он отложит потребность с использованием двойных байт OP кодов

-------------

EDIT (2015-сентябрь-1): Это может быть softfork, если положить его в "P3SH", Это позволит перенести потребности иметь новую версию P2SH каждый раз, когда мы хотим новый стек манипулирует код OP.