Bitcoin: un sistema de dinero electrónico entre iguales

autor

: Satoshi Nakamoto

correo electrónico

sitio

Resumen. Una versión puramente peer-to-peer de dinero electrónico permitiría
permitir que los pagos en línea se envíen directamente de una parte a otra
sin pasar por una entidad financiera. Las firmas digitales
parte de la solución, pero las principales ventajas se pierden si se sigue necesitando un
tercero de confianza para evitar el doble gasto. En
proponemos una solución al problema del doble gasto mediante una red
entre iguales. La red marca el tiempo de las transacciones introduciéndolas en una
en una cadena continua de pruebas de trabajo basadas en hash, formando un registro que no puede modificarse sin rehacer la prueba de trabajo.
sin rehacer la prueba de trabajo. La cadena más larga no sólo
sirve como prueba de la secuencia de eventos presenciados, sino como prueba de que
proviene del mayor conjunto de CPU. Mientras la mayoría de la CPU
CPU esté controlada por nodos que no cooperan para atacar la red.
red, generarán la cadena más larga y superarán a los atacantes. La red
red requiere una estructura mínima. Los mensajes se difunden
y los nodos pueden abandonar la red y volver a unirse a ella a voluntad,
aceptando la cadena de prueba de trabajo más larga como prueba de lo que ocurrió
de lo que ha ocurrido en su ausencia.

Introducción

El comercio en Internet se ha basado casi exclusivamente en
instituciones financieras que actúan como terceros de confianza para procesar
pagos electrónicos. Aunque el sistema funciona bastante bien para la mayoría de
transacciones, sigue adoleciendo de las debilidades inherentes al modelo basado en la confianza.
confianza. Las transacciones totalmente irreversibles no son realmente posibles, ya que las instituciones financieras no pueden evitar mediar en las disputas.
posibles, ya que las instituciones financieras no pueden evitar mediar en las disputas.
El coste de la mediación aumenta los costes de transacción, limitando el tamaño mínimo
transacciones, limitando el tamaño mínimo práctico de las transacciones y eliminando la posibilidad de pequeñas transacciones casuales.
transacciones casuales, y hay un coste más amplio en la pérdida de capacidad
de realizar pagos no reversibles por servicios no reversibles. Con la
posibilidad de reversión, se extiende la necesidad de confianza. Los comerciantes deben
de sus clientes y pedirles más información de la que necesitarían.
de la que necesitarían. Un cierto porcentaje de fraude se acepta como
inevitable. Estos costes e incertidumbres de pago pueden evitarse en
en persona utilizando moneda física, pero no existe ningún mecanismo para hacer
pagos a través de un canal de comunicación sin una parte de confianza.

Lo que se necesita es un sistema de pago electrónico basado en pruebas criptográficas en lugar de en la confianza.
criptográfica en lugar de en la confianza, que permita a dos partes
directamente entre sí sin necesidad de un tercero de confianza.
Las transacciones que son computacionalmente impracticables de revertir protegerían a los vendedores del fraude.
protegerían a los vendedores del fraude, y para proteger a los compradores podrían aplicarse
para proteger a los compradores. En este artículo proponemos una solución
al problema del doble gasto mediante un servidor de marcas de tiempo
para generar pruebas computacionales del orden cronológico de las transacciones.
cronológico de las transacciones. El sistema es seguro siempre que los nodos honestos
controlen colectivamente más potencia de CPU que cualquier grupo de nodos
nodos atacantes.

Transacciones

Definimos una moneda electrónica como una cadena de firmas digitales. Cada propietario de
propietario transfiere la moneda al siguiente firmando digitalmente un hash de la
transacción anterior y la clave pública del siguiente propietario y añadiendo
al final de la moneda. Un beneficiario puede verificar las firmas para
verificar la cadena de propiedad.

