Bitcoin no tiene CEO, ni consejo de administración, ni departamento de producto. Y aun así, lleva funcionando sin interrupciones desde enero de 2009, incorporando mejoras que han transformado su capacidad, su seguridad y su privacidad. ¿Cómo se pone de acuerdo una red descentralizada para cambiar sus propias reglas? Con un sistema llamado BIP en Bitcoin: las propuestas de mejora que cualquier persona puede presentar y que nadie puede imponer por decreto.
Un BIP (Bitcoin Improvement Proposal) es un documento formal que describe un cambio propuesto para el protocolo de Bitcoin, sus procesos o su entorno. No es una orden. Es una idea bien argumentada que se somete al escrutinio público. Si la comunidad alcanza consenso, el cambio se implementa. Si no, la propuesta se archiva o se reformula. Sin jefes, sin votación corporativa, sin atajos.
En este artículo:
De dónde viene el sistema BIP en Bitcoin
La idea no surgió con Satoshi Nakamoto. El primer BIP lo presentó el desarrollador Amir Taaki el 19 de agosto de 2011, inspirándose en un modelo que ya existía en el mundo del software libre: los PEP (Python Enhancement Proposals), el sistema que usa la comunidad de Python para proponer cambios al lenguaje. Taaki adaptó ese formato a Bitcoin y lo publicó como BIP 1, el documento que definió qué es un BIP, cómo debe escribirse y qué proceso debe seguir para ser evaluado.
Esa primera propuesta no cambió una sola línea de código. Cambió algo más difícil: estableció las reglas del juego para que miles de personas dispersas por el mundo pudieran debatir mejoras sin que ninguna de ellas tuviera la última palabra por jerarquía. El proceso actual está definido en el BIP 3, una versión actualizada que refina las reglas originales de Taaki.
Hoy, un grupo reducido de editores (entre ellos Luke Dashjr y Mark Erhardt) se encarga de revisar que las propuestas cumplan los requisitos formales antes de publicarlas en el repositorio oficial de GitHub. Pero su papel es editorial, no ejecutivo: publican propuestas que cumplen el formato, no deciden cuáles se implementan.
Tres tipos de BIP y para qué sirve cada uno
No todos los BIP en Bitcoin proponen cambios técnicos al protocolo. Existen tres categorías, y entenderlas ayuda a distinguir entre una propuesta que puede cambiar las reglas de consenso y otra que simplemente documenta un proceso.
BIP estándar (Standards Track)
Son los que proponen cambios que afectan directamente al funcionamiento de la red: reglas de validación de transacciones, formato de bloques, estructura de direcciones. Requieren consenso amplio para activarse. La mayoría de los BIP que han marcado hitos en la historia de Bitcoin pertenecen a esta categoría.
BIP informativo
Describen un problema de diseño, presentan datos o proponen recomendaciones. No exigen cambios en el código ni requieren votación. Son investigaciones que la comunidad puede leer, debatir y usar como referencia.
BIP de proceso
Proponen cambios en los procedimientos que rodean a Bitcoin: cómo se escriben los propios BIP, cómo se activan los soft forks, qué pasos debe seguir una propuesta para pasar de borrador a implementación. El propio BIP 3 es un BIP de proceso.
El recorrido de un BIP: de la idea al código
Presentar un BIP no garantiza nada. Ni siquiera garantiza que alguien lo lea. El proceso es deliberadamente lento, porque en un sistema monetario que custodia valor real, un cambio precipitado puede ser irreversible.
El camino típico tiene varias etapas:
1. Discusión informal. El autor plantea la idea en la lista de correo de desarrollo de Bitcoin (bitcoindev@googlegroups.com) o en canales como IRC. Si la comunidad ve potencial, el autor desarrolla la propuesta.
2. Borrador (Draft). El autor redacta el BIP siguiendo el formato estándar: resumen, motivación, especificación técnica, compatibilidad con versiones anteriores e implementación de referencia. Lo envía al repositorio de GitHub.
3. Revisión y debate. Desarrolladores, operadores de nodos y usuarios analizan la propuesta. Se buscan fallos, se plantean objeciones, se sugieren mejoras. Este debate puede durar meses o años.
4. Activación. Si el BIP es de tipo estándar y afecta al consenso, necesita que una mayoría significativa de la red acepte el cambio. La forma exacta de activación varía: algunos BIP definen umbrales de señalización por parte de los mineros, otros han usado mecanismos activados directamente por los usuarios.
5. Estado final. Un BIP puede terminar como Final (implementado y activo), Withdrawn (retirado por el autor), Rejected (rechazado por falta de consenso) u Obsolete (reemplazado por una propuesta posterior).
No hay atajos. Y esa lentitud no es un defecto. Es la consecuencia directa de que Bitcoin no tiene un líder que pueda forzar un cambio, solo miles de participantes que operan bajo reglas verificables.
Los BIP en Bitcoin que cambiaron la red
En el repositorio oficial hay propuestas con números que superan el 370. No todas están activas: muchas quedaron en borrador, otras fueron retiradas o reemplazadas. Pero un puñado de ellas redefinió cómo funciona Bitcoin.
BIP 32: carteras deterministas jerárquicas
Propuesto por Pieter Wuille. Antes de este BIP, cada dirección de Bitcoin requería gestionar su propia clave privada por separado. BIP 32 introdujo un sistema en el que una sola semilla genera un árbol completo de claves. Una semilla, (casi) infinitas direcciones, un solo respaldo. Este BIP sentó la base para las wallets modernas que usamos hoy.
BIP 39: frases semilla legibles
Propuesto por Marek Palatinus, Pavol Rusnak, Aaron Voisine y Sean Bowe. BIP 32 resolvió la estructura de claves, pero el respaldo seguía siendo una cadena de caracteres ilegible para un humano. BIP 39 convirtió esa semilla en una secuencia de 12 o 24 palabras tomadas de una lista de 2.048 términos. El resultado: cualquier persona puede anotar su frase semilla en papel y recuperar su wallet completa desde cualquier dispositivo compatible. Es el BIP que hizo posible que la autocustodia fuera accesible para personas sin formación técnica.
BIP 141: Segregated Witness (SegWit)
Propuesto por Pieter Wuille y presentado en la conferencia Scaling Bitcoin de 2015. SegWit separó los datos de firma (el «testigo») del cuerpo de la transacción, resolviendo dos problemas a la vez: la maleabilidad de transacciones y el límite efectivo del tamaño de bloque. Sin SegWit no existiría la red Lightning, porque Lightning requiere transacciones no maleables para funcionar de forma segura. Fue activado en agosto de 2017 tras uno de los debates más intensos en la historia de Bitcoin.
BIP 148: cuando los usuarios tomaron el control
En 2017, parte de la comunidad de mineros bloqueaba la activación de SegWit. BIP 148 propuso un UASF (User Activated Soft Fork): los operadores de nodos declararían que a partir de una fecha determinada solo aceptarían bloques que señalizaran soporte para SegWit, independientemente de lo que hicieran los mineros.
Fue un momento sin precedentes. No fueron los mineros quienes decidieron. Fueron los usuarios, coordinándose de forma voluntaria, quienes forzaron el cambio. BIP 148 demostró en la práctica la descentralización entendida como: una acción colectiva emergente sin un líder que la dirija.
BIP 173: direcciones Bech32
Propuesto por Pieter Wuille y Gregory Maxwell. Introdujo un nuevo formato de dirección (las que empiezan por bc1) diseñado para ser más eficiente, más resistente a errores de escritura y nativo de SegWit. Si alguna vez has visto una dirección de Bitcoin que empieza por bc1q, estás viendo BIP 173 en acción.
BIP 340, 341 y 342: Taproot
Activado en noviembre de 2021, Taproot fue la mayor actualización del protocolo desde SegWit. Este conjunto de tres BIP introdujo firmas Schnorr (más eficientes que las firmas ECDSA anteriores), nuevos tipos de script y mejoras significativas en privacidad transaccional. Con Taproot, una transacción compleja (multifirma, timelock, condiciones múltiples) puede verse en la blockchain exactamente igual que una transacción simple. Menos información visible, más privacidad para todos.
Por qué los BIP importan aunque no seas desarrollador
Si usas Bitcoin, los BIP ya afectan tu experiencia. La frase semilla que anotaste en papel existe gracias a un BIP. El formato de dirección de tu wallet es producto de otro. La velocidad con la que puedes enviar bitcoin por Lightning depende de un tercero. Y la privacidad de tus transacciones mejoró con un cuarto.
Los BIP son el mecanismo que permite a Bitcoin evolucionar sin renunciar a lo que lo hace diferente: nadie puede cambiar las reglas sin que el resto de la red esté de acuerdo. No hay un CEO que decida una actualización un viernes por la tarde. No hay un consejo que vote a puerta cerrada. Hay propuestas públicas, debate abierto y consenso verificable.
Eso no significa que el proceso sea perfecto. Es lento, a veces frustrante, y las propuestas más controvertidas pueden tardar años en resolverse. Pero esa lentitud es el precio de un sistema donde ningún actor tiene el poder de imponer cambios unilaterales. Y para un protocolo que custodia el ahorro de millones de personas, ese precio es barato.
Preguntas frecuentes sobre BIP en Bitcoin
¿Cualquier persona puede proponer un BIP en Bitcoin?
Sí. No hay requisito de credenciales ni afiliación. Cualquier persona puede redactar un BIP y enviarlo al repositorio de GitHub. Sin embargo, la propuesta debe cumplir el formato estándar definido en BIP 3 y, antes de formalizarla, se recomienda plantear la idea en la lista de correo de desarrollo para recibir retroalimentación. El mérito de la propuesta importa más que el currículum de quien la presenta.
¿Cuántos BIP existen actualmente?
El repositorio oficial de GitHub contiene propuestas con números que superan las 400. No todos están activos: muchos quedaron en estado de borrador, fueron retirados o reemplazados por propuestas posteriores. El número exacto de BIP en estado Final (implementados y activos en la red) es considerablemente menor. Puedes consultar el listado completo y actualizado en bips.dev.
¿Qué diferencia hay entre un BIP y un fork?
Un BIP es una propuesta: un documento que describe un cambio. Un fork es el mecanismo técnico por el cual ese cambio se implementa en la red. Algunos BIP se activan mediante un soft fork (compatible con versiones anteriores), otros mediante un hard fork (incompatible). No todo BIP requiere un fork: los BIP informativos y algunos de proceso no modifican el código del protocolo.
¿Qué pasa si un BIP se rechaza?
El autor puede retirarlo voluntariamente, reformularlo y presentarlo de nuevo, o dejarlo en estado de borrador indefinidamente. No hay penalización por proponer un BIP que no se adopta. El repositorio conserva un registro histórico de todas las propuestas, incluidas las rechazadas, como referencia para futuros desarrolladores.
