Guerra del tamaño de bloque

Imaginemos dos necesidades cotidianas. Anna quiere enviar bitcoin sin esperar mucho ni pagar una comisión elevada. Pavel mantiene un nodo completo: un ordenador que comprueba bloques y transacciones por sí mismo. Quiere verificar su dinero sin equipos caros. Ambas necesidades son razonables, pero añadir datos a cada bloque también exige transmitir y comprobar más información. Ese equilibrio estaba en el centro de la Block Size War. Un bloque es un conjunto de transacciones que se añade al historial de pagos compartido por la red. Anna y Pavel son personajes ilustrativos. En el debate real de 2015–2017 participaron desarrolladores, operadores de minería, plataformas de intercambio, proveedores de monederos y usuarios. Discrepaban sobre la capacidad y sobre cómo introducir cambios de forma segura. Bitcoin no tenía un director que pudiera escoger una opción y ordenar a todos que la adoptaran. [1] [11] [13]

Antes de SegWit, las reglas limitaban cada bloque a 1 MB, es decir, 1 000 000 de bytes. No era un número fijo de pagos: las transacciones ocupan espacios diferentes. Se genera un bloque aproximadamente cada diez minutos de media. Si la demanda supera la capacidad, los mineros suelen priorizar las transacciones con tasas de comisión más altas y las demás esperan. Los defensores de bloques mayores querían ampliar directamente la red base y mantener los pagos asequibles. Sus oponentes temían que aumentaran los requisitos de conexión, equipos y propagación rápida de bloques. Si menos personas pudieran verificar por su cuenta, más usuarios dependerían de servicios ajenos. Un límite mayor no acelera por sí solo la creación de bloques ni garantiza comisiones bajas para siempre: también importan la demanda y el uso real del espacio. [1] [2] [13]

Un desarrollador puede escribir software y un minero producir bloques con él. Sin embargo, quien opera un Full Node decide qué reglas comprueba su nodo. Ni siquiera una mayoría de potencia de cálculo puede hacer que un nodo sin modificar acepte un bloque contrario a sus reglas. La potencia ayuda a elegir entre cadenas válidas; no convierte un bloque inválido en válido. Esto tampoco equivale a un voto por nodo en unas elecciones mundiales, ni permite a una persona impedir que otras se marchen. Las empresas deciden qué aceptan; los mineros, qué minan; los usuarios, qué valoran. Unas reglas incompatibles pueden dar lugar a dos redes. Un acuerdo empresarial podía apoyar un cambio, pero no reescribir automáticamente el software y las decisiones de todos. [11] [12]

Las propuestas se documentaban como BIP, siglas de Bitcoin Improvement Proposal. Un BIP explica una propuesta para que otros puedan examinarla y debatirla. Recibir un número no significa que la red la haya adoptado. Gavin Andresen propuso en BIP 101 elevar el límite a 8 MB y aumentarlo después según un calendario. El plan contemplaba aproximadamente duplicarlo cada dos años y fijaba condiciones de activación. Mike Hearn y Andresen defendían Bitcoin XT, un software alternativo que ofrecía esta vía. Publicarlo no equivalía a modificar las reglas de toda la red. Los nodos antiguos rechazarían un bloque superior al límite vigente. Era un Hard Fork: un cambio que ampliaba el conjunto de bloques permitidos y exigía otras reglas para aceptarlos. La discusión dejó de ser solo cuánto espacio añadir. Había que decidir quién migraría, cómo coordinar el cambio y qué ocurriría si una parte importante no estaba de acuerdo. [1] [18] [13]

Eric Lombrozo, Johnson Lau y Pieter Wuille describieron otra vía en BIP 141. SegWit reorganizó los datos de las transacciones e introdujo el peso del bloque, limitado a 4 000 000 weight units. La parte denominada witness contiene, entre otros datos, los que permiten comprobar la autorización para gastar. No desaparecieron ni dejaron de verificarse: recibieron otro tratamiento al calcular el peso. La capacidad depende de la combinación de transacciones, no de permitir simplemente bloques ordinarios de cuatro megabytes. El peso indica cómo se contabilizan los datos dentro del límite del bloque: cada byte de datos base cuenta como 4 unidades, mientras que cada byte adicional relacionado con witness cuenta como 1. Por eso, transacciones del mismo tamaño en bytes pueden consumir distintas cantidades de peso. La capacidad también depende del tipo de transacciones que se utilicen. En las transacciones adecuadas, SegWit también impidió cambiar su identificador mediante modificaciones de los datos de firma. Eso facilitó construir los canales de pago de Lightning Network. Se diseñó como Soft Fork: los nuevos bloques válidos encajan en las reglas antiguas, aunque los nodos antiguos no verifican todas las nuevas restricciones. Bitcoin Core 0.13.1 incluyó el mecanismo de activación; publicar el programa no activó SegWit por sí solo. [2] [3]