El problema, por supuesto, es que el beneficiario no puede verificar que uno de los propietarios
no gastó dos veces la moneda. Una solución común es introducir una
autoridad central de confianza, o casa de la moneda, que compruebe cada transacción para
doble gasto. Después de cada transacción, la moneda debe devolverse a la ceca para que emita una nueva moneda.
a la Fábrica de la Moneda para que emita una nueva moneda, y sólo se confía en que las monedas emitidas directamente por la Fábrica de la Moneda no hayan sido gastadas dos veces.
de la fábrica de la moneda. El problema de esta solución
es que el destino de todo el sistema monetario depende de la empresa
que gestiona la fábrica de la moneda, ya que cada transacción tiene que pasar por ellos, al igual que
como un banco.

Necesitamos una forma de que el beneficiario sepa que los propietarios anteriores no firmaron ninguna transacción anterior.
no firmaron ninguna transacción anterior. Para nuestros propósitos, la transacción
transacción es la que cuenta, así que no nos importan los posteriores
intentos posteriores de doble gasto. La única forma de confirmar la ausencia de una
transacción es estar al tanto de todas las transacciones. En el modelo basado en la casa de la moneda,
la casa de la moneda estaba al tanto de todas las transacciones y decidía cuál llegaba primero.
Para lograr esto sin una parte de confianza, las transacciones deben ser
anunciarse públicamente[^1], y necesitamos un sistema para que los participantes se pongan de acuerdo
en un único historial del orden en que se recibieron. El beneficiario
necesita pruebas de que en el momento de cada transacción, la mayoría de los nodos
acordaron que fue la primera recibida.

Servidor de marcas de tiempo

La solución que proponemos comienza con un servidor de marcas de tiempo. Un servidor
Un servidor de marcas de tiempo funciona tomando un hash de un bloque de elementos a los que se les va a poner una marca de tiempo y publicando ampliamente el hash, por ejemplo, en un sitio web.
y lo publica ampliamente, por ejemplo en un periódico o en Usenet.
post[^2][^3][^4][^5]. La marca de tiempo demuestra que los datos
existir en ese momento, obviamente, para poder entrar en el hash. Cada
marca de tiempo incluye la marca de tiempo anterior en su hash, formando una cadena,
Cada marca de tiempo adicional refuerza las anteriores.

Prueba de trabajo

Para implementar un servidor de marcas de tiempo distribuido de igual a igual, necesitaremos
necesitaremos utilizar un sistema de prueba de trabajo similar a Hashcash
[^6] de Adam Back, en lugar de periódicos o mensajes de Usenet. La prueba de trabajo consiste en
la búsqueda de un valor que cuando se hash, como con SHA-256, el hash
comience con un número de bits cero. El trabajo medio requerido es
exponencial en el número de bits cero necesarios y puede verificarse
ejecutando un único hash.

Para nuestra red de marcas de tiempo, implementamos la prueba de trabajo mediante
incrementando un nonce en el bloque hasta que se encuentra un valor que da al
hash del bloque los cero bits necesarios. Una vez que el esfuerzo de la CPU
para hacer que satisfaga la prueba de trabajo, el bloque no puede ser
cambiar sin rehacer el trabajo. Como los bloques posteriores se encadenan después de él,
el trabajo para cambiar el bloque incluiría rehacer todos los bloques después de
de él

La prueba de trabajo también resuelve el problema de determinar la representación
en la toma de decisiones por mayoría. Si la mayoría se basara en
una dirección IP, un voto, podría ser subvertida por cualquiera capaz de asignar muchas direcciones IP.
asignar muchas IPs. Proof-of-work es esencialmente una CPU por voto. La decisión mayoritaria de
decisión mayoritaria está representada por la cadena más larga, que tiene el
mayor esfuerzo de prueba de trabajo invertido en ella. Si la mayoría de la CPU
está controlada por nodos honestos, la cadena honesta crecerá más rápido
y superará a cualquier cadena competidora. Para modificar un bloque anterior, un atacante
tendría que rehacer la prueba de trabajo del bloque y de todos los bloques posteriores.
y después alcanzar y superar el trabajo de los nodos honestos. En
demostraremos más adelante que la probabilidad de que un atacante lento se ponga al día
disminuye exponencialmente a medida que se añaden bloques.

