Bifurcación blanda activada por los usuarios

La idea invierte el orden habitual de los pasos. En lugar de esperar a que el poder de hash señalice su preparación, los nodos que reciben pagos anuncian una fecha a partir de la cual rechazarán cualquier bloque que no cumpla. El BIP-148 estableció esa fecha en el 1 de agosto de 2017, y a la amenaza creíble que suponía se le atribuye ampliamente haber puesto fin a un punto muerto en la señalización que duraba desde noviembre de 2016.

Cómo funciona

Es en la validación, no en la minería, donde en última instancia se hace cumplir una regla, y una bifurcación blanda activada por los usuarios se basa en ese hecho.

Un nodo decide por sí mismo qué bloques son válidos. Si una parte suficiente de la economía (los exchanges, los procesadores de pagos y los custodios con los que la gente liquida de verdad sus pagos) ejecuta software que rechaza los bloques que no cumplen, entonces un minero que produce esos bloques cobra en monedas que nadie aceptará. La recompensa de bloque solo vale algo si la cadena en la que se encuentra es la que reconocen los compradores, así que el incentivo apunta al cumplimiento sin que se celebre ninguna votación.

El mecanismo es una fecha y no un umbral. El BIP-148 exigía que, a partir del 1 de agosto de 2017, todo bloque señalizara su preparación para SegWit, e indicaba a los nodos que dejaran huérfanos los bloques que no lo hicieran. Se trata de una restricción de las reglas, así que una cadena que cumple la regla sigue siendo válida para los nodos que nunca se actualizaron. Lo que no elimina es el riesgo de una división de la cadena: si la mayor parte del poder de hash sigue minando bloques que no cumplen, el lado que hace cumplir la regla tiene menos trabajo acumulado, y las dos cadenas coexisten hasta que uno de los dos lados cede.

Más tarde, el BIP-8 convirtió el enfoque en un conjunto general de parámetros. Cuenta las señales igual que el BIP-9, pero añade el parámetro lockinontimeout, que suele escribirse LOT. Con LOT en false, el despliegue simplemente expira si los mineros nunca alcanzan el umbral. Con LOT en true, queda fijado de todos modos al llegar a la altura del timeout (fecha de expiración), lo que es una bifurcación blanda activada por los usuarios expresada como una opción de configuración.

Dónde aparece

La secuencia de 2017 es el único ejemplo que ha llegado a completarse en bitcoin, y vale la pena conocerla en orden. El BIP-148 lo publicó en marzo de 2017 un desarrollador que usaba el nombre Shaolin Fry, y los operadores de nodos lo fueron adoptando a lo largo de la primavera. Ante una fecha límite en agosto, los mineros adoptaron en julio el BIP-91 para hacer obligatoria entre ellos la señalización de SegWit. Después, SegWit quedó fijado en el bloque 479.808, el 8 de agosto de 2017, y pasó a ser exigible desde el bloque 481.824, el 24 de agosto de 2017. La fecha fija llegó sin una división duradera porque el resultado que exigía ya se había conseguido.

El enfoque reapareció antes de Taproot. Entre finales de 2020 y principios de 2021, la discusión giró por completo en torno a si distribuir el BIP-8 con LOT en true o en false, se publicó un cliente alternativo con LOT en true, y la solución intermedia fue Speedy Trial, que estableció una ventana corta y ninguna activación forzada. Los mineros alcanzaron el umbral en junio de 2021, así que la cuestión nunca llegó a ponerse a prueba.

Si usted conserva bitcoin, la conclusión que importa es que ejecutar su propio nodo es lo que da relevancia a todo esto. Una bifurcación blanda activada por los usuarios cuenta a los usuarios que validan, y alguien cuyo saldo está por completo en un exchange queda representado por el software de ese exchange, no por el suyo.

Bifurcación blanda activada por los usuarios frente a bifurcación dura

Una bifurcación blanda activada por los usuarios restringe las reglas; una bifurcación dura (hard fork) las relaja, y la confusión de 2017 vino de que ambas conllevaban un riesgo de división. Con el BIP-148, una billetera antigua seguía funcionando y la cadena resultante seguía siendo válida para todas las versiones anteriores del software, que es exactamente lo que una bifurcación dura no puede prometer. El riesgo de división era temporal y dependía del comportamiento de los mineros, mientras que la división de una bifurcación dura está prevista en el diseño desde el primer bloque incompatible.