Bitcoin: Un Sistema de Dinero Electrónico Peer-to-Peer

Satoshi Nakamoto 

[email protected] 

www.bitcoin.org 

Resumen.

Una versión puramente peer-to-peer de dinero electrónico permitiría que los pagos en línea fuesen enviados directamente de una parte a otra sin tener que pasar a través de una institución financiera. Las firmas digitales proveen parte de la solución, pero los principales beneficios se pierden si un tercero confiable aún es necesario para prevenir el doble gasto. Proponemos una solución al problema del doble gasto utilizando una red peer-to-peer. La red hace marcas horarias a las transacciones troceándolas (hashing) en una cadena continua de prueba-de-trabajo basada en hash, formando un registro que no puede ser cambiado sin re-hacer la prueba-de-trabajo. La cadena más larga no sólo sirve como prueba de la secuencia de eventos presenciada, sino también prueba que vino del grupo más grande de poder CPU. Siempre y cuando una mayoría de poder CPU sea controlada por nodos que no estén cooperando para atacar la red, generarán la cadena más larga y superarán los atacantes. La red en sí misma requiere una estructura mínima. Los mensajes son transmitidos en un principio de mejor esfuerzo, y los nodos pueden abandonar y volver a unirse a la red a voluntad, aceptando la cadena más larga de prueba-de-trabajo como prueba de lo que ocurrió mientras estuvieron fuera. 

  • Introducción 

El comercio en Internet ha terminado confiando casi exclusivamente en instituciones financieras, las cuales sirven como actores confiables para procesar transacciones y pagos electrónicos. Si bien el sistema funciona lo suficientemente bien para la mayoría de las transacciones, aún sufre por las inherentes debilidades del modelo basado en la confianza. Las transacciones completamente no-reversibles no son realmente posibles, dado que las instituciones financieras no pueden evitar mediar disputas. El costo de la mediación aumenta los costos de transacción, limitando el tamaño de transacción mínimo práctico y eliminando la posibilidad de transacciones casuales y pequeñas, habiendo además un costo más amplio en la pérdida de habilidad de hacer pagos no reversibles, por servicios no reversibles. Con la posibilidad de la anulación, la necesidad de confianza se propaga. Los mercaderes deben de tener cautela con sus clientes, demandándoles más información de la que de cualquier otra manera necesitarían. Un cierto porcentaje de fraude es aceptado como inevitable. Estos costos e incertidumbres de pago pueden ser evitadas en persona utilizando moneda física, pero ningún mecanismo existe para hacer pagos a través de un canal de comunicaciones sin un actor confiable. 

Lo que se necesita es un sistema de pagos electrónicos basado en pruebas criptográficas en vez de confianza, permitiendo que dos actores cualquiera realicen transacciones directamente entre sí, sin necesidad de un tercer actor confiable. Las transacciones que son informáticamente in-prácticas de revertir protegerían a los vendedores de fraude, mientras que mecanismos de garantía de rutina podrían, fácilmente, ser implementados para proteger a los compradores. En este documento, proponemos una solución al problema del doble gasto, usando un servidor de estampa horaria distribuida peer-to-peer para generar prueba informática del orden cronológico de las transacciones. El sistema es seguro siempre y cuando los nodos honestos controlen colectivamente más poder CPU que cualquier otro grupo cooperador de nodos atacantes. 

  • Transacciones

Definimos una moneda electrónica como una cadena de firmas digitales. Cada dueño transfiere la moneda al siguiente firmando digitalmente un trozo (hash) de la transacción previa y la clave pública del próximo dueño, agregando estos 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 dueños no hizo un doble gasto de la moneda. Una solución común es introducir una autoridad central confiable, o casa de moneda, que chequee cada transacción en búsqueda de gasto doble. Después de cada transacción, la moneda debe ser devuelta a la casa de moneda para emitir una nueva, y sólo las monedas emitidas directamente desde la casa de moneda llevan la confianza de no haber sido doblemente gastadas. El problema con esta solución es que el destino de todo el sistema monetario depende de la compañía dirigiendo la casa de moneda, siendo necesario que todas las transacciones pasen a través de ellos, tal como un banco. Necesitamos una manera de que el beneficiario sepa que el dueño previo no firmó ninguna transacción anterior. Para nuestros propósitos, la transacción más temprana es la que cuenta, así que no nos interesan intentos posteriores de doble gasto. La única manera de confirmar la ausencia de una transacción es estar al tanto de todas las transacciones. En el modelo basado en casa de moneda, esta está al tanto de todas las transacciones y decide cuál llega primero. Para lograr esto sin necesidad de un tercero confiable, las transacciones deben ser públicamente anunciadas [1], y necesitamos un sistema para que los participantes acuerden un solo historial del orden en el que estas fueron recibidas. El beneficiario necesita prueba de que, al momento de cada transacción, la mayoría de los nodos estuvo de acuerdo en que era la primera en ser recibida.

  • Servidor de Estampa de Tiempo

