Cómo funciona una propuesta de mejora de Bitcoin (BIP)

¿Te has preguntado alguna vez como se cambia el código de Bitcoin? o ¿Quiénes tienen el poder para poder cambiarlo? Pues en este artículo voy a hablaros sobre las propuestas de mejora de bitcoin, también conocido como BIP por sus siglas en inglés (Bitcoin Improvement Proposals).

A continuación, os contaré que son estas propuestas, como como se desarrollan, como se votan y finalmente quien las integra en el código de Bitcoin.

¿Qué es una Propuesta de Mejora de Bitcoin (BIP)?

Como adelanté en la introducción de este artículo, BIP son las siglas en inglés de «Bitcoin Improvement Proposal» o como lo traduciríamos al español, «Propuesta de Mejora de Bitcoin». 

BIP es un tipo de estándar, el cual permite a los usuarios proponer cambios en el protocolo de Bitcoin de forma ordenada. Cada BIP presentado es un documento donde se debe realizar una especificación técnica de los cambios a introducir en la estructura de Bitcoin de forma clara y concisa, así como su justificación y motivaciones que llevan al desarrollo de esta nueva implementación.

El formato de los BIP es mérito de Amir Taaki, quien presentó el primer BIP (BIP-0001) en agosto de 2011 donde definía que es un BIP y cómo podían utilizarlo los usuarios para proponer mejoras. Como curiosidad, Amir Taaki creó a BIP a semejanza del PEP, un estándar para introducir mejoras en el lenguaje de programación Python.

Más tarde, en febrero de 2016, Luke Dashjr traería ciertas mejoras al estándar con su BIP-0002, como una mayor variedad de licencias abiertas, el requisito de la implementación antes del cambio de estado ha propuesto (ya veremos más adelante que significa esto) o los encabezados para los BIP entre otras mejoras.

Todos los BIP están recopilados en el repositorio Git oficial, y podéis consultarlos desde aquí: https://github.com/bitcoin/bips

Los tres tipos de BIP

Debido a la variedad de propuestas de mejora para Bitcoin, se tomó la decisión de clasificar estos BIP según su propósito y se formaron tres grupos de BIP:

• Estándar (o seguimiento de estándares): En este tipo de BIP se describen todos los cambios que afecten a la mayoría o a la totalidad de las implementaciones en Bitcoin. Por ejemplo, en este tipo de BIP incluiríamos los cambios de protocolo de red, cambios en las reglas de validación de bloques o transacciones… etc. Un ejemplo de este tipo de bip sería el BIP-141, que implementó SegWit.
• Informativo: En este tipo de BIP se describen problemas en el diseño de Bitcoin o se aportan pautas generales a la comunidad, pero no implementa una característica nueva. Este tipo de BIP pueden ser libremente ignorados por los usuarios e implementadores. Un ejemplo de este tipo de BIP seria el BIP-010 que define distribución de transacciones multifirma.
• Proceso: Este tipo de BIP describe un proceso que afecta en Bitcoin o propone un cambio o un evento para un proceso. En estos BIP se puede proponer una implementación siempre y cuando no afecte al código base de Bitcoin. Aquí tenemos como ejemplo el BIP-123, que introduce la clasificación de los BIP en cuatro capas.
  

El flujo de una propuesta de mejora de Bitcoin (BIP)

Lo primero que debe hacer el autor de un BIP es determinar si su idea es compatible con un BIP. Muchas veces las ideas se corresponden más con un parche que con una propuesta de mejora y estos parches siguen un camino diferente ya que son enviados directamente al tracker de incidencias.

Después es necesario revisar las discusiones de desarrollo (bien en la lista de correo de desarrollo o bien en el subforo dedicado para ello en BitcoinTalk) para asegurarnos que la idea que planteamos no ha sido discutida antes y rechazada por algún motivo. Además, es recomendable que los BIP solo incluyan una propuesta o idea nueva. Si tu BIP incorpora varias propuestas, es mejor que cada una sea presentada por separado como BIP independiente.

Una vez tenemos claro que nuestra idea no ha sido rechazada previamente y se corresponde con un BIP, debemos enviar nuestra idea (no el BIP) a la lista de correo de desarrollo de Bitcoin para ser discutida por la comunidad. Esto es necesario para asegurarnos que la idea es aplicable a toda la comunidad y no es una propuesta que va a beneficiar únicamente al autor.

Cuando ya hemos debatido con la comunidad y hemos concluido que nuestra idea tiene opciones de ser aceptada empezaremos a redactar el BIP y una vez lo tengamos lo volveremos a enviar a la lista de correo de desarrollo de Bitcoin. Ahora será el BIP sobre lo que se va a discutir, se informará de las correcciones necesarias (en caso de necesitarlas) para que tenga el formato adecuado y se abordarán las dudas o inquietudes nuevas que surjan de la propuesta.

Una vez discutido el BIP, el autor deberá recopilar los comentarios de la comunidad sobre su propuesta inicial y los comentarios sobre su BIP para incluirlos en su propuesta mediante un enlace en la wiki del git de los BIP.

Una vez recopilados los comentarios, el BIP se enviará al repositorio git de BIP con una pull request (un tipo de petición para que ciertos cambios o mejoras se integren en un repositorio). En este punto deberemos subirlo con alias tipo “bip-taberna-propuestaX” ya que los autores tienen prohibido asignar un número de BIP a su propuesta. Son los editores de BIP los que asignan los números a las propuestas (hablaremos más adelante sobre este grupo).

