La discusión ya estaba completa en 2010
El 3 de octubre de 2010 Jeff Garzik publicó en el foro bitcointalk un parche que subía el límite de un megabyte al tamaño de bloque, con este comentario: "Deberíamos poder igualar al menos la tasa media de transacciones de Paypal." Satoshi Nakamoto respondió esa misma noche: "No usen este parche, los va a volver incompatibles con la red, en su propio perjuicio. Podemos introducir un cambio por fases más adelante, si nos acercamos a necesitarlo."
Garzik contestó explicando qué exigiría ese cambio por fases: "El esfuerzo para subir el límite de la tasa de transacciones es el mismo que el esfuerzo para cambiar la naturaleza fundamental de los bitcoins: convencer a la enorme mayoría de que actualice." Al día siguiente Satoshi aportó el mecanismo, no un veredicto:
Se puede introducir por fases, así: if (blocknumber > 115000) maxblocksize = largerlimit
Puede estar presente en versiones muy anteriores, de modo que para cuando se llegue a ese número de bloque y entre en vigor, las versiones viejas que no lo tienen ya sean obsoletas.
Ese intercambio sigue en línea y contiene casi todo lo que produjeron los siete años siguientes: el límite no se trataba como sagrado, subirlo se entendía como un hard fork y un hard fork se entendía como convencer prácticamente a todo el mundo. Lo que nadie tenía en 2010 era un caso en el que a la enorme mayoría no se la pudiera convencer.
Cuál era el problema, exactamente
Un bloque está limitado a 1.000.000 de bytes y llega aproximadamente cada diez minutos. Esa es toda la restricción, y hacia 2015 el espacio se estaba usando.
Un artículo de posición de 2016 firmado por doce investigadores planteaba la situación con claridad: Bitcoin "alcanza un rendimiento máximo de 7 transacciones por segundo", y "la tendencia actual de bloques cada vez más grandes en Bitcoin anticipa un posible problema en el que el sistema alcanzará su capacidad máxima para liquidar transacciones, probablemente para 2017" (On Scaling Decentralized Blockchains, Croman y once coautores, 2016).
Todos coincidían con esa frase. La discrepancia estaba en si un bloque lleno era un problema por resolver o una señal de precio funcionando como corresponde, y en sobre quién recaía el costo de subir el límite.
El argumento a favor de bloques más grandes, en su versión más fuerte
La mayoría de los relatos de este período los escriben quienes obtuvieron el resultado que querían. Así que conviene exponer primero qué proponía el otro lado, con sus propias palabras publicadas.
La lectura del whitepaper. El documento fundacional de Bitcoin se titula A Peer-to-Peer Electronic Cash System, es decir, un sistema de efectivo electrónico entre pares. La propia portada de Bitcoin Classic sigue declarando su propósito como sostener "el Bitcoin original tal como lo describió Satoshi" (bitcoinclassic.com). Bajo esa lectura, los pagos en cadena entre personas comunes no son un uso de Bitcoin entre varios. Son el uso, y un límite que los deja fuera por precio no es neutral: decide para qué sirve el sistema. La respuesta de Satoshi de 2010 se ofrece como prueba de que el límite siempre se entendió como ajustable.
El mercado de comisiones. Las propuestas de bloques grandes no negaban que las comisiones deban pagar la seguridad con el tiempo. Negaban que la transición tuviera que forzarla una constante escrita en el programa. La BIP 102 de Jeff Garzik, un aumento único a 2.000.000 de bytes, enumera como primera motivación "continuar la política económica actual" ("Continue current economic policy"), y sostiene que el aumento hacía falta "para estar a la altura de las expectativas del mercado y evitar una disrupción del mercado". La BIP 109 de Gavin Andresen repite esa primera motivación palabra por palabra. Dos años más tarde, la propuesta Segwit2Mb de Sergio Demian Lerner daba como objetivo "reducir temporalmente la presión de comisiones hasta que otras técnicas de escalado, como la Lightning Network, las sidechains, las drivechains y los extension blocks, demuestren ser útiles o no" (bitcoin-dev, 31 de marzo de 2017). El planteo es acotado y difícil de descartar: un mercado de comisiones que aparece porque un límite aprieta no es el mismo suceso que un mercado de comisiones que aparece porque la demanda superó a la tecnología, y el primero es una decisión que alguien tomó.
Contar nodos no es la única medida de descentralización. Este es el argumento que más se omite. La propia sección de objeciones de la BIP 101 admite que los nodos completos alcanzables venían cayendo, y luego discute la causa: el autor "cree que la caída de nodos que validan por completo en la red se debe en gran medida a la disponibilidad de programas de billetera livianos, cómodos, atractivos y seguros, y a la tendencia general a dejar la computadora de escritorio por teléfonos y tabletas". Después hace el planteo positivo: una capacidad mayor "debería permitir una mayor adopción por parte de usuarios y empresas, en especial en zonas del mundo donde la infraestructura financiera existente es débil. Eso podría llevar a una red más robusta, con nodos funcionando en más jurisdicciones políticas" (BIP 101). Sobre minería, el mismo documento sostiene que el ancho de banda es un insumo entre muchos, ya que "muchos otros factores influyen en la rentabilidad de la minería, incluidos el costo de la electricidad, la mano de obra y los inmuebles", de modo que "aumentar la influencia del ancho de banda en la ecuación de rentabilidad minera no llevará necesariamente a más centralización". Una red de cinco mil nodos en tres países y una red de cinco mil nodos en ochenta no están igual de descentralizadas, y contar nodos no permite distinguirlas.
No era una afirmación sin medir. El artículo de posición citado más arriba concluía, a partir de mediciones de propagación, que "dada la red superpuesta actual y el intervalo medio de bloque de diez minutos de hoy, el tamaño de bloque no debería superar los 4MB" si se pretende que al menos el noventa por ciento de los nodos siga el ritmo. Cuatro megabytes son cuatro veces el límite que se estaba defendiendo. El mismo artículo es cuidadoso también en el otro sentido, al decir que reajustar los parámetros "debería verse solo como un primer paso" y que los avances mayores exigen "un replanteo básico de los enfoques técnicos". Las dos mitades son reales, y la especificación de segwit2x citó después exactamente ese artículo para sostener que un bloque base de dos megabytes "es considerado seguro por muchos usuarios, empresas, mineros y académicos" (PCS-2017-0002).
Y el punto de procedimiento, que resultó ser el más fuerte. La BIP 109 eligió un umbral de activación del 75 por ciento en vez del 95, y explicó por qué: "para minimizar la posibilidad de que un solo pool de minería grande, o un solo minero, pueda vetar un aumento, ya sea por oposición ideológica o por amenaza de violencia o extorsión." Se piense lo que se piense sobre el tamaño de bloque, esa frase identifica un defecto real en la forma en que Bitcoin cambiaba sus reglas, y quienes ganaron la guerra terminaron escribiendo la misma queja en su propia especificación. Conviene tenerlo presente para el final de este texto.
El argumento contrario se publicó con la misma claridad. La hoja de ruta de capacidad de Greg Maxwell del 7 de diciembre de 2015 descansa sobre un solo compromiso: "Si el sistema es demasiado costoso, la gente se verá forzada a confiar en terceros en lugar de hacer cumplir las reglas del sistema de forma independiente", y "dado que Bitcoin es efectivo electrónico, no es una base de datos genérica" (bitcoin-dev, 7 de diciembre de 2015). Los dos lados reclamaban la descentralización. Discrepaban sobre qué costo la destruye primero.
Tres implementaciones, tres apuestas distintas
Bitcoin XT llegó primero. El 15 de agosto de 2015 Mike Hearn anunció la versión 0.11A en la lista bitcoin-dev, "que incluye el conjunto de parches de bloques más grandes", y dio su razón: "El proyecto Bitcoin Core se ha alejado tanto de los principios que yo y muchos otros consideramos importantes, que un fork es la única forma de arreglar las cosas" (bitcoin-dev, 15 de agosto de 2015). XT llevaba la BIP 101: 8.000.000 de bytes desde enero de 2016, con duplicación cada dos años hasta un techo de 8.192.000.000 de bytes en 2036, activándose cuando 750 de 1.000 bloques consecutivos señalizaran, más un período de gracia de dos semanas.
Bitcoin Classic hizo el pedido más pequeño posible. El responsable de publicación de Classic describió el razonamiento en la nota de cierre del proyecto: "la decisión fue ir por la mejora más pequeña posible, de 1 MB a 2 MB. Evitaría cualquier complicación técnica y bajaría el listón tanto que lógicamente no podíamos bajarlo más. Fue la última y mejor oferta de paz" (Bitcoin Classic, 9 de noviembre de 2017). La especificación correspondiente era la BIP 109 de Gavin Andresen, un paso único a 2.000.000 de bytes acompañado de dos límites nuevos pensados para que el aumento no se convirtiera en una superficie de ataque: operaciones de firma contadas con exactitud y topeadas en 20.000, y un máximo de 1.300.000.000 de bytes procesados con hash para firmas por bloque. El mismo disparador de 750 sobre 1.000, un período de gracia de 28 días y una fecha de vencimiento del 1 de enero de 2018, tras la cual quedaba retirada. Classic siguió otro camino antes de esa fecha, y publicó lo que sus notas llaman una "solución descentralizada de tamaño de bloque" en la versión 1.2.0, a fines de 2016 (noticias de Bitcoin Classic).
Bitcoin Unlimited tomó un camino distinto por completo: sacar el número del programa y dejar que lo fije quien opera el nodo. Su primera propuesta, de Andrew Stone en noviembre de 2015, agregaba una opción para cambiar el tamaño de los bloques que el nodo mina (1.000.000 de bytes por defecto), otra para el bloque más grande que aceptará (16MB por defecto) y una "profundidad de aceptación de bloques excesivos" (4 por defecto), de modo que un bloque sobredimensionado se acepta igual una vez que hay suficientes bloques construidos encima (BUIP001).
Ese tercer diseño merece una pausa, porque es donde los dos lados ya no discutían sobre un número. Bajo BUIP001, la validez depende de la configuración de cada operador y de qué tan enterrado está un bloque, así que dos nodos con el mismo programa y distinta configuración pueden discrepar sobre qué cadena existe, y volver a coincidir unos bloques después. Quienes lo apoyaban decían que era dejar que el límite se descubriera en vez de decretarse. Quienes se oponían decían que era convertir el consenso en una variable. Ambas descripciones son del mismo mecanismo.
Hong Kong, febrero de 2016
El 21 de febrero de 2016 una reunión en Hong Kong produjo una declaración firmada, publicada como Bitcoin Roundtable Consensus. Es breve, y lo que dice importa más que aquello por lo que se la recuerda.
Los firmantes coincidieron en que SegWit "continúa desarrollándose activamente como soft fork y es probable que avance hacia su publicación en los próximos dos meses". Acordaron trabajar en "un hard fork seguro basado en las mejoras de SegWit", y que "los colaboradores de Bitcoin Core presentes en la Bitcoin Roundtable tendrán una implementación de ese hard fork disponible como recomendación para Bitcoin Core dentro de los tres meses siguientes a la publicación de SegWit". Se esperaba que ese hard fork "incluyera" un aumento de los datos que no son testigo "a alrededor de 2 MB, con un tamaño total no mayor a 4 MB", y que "solo se adoptará con amplio respaldo de toda la comunidad de Bitcoin". Por último, los firmantes acordaron "correr únicamente sistemas de consenso compatibles con Bitcoin Core" en el futuro previsible. El cronograma adjunto esperaba SegWit en abril de 2016, el código del hard fork para julio de 2016 y la activación "alrededor de julio de 2017" si había respaldo amplio.
La lista de nombres es la parte interesante. Cinco firmantes aparecen identificados como "Bitcoin Core Contributor": Cory Fields, Johnson Lau, Luke Dashjr, Matt Corallo y Peter Todd. El resto son empresas: AntPool, BitFury, Bitmain, BTCC, F2Pool, Huobi, OKCoin, Ledger, Blockstream, Bitfinex y otras.
Leído al pie de la letra, el documento compromete a cinco personas a escribir y recomendar código, y a un conjunto de empresas a no correr reglas de consenso alternativas. No compromete, ni podría comprometer, al proyecto Bitcoin Core a integrar nada, y condiciona explícitamente la adopción a un respaldo amplio de la comunidad. Si debía leerse al pie de la letra es justamente el asunto de los dieciocho meses siguientes, y los dos lados nunca se pusieron de acuerdo sobre eso. Lo que no está en disputa es el calendario: la versión que traía los parámetros de activación de SegWit, Bitcoin Core 0.13.1, se etiquetó el 27 de octubre de 2016, seis meses después de la fecha de la declaración, y no se adoptó ningún hard fork.
SegWit fue un soft fork, e hizo más que agregar espacio
SegWit traslada los datos de firma a una estructura separada que el identificador de la transacción no cubre, y reemplaza el límite en bytes de los bloques por un límite de peso de 4.000.000 de unidades, donde un byte base cuenta cuatro y un byte de testigo cuenta uno (BIP 141). Los nodos viejos ven bloques que, según su propia contabilidad, siguen por debajo de 1.000.000 de bytes, y eso es lo que lo convierte en un soft fork y no en un hard fork.
Su efecto sobre la capacidad fue moderado y condicional. Las notas de publicación de Bitcoin Core 0.13.1 lo plantean así: "Las estimaciones basadas en las transacciones que hoy se encuentran en los bloques indican que, si todas las billeteras pasan a usar segwit, la red podrá soportar alrededor de un 70% más de transacciones" (notas de publicación, 0.13.1). La hoja de ruta de Maxwell lo había descrito como "un aumento de tamaño de bloque de 4MB en el peor caso" y "un aumento de capacidad de 2x" si se usaba de forma generalizada. Esa condicionalidad era una objeción real: subir un límite duro entrega el espacio cambie o no alguien su billetera, y el de SegWit no.
La parte que importó por más tiempo no fue la capacidad. Las mismas notas afirman que SegWit "resuelve todos los casos conocidos de maleabilidad de transacciones no deseada", es decir que un tercero ya no puede alterar el identificador de una transacción después de firmada. La BIP 141 explica por qué eso justificaba un cambio de consenso: "permite crear cadenas de dependencias de transacciones sin confirmar sin riesgo de contraparte, una funcionalidad importante para protocolos fuera de cadena como la Lightning Network". Abrir un canal de pago implica firmar un reembolso sobre una transacción de financiación que todavía no se confirmó. Si el identificador de esa transacción puede cambiar por debajo, el reembolso queda imposible de gastar. Por eso Lightning necesitaba SegWit, y es el caso más claro de todo el episodio en el que un soft fork compró algo que un aumento de tamaño no podía comprar.
Nueva York, mayo de 2017
Quince meses después de Hong Kong se firmó un segundo acuerdo en la conferencia Consensus de Nueva York. Una copia circuló en la lista bitcoin-dev el 22 de mayo de 2017 de la mano del desarrollador seudónimo shaolinfry. Esa copia dice:
Acordamos apoyar de inmediato las siguientes mejoras paralelas del protocolo bitcoin, que se desplegarán simultáneamente y se basan en la propuesta original Segwit2Mb: activar Segregated Witness con un umbral del 80%, señalizando en el bit 4. Activar un hard fork de 2 MB el 21 de septiembre de 2017.
Nombra nueve empresas que se comprometen a aportar soporte de ingeniería: Bitcoin.com, BitFury, BitGo, Bitmain, BitPay, Blockchain, Bloq, RSK Labs y Xapo.
Los relatos del segundo compromiso difieren, y la diferencia vale la pena registrarla. La copia que circuló fecha el hard fork el 21 de septiembre de 2017. Cuatro días más tarde Tom Zander citaba en la misma lista la versión publicada como "activar un hard fork de 2 MB dentro de seis meses" (bitcoin-dev, 26 de mayo de 2017). La implementación que finalmente se construyó no apuntó a ninguna de las dos fechas, y programó el aumento para el bloque 494.784, en noviembre (anuncio de SegWit2x). La carta del grupo de trabajo fecha el acuerdo mismo el 21 de mayo de 2017 y fijó un calendario: software alfa para el 16 de junio, nodos señalizando desde el 21 de julio, "23 de agosto: SegWit activo en la red" (segwit2x.github.io).
La base técnica era Segwit2Mb, de Lerner, publicada en bitcoin-dev el 31 de marzo de 2017, cuyo objetivo declarado era desarmante por lo modesto: "El único objetivo de esta propuesta es reunificar a la comunidad de Bitcoin y evitar una división de la criptomoneda."
BIP 148, BIP 91 y la quincena en que todo se resolvió
Mientras se negociaban los acuerdos, se estaba planteando otra discusión sobre quién puede disparar un soft fork.
El 25 de febrero de 2017 shaolinfry publicó "Moving towards user activated soft fork activation" en bitcoin-dev, enumerando cuatro problemas de la activación basada en hashrate. Dos de ellos resultaron decisivos: "la señalización de los mineros tiene un veto natural que permite a un pequeño porcentaje de hashrate vetar para todos la activación de la mejora por parte de los nodos" y, más de fondo, "las reglas de los soft forks en realidad siempre las hacen cumplir los nodos, no los mineros" (bitcoin-dev, 25 de febrero de 2017). Es la misma queja que la BIP 109 había hecho sobre el umbral del 95 por ciento, llegando desde la dirección opuesta.
El resultado fue la BIP 148, asignada el 12 de marzo de 2017: desde el 1 de agosto de 2017 hasta el 15 de noviembre, todo bloque debía señalizar el despliegue existente de SegWit, y "los bloques que no señalicen como se requiere serán rechazados". Los nodos que la corrieran aplicarían la regla hicieran lo que hicieran los mineros, y dejarían la cadena si suficientes mineros no cumplían.
La BIP 91, de James Hilliard y asignada el 22 de mayo de 2017, desactivó esa bomba. Ofrecía "una manera de que una mayoría simple de mineros coordine la activación del despliegue existente de segwit con menos del 95% de la potencia de hash": bit 4, un umbral de 269 bloques dentro de una ventana de 336, es decir el 80 por ciento, a partir del 1 de junio de 2017. Conviene notar qué era en términos mecánicos. La BIP 91 también rechazaba los bloques que no señalizaran, así que era un soft fork de señalización obligatoria exactamente del tipo que proponía la BIP 148, con los mineros y no el calendario apretando el gatillo. Su umbral y su bit de versión son los parámetros de Nueva York, y la especificación de segwit2x describe su propio despliegue como "una BIP91 modificada" con la señal renombrada.
SegWit quedó entonces bloqueada según el calendario que define la BIP 9. El período de reajuste que empieza en el bloque 479.808, minado el 9 de agosto de 2017, fue el primero en estado LOCKED_IN, y las reglas nuevas entraron en vigor un período más tarde, en el bloque 481.824, minado a las 01:57 UTC del 24 de agosto de 2017 (mempool.space). La página de anuncio del propio grupo de trabajo de segwit2x, escrita de antemano, esperaba la activación "alrededor del 23 de agosto de 2017 (altura de bloque 481.824)".
Las cadenas que se fueron
El 1 de agosto de 2017, tres semanas antes de que SegWit entrara en vigor, se separó el hard fork que se convirtió en Bitcoin Cash. Su especificación fijaba una hora de activación por defecto a las 12:20 UTC de ese día, exigía que los clientes estuvieran configurados para aceptar bloques de al menos 8.000.000 de bytes y exigía que el primer bloque posterior al fork superara 1.000.000 de bytes, para que la cadena nueva nunca pudiera reorganizarse de vuelta dentro de la vieja (especificación técnica UAHF, versión 1.6, 24 de julio de 2017). También impuso protección de replay a nivel de consenso, exigiendo una bandera nueva en el tipo de hash y un algoritmo de firma modificado, para que una firma válida en una cadena no verificara en la otra. Una versión anterior había ofrecido en cambio un marcador para excluirse: una transacción compuesta por un único OP_RETURN que llevara la cadena de 46 caracteres "Bitcoin: A Peer-to-Peer Electronic Cash System" sería rechazada en la cadena nueva. La disputa era sobre el subtítulo del whitepaper, y durante unas semanas el subtítulo fue, literalmente, la salida de emergencia.
SegWit2x no llegó tan lejos. El 8 de noviembre de 2017 un correo a la lista de segwit2x, firmado por Mike Belshe de BitGo junto con Wences Casares de Xapo, Jihan Wu de Bitmain, Jeff Garzik de Bloq, Peter Smith de Blockchain y Erik Voorhees de ShapeShift, lo suspendió: "Aunque creemos firmemente en la necesidad de un tamaño de bloque mayor, hay algo que consideramos aún más importante: mantener unida a la comunidad. Lamentablemente, está claro que no hemos construido suficiente consenso para una mejora limpia del tamaño de bloque en este momento" (Bitcoin Magazine, 10 de noviembre de 2017). El bloque 494.784 se minó el 17 de noviembre de 2017 bajo las reglas existentes, como cualquier otro bloque.
Bitcoin Classic anunció su propio cierre al día siguiente.
Qué dejó resuelto
No dejó resuelto que los bloques grandes estén mal. Nada en el desenlace refuta el argumento de la BIP 101 sobre las jurisdicciones, ni el de la BIP 109 sobre el costo de un umbral del 95 por ciento, ni la medición que mostraba que cuatro megabytes estaban al alcance de la red de esa época. Esos argumentos no fueron derrotados. Quedaron sin adoptar, que es otra cosa, y decirlo no es una concesión.
Lo que sí dejó resuelto es una cuestión de método, y la respuesta tiene cuatro partes.
Un acuerdo no es un mecanismo. Hong Kong y Nueva York fueron firmados por partes que controlaban porciones enormes de la minería y del comercio, y ninguno cambió una regla de consenso. Las reglas cambian cuando los nodos aplican código distinto. Ninguna cantidad de firmas sustituye ese paso, y a ambos documentos los pasó por encima un mecanismo: a uno un calendario de publicación, al otro la BIP 91.
Señalizar es estar listo, no consentir. El bit de versión dice que un minero está preparado para aplicar una regla. Nunca dijo si la regla se quería, y tratarlo como una papeleta convirtió a una pequeña minoría de hashrate en un veto. Ese defecto era real, los dos lados lo nombraron y terminó corrigiéndose del lado de los soft forks: la BIP 8 bajó el umbral sugerido al 90 por ciento y agregó una bandera de bloqueo al vencimiento, recomendándola "para cualquier softfork del que se espere, o del que se compruebe, que tiene oposición política por parte de un porcentaje no despreciable de mineros" (BIP 8). Taproot se activó después con un 90 por ciento y sin incidentes.
La asimetría no es un juicio de valor. Un soft fork arrastra consigo a los nodos sin actualizar; un hard fork no, así que un relajamiento necesita a todos y un endurecimiento no. Eso es una propiedad de las reglas, no un veredicto sobre qué cambio merecía ganar, y significó que el lado que proponía aflojar el límite siempre enfrentó el despliegue más difícil. Quien lea esto como una reivindicación debería notar que habría aplicado igual a una propuesta de su agrado.
Quienes corren nodos tienen la última palabra, y eso sale caro. La lección que todos sacaron de agosto de 2017 es que los mineros no podían activar SegWit por su cuenta ni tampoco impedirlo. La parte que suele omitirse es lo que costó: dos años de discusión, varias implementaciones bifurcadas, dos acuerdos firmados que no cambiaron ninguna regla, y una resolución que llegó por una fecha límite fijada por un desarrollador seudónimo. Funcionó. No fue barato, y nada garantiza que funcione una segunda vez.
La cadena que la mayoría llama Bitcoin sigue con un límite de bloque base de un megabyte. Si este método puede decidir algo más difícil que eso tampoco es una cuestión zanjada: una propuesta de soft fork llegó a su ventana de señalización obligatoria en agosto de 2026 y se separó en su propia cadena, que es la misma discusión con el signo cambiado. Si los forks son territorio nuevo, la mecánica está aquí.