La solución que proponemos comienza con un servidor de estampa de tiempo. Un servidor de estampa de tiempo trabaja tomando un trozo de un bloque de elementos a ser estampados, al tiempo que publica ampliamente el trozo, ya sea en un periódico o un post de Usenet [2-5]. La estampa de tiempo prueba que los datos debieron de haber existido en el momento, obviamente, para poder entrar en el trozo o hash. Cada estampa de tiempo incluye la estampa de tiempo previa en su trozo, formando una cadena, con cada estampa de tiempo adicional reforzando a las que le preceden. 

  • Prueba-de-Trabajo

Para implementar un servidor de estampa de tiempo distribuido en una base peer-to-peer, necesitaremos usar un sistema de prueba-de-trabajo similar al Hashcash [6] de Adam Back, en vez de un periódico o publicaciones de Usenet. La prueba-de-trabajo involucra escanear un valor que, al ser troceado, tal como con SHA-256, el trozo comience con un número de cero bits. El trabajo promedio requerido es exponencial al número de cero bits requerido y puede ser verificado al ejecutar un único hash o trozo. Para nuestra red de estampa de tiempo, implementamos la prueba-de-trabajo al incrementar un nonce en el bloque hasta que se encuentra un valor que entregue al trozo del bloque los requeridos cero bits. Una vez el esfuerzo CPU ha sido gastado para satisfacer la prueba-de-trabajo, el bloque no puede ser cambiado sin rehacer el trabajo. A medida que los bloques posteriores son encadenados después de este, el trabajo para cambiar el bloque incluiría rehacer todos los bloques posteriores.

La prueba de trabajo también resuelve el problema de determinar la representación en la toma de decisiones mayoritaria. Si la mayoría estuviese basada en una-dirección-IP-un-voto, podría ser subvertida por cualquiera capaz de asignar muchas IPs. La prueba-de-trabajo es esencialmente, un-CPU-un-voto. La decisión mayoritaria está representada por la cadena más larga, la cual tiene el mayor esfuerzo de prueba-de-trabajo invertido en ella. Si una mayoría de poder CPU es controlado por nodos honestos, la cadena honesta crecerá más rápido y superará a cualquier cadena competidora. Para modificar un bloque pasado, un atacante debería tener que rehacer la prueba-de-trabajo del bloque y todos los bloques que le siguen, para luego ponerse al día con y sobrepasar el trabajo de los nodos honestos. Mostraremos más adelante que la probabilidad de que un atacante más lento se ponga al día disminuye exponencialmente a medida que los bloques subsecuentes son agregados. Para compensar por la velocidad de hardware en aumento y el interés variante en los nodos ejecutables a través del tiempo, la dificultad de la prueba-de-trabajo es determinada por un promedio movible focalizado en un número promedio de bloques por hora. Si estos se generan muy rápido, la dificultad aumenta. 

  • Red

Los pasos para ejecutar la red son los siguientes: 1) Nuevas transacciones son transmitidas a todos los nodos. 2) Cada nodo recolecta las nuevas transacciones en un bloque. 3) Cada nodo trabaja en encontrar una prueba-de-trabajo difícil para su bloque. 4) Cuando un nodo encuentra una prueba-de-trabajo, transmite el bloque a todos los nodos. 5) Los nodos aceptan el bloque sólo si todas las transacciones en él son válidas y no han sido ya gastadas. 6) Los nodos expresan su aceptación del bloque trabajando en crear el próximo bloque en la cadena, usando el trozo del bloque aceptado como el trozo previo. Los nodos siempre consideran que la cadena más larga es la correcta, por lo que seguirán trabajando para extenderla. Si dos nodos emiten diferentes versiones del siguiente bloque simultáneamente, algunos nodos podrían recibir una o la otra primero. En ese caso, trabajarán en la primera que reciban, pero guardarán la otra rama en caso de que esta se vuelva más larga. El nudo puede ser roto cuando la próxima prueba-de-trabajo se encuentre y una rama se haga más larga; los nodos que estaban trabajando en la otra rama entonces cambiarán a la más larga. 

