BIP significa Bitcoin Improvement Proposal. Es un documento que describe una solución técnica, un procedimiento o información importante sobre Bitcoin. Permite estudiar, cuestionar y quizá utilizar la propuesta; publicarla no modifica automáticamente el software ni las reglas de la red.
Anna prepara un pago en el ordenador, pero quiere firmarlo con un monedero físico de otro fabricante. Ambos programas deben entender los datos que intercambian. BIP 174 aborda precisamente ese problema: describe PSBT, un formato común para transmitir una transacción aún sin completar y la información necesaria para firmarla. Los desarrolladores pueden seguir el mismo documento en vez de inventar por separado formatos incompatibles. Ese es uno de los motivos prácticos por los que existen los BIP. [8]
Cada número puede corresponder a una tarea distinta. BIP39 describe cómo generar palabras de recuperación y convertirlas en una seed, los datos iniciales para derivar las claves del monedero. BIP 141 describe SegWit, un cambio en las reglas de las transacciones que entró en vigor mediante su activación en la red. BIP 174 ayuda a intercambiar transacciones para firmarlas sin cambiar la validez de los bloques. BIP 50 recoge las causas y la solución del incidente de marzo de 2013 que dividió temporalmente la red. No todos los BIP proponen una nueva regla de Bitcoin. [6] [7] [8] [9]
Describir una solución, programarla y utilizarla son pasos diferentes. La descripción es la especificación; el código, la implementación. Un monedero puede experimentar con un borrador, mientras otro documento quizá no tenga ningún programa en uso. Los cambios en las reglas de validez de los bloques requieren además una activación: el momento en que el software correspondiente empieza a exigirlas. Publicar el documento no actualiza automáticamente tu nodo, el ordenador que comprueba las reglas de la red. [7] [10]
El número sirve sobre todo para encontrar el documento correcto y participar en la misma discusión. Un número mayor no significa una propuesta mejor ni una actualización recomendada. Incluso un documento numerado puede quedar sin terminar o abandonarse. Si un servicio anuncia que admite un BIP, aún necesitas saber a qué función se refiere y si su versión concreta realmente la ofrece. [2]
Los autores estudian primero trabajos anteriores y debaten la idea en Bitcoin Development Mailing List, una conversación pública por correo entre desarrolladores. Los comentarios pueden detectar problemas antes de escribir un documento largo. Una propuesta suficientemente elaborada se presenta al repositorio compartido bitcoin/bips en GitHub mediante un pull request, una solicitud de incorporación. Los autores no eligen el número: lo asigna un editor tras revisar el tema, el formato y la madurez del texto. [1]
Los BIP Editors cuidan los documentos publicados: revisan la discusión previa, la claridad, el formato y la licencia, asignan números y mantienen los registros. Eso no les permite decidir qué software debes usar ni qué reglas debe aceptar tu nodo. Aparecer en el repositorio no garantiza seguridad ni acuerdo de la comunidad. El uso real depende de cada proyecto y de los participantes de la red. [1]
Si lees que se ha aprobado un nuevo BIP, abre el documento y comprueba qué ha ocurrido. ¿Solo recibió un número, sus autores terminaron el trabajo o ya hay soporte en uso? Para una función del monedero, busca pruebas en su documentación y versiones publicadas; para cambios de reglas, revisa también las condiciones y el desarrollo de la activación. Así distingues una propuesta interesante de una función que ya puedes utilizar. [10] [2]
El procedimiento actual figura en BIP 3, Updated BIP Process, con estado Deployed. Sustituyó a BIP 2 y simplificó tipos y estados. Por eso los artículos antiguos pueden mencionar Standards Track o Final, etiquetas que no coinciden con la clasificación actual. Consulta el archivo vigente y su historial en el repositorio. Este publica y conserva propuestas; no es un sistema de votación sobre el futuro de Bitcoin. [1] [5]
Specification describe reglas técnicas con las que pueden crearse programas compatibles entre sí. Antes de completarse exige una implementación de referencia funcional, es decir, un programa que muestra cómo llevar el diseño a la práctica, y vectores de prueba: entradas de ejemplo con resultados esperados. Informational aporta información, análisis o recomendaciones. Process regula una forma de trabajar, como la publicación de los propios BIP. BIP 3 pertenece a este último grupo; no define un nuevo formato de transacción de Bitcoin. [1]
Draft es un borrador en desarrollo. Complete indica que los autores terminaron el trabajo previsto y recomiendan adoptarlo. Deployed señala un uso activo demostrado; en Process puede reflejar el rough consensus exigido, un acuerdo amplio tras debatir y resolver objeciones fundamentadas, no un simple recuento de votos. Closed identifica material histórico que ya no se desarrolla, promueve ni utiliza activamente. Permanece archivado. Ni siquiera Deployed significa que todos los monederos lo admitan. [1]
La cabecera recoge autores, tipo, estado, fecha de asignación del número, licencia y enlaces a discusiones. Requires enumera otros BIP necesarios, Replaces las propuestas que se pretende sustituir y Proposed-Replacement un posible sucesor. Tras alcanzar el estado Complete, los cambios posteriores se anotan en Changelog, el registro de cambios, con su fecha y número de versión. El campo Version de la cabecera indica la versión actual del documento. Un cambio incompatible con el diseño anterior debería normalmente recibir otro BIP, para que el mismo número no pase a significar algo distinto sin advertencia. [1]
Para obtener la imagen más completa, lee esta entrada junto con Soft Fork, Reglas de consenso, Bitcoin Core, Bitcoin, Hard Fork, BIP 39. También enlazan con esta entrada Soft Fork, Guerra del tamaño de bloque, Bitcoin Core, Educación sobre Bitcoin.