El whitepaper de Bitcoin en español

Traducción al español del documento original Bitcoin: A Peer-to-Peer Electronic Cash System, publicado por Satoshi Nakamoto el 31 de octubre de 2008.

Resumen

Una versión puramente entre pares de dinero electrónico permitiría enviar pagos en línea directamente de una parte a otra sin pasar por una institución financiera. Las firmas digitales aportan parte de la solución, pero las ventajas principales se pierden si sigue haciendo falta un tercero de confianza para evitar el doble gasto.

Proponemos una solución al problema del doble gasto mediante una red entre pares. La red marca las transacciones con una fecha y hora al incorporarlas a una cadena continua de pruebas de trabajo basadas en hashes, formando un registro que no puede modificarse sin rehacer toda esa prueba de trabajo.

La cadena más larga no solo sirve de prueba de la secuencia de acontecimientos presenciados, sino también de prueba de que procede del mayor conjunto de potencia de cómputo. Mientras la mayoría de esa potencia esté controlada por nodos que no cooperan para atacar la red, generarán la cadena más larga y superarán a los atacantes.

La red en sí requiere una estructura mínima. Los mensajes se difunden con el mejor esfuerzo posible, y los nodos pueden entrar y salir a voluntad, aceptando la cadena de prueba de trabajo más larga como constancia de lo ocurrido mientras estuvieron ausentes.

1. Introducción

El comercio en internet ha pasado a depender casi exclusivamente de instituciones financieras que actúan como terceros de confianza para procesar los pagos electrónicos. Aunque el sistema funciona suficientemente bien para la mayoría de las transacciones, sigue arrastrando las debilidades inherentes al modelo basado en la confianza.

Las transacciones completamente irreversibles no son realmente posibles, porque las instituciones financieras no pueden evitar mediar en las disputas. El coste de esa mediación encarece las transacciones, limita el tamaño mínimo práctico de una operación y elimina la posibilidad de hacer pagos pequeños y ocasionales. Además, se pierde algo más amplio: la capacidad de realizar pagos no reversibles por servicios que tampoco lo son.

Con la posibilidad de revertir, la necesidad de confianza se extiende. Los comerciantes deben desconfiar de sus clientes y pedirles más datos de los que harían falta. Se acepta un porcentaje de fraude como algo inevitable. Todos estos costes e incertidumbres en los pagos pueden evitarse en persona usando dinero físico, pero no existe ningún mecanismo para pagar a través de un canal de comunicación sin una parte de confianza.

Lo que hace falta es un sistema de pago electrónico basado en pruebas criptográficas en lugar de confianza, que permita a dos partes dispuestas a ello transaccionar directamente entre sí sin necesidad de un tercero de confianza. Las transacciones computacionalmente impracticables de revertir protegerían a los vendedores del fraude, y los mecanismos habituales de depósito en garantía podrían implementarse fácilmente para proteger a los compradores.

En este documento proponemos una solución al problema del doble gasto mediante un servidor distribuido de sellado de tiempo entre pares, que genera una prueba computacional del orden cronológico de las transacciones. El sistema es seguro mientras los nodos honestos controlen conjuntamente más potencia de cómputo que cualquier grupo de nodos atacantes que cooperen entre sí.

2. Transacciones

Definimos una moneda electrónica como una cadena de firmas digitales. Cada propietario transfiere la moneda al siguiente firmando digitalmente un hash de la transacción anterior junto con la clave pública del nuevo propietario, y añadiendo ambos al final de la moneda. El receptor del pago puede verificar las firmas para comprobar la cadena de propiedad.

El problema, por supuesto, es que quien recibe el pago no puede verificar que uno de los propietarios anteriores no haya gastado dos veces la misma moneda. La solución habitual consiste en introducir una autoridad central de confianza, una casa de la moneda, que compruebe cada transacción por si hubiera doble gasto. Después de cada operación, la moneda debe volver a esa casa de la moneda para emitir una nueva, y solo se confía en que las monedas emitidas directamente por ella no se hayan gastado dos veces.

El problema de esta solución es que el destino de todo el sistema monetario queda en manos de la empresa que gestiona esa casa de la moneda, con cada transacción teniendo que pasar por ella igual que en un banco.