El 23 de mayo de 2017, Digital Currency Group publicó el New York Agreement, un acuerdo entre empresas y mineros. Vinculaba el apoyo a SegWit con un Hard Fork a 2 MB en un plazo de seis meses. Este segundo paso se conoció como SegWit2x y se implementó en el proyecto btc1. Para algunos era un compromiso aceptable: cada grupo obtendría parte de lo que pedía. Otros rechazaban tanto el segundo cambio como la forma de impulsarlo. El apoyo de una empresa no representaba automáticamente el consentimiento de todos sus clientes. Bitcoin Core aclaró después que btc1 no era una actualización obligatoria de su programa y que apoyar SegWit no significaba apoyar SegWit2x. Conviene recordarlo al leer noticias de la época: dos cambios incluidos en un acuerdo seguían siendo dos cambios de reglas diferentes. [6] [7] [11]

El autor seudónimo Shaolin Fry propuso BIP 148, un UASF o Soft Fork activado por usuarios. Desde el 1 de agosto de 2017, según Median Time Past, los nodos con esa regla rechazarían bloques que no señalaran apoyo a SegWit, salvo que ya estuviera fijada su activación o estuviera activo. Si la minería y la aceptación de bloques divergían, podía dividirse la red. No era un interruptor sin riesgo accionado por todos a la vez. Median Time Past es el valor central al ordenar las marcas de tiempo de los últimos 11 bloques, no la hora del reloj de cada usuario. La señalización consistía en una marca en la cabecera del bloque que expresaba el apoyo del minero a ese despliegue; la marca no activaba por sí sola las nuevas reglas. James Hilliard describió en BIP 91 una coordinación minera con un umbral menor: 269 de 336 bloques, aproximadamente el 80 %. Una vez en vigor, los participantes rechazarían bloques sin la señal de la implementación original de SegWit. La coordinación de julio redujo el peligro de conflicto alrededor de agosto. No significó que SegWit ya estuviera fijado o activo en julio: seguía su propio mecanismo BIP 9. [4] [5] [9] [19]

Bitcoin Cash se separó el 1 de agosto de 2017. El software Bitcoin ABC admitía bloques mayores para esa rama, entonces con un límite predeterminado de 8 MB. A partir de la separación, ambas redes tenían reglas y monedas distintas. Compartir la historia anterior no permitía transferir libremente pagos posteriores entre BTC y BCH. Bitcoin Cash no era SegWit2x, ni Bitcoin ABC era btc1. Confundirlos mezcla la separación de agosto con otro proyecto suspendido después. También diferían en replay protection: cómo impedir que una transacción se repitiera en la otra cadena. Para el usuario, esto tenía una consecuencia práctica: operar en una rama no debía gastar accidentalmente fondos de la otra. Tampoco era seguro introducir las claves compartidas en cualquier herramienta que prometiera nuevas monedas. [8] [15] [11]

SegWit entró en el estado LOCKED_IN desde el bloque 479 808, el 9 de agosto de 2017. Había terminado el periodo de decisión y faltaba otro de espera antes de aplicar las nuevas reglas. Se activó en el bloque 481 824, el 24 de agosto. Ambas alturas están separadas por 2 016 bloques. La coordinación BIP 91 de julio, la fijación de agosto y la activación fueron, por tanto, acontecimientos diferentes. Quedaba la segunda etapa de SegWit2x, prevista para la altura 494 784. El 8 de noviembre, sus organizadores, encabezados por Mike Belshe, anunciaron la suspensión: según su comunicado, no habían conseguido suficiente acuerdo para una transición fluida. Bitcoin no perdió el SegWit ya activo ni desapareció Bitcoin Cash. Terminó ese intento concreto de convertir el apoyo empresarial y minero en un aumento del límite de Bitcoin. [9] [10] [12] [14] [16] [17]

La disputa mostró que Bitcoin puede cambiar, pero escribir código, reunir firmas empresariales y lograr que se acepten reglas son tareas distintas. No demostró que los desarrolladores carezcan de influencia, que los mineros no importen o que toda decisión futura vaya a terminar igual. La capacidad, la verificación asequible y el acuerdo entre participantes no se resuelven cambiando el nombre de una actualización. Ante una propuesta, pregúntese qué modifica, qué nodos discreparían después y cómo se activaría. Distinga entre propuesta, software publicado y reglas realmente vigentes. Los BIP y el código de la época documentan mecanismos; los comunicados de los distintos grupos, sus posiciones. Ningún comunicado de un participante constituye por sí solo una historia imparcial de todo el conflicto. [1] [6] [11] [12]