Qué pasó
El 17 de agosto de 2026, el repositorio de propuestas de Bitcoin incorporó una política de seguridad que enumera a cinco editores de BIPs y sus direcciones de correo como un lugar al que enviar el reporte de una vulnerabilidad. La primera instrucción del archivo es enviarlo a otra parte: "El enfoque preferido para reportar una vulnerabilidad de seguridad es contactar a los respectivos responsables del BIP y a los proyectos afectados que implementan ese BIP". Los editores son el recurso de reserva, para cuando "los intentos de contactar a las partes afectadas fallan". El pull request se abrió el 8 de agosto y se integró nueve días después.
Qué cambia
El repositorio guarda documentos, no software, y ahí está toda la forma del problema. Un defecto descrito en una especificación ya está corriendo en cada proyecto que la implementó con fidelidad, y cada uno de esos proyectos publica su propia corrección en su propio calendario. No hay parche que el repositorio pueda lanzar por sí mismo. Así que lo útil que puede ofrecer un repositorio de estándares no es un arreglo sino una ruta: una manera de llegar a quienes sí pueden publicarlo.
Vale la pena leer el pull request por el argumento. Un editor preguntó, con razón: "Como no publicamos un proyecto de software, ¿qué divulgaciones responsables podríamos llegar a recibir?". La respuesta que se ofreció fue una falla en una especificación, o en la implementación de ejemplo impresa dentro de ella, que se convierte en un exploit en el software que la copió. Otro participante planteó la secuencia para un estándar ya desplegado: contactar primero a las implementaciones y después agregar al documento una advertencia de "esta especificación no debería implementarse" hasta que la divulgación completa sea razonable.
Esa advertencia es el mecanismo que la mayoría de quienes lean esto no habrá considerado. Una especificación no se puede retirar de circulación, pero sí se puede marcar, y esa marca es lo que verá dentro de un año quien la lea.
Qué no cambia
Los editores no son un equipo de seguridad. El archivo dice que "harán su mejor esfuerzo para triar el reporte y ponerse en contacto con las partes correspondientes": mejor esfuerzo, de personas voluntarias, sin ningún tiempo de respuesta comprometido. Tampoco son una autoridad sobre lo que cada quien ejecuta: el BIP-3 es explícito en que "los editores NO evalúan si es probable que la propuesta sea adoptada", y una advertencia agregada a un documento no impide que nadie corra código que ya existe.
La ruta además supone el caso alcanzable. Funciona cuando un BIP tiene responsables identificables e implementaciones que contestan el correo, que es justamente la situación en la que quien investiga se habría arreglado sin ningún archivo de política.
Contexto
Esto es tarea de mantenimiento, y el valor del mantenimiento aparece después. El mismo repositorio tuvo un mes ruidoso: BIP-110 quedó cerrado tras una división de cadena y BIP-89 avanzó a Deployed. Ambos fueron cambios de estado en documentos que describen software que corren otras personas, que es la misma relación que esta política intenta volver transitable. Conviene tener presente el límite al leerla: la falla de entropía de Coldcard en julio, el incidente que puso la generación de seeds en las noticias, se corrigió con un parche de firmware de un solo fabricante, no con un cambio en ninguna especificación.