Las emisiones de nuevas transacciones no necesariamente deben llegar a todos los nodos. Siempre y cuando alcancen a varios nodos, entrarán en un bloque antes que pase mucho tiempo. Las emisiones de bloques son también tolerantes a mensajes eliminados. Si un nodo no recibe un bloque, lo requerirá cuando reciba el próximo bloque y se dé cuenta de que se ha saltado uno. 

  • Incentivo

Por convención, la primera transacción en un bloque es una transacción especial que empieza una nueva moneda, propiedad del creador del bloque. Esto agrega un incentivo para que los nodos apoyen la red, además de proveer una manera de distribuir monedas inicialmente para su circulación, dado que no existe autoridad central para emitirlas. La adición estable de un número constante de nuevas monedas es análogo a los mineros de oro gastando recursos para agregar oro a la circulación. En nuestro caso, es el tiempo de CPU y la electricidad lo que se gasta. 

El incentivo también puede ser financiado con tasas de transacción. Si el valor de salida de una transacción es menor a su valor de entrada, la diferencia es una tasa de transacción que se agrega al valor incentivo del bloque que contiene dicha transacción. Una vez un número predeterminado de monedas ha entrado en circulación, el incentivo puede transicionar enteramente a tasas de transacción y estar completamente libre de inflación. 

El incentivo puede ayudar a motivar a los nodos a mantenerse honestos. Si un atacante codicioso es capaz de ensamblar más poder de CPU que todos los nodos honestos, deberá de escoger entre usarlo para defraudar a las personas, robando sus pagos, o usarlo para generar nuevas monedas. Deberá de encontrar mucho más rentable el jugar bajo las reglas, reglas que le favorecen con más monedas nuevas, que perjudicar el sistema y la validez de sus propias riquezas. 

  • Recuperando Espacio de Disco

Una vez que la última transacción en una moneda está enterrada bajo suficientes bloques, las transacciones gastadas antes pueden ser descartadas para salvaguardar espacio en disco. Para facilitar esto sin romper el trozo de bloque, las transacciones son troceadas en un Árbol Merkle [7][2][5], con sólo la raíz incluida en el trozo de bloque. Los bloques viejos pueden ser entonces compactados al cortar ramas del árbol. Los trozos interiores no necesitan ser almacenados. 

Un encabezado de bloque sin transacciones sería de alrededor de 80 bytes. Si suponemos que los bloques son generados cada 10 minutos, 80 bytes * 6 * 24 * 365 = 4.2MB por año. Considerando que usualmente, en el año 2008, los sistemas informáticos se venden con 2GB de RAM, y considerando que la Ley de Moore predice un actual crecimiento de 1.2GB por año, el almacenamiento no debería ser un problema incluso si los encabezados de bloque deben ser guardados en la memoria. 

  • Verificación Simplificada de Pago

Es posible verificar pagos sin ejecutar un nodo de red completo. Un usuario sólo necesita una copia de los encabezados de bloque de la cadena de prueba-de-trabajo más larga, lo que puede ser obtenido cuestionando a los nodos de red hasta que se esté convencido de tener la cadena más larga, obteniendo así la rama Merkle que enlaza la transacción al bloque en la que está estampado en el tiempo. No puede chequear la transacción por sí mismo, pero al enlazarla a un lugar en la cadena, puede ver que un nodo de red lo ha aceptado, y los bloques agregados después de este confirmarán que la red lo ha aceptado. 