Necesitamos una manera de que quien recibe el pago sepa que los propietarios anteriores no firmaron ninguna transacción previa. Para nuestros fines, la primera transacción es la que cuenta, así que no nos importan los intentos posteriores de doble gasto. La única forma de confirmar que una transacción no existe es conocerlas todas.

En el modelo basado en una casa de la moneda, esta conocía todas las transacciones y decidía cuál llegó primero. Para lograr lo mismo sin una parte de confianza, las transacciones deben anunciarse públicamente y necesitamos un sistema en el que los participantes acuerden un único historial del orden en que se recibieron. Quien recibe el pago necesita la prueba de que, en el momento de cada transacción, la mayoría de los nodos coincidió en que fue la primera recibida.

3. Servidor de sellado de tiempo

La solución que proponemos comienza con un servidor de sellado de tiempo. Este servidor funciona tomando el hash de un bloque de elementos que deben sellarse y publicando ampliamente ese hash, por ejemplo en un periódico o en una publicación de Usenet.

El sello demuestra que los datos tuvieron que existir en ese momento, evidentemente, para poder entrar en el hash. Cada sello incluye el sello anterior dentro de su propio hash, formando una cadena en la que cada sello adicional refuerza los que lo preceden.

4. Prueba de trabajo

Para implementar un servidor distribuido de sellado de tiempo entre pares necesitamos usar un sistema de prueba de trabajo similar al Hashcash de Adam Back, en lugar de periódicos o publicaciones de Usenet.

La prueba de trabajo consiste en buscar un valor que, al aplicarle una función hash como SHA-256, produzca un resultado que empiece por una cantidad determinada de bits en cero. El trabajo medio necesario es exponencial respecto al número de ceros exigidos, y puede verificarse ejecutando un único hash.

Para nuestra red de sellado, implementamos la prueba de trabajo incrementando un contador dentro del bloque hasta encontrar un valor que dé al hash del bloque los ceros requeridos. Una vez invertido el esfuerzo de cómputo para satisfacer esa prueba, el bloque no puede modificarse sin rehacer todo el trabajo. Como los bloques posteriores se encadenan detrás, cambiar uno obligaría a rehacer también el de todos los que vienen después.

La prueba de trabajo resuelve además el problema de determinar la representación en la toma de decisiones por mayoría. Si la mayoría se basara en un voto por dirección IP, cualquiera capaz de asignarse muchas direcciones podría subvertirla. La prueba de trabajo es esencialmente un voto por unidad de cómputo. La decisión de la mayoría está representada por la cadena más larga, que es la que concentra el mayor esfuerzo invertido.

Si la mayoría de la potencia de cómputo está controlada por nodos honestos, la cadena honesta crecerá más rápido y superará a cualquier cadena rival. Para modificar un bloque pasado, un atacante tendría que rehacer su prueba de trabajo y la de todos los bloques posteriores, y después alcanzar y superar el trabajo de los nodos honestos.

Más adelante demostraremos que la probabilidad de que un atacante más lento lo consiga disminuye exponencialmente a medida que se añaden bloques. Para compensar el aumento de la velocidad del hardware y el interés variable en ejecutar nodos con el paso del tiempo, la dificultad de la prueba de trabajo se determina mediante una media móvil que apunta a un número medio de bloques por hora. Si se generan demasiado rápido, la dificultad aumenta.

5. Red

Los pasos para hacer funcionar la red son los siguientes:

1. Las nuevas transacciones se difunden a todos los nodos.
2. Cada nodo reúne las nuevas transacciones en un bloque.
3. Cada nodo trabaja en encontrar la prueba de trabajo de su bloque.
4. Cuando un nodo encuentra la prueba de trabajo, difunde el bloque a todos los nodos.
5. Los nodos aceptan el bloque solo si todas sus transacciones son válidas y no se han gastado ya.
6. Los nodos expresan su aceptación del bloque trabajando en la creación del siguiente, usando el hash del bloque aceptado como hash previo.

