¿Cuáles son las desventajas de habilitar códigos de operación potencialmente subóptimos o no utilizados en una futura bifurcación blanda?

Cada pieza de lógica de consenso adicional tiene un costo de implementación y mantenimiento continuo que es perpetuo y nunca se puede eliminar sin potencialmente confiscar los activos de algún usuario.

Cuando Satoshi deshabilitó esos códigos de operación, se arriesgó a que al hacerlo destruiría los fondos de algunos usuarios, pero Bitcoin era joven, su uso aparentemente no existía, y todos esos códigos de operación podrían usarse para causar un uso de memoria ilimitado o corrupción de memoria y bloqueo de nodos. . No sé si Satoshi necesariamente se dio cuenta de que podría estar destruyendo los fondos de las personas, pero dada la amenaza en ese momento de la vida de Bitcoin (mientras que los Bitcoins tenían muy poco valor), probablemente fue la decisión correcta. Ya no lo sería.

Cualquier funcionalidad recién introducida no es solo un riesgo para el usuario, es un riesgo potencial para toda la red, ya que las fallas en ella podrían dar lugar a inconsistencias de consenso, bloqueos de nodos, aumentos en los tiempos de procesamiento en el peor de los casos o incluso vulnerabilidades de ejecución remota de código. . Protegerse contra eso requiere recursos de revisión y prueba que, de lo contrario, podrían gastarse en otra funcionalidad. Los costos tampoco son costos de una sola vez, ya que el código debe mantenerse y los errores podrían introducirse más adelante.

La complejidad adicional también dificulta la vida de las implementaciones de nodos alternativos, ya que también tienen que implementar todas las reglas de consenso, y va en contra de la libertad de los usuarios para modificar su propio nodo (o implementar el suyo propio). Debido a estos costos, "tal vez alguien lo encuentre útil" no es un argumento realmente convincente.

Los costos también significan que una vez que se implementa alguna funcionalidad, hay razones para no implementar otra que sea parcialmente redundante con ella, por lo que si las fallas en una función eliminan algunos usos pero no todos, será más difícil obtener una alternativa mejorada que cubra todos. los usos desplegados.

En cuanto a las ventajas de ofrecer un conjunto de instrucciones simplificado y en su mayoría ortogonal, no creo que eso en sí mismo importe mucho. Si bien la proliferación de operaciones es una molestia para cualquiera que cree una herramienta de análisis, las personas generalmente pueden crear subconjuntos de secuencias de comandos como quieran. Incluso si creara la carga de que los usuarios que necesitan construir una política de manera conjunta tengan que acordar un subconjunto común con el que sus herramientas de análisis estén satisfechas, creo que este costo podría compensarse fácilmente con la funcionalidad adicional.

Si OP_BAR es una pistola y es redundante con OP_BAZ, que es menos de uno, simplemente incluya OP_BAR en la lista negra y use solo OP_BAZ. Pero si OP_BAR se implementa primero, puede ser difícil argumentar que esa mejora marginal de OP_BAZ vale sus costos adicionales. Entonces, de esa manera, la implementación de una característica débil puede obstaculizar una alternativa más fuerte que podría haberse hecho en primer lugar si se hubiera invertido una cantidad adecuada de esfuerzo. La misma afirmación es cierta si reemplaza 'footgun' con 'ineficient'.

A veces, las funciones mal diseñadas pueden tener efectos de incentivos negativos en el sistema. Por ejemplo, la construcción original de nlocktime basada en el tiempo creó un incentivo para que los mineros mintieran sobre su tiempo actual, adelantándolo para poder cobrar transacciones posteriores de nlocktime y sus tarifas. Si las transacciones nlocktime basadas en el tiempo se volvieron muy comunes, esto eventualmente podría haber creado una carrera hacia el abismo en la que todos los mineros estaban adelantando sus tiempos lo más posible para maximizar sus tarifas, y potencialmente poniendo en peligro la estabilidad de la red como resultado incluso para usuarios que no usan locktime. Afortunadamente, nlocktime se podía arreglar de forma compatible. Del mismo modo, las características mal construidas podrían fragmentar innecesariamente el conjunto de anonimato o incentivar a los usuarios a reducir la privacidad de todos.

Es fácil imaginar funciones inventadas que crearían efectos sistémicos negativos: por ejemplo, OP_BOBSIG donde un txout usándolo se puede gastar sin restricciones siempre que Bob haya firmado todo el bloque, una opción extremadamente eficiente para aquellos que confían en Bob. Y parece inofensivo para las personas que no lo usan, hasta que considera que le da a los que confían en bob una ventaja injusta, le da a la minería de bob una ventaja injusta y, eventualmente, podría entregar el control de todo el sistema a Bob. Pero los efectos sistemáticos son una preocupación menos común, ya que requieren una función que sea lo suficientemente atractiva para que las personas decidan usarla, pero poco atractiva para el sistema en su conjunto. Todavía es un factor que debe ser considerado.

Aparte de los casos de esquina del efecto del sistema, la mayoría de los expertos en Bitcoin estarían de acuerdo en que el propietario de un fondo debería tener total libertad en la forma en que elige administrarlo, incluso si eso significa que a veces puede elegir un ineficiente o menos seguro personalmente. Las mejores prácticas se pueden abordar fuera del propio sistema. Pero debido a que las reglas de consenso deben implementarse en todos los nodos y no se pueden eliminar, existen costos. Estos costos crean situaciones en las que la elección entre una operación mal y una bien construida, o simplemente entre dos operaciones totalmente diferentes, es hasta cierto punto mutuamente excluyente. Debido a esto, una nueva función no solo debe ser segura para la red, sino que también debe ser claramente útil.

Hay otra consideración además de garantizar el uso limitado de recursos en todos los casos extremos para un código de operación que fue discutido brevemente por otros en IRC que resumiré aquí.

Existen diferentes enfoques filosóficos para diseñar futuros códigos de operación para Bitcoin. Una dimensión es si los códigos de operación deben diseñarse utilizando un enfoque RIS (conjunto de instrucciones reducido) o un enfoque CIS (conjunto de instrucciones complejo). Un enfoque de conjunto de instrucciones reducido (RIS) conduce a códigos de operación con una funcionalidad mínima, pero se pueden combinar como bloques de construcción con otros códigos de operación para crear una mayor funcionalidad (es decir, similar a UNIX). Un conjunto de instrucciones complejo (CIS) conduce a códigos de operación que ofrecen una funcionalidad completa y particular.

Otra dimensión tiene que ver con la seguridad y si los códigos de operación deben diseñarse para evitar las armas de fuego, lo que restringe a los programadores de crear scripts que pueden usarse indebidamente de manera que puedan dañar la seguridad del usuario. La alternativa es no preocuparse tanto por la seguridad del usuario, permitir la máxima flexibilidad y llevar las preocupaciones de seguridad a capas abstractas superiores (por ejemplo, Miniscript, Política, descriptores, etc.).

Estas dos dimensiones no son completamente ortogonales. Si no se consideran estas dimensiones, terminará con una bolsa de nuevos códigos de operación (y banderas sighash) habilitados y no está claro qué códigos de operación se deben usar para qué y qué orientación (si corresponde) se debe ofrecer sobre cómo usarlos. sin peligro. Cuando Satoshi habilitaba y deshabilitaba los códigos de operación, no tenía la comprensión que tenemos en 2021 y no estaba lidiando con un sistema que almacena y transfiere miles de millones de dólares con capas superiores que dependen de los cambios realizados en la capa base.