Para compensar el aumento de la velocidad del hardware y el interés variable en
nodos en funcionamiento a lo largo 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.

Red

Los pasos para hacer funcionar la red son los siguientes:

Las nuevas transacciones se difunden a todos los nodos.
Cada nodo recopila las nuevas transacciones en un bloque.
Cada nodo trabaja para encontrar una prueba de trabajo difícil para su bloque.
Cuando un nodo encuentra una prueba de trabajo, difunde el bloque a todos los nodos.
nodos.
Los nodos aceptan el bloque sólo si todas las transacciones que contiene son válidas y no se han gastado.
y no se han gastado.
Los nodos expresan su aceptación del bloque trabajando para crear
el siguiente bloque de la cadena, utilizando el hash del bloque aceptado como
el hash anterior.

Los nodos siempre consideran que la cadena más larga es la correcta y seguirán trabajando para ampliarla.
y seguirán trabajando para ampliarla. Si dos nodos difunden versiones diferentes
del siguiente bloque simultáneamente, algunos nodos pueden recibir uno u otro primero.
otro primero. En ese caso, trabajan en la primera que recibieron, pero
guardan la otra rama por si se alarga. El empate se romperá
cuando se encuentre la siguiente prueba de trabajo y una de las ramas se alargue.
nodos que estaban trabajando en la otra rama cambiarán entonces a la
rama más larga.

Las transmisiones de nuevas transacciones no tienen por qué llegar a todos los nodos.
Mientras lleguen a muchos nodos, no tardarán en entrar en un bloque.
tiempo. Las transmisiones en bloque también toleran los mensajes perdidos. Si un nodo
Si un nodo no recibe un bloque, lo solicitará cuando reciba el siguiente bloque y se dé cuenta de que ha perdido uno.
bloque y se dé cuenta de que ha perdido uno.

Incentivo

Por convención, la primera transacción de un bloque es una transacción especial
que inicia una nueva moneda propiedad del creador del bloque. Esto añade un incentivo
incentivo para que los nodos apoyen la red, y proporciona una forma de
distribuir inicialmente las monedas en circulación, ya que no hay una autoridad
central que las emita. La adición constante de una cantidad constante de
nuevas monedas es análoga a los mineros de oro que gastan recursos para añadir oro a la
a la circulación. En nuestro caso, lo que se gasta es tiempo de CPU y electricidad.
electricidad.

El incentivo también puede financiarse con comisiones por transacción. Si el valor
Si el valor de salida de una transacción es menor que su valor de entrada, la diferencia es una tasa de transacción que se añade al valor de incentivo del bloque.
que se añade al valor del incentivo del bloque que contiene la transacción.
que contiene la transacción. Una vez que un número predeterminado de monedas
de monedas en circulación, el incentivo puede pasar a ser
de transacción y estar completamente libre de inflación.

El incentivo puede ayudar a animar a los nodos a mantenerse honestos. Si un atacante
atacante es capaz de reunir más potencia de CPU que todos los nodos honestos,
tendría que elegir entre usarla para defraudar a la gente robando
sus pagos, o utilizarla para generar nuevas monedas. Debería
más rentable jugar según las reglas, unas reglas que le favorecen con
más monedas nuevas que todos los demás juntos, que socavar el sistema
y la validez de su propia riqueza.

Recuperar espacio en disco

Una vez que la última transacción de una moneda está enterrada bajo suficientes bloques, las
transacciones anteriores pueden descartarse para ahorrar espacio en disco. Para
facilitar esto sin romper el hash del bloque, las transacciones se
en un árbol Merkle[^7][^8][^9], y sólo la raíz se incluye en el hash del bloque.
hash del bloque. Los bloques antiguos se pueden compactar eliminando ramas
del árbol. No es necesario almacenar los hashes interiores.

