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.