Por Rick Falkvinge (@falkvinge)
Basándome en mi experiencia en programación y diseño de sistemas –empecé a programar hace 37 años– veo estas dos opciones para la escalabilidad de Bitcoin en el corto plazo:
OPCIÓN UNO: cambiar el límite superior del tamaño del bloque a dos megabytes. Una línea de código para la constante, alrededor de diez líneas de código para gatillar la activación. Requiere actualización del software de la mayoría de los servidores.
OPCIÓN DOS: Introducir SegWit (Segregated Witness). Alrededor de 500 líneas de código nuevo, de las cuales al menos 100 entrarían en la parte del código más sensible en cuanto al consenso. Requiere actualización del software de la mayoría de los servidores y el software y el hardware de todos los clientes/carteras, especialmente de aquellos que necesitan enviar dinero a una dirección arbitraria (ya que SegWit introduce un nuevo tipo de dirección que tanto el emisor como el receptor deben controlar).
Cuando los defensores de Core me dicen que su propuesta (la opción dos) es mejor porque es más segura, yo trato de comprenderlos y concluyo que o bien estoy completamente loco o la declaración es el equivalente a «lo negro es blanco y arriba es abajo». No solo es completamente contraria a toda experiencia en gestión de riesgos en ingeniería de software; está tan lejos que ya no refleja la luz del sol.
Cuando trato de entender más y cuestiono la afirmación de que la segunda opción es más segura –para lo cual debo decir que tengo fundamentos sólidos– me dicen que debería dejar el diseño a los expertos y que no entiendo lo suficiente acerca de la compleja máquina que es Bitcoin. Sé que soy capaz de aprender cosas complejas, pero me dicen con firmeza que ni siquiera lo intente.
Esa no es la forma de hacer que la gente quiera usar tu código.
Por supuesto, la gente es libre de utilizar cualquier código que les guste. Pero los pesos y contrapesos en una comunidad de código abierto funcionan de la siguiente manera: si los líderes de un proyecto construyen algo diferente de lo que la gente quiere utilizar, la gente utilizará otra cosa. Por lo tanto, es en interés de los líderes escuchar a la comunidad para comprender qué software quiere utilizar la mayoría.
Entiendo la complejidad de los tiempos de transferencia de los bloques a través del firewall de China y que las pruebas preliminares indican que un nodo completo típico se satura con un bloque de 32 megabytes. Sin embargo, ninguno de estos límites se verá afectado por la propuesta de Bitcoin Classic. Además, cuando uno abre un camino como éste, lo razonable es trabajar en un problema a la vez –resolver un cuello de botella a la vez–. La gente ha estado insistiendo en la necesidad de aumentar el tamaño del bloque por más de un año. Más adelante será posible ampliar la capacidad de los nodos de diferentes maneras, pero ese no es el cuello de botella inminente.
Cuando una enorme cantidad de datos cruciales es ignorada (en relación a la necesidad de elevar el límite al tamaño del bloque), se pone en riesgo el proyecto.
En la comunidad Bitcoin abundan los geeks capaces de absorber y analizar cantidades monstruosas de información. Si no puedes explicar por qué tu solución es mejor que otra solución propuesta, nadie estará satisfecho con la respuesta «porque somos los expertos». Debes asumir que hay otras personas al menos tan inteligentes y capaces de aprender como tú. Incluso es posible que si no puedes explicar tu solución a una mente abierta e inteligente, la tuya no sea en realidad una buena solución.