Una cabecera de bloque sin transacciones ocuparía unos 80 bytes. Si
Si suponemos que los bloques se generan cada 10 minutos, 80 bytes * 6 * 24 * 365 = 4,2 MB al año.
365 = 4,2 MB al año. Con los sistemas informáticos que suelen venderse con 2 GB
de RAM a partir de 2008, y la Ley de Moore predice un crecimiento actual de 1,2 GB
por año, el almacenamiento no debería ser un problema, incluso si las cabeceras de bloque deben mantenerse en memoria.
en memoria.

Verificación de pagos simplificada

Es posible verificar los pagos sin ejecutar un nodo de red completo. A
Un usuario sólo necesita guardar una copia de las cabeceras de bloque de la cadena de prueba de trabajo más larga.
de la cadena de prueba de trabajo más larga, que puede obtener consultando los nodos de la red hasta que esté convencido de que tiene la cadena de prueba de trabajo más larga.
que esté convencido de que tiene la cadena más larga, y obtener la rama Merkle
…que vincula la transacción con el bloque en el que está registrada. No puede
comprobar la transacción por sí mismo, pero mediante la vinculación a un lugar en el
…puede ver que un nodo de la red la ha aceptado, y los bloques agregados…
después confirman que la red la ha aceptado.

Así, la verificación es fiable mientras los nodos honestos controlen la red.
controlen la red, pero es más vulnerable si la red es dominada por un
atacante. Aunque los nodos de la red pueden verificar las transacciones por sí mismos,
el método simplificado puede ser engañado por un atacante.
mientras el atacante siga dominando la red.
red. Una estrategia para protegerse de esto sería aceptar alertas
de los nodos de la red cuando detecten un bloque inválido.
de descargar el bloque completo y las transacciones alertadas para confirmar la inconsistencia.
para confirmar la incoherencia. Las empresas que reciben pagos frecuentes
nodos propios para una seguridad más independiente y una verificación más rápida.
y una verificación más rápida.

Combinar y dividir valor

Aunque sería posible manejar las monedas de forma individual, sería
una transacción separada por cada céntimo de una transferencia. Para
dividir y combinar el valor, las transacciones contienen múltiples entradas y salidas.
entradas y salidas. Normalmente habrá una única entrada procedente de una
transacción anterior más grande o varias entradas que combinan
como máximo dos salidas: una para el pago y otra para devolver el cambio, si lo hay, al remitente.
el cambio, si lo hay, al remitente.

Hay que tener en cuenta que el fan-out, cuando una transacción depende de varias
transacciones, y esas transacciones dependen de muchas más, no es un
problema. Nunca es necesario extraer una copia completa e independiente del historial de una transacción.
del historial de una transacción.

Privacidad

El modelo bancario tradicional logra un nivel de privacidad limitando
acceso a la información a las partes implicadas y al tercero de confianza.
de confianza. La necesidad de anunciar públicamente todas las transacciones excluye este método.
este método, pero se puede mantener la privacidad interrumpiendo el flujo de
información en otro lugar: manteniendo el anonimato de las claves públicas. El público de
público puede ver que alguien está enviando una cantidad a otra persona, pero
pero sin información que vincule la transacción con nadie. Esto es similar
al nivel de información divulgada por las bolsas de valores, donde la hora
y el volumen de cada operación, la «cinta», se hace pública, pero sin decir quiénes son las partes.
quiénes son las partes.

Como cortafuegos adicional, debe utilizarse un nuevo par de claves para cada
para evitar que se vinculen a un propietario común. En
vinculación sigue siendo inevitable con las transacciones multientrada, que
necesariamente revelan que sus entradas pertenecían al mismo propietario. El riesgo
El riesgo es que si se revela el propietario de una clave, la vinculación podría revelar
otras transacciones que pertenecían al mismo propietario.

