Controversia en Bitcoin: ¿Por qué varios desarrolladores se oponen a la BIP-119?

La comunidad de Bitcoin y sus desarrolladores están en medio de un debate como no se había visto desde hace varios años. La Propuesta de Mejora de Bitcoin 119 o BIP 119 preocupa a algunos y entusiasma a otros por igual, sin que exista por el momento un consenso claro sobre si implementar o no esta actualización en el protocolo. 

La Bitcoin Improvement Proposal o BIP 119 es una creación del desarrollador Jeremy Rubin, quien apunta con ella a introducir parámetros avanzados para las transacciones de Bitcoin, como por ejemplo, que unos bitcoins solo puedan ser enviados a una dirección en específico y no a otra.  

Pero, además, y de manera importante, también puede condicionar el gasto de esos bitcoins en el futuro, de forma que una vez sean enviados a una dirección inicial, a partir de allí solo puedan enviarse hacia otras direcciones especificadas.  

Hasta allí todo bien pero ¿Por qué esta propuesta despierta opiniones tan disímiles en la comunidad? Son varios los argumentos a favor y en contra desde el punto de vista técnico, pero también, desde el punto de vista político sobre el consenso de Bitcoin y los mecanismos para implementar este tipo de actualizaciones. 

El argumento político: Jeremy Rubin quiere obligar la activación de un soft fork

Podría decirse que quienes se oponen a la activación de la BIP-119 no lo hacen principalmente porque sea enteramente una solución mal diseñada desde el punto de vista técnico, sino que se oponen a la persistencia de Jeremy Rubin para introducirla en Bitcoin. 

El pasado 17 de abril Jeremy Rubin publicó en su blog sus planes de activar la BIP-119, apelando a un juicio rápido o speedy trial como el que se hizo con Taproot, de la mano de los mineros de Bitcoin durante 2021. 

Esto despertó fuertes críticas, entre ellas la de Andreas Antonopoulos, quien se opuso a la activación de la BIP-119 cuando ésta no ha recibido un apoyo abrumador para formar un consenso que favorezca su implementación segura y controlada. 

De hecho, Jeremy Rubin retó a Antonopoulos a debatir la BIP 119, invitándolo a discutir sus ideas en la MIT Bitcoin Expo el próximo 7 de mayo, pero el conocido divulgador no ha respondido a esta propuesta. 

Por su parte, Michael Folkson, otro desarrollador de Bitcoin, también escribió en un correo, el pasado 20 de abril, que no pretendía discutir el tema de la BIP-119. Pero la inminencia de un soft fork impulsado por Jeremy Rubin era demasiado riesgosa como para no emitir una opinión al respecto e invitar al resto de la comunidad a fijar una posición lo antes posible. 

Lo más triste de todo es que si el intento de Jeremy [Rubin] por activar un soft fork causa incertidumbre y confusión, temo que en un futuro aquellos soft forks que tengan apoyo abrumador de la comunidad serán más difíciles de implementar.
 
Existen un número de soft forks sobre los que estoy emocionado […] que a largo plazo podríamos obtener con una aproximación sensible respecto a activar soft forks con el cosnenso de la comunidad. Pero mientras más incertidumbre y confusión creemos sobre soft forks contenciosos, aparecerán más y más soft forks peligrosos en cualquier forma. 
 
El foco principal debe ser resistir los soft forks que no tienen consenso de la comunidad y asegurar que Bitcoin no se divida en una cantidad mayor de activos y blockchains con una cantidad diferente de soft forks activos. 

Michael Folkson, desarrollador.

Bitcoin no puede tener funcionalidades que nadie ha pedido

Uno de los puntos contra la BIP-119 es que sus funcionalidades no parecen ser demandadas por el mercado. Según John Carvalho, CEO de Synonym, los cambios realizados en Bitcoin «deberían solucionar problemas obvios y proveer ventajas en cuanto a optimización, seguridad y privacidad de forma simple».

Así lo explicó el también desarrollador en un correo electrónico dirigido a Jeremy Rubin fechado el 2 de mayo de 2022: 

La ruta del consenso es proponer cosas que todos necesiten. La demanda proviene del mercado, no de los diseñadores. Los ingenieros solucionan problemas con sus diseños, pero cuando especulan y lideran el proceso, crean problemas en su lugar. Bitcoin no es un lugar para actualizaciones especulativas. Bitcoin no puede sostener una cultura de funcionalidades que nadie está pidiendo. Bitcoin se sostiene en la cultura del “NO”. La resistencia al cambio es la característica principal de Bitcoin.

John Carvalho, CEO de Synonym.

Carvalho continúa diciendo que no existe ninguna probabilidad de que la mayoría de usuarios de Bitcoin sean capaces de auditar los cambios introducidos en el protocolo, o medir las consecuencias, y los desarrolladores tienden a ignorar esto. «El público ya confía en los desarrolladores de Bitcoin Core más de lo que deberían, y es poco sabio inclinarse a ello», dice. 

Jimmy Song, otro desarrollador de Bitcoin y divulgador, tiene una opinión parecida en este sentido:

Solo porque podamos hacer algo no significa que deberíamos. Lo que es para mí alarmante sobre la propuesta es que sigo escuchando quien afirma que ‘hay un amplio consenso entre los desarrolladores’ de que los covenants son deseables. Tal vez para los desarrolladores, lo son. ¿Pero y para los usuarios? Ultimadamente, son ellos los que tienen el control porque ellos corren los nodos [de Bitcoin].

Jimmy Song, desarrollador

Una oportunidad de redención para Jeremy Rubin

En el mismo correo, Carvalho reconoce la libertad de cada usuario y desarrollador de proponer los cambios que crea necesarios para Bitcoin. En este principio parece haberse afianzado Jeremy Rubin para haber propuesto una ruta de activación y cliente propio que implemente la BIP-119, aunque ahora se ha retractado de seguir lo que había anunciado. 

Ayer 2 de mayo Jeremy Rubin envió un mensaje a la lista de correos de desarrolladores de Bitcoin donde aceptaba su responsabilidad y se comprometía a seguir escuchando las opiniones del resto de desarrolladores para evaluar la viabilidad de la BIP-119. 

Desde que publiqué mi blog, han surgido afirmaciones imprecisas en varias plataformas sobre que yo estaría tratando de evadir los mecanismos de consenso, forzar a los mineros a hacer una speedy trial, forzar a los usuarios a aceptar algo que no quieren; afirmaciones que me ofrecen enfrentar repercusiones, que atacan mi carácter y más.

Cada quién es libre de leer el material que he comunicado y evaluar dichas afirmaciones de mi alegada mala fe. Acepto la responsabilidad de que últimamente no me he comunicado claramente. Ahora, yo he mantenido mi palabra de que escuchar lo que tengan que decir antes de hacer cualquier lanzamiento: no he lanzado el software para hacer speedy trial en un cliente de CTV [BIP-119] y he mantenido mi promesa de no seguir un proceso de soft fork.

Jeremy Rubin.

Al mismo tiempo, Rubin considera que muchas de las opiniones provenientes de voces respetadas en la comunidad han consistido en desinformación, y que «ellos representan un precedente peligrosos para todos los desarrolladores de Bitcoin». 

Si bien Jeremy Rubin parece entender que seguir la ruta de activación de la BIP-119 sin el apoyo de la comunidad no es lo más conveniente, aún podría reorganizar sus ideas, ya que está convencido de que CTV es una funcionalidad deseable para Bitcoin. 

En una próxima entrega analizaremos los argumentos a favor y en contra desde el punto de vista técnico para implementar o no la BIP-119 en Bitcoin.