De tal forma, la verificación es confiable siempre y cuando la red sea controlada por nodos honestos, pero es más vulnerable si la red es dominada por un atacante. Mientras que los nodos de red pueden verificar transacciones por sí mismos, el método simplificado puede ser embaucado por las transacciones fabricadas de un atacante, por tanto tiempo como el atacante continúe dominando la red. Una estrategia para protegerse contra esto sería aceptar alertas de nodos de red cuando detectan un bloque inválido, impulsando al software del usuario a descargar el bloque entero y alertar las transacciones para confirmar la inconsistencia. Los negocios que reciben pagos frecuentemente probablemente aún querrán ejecutar sus propios nodos para seguridad más independiente y verificación más rápida. 

  • Combinando y Dividiendo Valores

Aunque sería posible manejar monedas individualmente, sería inmanejable hacer una transacción separada por cada centavo en una transferencia. Para permitir que los valores se dividan y combinen, las transacciones contienen múltiples entradas y salidas. Normalmente, habrá ya sea una sola entrada de una transacción previa más grande, o múltiples entradas combinando cantidades más pequeñas, y a lo más, dos salidas: una para el pago y otra para devolver el cambio, si es que lo hay, al emisor. 

Debería ser acotado que aquellos casos en los que una transacción depende de varias transacciones, estas a su vez dependiendo de muchas transacciones más, no es un problema aquí. No existe nunca la necesidad de extraer una copia independiente única de un historial de transacción. 

  • Privacidad

El modelo de banca tradicional alcanza un cierto nivel de privacidad al limitar los accesos a la información de las partes involucradas y el tercer actor confiable. La necesidad de anunciar todas las transacciones públicamente excluye este método, pero la privacidad puede aún mantenerse al romper el flujo de información en otro lugar: manteniendo las claves públicas anónimas. El público puede ver que alguien está enviando una cantidad a otra persona, pero sin información enlazando la transacción a nadie en específico. Esto es similar al nivel de información revelada por los intercambios de acciones, donde el tiempo y el tamaño de los intercambios individuales se hace público pero sin revelar cuáles fueron las partes involucradas. 

Como si fuera un firewall adicional, un nuevo par de claves debe ser usado para cada transacción, evitando así que estas sean enlazadas a un dueño en común. Algún enlazamiento es aún inevitable con transacciones multi-entrada, las cuales necesariamente revelan que sus entradas eran propiedad del mismo dueño. El riesgo es que si el dueño de una clave es revelado, el enlazado podría develar otras transacciones pertenecientes a la misma persona.

  • Cálculos

Consideremos el escenario de un atacante intentando generar una cadena alterna más rápido que la cadena honesta. Incluso si esto es logrado, no habilita los cambios arbitrarios en el sistema, tales como crear valores de la nada o tomar dinero que nunca perteneció al atacante. Los nodos no van a aceptar una transacción inválida como pago, y los nodos honestos nunca aceptará un bloque que las contenga.  Un atacante solo puede intentar cambiar una de sus propias transacciones para tomar de vuelta dinero que recientemente gastó. 

La carrera entre la cadena honesta y la cadena de un atacante puede ser caracterizada como una Caminata Binomial Aleatoria. El evento exitoso es que la cadena honesta se extienda por un bloque, aumentando su ventaja a +1, mientras que el evento fallido sería que la cadena del atacante sea extendida por un bloque, reduciendo la diferencia en -1. 

La probabilidad de que un atacante se ponga al día con un déficit dado es análoga al problema de Ruina de un Apostador. Supongamos que un apostador con crédito ilimitado empieza en déficit y juega potencialmente un número infinito de pruebas para intentar emparejarse. Podemos calcular la probabilidad de que alguna vez alcance a estar parejo, o que un atacante alguna vez alcance el ritmo de la cadena honesta, como sigue [8]:

p = probabilidad de que un nodo honesto encuentre el próximo bloque

q = probabilidad de que el atacante encuentre el próximo bloque

qz= probabilidad de que el atacante alguna vez recupere terreno de z bloques detrás