Cálculos

Consideramos el escenario de un atacante que intenta generar una cadena alternativa
alternativa más rápida que la cadena honesta. Aunque esto se consiga
el sistema a cambios arbitrarios, como crear valor de la nada o tomar dinero que
crear valor de la nada o tomar dinero que nunca perteneció al atacante.
atacante. Los nodos no van a aceptar una transacción inválida como pago.
como pago, y los nodos honestos nunca aceptarán un bloque que las contenga. Un atacante de
Un atacante sólo puede intentar cambiar una de sus propias transacciones para recuperar el dinero que ha gastado recientemente.
dinero que ha gastado recientemente.

La carrera entre la cadena honesta y una cadena atacante se puede
puede caracterizarse como un paseo aleatorio binomial. El evento de éxito es que la cadena honesta
honesta se amplía en un bloque, aumentando su ventaja en +1, y el
El evento de fracaso es que la cadena del atacante se extienda un bloque,
reduciendo la diferencia en -1.

La probabilidad de que un atacante se ponga al día a partir de un déficit dado es
análoga al problema de la ruina del jugador. Supongamos que un jugador con crédito ilimitado
crédito ilimitado comienza con un déficit y juega un número potencialmente infinito de pruebas para intentar alcanzar el punto de equilibrio.
pruebas para intentar alcanzar el punto de equilibrio. Podemos calcular la probabilidad de que
de que llegue al punto de equilibrio, o de que un atacante alcance a la
cadena honesta, como sigue[^10]:

| p = probabilidad de que un nodo honesto encuentre el siguiente bloque
| q = probabilidad de que el atacante encuentre el siguiente bloque
| qz = probabilidad de que el atacante alcance a z bloques por detrás

$$begin{aligned}
q_z =
…q_z = …q_z = …q_z = …q_z = …q_z =
1 & text{if } p leqslant q
left(q/pright)^z & text{if } p > q
fin{casos}
end{aligned}$$

Dada nuestra suposición de que p > q, la probabilidad cae exponencialmente a medida que
el número de bloques que el atacante tiene que alcanzar aumenta. Con
con las probabilidades en su contra, si no da un golpe de suerte pronto
sus posibilidades se desvanecen a medida que se retrasa.

Consideremos ahora cuánto tiempo debe esperar el destinatario de una nueva transacción
esperar antes de estar suficientemente seguro de que el emisor no puede cambiar la transacción.
transacción. Suponemos que el remitente es un atacante que quiere hacer creer al destinatario que le ha pagado durante un tiempo.
destinatario crea que le ha pagado durante un tiempo, y luego lo cambie para pagarse a
sí mismo después de que haya pasado algún tiempo. El receptor será alertado cuando
eso ocurra, pero el remitente espera que sea demasiado tarde.

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

El receptor espera hasta que la transacción se haya añadido a un bloque y
z bloques se hayan enlazado después de ella. No conoce la cantidad exacta de
progreso que ha hecho el atacante, pero suponiendo que los bloques honestos tardaron el
tiempo medio esperado por bloque, el progreso potencial del atacante será
será una distribución de Poisson con valor esperado:

$$lambda = z frac{q}{p}$$

Para obtener la probabilidad de que el atacante aún pueda alcanzarnos ahora, multiplicamos
multiplicamos la densidad de Poisson para cada cantidad de progreso que podría haber
…por la probabilidad de que pueda alcanzarlo desde ese punto:

$$begin{aligned}
suma _{k=0}^infty frac{lambda ^k e^{-lambda}} ¡k!} cdot
begin{casos}
izquierda(q/pderecha)^{(z-p)} & text{if } k leqslant z
1 y si k > z
y si k > z
end{aligned}$$

Reordenando para evitar sumar la cola infinita de la distribución…

$$1 – sum _{k=0}^z frac{lambda ^k e^{-lambda}}{k!} left(1 – left(q/pright)^{(z-k)}right)$$

