Bitcoin Whitepaper

Un whitepaper presenta un problema y propone una solución. El de Bitcoin comienza con una pregunta cotidiana: cuando envío dinero por Internet, ¿siempre debe haber un banco u otro administrador entre nosotros? Satoshi envió su propuesta a una lista de correo sobre criptografía el 31 de octubre de 2008 e incluyó un enlace al texto. No prometía un precio del bitcoin ni una rentabilidad. Explicaba cómo recibir pagos sin confiar a una sola empresa las decisiones sobre su historial. Ese problema conecta todo el documento. [2] [1]

Imagine que alguien firma dos pagos distintos que gastan el mismo dinero. Un destinatario ve el primero y otro el segundo. Ambos pueden comprobar una firma digital válida, es decir, la autorización para pagar, pero ambos no pueden cobrar. Copiar datos es fácil en Internet; una firma por sí sola no lo impide. Por eso la sección 2 distingue la autorización para gastar de la cuestión de qué pago entrará en el historial común. Bitcoin añade a las firmas un registro público con el que reconocer fondos ya gastados. [1]

Las secciones 3–5 agrupan pagos en bloques. Cada bloque nuevo enlaza al anterior mediante un hash, una breve huella digital de los datos. Cambiar un registro antiguo alteraría esa huella y rompería los enlaces. Proof of Work añade trabajo computacional costoso: producir un bloque aceptable requiere muchos intentos, mientras que comprobar el resultado es sencillo. Entre ramas rivales cuenta el trabajo acumulado en un historial que respeta las reglas, no el número de cuentas o direcciones IP creadas. El texto lo llama la cadena más larga. Ni siquiera mucho trabajo vuelve válida una transacción inválida. La cadena también ordena los sucesos, sin proporcionar una hora exacta para cada pago. [1] [3]

Los ordenadores y la electricidad cuestan dinero. La sección 6 añade un incentivo económico: el creador de un bloque aceptado puede recibir monedas recién emitidas y las comisiones de los pagos incluidos. La comisión es la diferencia entre el valor consumido por una transacción y el de sus nuevas salidas. No son monedas adicionales creadas de la nada. El texto contempla un futuro en el que las comisiones aporten toda la recompensa. Pero conviene saber dónde termina la propuesta: el whitepaper no especifica el límite exacto de 21 millones ni la reducción a la mitad cada 210.000 bloques. Esas reglas requieren otras fuentes sobre Bitcoin. [1] [3]

No todo el mundo quiere descargar y verificar todas las transacciones. La sección 8 propone SPV, la verificación simplificada de pagos. El cliente obtiene cabeceras con los datos esenciales de los bloques y una prueba de Merkle: una conexión de hashes que demuestra la inclusión de una transacción en un bloque. Es la diferencia entre comprobar que una entrada figura en un libro y verificar la corrección de todo el libro. La inclusión no comprueba por sí sola todas las reglas ni el historial completo de gastos. El whitepaper reconoce esta limitación: el cliente simplificado es más vulnerable a ciertos ataques que un Full Node que verifica las transacciones por sí mismo. [1]

En la banca, gran parte del registro de pagos no es público. Bitcoin necesita un historial compartido y debe proteger la privacidad de otra forma. La sección 10 explica cómo separar los pagos de la identidad de quienes poseen las claves y recomienda pares de claves nuevos para otras transacciones. También reconoce un punto débil: los pagos pueden vincularse. Identificar a una persona detrás de un registro puede revelar otros pagos suyos. Una dirección nueva no es un disfraz mágico. Limita ciertos vínculos, pero no borra por sí sola la información pública ni lo que sabe la contraparte. [1]

La sección 11 pregunta qué posibilidades tiene un atacante de alcanzar la cadena creada por los participantes honestos. Imagine una carrera: un bando lleva ventaja, pero ambos siguen trabajando. Cuanto menor es la proporción de potencia del atacante y mayor la ventaja, menos probable es que alcance la cadena en el modelo descrito. El cálculo usa supuestos y una aproximación de Poisson, una simplificación matemática para estimar cuántos sucesos ocurren durante un periodo. No predice todos los ataques reales. Por eso un número extraído de la tabla no constituye una cantidad segura de confirmaciones para cualquier pago. [1]

El documento explica el diseño original. La red y el software han evolucionado; SegWit, por ejemplo, descrito en la propuesta BIP 141, no aparece. Un BIP documenta una propuesta de mejora, no una decisión que se convierta automáticamente en regla de la red al publicarse. Para entender cuestiones actuales hay que distinguir propuesta, programa, reglas comunes realmente aplicadas y decisiones locales de un nodo sobre retransmisión. Un nodo puede no retransmitir una transacción y después aceptarla dentro de un bloque válido. Ambas situaciones son compatibles. [4] [3]

Comience por el resumen y la pregunta de cómo impedir el doble gasto sin administrador. Después siga lo que aportan las firmas, el historial compartido y el trabajo necesario para crear bloques. Si las matemáticas le frenan, no necesita entender enseguida cada fórmula: primero aclare qué ataque modela el cálculo y qué supuestos utiliza. Puede volver a los detalles más tarde. El correo original acredita cuándo Satoshi presentó la propuesta; el PDF contiene su razonamiento. Una frase aislada no demuestra que una cartera o un servicio concreto tenga que ser seguro. [2] [1]

Lo principal no es memorizar los nombres de las secciones, sino entender por qué ninguna pieza basta sola: la firma acredita autorización, el historial público ayuda a detectar el doble gasto y Proof of Work dificulta reescribir el orden. Las piezas tenían antecedentes que Satoshi cita en las referencias. La aportación está en cómo se conectan. El whitepaper sigue siendo una buena introducción al razonamiento de Bitcoin si se lee como una propuesta fundamentada con supuestos concretos. No es una lista de precios, una guía de inversión ni la especificación completa de todas las reglas y herramientas que hoy llevan el nombre Bitcoin. [1]