Luke-Jr, un desarrollador de protocolos de bitcoin y contratista de Blockstream, ha argumentado durante los últimos años que bitcoin no solo debería abstenerse de agregar capacidad de datos al aumentar el tamaño de bloque de 1 MB, sino que debería reducirlo a 250 kilobytes por bloque.
Antes de unirse a Blockstream, sin embargo, argumentó que el tamaño del bloque debería adaptarse dinámicamente, con Gregory Maxwell, el ex CTO de Blockstream y un ex desarrollador de protocolo de bitcoin, encerrándolo.
En una discusión pública poco conocida donde Gavin Andresen, el ex mantenedor de Bitcoin Github, propuso una bifurcación dividida en cadena para múltiples firmas desde el 24 de agosto de 2011, Luke-jr dice:
“Si se deliver una división de la cadena de bloques, tiene sentido intente solucionar tantos problemas
como sea posible:
Reemplace los límites duros (como un tamaño de bloque máximo de 1 MB) con algo que pueda adaptarse dinámicamente con los tiempos. ¿Tal vez basado en la dificultad para que no se pueda jugar?
Ajuste la dificultad cada bloque, sin límites, en función de una ventana deslizante de bloque N …
21 millones realmente no son suficientes si Bitcoin alguna vez despega, incluso con 100,000,000 unidades por BTC. Reemplazando los enteros de 64 bits 'Satoshi' con fracciones de tamaño variable 'Satoshi' … ”
El mismo día, al reemplazar el límite duro, Gregory Maxwell simplemente dice“ demasiado pronto para eso ”, con Luke-jr respondiendo: [19659002] “La adaptación dinámica sería por diseño, nunca demasiado temprano / tarde. Cambiar de un 1 MB fijo bifurcará la cadena de bloques, lo que debería ser un evento minimizado ”.
Cuando comenzó el debate del tamaño de bloque, Pieter Wuille, un desarrollador de protocolo de bitcoin, propuso esta configuración dinámica del tamaño de bloque en 2014-15. Empleado de Blockstream.
Sin embargo, en 2011, Maxwell ya estaba argumentando en contra de cualquier aumento, ampliando el “demasiado pronto” al afirmar:
“No estamos en el tamaño máximo en este momento (afortunadamente). No sabemos cómo se vería la dinámica de la purple en ese nivel de tráfico. Entonces, ¿cómo podríamos decir de manera competente cuáles serían las métricas correctas para obtener el comportamiento correcto allí? Eso es lo que quise decir con demasiado pronto “.
No está claro por qué estaba agradecido de que la pink no se estuviera ejecutando a plena capacidad porque unos años más tarde abrió la campaña para celebrar tarifas muy altas causadas por esta falta de capacidad.
Sin embargo, esta thought de hardfork se archivó después de que la discusión se ramificó en muchos asuntos y Gavin Andresen declaró:
“Esta discusión me convence de que programar una división de blockchain es definitivamente la notion incorrecta en este momento. Podemos volver a visitarlo en N meses, cuando tengamos una hoja de ruta y buenas pruebas unitarias y un montón de parches bien probados para arreglar todas las cosas que hay que arreglar cuando decidamos que una división de blockchain es necesaria ”. [19659002] Llamarlo una división de blockchain es una forma de decirlo, pero a medida que sucedió, la capacidad se incrementó ligeramente a través de una bifurcación suave.
No se agregó ningún mecanismo adaptable dinámicamente a este cambio de bifurcación suave, por lo que la crimson ahora tiene que esperar el comité de desarrollo en algún momento dirá que se debe aumentar el peso del tamaño de bloque.
Si alguna vez esperamos que este comunicado no sea claro, con Bitcoin ahora está bastante estancado cuando se trata de escalabilidad, incluso cuando otras cadenas de bloques intentan abordarlo.