Tras la revisión por los editores y una vez el BIP esté completo, un editor le asignará un número, le dará el estado de “borrador” y le asignará el tipo de BIP que le corresponda. A continuación, integrará propuesta de BIP en el repositorio.

Cuando el autor considera que tiene suficiente apoyo de la comunidad, ha completado el BIP con los cambios necesarios planteados en las discusiones con la comunidad y tiene una implementación funcional es cuando podrá cambiar el estado de “borrador” a “propuesto”. El autor también puede volver al estado de “borrador” si considera que tiene propuestas que corrigen las objeciones planteadas por la comunidad.

Para que nuestra propuesta cambie de estado “Propuesto” a “Final” y sea implementado en el código de Bitcoin deberemos tener en cuenta que tipo de fork se va a realizar, soft-fork o hard-fork.

En un soft-fork se requiere una clara mayoría de los mineros expresada en una votación en la blockchain y se recomienda que el BIP reciba alrededor de un 95% del apoyo. También es posible determinar un porcentaje inferior siempre que se pueda justificar esta decisión.

En el caso del hard-fork se requiere la adopción de toda la comunidad de Bitcoin y no valdrá con una amplia mayoría. Esta aceptación se demostrará por el uso del fork por parte de la comunidad. 

Para finalizar con el flujo de las propuestas de mejora de Bitcoin, comentar que hay otra serie de estados menos importantes como son “Rechazado” si el BIP no cumple los criterios. “Retirado” si tras la discusión el autor considera que su idea era errónea. “Reemplazado” u “Obsoleto” para los BIPs ya en estado final que no tienen uso o su implementación ha sido mejorada por otro BIP.

La estructura de una propuesta de mejora de Bitcoin (BIP)

Como os podréis imaginar para poder presentar una propuesta de mejora se debe presentar un documento que siga un estándar definido por la comunidad. Este estándar quedó definido con los BIP-0001 publicado en 2013 y BIP-0002 publicado en 2016 que es simplemente una revisión del primero.

Todo BIP debe comenzar con un preámbulo que contiene los metadatos necesarios sobre el BIP. A continuación, se debe incluir un resumen de unas 200 palabras en el que se describe el problema técnico que se está abordando y seguidamente deberemos indicar qué derechos de autor tiene nuestra propuesta indicando explícitamente el tipo de licencia. Existen una serie de licencias recomendadas por la comunidad que están recopiladas en el BIP-002.

También se deberá incluir la especificación en la que se describe la sintaxis y la semántica de cualquier función nueva lo suficientemente detallada para permitir implementaciones interoperables.

Lo siguiente a añadir será la motivación, este punto es fundamental para cualquier BIP que quiera cambiar el protocolo. En este punto se debe explicar claramente porque el protocolo existente es inadecuado para abordar el problema que resuelve este BIP. Además se debe añadir la justificación en los casos necesarios, donde se especifica que motivó el diseño y porqué se tomaron ciertas decisiones en el diseño.

En penúltimo lugar habrá que indicar la compatibilidad con versiones anteriores, en este punto se deben detallar todas las incompatibilidades junto con su gravedad, así como la propuesta del autor del BIP para solucionarlas.

Finalmente llegamos a la implementación de referencia, la cual no es necesaria completar antes de la aceptación del BIP, pero si es imprescindible para que el estado de un BIP pase a «Final». La implementación final debe incluir el código de prueba y la documentación necesaria para el protocolo de Bitcoin.

El equipo que mantiene el código de Bitcoin

Desde que en 2010 Satoshi publicó la última versión en la que participa y la primera que sería alojada en Github, han sido varios los desarrolladores que han trabajado en el código de Bitcoin. Inicialmente Satoshi Nakamoto era el creador y mantenedor principal del código de Bitcoin, pero tras su desaparición este puesto quedó a cargo de Gavin Andresen a quien Satoshi le concedió permisos para modificar el código de Bitcoin.

Unos años después, Andresen dejaría su cargo de mantenedor principal tras una polémica surgida entre la comunidad por el cambio de nombre del repositorio de Bitcoin, el cual pasó a llamarse Bitcoin Core (este nombre tenía connotaciones de centralización cuando esa no era una idea que se compartiese en la comunidad de Bitcoin).

El cargo de mantenedor principal cayó en manos de Wladimir J. van der Laan hasta la actualidad. Pero no solo Wladimir J. van de Laan tiene permisos sobre Bitcoin Core. Hay otra serie de desarrolladores que también tienen permisos:

• Marco Falke que tiene el cargo de mantenedor de QA/Testing
• Michael Ford que tiene el cargo de mantenedor del sistema de compilación y mantenedor general.
• Hennadii Stepanov mantenedor de la GUI y mantenedor general.
• Andrew Chow mantenedor de la wallet.
• Gloria Zhao mantenedora general, y primera mujer y última persona en ser aceptada dentro del equipo de mantenedores.

Además de las figuras de mantenedor principal y mantenedor, existe otra figura importante en todo el proceso. El editor de BIP. Este cargo actualmente lo ocupan Luke Dashjr y Kalle Alm quienes se encargan de revisar y validar todos los BIPs que aspiran al estado de borrador, y una vez aceptado un BIP y cambiado su estado al de borrador se procede a solicitar el autor que haga un pull request del BIP para poder recibir comentarios. Es en este momento cuando el editor le asignará un número de BIP.