Dada nuestra suposición de que p > q, la probabilidad cae exponencialmente a medida que el número de bloques con los que el atacante debe ponerse al día aumenta. Con las probabilidades en su contra, si no toma un salto de suerte desde el principio, sus oportunidades se vuelven cada vez más pequeñas a medida que se va quedando atrás. Ahora consideramos cuánto tiene que esperar el recipiente de una nueva transacción antes de estar lo suficientemente seguro de que el emisor no puede cambiar la transacción. Asumimos que el emisor es un atacante que quiere hacer creer al receptor que le pagó por unos momentos, para entonces cambiar a que el pago llegue a sí mismo luego de cierto tiempo. El receptor será alertado cuando esto pase, pero el emisor espera que para entonces ya sea demasiado tarde. El receptor genera un nuevo par de claves y entrega la clave pública al emisor poco después de firmar. Esto previene que el emisor prepare una cadena de bloques antes de tiempo trabajando en ella continuamente hasta que sea lo suficientemente afortunado como para adelantarse lo suficiente, para luego ejecutar la transacción en ese momento. Una vez que la transacción es enviada, el emisor deshonesto empieza a trabajar en secreto en una cadena paralela conteniendo una versión alternativa de su transacción. El receptor espera hasta que la transacción ha sido agregada a un bloque y z bloques han sido enlazados después de este. No conoce la cantidad de progreso exacta que ha hecho el atacante, pero asumiendo que los bloques honestos se tomaron el tiempo promedio esperado por bloque, el progreso potencial del atacante será una distribución Poisson con valor esperado:

Para obtener la probabilidad de que el atacante pudiese aún ponerse al día ahora, multiplicamos la densidad Poisson por cada cantidad de progreso que este pudo haber hecho  por la probabilidad de que pudiese alcanzarle desde ese punto:

Reordenando para evitar totalizar la cola infinita de distribución:

Convirtiendo a código C:

#incluir

doble ProbabillidadDeExitoDelAtacante(doble q, int z)

{

 doble p = 1.0 – q;

 doble lambda = z * (q / p);

 doble sum = 1.0;

 int i, k;

 para (k = 0; k <= z; k++)

 {

 doble poisson = exp(-lambda);

 para (i = 1; i <= k; i++)

 poisson *= lambda / i;

 sum -= poisson * (1 – pow(q / p, z – k));

 }

 regresar sum;

 

Ejecutando 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 con P menor a 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 de transacciones electrónicas que no requiera de la confianza. Empezamos con el marco de trabajo usual de monedas hechas de firmas digitales, lo cual provee un control de propiedad fuerte, pero está incompleto si no hay una manera de prevenir el doble gasto. Para resolver esto, propusimos una red peer-to-peer que utilice la prueba-de-trabajo para grabar un historial público de transacciones que, rápidamente, vuelve  informáticamente impráctica la posibilidad de que un atacante lo cambie si nodos honestos controlan una mayoría de poder CPU. La red es robusta en su simplicidad inestructurada. Los nodos trabajan todos a la vez con poca coordinación. No necesitan ser identificados, dado que los mensajes no están dirigidos a ningún lugar en particular y sólo necesitan ser entregados en una base al 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 ocurrió mientras estaban fuera. Votan con su poder CPU, expresando su aceptación de bloques válidos trabajando en extenderlos y rechazando bloques inválidos al rehusarse a trabajar en ellos. Cualquier reglamento e incentivo necesario puede ser reforzado 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, “Diseño de un servicio de estampa de tiempo seguro con mínimos requerimientos de confianza,” en el 20º Simposio de Teoría de la Información en el Benelux, Mayo 1999. 

[3] S. Haber, W.S. Stornetta, “Cómo estampar en el tiempo un documento digital,” En el Journal de Criptología, vol 3, no 2, páginas 99-111, 1991. 

[4] D. Bayer, S. Haber, W.S. Stornetta, “Aumentando la eficiencia y confiabilidad del estampado de tiempo digital,” En Secuencias II: Métodos en Comunicación, Seguridad y Ciencias Informáticas, páginas 329-334, 1993. 

[5] S. Haber, W.S. Stornetta, “Nombres seguros para cadenas de bits,” En Procesos de la 4ta Conferencia ACM en Seguridad Informática y de Comunicaciones, páginas 28-35, Abril 1997. 

[6] A. Back, “Hashcash – una contra-medida de negación de servicio,” http://www.hashcash.org/papers/hashcash.pdf, 2002. 

[7] R.C. Merkle, “Protocolos de criptosistemas de clave pública,” En Proc. Simposio de Seguridad y Privacidad 1980, IEEE Computer Society, páginas 122-133, Abril 1980. 

[8] W. Feller, “Una introducción a la teoría de las probabilidades y sus aplicaciones,” 1957.

 

 

Fuente: https://nakamotoinstitute.org/static/docs/bitcoin.pdf