Convirtiendo a código C…

#include <math.h> double ProbabilidadSuccesoAtacante(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; }

Corriendo algunos resultados, podemos ver que la probabilidad cae exponencialmente
con z.

q=0.1 z=0 P=1.0000000 z=1 P=0.2045873 z=2 P=0.0509779 z=3 P=0.0131722 z=4 P=0.0034552 z=5 P=0.0009137 z=6 P=0.0002428 z=7 P=0.0000647 z=8 P=0.0000173 z=9 P=0.0000046 z=10 P=0.0000012 q=0.3 z=0 P=1.0000000 z=5 P=0.1773523 z=10 P=0.0416605 z=15 P=0.0101008 z=20 P=0.0024804 z=25 P=0.0006132 z=30 P=0.0001522 z=35 P=0.0000379 z=40 P=0.0000095 z=45 P=0.0000024 z=50 P=0.0000006

Resolviendo para P inferior al 0,1%…

P < 0.001 q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z=340

Conclusión

Hemos propuesto un sistema para transacciones electrónicas sin depender de
confianza. Empezamos con el marco habitual de monedas hechas a partir de firmas
digital, que proporciona un fuerte control de la propiedad, pero es
incompleto sin una forma de evitar el doble gasto. Para solucionarlo
Para resolverlo, propusimos una red de igual a igual que utiliza la prueba de trabajo para registrar un historial público de transacciones que se convierte rápidamente en una prueba computacional.
público de transacciones que rápidamente se convierte en computacionalmente impracticable
si los nodos honestos controlan la mayoría de la potencia de la CPU.
de la CPU. La red es robusta en su simplicidad no estructurada. Los nodos trabajan
todos a la vez con poca coordinación. No necesitan identificarse,
ya que los mensajes no se dirigen a ningún lugar en particular y sólo necesitan
y sólo tienen que entregarse en función del mejor esfuerzo. Los nodos pueden abandonar y volver a unirse a la
red a voluntad, aceptando la cadena de prueba de trabajo como prueba de lo que ha ocurrido en su ausencia.
de lo que ha sucedido en su ausencia. Votan con su potencia de CPU,
expresan su aceptación de bloques válidos trabajando en su ampliación
y rechazan los bloques inválidos negándose a trabajar en ellos. Con
con este mecanismo de consenso.

Referencias

[^1]: W. Dai, «b-money», http://www.weidai.com/bmoney.txt, 1998.

[^2]: H. Massias, X.S. Avila y J.-J. Quisquater, «Design of a
secure timestamping service with minimal trust requirements».
En 20th Symposium on Information Theory in the Benelux,
mayo de 1999.

[^3]: S. Haber, W.S. Stornetta, «How to time-stamping a digital
digital», en Journal of Cryptology, vol. 3, nº 2, pp.
99-111, 1991.

[^4]: D. Bayer, S. Haber, W.S. Stornetta, «Improving the efficiency
and reliability of digital time-stamping,» In Sequences II:
Methods in Communication, Security and Computer Science, pp.
329-334, 1993.

[^5]: S. Haber, W.S. Stornetta, «Secure names for bit-strings», en
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».
http://www.hashcash.org/papers/hashcash.pdf, 2002.

[^7]: R.C. Merkle, «Protocols for public key cryptosystems», en Proc.
1980 Symposium on Security and Privacy, IEEE Computer Society, páginas
122-133, abril de 1980.

[^8]: H. Massias, X.S. Avila, y J.-J. Quisquater, «Design of a
secure timestamping service with minimal trust requirements».
En 20th Symposium on Information Theory in the Benelux,
mayo de 1999.

[^9]: S. Haber, W.S. Stornetta, «Secure names for bit-strings,» In
Proceedings of the 4th ACM Conference on Computer and
Communications Security, páginas 28-35, abril de 1997.

[^10]: W. Feller, «An introduction to probability theory and its
aplicaciones», 1957.