Gavin Andresen, en representación del grupo de desarrolladores de Bitcoin Classic, ha anunciado el lanzamiento de la versión 0.12.0 de su protocolo.
El anuncio se realizó a través del repositorio en GitHub de Andresen. La primera versión candidata fue lanzada hace 5 días en el mismo repositorio. Ambas versiones están basadas en la versión 0.12.0 de Bitcoin Core, la cual fue publicada hace pocas semanas, y son compatibles con los archivos de la blockchain y carteras. Sin embargo, la primera versión no estaba destinada a la minería sino a recibir las opiniones por parte de la comunidad.
Los cambios más notables que ofrece la versión 0.12.0 de Bitcoin Core, incluyen el reemplazo del protocolo OpenSSL por libsecp256k para la firma de transacciones, la compatibilidad con Tor, modificación en las políticas de comisiones por transacción y la nueva característica de transacciones reemplazables.
Tras recibir un amplio apoyo por parte de la comunidad Bitcoin en el subreddit btc, Bitcoin Classic lanzó su nueva versión destinada a la minería. Lo que diferencia esta versión de Classic de la de Core, son básicamente tres aspectos: el opt-in RBF está deshabilitado por defecto; el comando RPC “getblockchaininfo” muestra un status de 2MB; por último, la característica de Core de ofuscación del estado de la cadena (chainstate obfuscation) se apoya, pero no está habilitada.
Opt-in RBF
El Opt-in RBF (Replace-by-Fee) es una función que permite a las transacciones ser marcadas como reemplazables hasta que sean confirmadas en un bloque, pagando una tasa mayor por la confirmación de la transacción. El reemplazo de transacciones fue introducido por Satoshi en el primer lanzamiento del software de Bitcoin, pero luego fue removido por problemas de denegación de servicios.
Core agregó la opción de reemplazo si se paga una tasa más alta por la confirmación. No obstante, esta función fue criticada por un amplio número de miembros de la comunidad porque le restaba a Bitcoin su cualidad de inmutabilidad de transacciones. Por esta razón, y para mantener la compatibilidad con Bitcoin Core por los momentos, Bitcoin Classic tan solo deshabilita por defecto esta característica de su nueva versión, la cual puede ser habilitada manualmente sí se desea. Sin embargo, anuncian que para la próxima versión, esta característica será completamente removida.
Comando RPC muestra 2MB
Con esta actualización, se aplica el esperado aumento del tamaño de los bloques a 2MB, a través de la implementación del BIP 109. Este BIP supone que se aumente el límite de MAX_SIGOPS a 20.000 operaciónes firmadas por bloque, pero solo serán contadas verificaciones ECDSA para validar los bloques.
Además, agrega un nuevo límite de 1.300.000.000 bytes procesados para computar las firmas de las transacciones por bloque. Para activar este BIP se necesita el apoyo del 75% del poder de hash, seguido por un período de gracia de 28 días. La fecha de expiración de este BIP es el 1ero de enero de 2018.
Chainstate Obfuscation
Esta característica fue introducida por el equipo de Bitcoin Core para corregir un error que se presentaba para los usuarios de Windows. Al parecer, la copia de la data de los nodos completos individuales en dicho sistema operativo era detectada como una amenaza por los programas anti-virus.
La solución de Core fue que se guardara parte de la data de los nodos (la llave a su lado) en un blockchain encriptado en el disco. Sin embargo, según establece el usuario de Reddit, ThomasZander, esto todavía creaba incompatibilidad, pues los clientes más antiguos ya no podrían leer la data, creando un sistema cerrado muy costoso de cambiar.
A pesar de ser una solución exclusiva para usuarios de Windows, en la versión de Core, la función está habilitada para usuarios de Linux y otros sistemas operativos sin agregar ningún beneficio extra. Es por esto que Classic en esta versión lo apoya pero lo deshabilita.
Sigue la hoja de ruta
Con esta actualización se finaliza la parte de desarrollo de la primera fase establecida en la hoja de ruta de Bitcoin Classic. Para que el aumento del tamaño de los bloques tenga lugar, el cliente Classic debe minar 750 de los últimos 1.000 bloques de la red. Tras esto, el énfasis pasaría a temas como la reducción de los tiempos de propagación de los bloques sobre las tasas de bloques huérfanos y optimizaciones para los nodos con ancho de banda limitado a través de mejoras en la capa P2P.
En esta última versión lanzada, trabajaron en el equipo de desarrollo Gavin Andresen, Jeff Garzik, Pedro Pinheiro, Tom Zander y Jon Rumion; en el equipo de minería, Marshall Long; como facilitador estuvo Olivier Janssens; como consultores externos, Jonathan Toomim y Peter Rizun. Classic seguirá los pasos establecidos en su mapa de ruta, buscando obtener un apoyo amplio de la comunidad para darle pronta respuesta a los problemas relacionados a la escalabilidad.
Luego de haber concretado la Fase 2 con empresas y mineros, así como haber resulto sus dudas sobre el aumento del tamaño de los bloques, se pasará a la fase 3, en la que se buscará implementar una variación de la propuesta Stephen Pair/BitPay, la cual demanda que el costo de la validación de un bloque debe ser inferior a un pequeño múltiplo del costo promedio del último período de adaptación de la dificultad. Además de ello, se desarrollará una versión simplificada del Segregated Witness de Bitcoin Core, una vez que la versión completa esté disponible.