Los nodos consideran siempre que la cadena más larga es la correcta y seguirán trabajando para extenderla. Si dos nodos difunden simultáneamente versiones distintas del siguiente bloque, algunos recibirán uno u otro primero. En ese caso trabajan sobre el primero que recibieron, pero guardan la otra rama por si acaba siendo la más larga. El empate se rompe cuando se encuentra la siguiente prueba de trabajo y una de las ramas se alarga; los nodos que trabajaban en la otra cambian a la más larga.

Las difusiones de nuevas transacciones no necesitan alcanzar necesariamente a todos los nodos. Mientras lleguen a muchos, entrarán en un bloque tarde o temprano. Las difusiones de bloques también toleran mensajes perdidos: si un nodo no recibe un bloque, lo pedirá al recibir el siguiente y darse cuenta de que le falta uno.

6. Incentivo

Por convención, la primera transacción de un bloque es una transacción especial que crea una moneda nueva propiedad de quien creó el bloque. Esto añade un incentivo para que los nodos den soporte a la red y ofrece una forma de poner monedas en circulación al principio, ya que no existe ninguna autoridad central que las emita.

La incorporación constante de una cantidad fija de monedas nuevas es análoga a los mineros de oro que gastan recursos para añadir oro a la circulación. En nuestro caso, lo que se gasta es tiempo de CPU y electricidad.

El incentivo también puede financiarse con las comisiones de las transacciones. Si el valor de salida de una transacción es menor que el de entrada, la diferencia es una comisión que se añade al valor del incentivo del bloque que la contiene. Una vez que haya entrado en circulación un número predeterminado de monedas, el incentivo podrá pasar a depender por completo de las comisiones y quedar totalmente libre de inflación.

El incentivo puede ayudar además a que los nodos se mantengan honestos. Si un atacante codicioso llegara a reunir más potencia de cómputo que todos los nodos honestos juntos, tendría que elegir entre usarla para estafar a la gente recuperando sus pagos o para generar monedas nuevas. Debería resultarle más rentable jugar según las reglas —reglas que le favorecen con más monedas nuevas que a todos los demás juntos— que socavar el sistema y la validez de su propia riqueza.

7. Recuperar espacio en disco

Una vez que la última transacción de una moneda queda enterrada bajo suficientes bloques, las transacciones gastadas anteriores pueden descartarse para ahorrar espacio en disco. Para facilitarlo sin romper el hash del bloque, las transacciones se registran en un árbol de Merkle, del que solo la raíz se incluye en el hash del bloque. Los bloques antiguos pueden entonces compactarse podando las ramas del árbol, sin necesidad de guardar los hashes interiores.

Una cabecera de bloque sin transacciones ocuparía unos 80 bytes. Si suponemos que se generan bloques cada diez minutos, eso equivale a 4,2 MB al año. Con sistemas informáticos que en 2008 se vendían habitualmente con 2 GB de memoria RAM, y con la ley de Moore prediciendo un crecimiento de 1,2 GB anuales, el almacenamiento no debería suponer un problema aunque las cabeceras de los bloques tuvieran que mantenerse en memoria.

8. Verificación de pago simplificada

Es posible verificar pagos sin ejecutar un nodo completo de la red. Un usuario solo necesita conservar una copia de las cabeceras de bloque de la cadena de prueba de trabajo más larga, que puede obtener consultando a los nodos de la red hasta convencerse de que tiene la más larga, y obtener la rama del árbol de Merkle que enlaza la transacción con el bloque en el que quedó sellada.

El usuario no puede comprobar la transacción por sí mismo, pero al enlazarla con un lugar de la cadena puede ver que un nodo de la red la aceptó, y los bloques añadidos después confirman que la red la ha dado por buena.

Así, la verificación es fiable mientras los nodos honestos controlen la red, pero se vuelve más vulnerable si la red es dominada por un atacante. Mientras que los nodos de la red pueden verificar las transacciones por sí mismos, el método simplificado puede ser engañado por transacciones fabricadas por un atacante mientras mantenga el control de la red.

Una estrategia de protección consiste en aceptar alertas de los nodos de la red cuando detecten un bloque inválido, lo que llevaría al programa del usuario a descargar el bloque completo y las transacciones señaladas para confirmar la inconsistencia. Las empresas que reciben pagos con frecuencia probablemente querrán seguir ejecutando sus propios nodos para tener una seguridad más independiente y una verificación más rápida.

