Tamaño del bloque: argumentos a favor y en contra de BIP101 y BIP100

El tamaño de los bloques de transacciones no va a quedar arbitrariamente restringido por mucho tiempo más. Lo único que resta definir es exactamente cuándo y exactamente cómo será incrementado el actual límite de 1 MB.

Hay dos propuestas que hoy parecen tener chances de ser aceptadas por la mayoría económica en el transcurso de 2016: BIP 101 y BIP 100. Veamos algunos argumentos en contra de cada una de estas propuestas, y sus correspondientes contraargumentos.

tamaño-bloque-argumentos-bip101-bip100

Fuente: r/bitcoinxt

BIP 101: Activará un tamaño máximo de 8MB por bloque cuando el 75% de los últimos 1000 bloques hayan sido encontrados con un cliente BIP 101 –aunque no antes del 11 de enero de 2016–, y otorga un período de gracia de 2 semanas a los nodos que no hayan incorporado BIP 101 para que lo hagan. El tamaño máximo del bloque se duplica cada 2 años hasta llegar a 8GB.

Argumentos en contra:

• ¡8MB / 8GB es demasiado! Las mejoras en el hardware y el ancho de banda no van a acompañar un programa de aumentos tan agresivo. Los nodos quedarán en manos de cada vez menos entidades, puesto que los dispositivos con hardware antiguo y escaso ancho de banda no podrán mantenerse al día con la cadena de bloques.

Contraargumento: No hay ninguna evidencia de que aumentar de esa manera la capacidad vaya a producir esos resultados –sólo simulaciones basadas en suposiciones arbitrarias–. De todas formas, seguirá siendo posible introducir un soft-fork para establecer un tamaño máximo del bloque más bajo en caso de que surjan problemas. Si surgen problemas con un límite demasiado bajo, en cambio, volveríamos a tener que pasar por un hard-fork. Los soft-forks son mucho más fáciles de llevar a cabo que los hard-forks.

• Los grandes mineros podrán crear bloques artificialmente grandes y forzar a los mineros pequeños, con menor ancho de banda, a descargarlos, y así la tasa de bloques huérfanos de estos últimos aumentaría hasta el punto de hacer inviable su actividad, con lo cual la minería tendería a centralizarse.

Contraargumento: Los grandes bloques son más difíciles de propagar a través de la red. Incluso con alta velocidad de carga, los mineros están limitados por la velocidad de propagación de la red. Los mineros pequeños pueden establecer un límite personal para el tamaño de los bloques creados por ellos, para que estos bloques se propaguen incluso más rápido que los grandes aún cuando utilicen un ancho de banda inferior al de los grandes mineros. Además, existe la minería SPV: los pequeños mineros pueden descargar sólo los encabezados del bloque más reciente y empezar a trabajar a partir de este inmediatamente, incluso antes de que termine la descarga y la verificación del mismo.

• Un umbral del 75% es demasiado bajo y / o 2 semanas no es un período de gracia suficiente.

Contraargumento: Si el umbral es muy superior al 75%, un único pool minero podría vetar el cambio. El umbral no llegará por sorpresa; lo veremos llegar de muy lejos, así que habrá mucho tiempo para actualizar los nodos, no sólo 2 semanas.

• Bloques tan grandes van a destruir cualquier mercado de tarifas de transacción; las tarifas serán minúsculas, abundará el spam, y los mineros no tendrá ningún incentivo extra proveniente de las tarifas.

Contraargumento: Los mineros ya están configurados para ignorar las transacciones por debajo de un mínimo y para dar prioridad a las transacciones con más altas tarifas. Ya tenemos un precedente de «máximo tamaño del bloque demasiado grande» durante los primeros 5 años de Bitcoin, que nunca ha sido un problema.


BIP 100: Permite que los mineros voten en la cadena de bloques cada 3 meses para expresar el tamaño máximo del bloque que prefieren. Descarta el 20% superior y el 20% inferior y elige el límite más bajo del resto de los votos como el tamaño máximo del bloque, que puede aumentar o disminuir no más de un 50% en cada ocasión.

Argumentos en contra:

• Si un minero tiene el 21% del poder de cómputo, puede atacar la red disminuyendo el tamaño máximo del bloque en un 50% cada 3 meses hasta dejar a Bitcoin inutilizable.

Contraargumento: Es mucho más fácil y barato para una entidad maliciosa llenar de spam la red con milones de transacciones con altas tarifas, que controlar el 21% del poder de cómputo.

• Los mineros ya pueden establecer su propio límite al tamaño de los bloques que generan. Si un determinado minero no quiere o no puede minar bloques muy grandes con BIP 101, no tiene que hacerlo; es un simple cambio de configuración.

Contraargumento: Minar bloques más pequeños implica perder una parte del total de tarifas que podrían cobrarse minando bloques de mayor tamaño, lo que significa un fuerte incentivo para tener más ancho de banda, y esto tenderá a aumentar con cada halving (disminución a la mitad de la recompensa por bloque hallado).

• Pone demasiado control en manos de los mineros.

Contraargumento: Si los mineros quisieran arruinar a Bitcoin podrían hacerlo, con o sin BIP 100.

• Los mineros por lo general se quedan con la configuración predeterminada (que es 1 MB en BIP 100); nada garantiza que estén siempre dispuestos a votar por algún cambio.

Contraargumento: Ya ha habido una importante demostración de apoyo por medio de votos en la cadena de bloques durante este debate.

• El código aún no se ha escrito; no podemos revisar adecuadamente la propuesta.

Contraargumento: La propuesta es bastante fácil de traducir a código.

Leer texto original, en inglés

Imagen por Chris Potter