Los cambios de consenso y P2P en los que se basa segwit afectan a 1486 líneas de código, más otras 3338 de pruebas. Los ensayos fueron de la versión de Pieter Wuille en la sidechain Elements, en 2015, pasando por segnet, a la testnet normal de Bitcoin en mayo de 2016. Las firmas Schnorr y MAST figuran como mejoras posteriores que segwit facilitaría.
Los mineros tienen hasta el bloque 419328 para actuar: el soft fork CSV quedó en lock-in en el bloque 417312 después de que 1946 de 2016 bloques (96,53 %) señalizaran BIP68, BIP112 y BIP113. Todos los nodos de minería y de respaldo deben usar Bitcoin Core o Knots 0.12.1, y quien tenga fijada en el código la versión de bloque debe desactivar el bit 0.
BIP9 permite a los mineros señalizar que están listos para hasta 29 soft forks simultáneos mediante bits en la cabecera del bloque. Una propuesta entra en lock-in cuando el 95 % de los bloques de una ventana de 2016 la señaliza y se activa un reajuste después, o bien fracasa al agotarse su plazo. A diferencia de IsSuperMajority, no deja huérfano un bloque que no señaliza pero cumple las nuevas reglas.
Los pares que usan la retransmisión de bloques compactos (BIP152) intercambian un esbozo de cada bloque nuevo, de unos 9 KB para un bloque medio de 1 MB, más la sobrecarga de las transacciones que le falten al receptor. En experimentos reales en modo de alto ancho de banda con hasta 6 transacciones prerrellenadas, bastante más del 90 % de los bloques se propagó sin ninguna petición adicional.
La señalización del soft fork CSV arranca a medianoche del 1 de mayo de 2016 con Bitcoin Core 0.12.1, el primer despliegue mediante version bits de BIP9. Abarca BIP68, BIP112 y BIP113; OP_CHECKSEQUENCEVERIFY permite congelar monedas durante un tiempo determinado tras la confirmación, algo de lo que dependerá Lightning Network. El sistema de alertas P2P pasa a estar desactivado por defecto.
Marco Falke es el nuevo mantenedor de Testing & QA de Bitcoin Core, según ha anunciado Wladimir van der Laan. Se encargará de fusionar los pull requests del framework de pruebas, un paso natural tras un año dedicado a pruebas unitarias, cobertura y revisión del trabajo de otros colaboradores.
Los fallos de seguridad y las nuevas versiones ya tienen su propia lista de anuncios de Bitcoin Core, de suscripción voluntaria y solo para anuncios. Los usuarios habían pedido una forma de recibir únicamente los avisos críticos, y el proyecto prevé muy poco volumen.
La solución de un sudoku de 16x16 se vendió por 0,10 BTC en el primer Zero-Knowledge Contingent Payment con éxito sobre Bitcoin, demostrado en directo en Financial Cryptography 2016, en Barbados. Sean Bowe, del equipo de Zcash, fue el vendedor y se encargó de casi toda la ingeniería. Con este protocolo, los datos solo cambian de manos si se paga, sin ningún tercero que arbitre.
OpenSSL sale de la verificación de firmas en Bitcoin Core 0.12.0, sustituido por libsecp256k1, que reduce a menos de la mitad el tiempo de reindexar y de validar bloques nuevos. Las mempools tienen un tope predeterminado de 300 MB, lo que cierra una vía por la que un atacante podía tumbar nodos con poca RAM. También son nuevos Replace-by-Fee opt-in (BIP 125) y -maxuploadtarget, para limitar el tráfico de subida.
Bitcoin Core aclara que el sitio que alojó por primera vez el artículo de Bitcoin no está afiliado al proyecto, que tiene su propia web oficial. El desarrollo se lleva a cabo en IRC, GitHub y la lista de correo bitcoin-dev. El proyecto no se responsabiliza de otros foros y pide a los miembros de la comunidad que no organicen ataques en grupo ni de denegación de servicio.
La maleabilidad por parte de terceros se acaba en las transacciones cuyas entradas son todas gastos segwit, porque las firmas pasan a un witness que ya no interviene en el txid. Ganan con ello tanto los autores de monederos como Lightning Network. El hash de firmas se vuelve además lineal, con cada byte procesado como máximo dos veces; con el esquema anterior, validar un solo bloque ha llegado a llevar 25 segundos.
Los desarrolladores ya pueden probar Segregated Witness en su propia red compilando la rama segwit y añadiendo -segnet a bitcoind y bitcoin-cli. Ledger, Trezor, Electrum y Bitgo han anunciado que darán soporte a segwit, mientras que mSIGNA y Green Address ofrecen versiones preliminares.
Un vídeo recorre la actividad de commits de 2015 en el repositorio de Bitcoin Core, un año con 2 versiones principales, 5 de mantenimiento y dos soft forks activados: BIP66 y BIP65, este último con CHECKLOCKTIMEVERIFY. El proyecto recuerda que revisores, probadores y traductores no aparecen en los datos de commits.
Las reglas de consenso no las decide el equipo de Bitcoin Core, afirman sus colaboradores: las deciden los usuarios al elegir qué software ejecutan, y por eso no incluye actualización automática. Prefieren los soft forks, reservan los hard forks para casos poco frecuentes con un acuerdo casi universal y ven en capas adicionales sobre el protocolo la vía hacia una escala extremadamente alta.
Los bloques con el nuevo límite de coste de segwit pueden rozar los 4 MB, pero los cálculos de Anthony Towns sitúan un bloque de transacciones P2PKH de una sola firma cerca de 1,6 MB y uno de multifirma 2 de 2 cerca de 2,0 MB. El calendario provisional de las FAQ prevé el despliegue de segwit en 0.13.1 en octubre de 2016, seguido en 2017 de weak blocks, IBLT o Lightning.
Un total de 57 personas, entre ellas Pieter Wuille, Gregory Maxwell y Wladimir J. van der Laan, firman la hoja de ruta de capacidad y la consideran la mejor continuación de su trabajo de escalabilidad dentro de Bitcoin Core. La lista sigue abierta a más firmas.
La hoja de ruta de Gregory Maxwell, enviada a la lista de correo bitcoin-dev al terminar Scaling Bitcoin Hong Kong, se apoya en libsecp256k1, los versionbits de BIP9 y Segregated Witness de Pieter Wuille. Maxwell indica que ConnectTip va 7 veces más rápido en 0.12 y describe segwit como un soft fork que saca las firmas del límite actual de tamaño de bloque, lo que equivale en el peor caso a un aumento de 4 MB.
Colaboradores técnicos como Wladimir J. van der Laan y Pieter Wuille firman una carta en la que piden a la comunidad que no prejuzgue las propuestas de escalado. Remiten en cambio al proceso de consenso y a dos talleres abiertos de Scaling Bitcoin: Montreal, los días 12 y 13 de septiembre, y Hong Kong, los días 6 y 7 de diciembre.