9. Combinar y dividir el valor

Aunque sería posible manejar las monedas individualmente, resultaría poco manejable hacer una transacción separada por cada céntimo de una transferencia. Para permitir que el valor se divida y se combine, las transacciones contienen múltiples entradas y salidas.

Normalmente habrá una única entrada procedente de una transacción anterior de mayor importe, o varias entradas que combinen cantidades más pequeñas, y como mucho dos salidas: una para el pago y otra que devuelve el cambio, si lo hay, al emisor.

Conviene señalar que la difusión en abanico, donde una transacción depende de varias transacciones y esas a su vez de muchas más, no supone aquí ningún problema. Nunca hace falta extraer una copia completa e independiente del historial de una transacción.

10. Privacidad

El modelo bancario tradicional alcanza cierto nivel de privacidad limitando el acceso a la información a las partes implicadas y al tercero de confianza. La necesidad de anunciar públicamente todas las transacciones descarta este método, pero la privacidad puede mantenerse igualmente rompiendo el flujo de información en otro punto: manteniendo anónimas las claves públicas.

El público puede ver que alguien está enviando una cantidad a otra persona, pero sin información que vincule la transacción con nadie. Es similar al nivel de información que publican las bolsas de valores, donde se hacen públicos la hora y el tamaño de las operaciones individuales, pero sin decir quiénes fueron las partes.

Como cortafuegos adicional, debería usarse un par de claves nuevo en cada transacción, para evitar que queden vinculadas a un propietario común. Cierta vinculación sigue siendo inevitable en las transacciones con múltiples entradas, que necesariamente revelan que esas entradas pertenecían al mismo propietario. El riesgo es que, si se descubre quién es el dueño de una clave, esa vinculación podría revelar otras transacciones suyas.

11. Cálculos

Consideremos el escenario de un atacante que intenta generar una cadena alternativa más rápido que la cadena honesta. Aunque lo consiguiera, eso no abre el sistema a cambios arbitrarios, como crear valor de la nada o quedarse con dinero que nunca perteneció al atacante. Los nodos no aceptarán una transacción inválida como pago, y los nodos honestos nunca aceptarán un bloque que las contenga. Un atacante solo puede intentar cambiar una de sus propias transacciones para recuperar el dinero que gastó hace poco.

La carrera entre la cadena honesta y la del atacante puede describirse como un paseo aleatorio binomial. El suceso favorable es que la cadena honesta se alargue en un bloque, aumentando su ventaja en uno; el desfavorable, que sea la cadena del atacante la que crezca, reduciendo la diferencia.

La probabilidad de que un atacante alcance a la cadena honesta partiendo de una desventaja dada es análoga al problema conocido como la ruina del jugador. Supongamos que un jugador con crédito ilimitado empieza con un déficit e intenta un número infinito de apuestas para llegar al equilibrio. Podemos calcular la probabilidad de que alcance ese punto o de que un atacante alcance a la cadena honesta, así:

p = probabilidad de que un nodo honesto encuentre el siguiente bloque
q = probabilidad de que lo encuentre el atacante
qz = probabilidad de que el atacante alcance la cadena estando z bloques por detrás

qz = 1                    si p ≤ q
qz = (q / p) ^ z          si p > q

Dado que suponemos que p es mayor que q, la probabilidad cae exponencialmente a medida que aumenta el número de bloques que el atacante tiene que recuperar. Con las probabilidades en su contra, si no da un golpe de suerte pronto, sus opciones se vuelven ínfimas conforme se queda más atrás.

Consideremos ahora cuánto debe esperar el receptor de una transacción para estar suficientemente seguro de que el emisor no puede revertirla. Suponemos que el emisor es un atacante que quiere hacer creer al receptor que le pagó durante un tiempo, para después revertir el pago hacia sí mismo. El receptor recibirá un aviso cuando ocurra, pero el emisor confía en que para entonces sea demasiado tarde.

