Bitcoinjs-lib 7.0.0: adiós a las funciones obsoletas y llega el soporte para 20 claves en multisig

La librería JavaScript para bitcoin, clave en miles de monederos y aplicaciones, elimina validaciones heredadas y estrena un sistema más moderno. Los contratos multifirma ahora pueden usar hasta 20 claves, lo que abre la puerta a esquemas de seguridad más complejos.

Bitcoinjs-lib 7.0.0 ya está aquí y trae cambios de fondo. La librería JavaScript más veterana para crear transacciones de bitcoin dice adiós a su validador de datos interno y estrena uno más moderno, pensado para facilitar la auditoría del código. Además, los contratos multifirma ganan músculo: ahora aceptan hasta 20 claves diferentes. Un salto discreto pero relevante para decenas de miles de desarrolladores.

El cambio más visible es la sustitución de typeforce por valibot. El antiguo sistema de validación de tipos, que llevaba años en el núcleo del proyecto, desaparece junto con funciones exportadas como Buffer256bit, Hash160bit o UInt8. En su lugar, valibot ofrece esquemas reutilizables (Buffer256bitSchema, Hash160bitSchema, etc.) que mantienen la misma seguridad pero con una arquitectura más mantenible. Para quien se limitaba a usar la librería sin hurgar en sus tripas, el cambio pasa casi desapercibido. Para los mantenedores de proyectos complejos, menos dependencias obsoletas y validación más estricta sin perder compatibilidad.

Publicidad

La otra novedad importante amplía el horizonte de la multifirma. Hasta ahora, bitcoinjs-lib establecía un techo de 15 claves por contrato. Con la versión 7, ese límite sube a 20. Puede sonar a detalle técnico, pero en la práctica abre la puerta a configuraciones de seguridad más finas: tesorerías empresariales que quieran repartir el control entre más departamentos, organizaciones autónomas descentralizadas (DAO) con decenas de miembros firmantes, o carteras que exijan múltiples aprobaciones para movimientos grandes. Más claves, más flexibilidad.

La librería, que se descarga millones de veces al mes desde npm, es el motor oculto de carteras web, herramientas de firma offline e incluso soluciones institucionales. Actualizarla no es un capricho cosmético. Implica revisar dependencias y garantizar que los cambios no rompan nada. El equipo de desarrollo ha lanzado la versión como release candidate (rc.0), lo que significa que aún está en fase de pruebas antes del lanzamiento definitivo. La comunidad ya puede probarla y reportar cualquier contratiempo.

Además de limpiar código heredado, la actualización beneficia especialmente al manejo de PSBT (Partially Signed Bitcoin Transactions, las transacciones parcialmente firmadas que usan carteras hardware y multifirma) y a las funciones vinculadas a taproot. Ambos componentes han quedado más ligeros y fáciles de auditar. El equipo ha preferido eliminar antes que acumular parches: una decisión que, aunque aumente el esfuerzo de migración, reduce la superficie de ataque a largo plazo.

Adiós a lo viejo sin romper lo que funciona: la lección de este salto de versión es que se puede modernizar sin despeinar el código de producción.

Qué cambia exactamente en bitcoinjs-lib 7.0.0

El registro de cambios es quirúrgico. Se han eliminado todas las reexportaciones de typeforce (Buffer256bit, Hash160bit, Hash256bit, Number, Array, Boolean, String, Buffer, Hex, UInt8, UInt32, BufferN, Null, oneOf, maybe, tuple, Function y Satoshi). En su lugar, los desarrolladores encontrarán esquemas de valibot con nombres como Buffer256bitSchema o Hash160bitSchema. La migración suele resolverse con un buscar y reemplazar, pero conviene revisar los nuevos tipos porque la validación ahora es más precisa.

Las funciones de PSBT y taproot se han adaptado a estos cambios. Ninguna prestación esencial se pierde. De hecho, el soporte para multifirma con hasta 20 claves llega de serie en los métodos de creación de transacciones y en las firmas parciales, sin necesidad de parchear nada. Los detalles de la implementación están en el historial de confirmaciones del repositorio oficial.

Por qué le importa a un desarrollador que trabaje con bitcoin

Bitcoinjs-lib es una de las pocas librerías JavaScript preparadas para interactuar con la red bitcoin sin depender de un nodo completo. Cualquier billetera web, desde las más artesanales hasta plataformas de intercambio, puede usar sus funciones. Por eso, un cambio en las validaciones internas no es algo menor. Si una aplicación importaba directamente Hash160bit o Buffer256bit desde la librería, al actualizar a la versión 7 el código se romperá. La buena noticia es que la comunidad ya está publicando guías de migración.

Pensemos en una analogía. Cambiar typeforce por valibot es como sustituir el motor de un coche sin tocar el volante: el vehículo sigue siendo el mismo y el viaje, más fiable, pero el mecánico tiene que reaprender algunas piezas. Los desarrolladores que hagan la actualización ganarán una librería más saneada y con mejor tipado, lo que se traduce en menos errores silenciosos en producción.

Análisis: un paso adelante muy medido

Esta actualización encaja en un patrón que lleva años viéndose en el ecosistema Bitcoin: deshacerse de dependencias antiguas en lugar de mantenerlas con parches. Typeforce fue una solución brillante en 2014, pero el propio JavaScript ha madurado y ya existen alternativas más mantenibles como valibot. Al abrazar esa modernización, bitcoinjs-lib reduce su superficie de ataque y facilita que nuevos colaboradores entiendan el código sin tener que dominar herramientas olvidadas.

El aumento de 15 a 20 claves en multifirma, aunque parezca un gesto menor, refleja una demanda real. La custodia de fondos en entornos empresariales y las DAO requieren esquemas con más participantes para evitar puntos únicos de fallo. Veinte claves no es magia, pero sí un paso más hacia configuraciones robustas que antes exigían ensamblajes artesanales sobre la librería.

Eso sí, el camino no está exento de riesgos. Cualquier cambio que obligue a tocar código de producción en cientos de proyectos puede provocar errores si la migración se hace con prisas. Lo prudente, mientras la versión siga en fase rc.0, es probar en entornos de testnet y compartir los resultados con el equipo de desarrollo. La historia reciente enseña que los saltos de versión en infraestructuras críticas se agradecen cuando son discretos y vienen acompañados de buena documentación. Esta vez, los mimbres están puestos.


Publicidad