El receptor genera un par de claves nuevo y entrega la clave pública al emisor poco antes de firmar. Esto impide que el emisor prepare de antemano una cadena de bloques trabajando en ella continuamente hasta tener la suerte de adelantarse lo suficiente, para ejecutar la transacción en ese momento. Una vez enviada, el emisor deshonesto empieza a trabajar en secreto en una cadena paralela que contiene una versión alternativa de su transacción.

El receptor espera hasta que la transacción se ha añadido a un bloque y se han enlazado z bloques después. No conoce el avance exacto del atacante, pero suponiendo que los bloques honestos tardaron el tiempo medio esperado, el progreso potencial del atacante sigue una distribución de Poisson con un valor esperado de:

λ = z * (q / p)

Para obtener la probabilidad de que el atacante aún pueda alcanzar la cadena, multiplicamos la densidad de Poisson correspondiente a cada avance posible por la probabilidad de que pudiera recuperar el terreno restante desde ese punto. Reordenando para evitar sumar la cola infinita de la distribución, y convirtiéndolo a código C, resulta:

#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
    double p = 1.0 - q;
    double lambda = z * (q / p);
    double sum = 1.0;
    int i, k;
    for (k = 0; k <= z; k++)
    {
        double poisson = exp(-lambda);
        for (i = 1; i <= k; i++)
            poisson *= lambda / i;
        sum -= poisson * (1 - pow(q / p, z - k));
    }
    return sum;
}

Al ejecutar algunos resultados, se observa que la probabilidad cae exponencialmente con z. Para un atacante que controle el 10 % de la capacidad de cómputo, la probabilidad de éxito baja por debajo de una entre mil a partir de cinco bloques, y por debajo de una entre un millón alrededor de diez. Si controlara el 30 %, harían falta bastantes más: en torno a veinticuatro bloques para bajar de una entre mil, y unos cincuenta para acercarse a una entre un millón. De ahí procede la costumbre de esperar varias confirmaciones antes de dar un pago por definitivo.

12. Conclusión

Hemos propuesto un sistema de transacciones electrónicas que no depende de la confianza. Empezamos con el marco habitual de monedas hechas con firmas digitales, que ofrece un control sólido de la propiedad pero resulta incompleto sin una forma de evitar el doble gasto.

Para resolverlo propusimos una red entre pares que utiliza prueba de trabajo para registrar un historial público de transacciones, y que se vuelve computacionalmente impracticable de alterar para un atacante si los nodos honestos controlan la mayor parte de la potencia de cómputo.

La red es robusta por su sencillez sin estructura. Los nodos trabajan todos a la vez con poca coordinación. No necesitan identificarse, ya que los mensajes no se dirigen a ningún destino concreto y basta con entregarlos con el mejor esfuerzo posible. Los nodos pueden entrar y salir de la red a voluntad, aceptando la cadena de prueba de trabajo como constancia de lo ocurrido mientras estuvieron ausentes.

Votan con su capacidad de cómputo, expresando su aceptación de los bloques válidos al trabajar en extenderlos y rechazando los inválidos al negarse a hacerlo. Cualquier regla e incentivo necesarios pueden imponerse con este mecanismo de consenso.

Referencias

1. W. Dai, «b-money», 1998.
2. H. Massias, X.S. Avila y J.-J. Quisquater, «Design of a secure timestamping service with minimal trust requirements», 20th Symposium on Information Theory in the Benelux, mayo de 1999.
3. S. Haber y W.S. Stornetta, «How to time-stamp a digital document», Journal of Cryptology, vol. 3, n.º 2, páginas 99-111, 1991.
4. D. Bayer, S. Haber y W.S. Stornetta, «Improving the efficiency and reliability of digital time-stamping», Sequences II: Methods in Communication, Security and Computer Science, páginas 329-334, 1993.
5. S. Haber y W.S. Stornetta, «Secure names for bit-strings», Proceedings of the 4th ACM Conference on Computer and Communications Security, páginas 28-35, abril de 1997.
6. A. Back, «Hashcash — a denial of service counter-measure», 2002.
7. R.C. Merkle, «Protocols for public key cryptosystems», Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, páginas 122-133, abril de 1980.
8. W. Feller, An introduction to probability theory and its applications, 1957.