Bitcoin: un sistema de efectivo electrónico entre pares

Satoshi Nakamoto
satoshin@gmx.com
www.bitcoin.org

Resumen

Una versión puramente entre pares del efectivo electrónico permitiría enviar los pagos en línea directamente de una parte a otra sin pasar por una institución financiera. Las firmas digitales proporcionan parte de la solución, pero los principales beneficios se pierden si todavía se requiere un tercero de confianza para evitar el doble gasto. Proponemos una solución al problema del doble gasto utilizando una red punto a punto. Las marcas de tiempo de la red las llevan a una cadena continua de prueba de trabajo basada en hash, formando un registro que no se puede cambiar sin rehacer la prueba del trabajo. La cadena más larga no solo sirve como prueba de la secuencia de eventos presenciados, sino como prueba de que proviene del mayor grupo de poder de la CPU. Mientras la mayoría de la potencia de la CPU esté controlada por nodos que no cooperan para atacar la red, ellos’Generaré los atacantes de cadena y espacio más largos. La red en sí requiere una estructura mínima. Los mensajes se transmiten con el mejor esfuerzo, y los nodos pueden salir y volver a unirse a la red a voluntad, aceptando la cadena de prueba de trabajo más larga como prueba de lo que sucedió mientras se fueron.

1). Introducción

El comercio en Internet ha llegado a depender casi exclusivamente de instituciones financieras que sirven como terceros de confianza para procesar pagos electrónicos. Si bien el sistema funciona lo suficientemente bien para la mayoría de las transacciones, aún sufre las debilidades inherentes del modelo basado en la confianza. Las transacciones completamente no reversibles no son realmente posibles, ya 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 mínimo práctico de la transacción y cortando la posibilidad de pequeñas transacciones casuales, y existe un costo más amplio en la pérdida de capacidad para realizar pagos no reversibles por servicios no reversibles. Con la posibilidad de reversión, la necesidad de confianza se extiende. Los comerciantes deben tener cuidado con sus clientes, molestándolos para obtener más información de la que de otro modo necesitarían. Un cierto porcentaje de fraude se acepta como inevitable. Estos costos e incertidumbres de pago se pueden evitar en persona mediante el uso de moneda física, pero no existe un mecanismo para realizar pagos a través de un canal de comunicaciones sin una parte confiable.

Lo que se necesita es un sistema de pago electrónico basado en pruebas criptográficas en lugar de confianza, que permita a dos partes dispuestas realizar transacciones directas entre sí sin la necesidad de un tercero de confianza. Las transacciones que son computacionalmente poco prácticas para revertir protegerían a los vendedores del fraude, y los mecanismos de custodia de rutina podrían implementarse fácilmente para proteger a los compradores. En este documento, proponemos una solución al problema del doble gasto utilizando un servidor de marca de tiempo distribuido entre pares para generar pruebas computacionales del orden cronológico de las transacciones. El sistema es seguro siempre que los nodos honestos controlen colectivamente más poder de la CPU que cualquier grupo cooperante de nodos atacantes.

2). Transacciones

Definimos una moneda electrónica como una cadena de firmas digitales. Cada propietario transfiere la moneda a la siguiente firmando digitalmente un hash de la transacción anterior y la clave pública del próximo propietario y agregándolos 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 haya gastado la moneda dos veces. Una solución común es introducir una autoridad central de confianza, o menta, que verifique cada transacción para obtener el doble gasto. Después de cada transacción, la moneda debe devolverse a la moneda para emitir una nueva moneda, y solo se confía en que las monedas emitidas directamente desde la menta no se gasten dos veces. El problema con esta solución es que el destino de todo el sistema monetario depende de que la empresa ejecute la moneda, y que cada transacción tenga que pasar por ellos, al igual que un banco.

Necesitamos una forma para que el beneficiario sepa que los propietarios anteriores no firmaron ninguna transacción anterior. Para nuestros propósitos, la transacción más temprana es la que cuenta, por lo que no nos importan los intentos posteriores de doble gasto. La única forma de confirmar la ausencia de una transacción es conocer todas las transacciones. En el modelo basado en la menta, la menta estaba al tanto de todas las transacciones y decidió cuál llegó primero. Para lograr esto sin una parte confiable, las transacciones deben anunciarse públicamente^{[ 1 ]}, y necesitamos un sistema para que los participantes acuerden un solo historial del orden en que fueron recibidos. 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.

3). Servidor de marca de tiempo

La solución que proponemos comienza con un servidor de marca de tiempo. Un servidor de marca de tiempo funciona tomando un hash de un bloque de elementos para ser sellado con el tiempo y publicando ampliamente el hash, como en un periódico o en una publicación de Usenet^{[ 2-5 ]}. La marca de tiempo demuestra que los datos deben haber existido en ese momento, obviamente, para entrar en el hash. Cada marca de tiempo incluye la marca de tiempo anterior en su hash, formando una cadena, con cada marca de tiempo adicional reforzando las anteriores.

4). Prueba de trabajo

Para implementar un servidor de marca de tiempo distribuido en una base de igual a igual, necesitaremos usar un sistema de prueba de trabajo similar al Hashcash de Adam Back^{[ 6 ]}, en lugar de publicaciones en periódicos o Usenet. La prueba de trabajo implica buscar un valor que cuando se hash, como con SHA-256, el hash comienza con varios bits cero. El trabajo promedio requerido es exponencial en el número de bits cero requeridos y puede verificarse ejecutando un solo hash.

Para nuestra red de marcas de tiempo, implementamos la prueba de trabajo al incrementar un nonce en el bloque hasta que se encuentre un valor que le dé al hash del bloque los bits cero requeridos. Una vez que se ha gastado el esfuerzo de la CPU para que satisfaga la prueba del trabajo, el bloque no se puede cambiar sin rehacer el trabajo. A medida que los bloques posteriores estén encadenados, el trabajo para cambiar el bloque incluiría rehacer todos los bloques después.

La prueba de trabajo también resuelve el problema de determinar la representación en la toma de decisiones mayoritarias. Si la mayoría se basara en una dirección IP de un voto, podría ser subvertida por cualquiera que pueda asignar muchas IP. La prueba de trabajo es esencialmente un voto de CPU. La 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 potencia 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 pasado, un atacante tendría que rehacer la prueba del trabajo del bloque y todos los bloques después y luego ponerse al día y superar el trabajo de los nodos honestos. Más adelante mostraremos que la probabilidad de que un atacante más lento se ponga al día disminuye exponencialmente a medida que se agregan bloques posteriores.

Para compensar el aumento de la velocidad del hardware y el interés variable en ejecutar nodos a lo largo del tiempo, la dificultad de la prueba de trabajo está determinada por un promedio móvil que apunta a un número promedio de bloques por hora. Si se generan demasiado rápido, la dificultad aumenta.

5). Red

Los pasos para ejecutar la red son los siguientes:

1. Se transmiten nuevas transacciones a todos los nodos.
2. Cada nodo recopila nuevas transacciones en un bloque.
3. Cada nodo trabaja para 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 solo si todas las transacciones en él son válidas y aún no se han gastado.
6. Los nodos expresan su aceptación del bloque trabajando en la creación del siguiente bloque en 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á trabajando para extenderla. Si dos nodos transmiten versiones diferentes del siguiente bloque simultáneamente, algunos nodos pueden recibir uno u otro primero. En ese caso, trabajan en el primero que recibieron, pero guardan la otra rama en caso de que sea más larga. El empate se romperá cuando se encuentre la próxima prueba de trabajo y una rama se alargue; los nodos que estaban trabajando en la otra rama cambiarán a la más larga.

Las nuevas transmisiones de transacciones no necesariamente necesitan llegar a todos los nodos. Mientras lleguen a muchos nodos, entrarán en un bloque en poco tiempo. Las transmisiones en bloque también son tolerantes a los mensajes descartados. Si un nodo no recibe un bloque, lo solicitará cuando reciba el siguiente bloque y se dé cuenta de que se perdió uno.

6). Incentivo

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

El incentivo también se puede financiar con tarifas de transacción. Si el valor de salida de una transacción es menor que su valor de entrada, la diferencia es una tarifa de transacción que se agrega al valor de incentivo del bloque que contiene la transacción. Una vez que un número predeterminado de monedas ha entrado en circulación, el incentivo puede pasar por completo a las tarifas de transacción y estar completamente libre de inflación.

El incentivo puede ayudar a alentar a los nodos a mantenerse honestos. Si un atacante codicioso es capaz de reunir más poder de la CPU que todos los nodos honestos, tendría que elegir entre usarlo para defraudar a las personas robando sus pagos, o usándolo para generar nuevas monedas. Debería encontrar más rentable seguir las reglas, reglas que lo favorecen con más monedas nuevas que todos los demás combinados, que socavar el sistema y la validez de su propia riqueza.

7). Recuperando espacio en disco

Una vez que la última transacción en una moneda se entierra bajo suficientes bloques, las transacciones gastadas antes de que se puedan descartar para ahorrar espacio en disco. Para facilitar esto sin romper el hash del bloque, las transacciones se aceleran en un árbol Merkle ^{[ 7 ][ 2 ][ 5 ]}, con solo la raíz incluida en el hash del bloque. Los bloques viejos se pueden compactar tallando ramas del árbol. Los hash interiores no necesitan ser almacenados.

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

8). Verificación de pago simplificada

Es posible verificar pagos sin ejecutar un nodo de red completo. Un usuario solo necesita conservar una copia de los encabezados de bloque de la cadena de prueba de trabajo más larga, que puede obtener consultando nodos de red hasta 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á marcada. No puede verificar la transacción por sí mismo, pero al vincularla a un lugar en la cadena, puede ver que un nodo de red la ha aceptado, y los bloques agregados después de confirmar aún más que la red lo ha aceptado.

Como tal, la verificación es confiable siempre que los nodos honestos controlen la red, pero es más vulnerable si la red es dominada por un atacante. Si bien los nodos de red pueden verificar las transacciones por sí mismos, el método simplificado puede ser engañado por las transacciones fabricadas por un atacante mientras el atacante pueda continuar dominando la red. Una estrategia para proteger contra esto sería aceptar alertas de nodos de red cuando detecten un bloque no válido, incitando al software del usuario a descargar el bloque completo y alertó a las transacciones para confirmar la inconsistencia. Las empresas que reciben pagos frecuentes probablemente aún querrán ejecutar sus propios nodos para una seguridad más independiente y una verificación más rápida.

9). Combinando y dividiendo valor

Aunque sería posible manejar monedas individualmente, sería difícil realizar una transacción por separado para cada centavo en una transferencia. Para permitir que el valor se divida y combine, las transacciones contienen múltiples entradas y salidas. Normalmente habrá una sola entrada de una transacción anterior más grande o múltiples entradas que combinen cantidades más pequeñas, y como máximo dos salidas: una para el pago y otra para devolver el cambio, en su caso, de vuelta al remitente.

Cabe señalar que el fan-out, donde una transacción depende de varias transacciones, y esas transacciones dependen de muchas más, no es un problema aquí. Nunca es necesario extraer una copia completa e independiente del historial de una transacción.

10). Privacidad

El modelo bancario tradicional logra un nivel de privacidad al limitar el acceso a la información a las partes involucradas y al tercero de confianza. La necesidad de anunciar todas las transacciones públicamente excluye este método, pero la privacidad aún se puede mantener rompiendo 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 que vincule la transacción a nadie. Esto es similar al nivel de información divulgada por las bolsas de valores, donde el tiempo y el tamaño de las transacciones individuales, la «cinta», se hacen públicas, pero sin saber quiénes eran las partes.

Como firewall adicional, se debe usar un nuevo par de claves para cada transacción para evitar que se vinculen con un propietario común. Algunos enlaces siguen siendo inevitables con las transacciones de múltiples insumos, que necesariamente revelan que sus insumos eran propiedad del mismo propietario. El riesgo es que si se revela al propietario de una llave, la vinculación podría revelar otras transacciones que pertenecían al mismo propietario.

11). Cálculos

Consideramos el escenario de un atacante que intenta generar una cadena alternativa más rápido que la cadena honesta. Incluso si esto se logra, no abre el sistema a cambios arbitrarios, como crear valor de la nada o tomar dinero que nunca perteneció al atacante. Los nodos no aceptarán una transacción no válida como pago, y los nodos honestos nunca aceptarán un bloque que los contenga. Un atacante solo puede tratar de cambiar una de sus propias transacciones para recuperar el dinero que gastó recientemente.

La carrera entre la cadena honesta y una cadena de atacantes se puede caracterizar como una caminata aleatoria binomial. El evento de éxito es que la cadena honesta se extiende por un bloque, aumentando su liderazgo en +1, y el evento de falla es que la cadena del atacante se extiende por un bloque, reduciendo la brecha en -1.

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

p = probabilidad de que un nodo honesto encuentre el siguiente bloque
q = probabilidad de que el atacante encuentre el siguiente bloque
q_z = probabilidad de que el atacante alcance [la cadena honesta] desde z bloques atrás

Dada nuestra suposición de que p > q, la probabilidad cae exponencialmente a medida que aumenta el número de bloques que el atacante tiene que alcanzar. Con las probabilidades en su contra, si no hace una estocada afortunada desde el principio, sus posibilidades se vuelven cada vez más pequeñas a medida que se queda atrás.

Ahora consideramos cuánto tiempo debe esperar el destinatario de una nueva transacción antes de estar lo suficientemente seguro de que el remitente no puede cambiar la transacción. Asumimos que el remitente es un atacante que quiere hacer que el destinatario crea que le pagó por un tiempo, y luego cambiarlo para que se lo pague a sí mismo después de que haya pasado algún tiempo. El receptor será alertado cuando eso suceda, pero el remitente espera que sea demasiado tarde.

El receptor genera un nuevo par de claves y le da la clave pública al remitente poco antes de firmar. Esto evita que el remitente prepare una cadena de bloques con anticipación trabajando en ella continuamente hasta que tenga la suerte de llegar lo suficientemente lejos, luego ejecutando la transacción en ese momento. Una vez que se envía la transacción, el remitente deshonesto comienza a trabajar en secreto en una cadena paralela que contiene una versión alternativa de su transacción.

El destinatario espera hasta que la transacción se haya agregado a un bloque y z los bloques se han vinculado después de ello. No sabe la cantidad exacta de progreso que ha hecho el atacante, pero suponiendo que los bloques honestos tomaron el tiempo promedio esperado por bloque, El progreso potencial del atacante será una distribución de Poisson con valor esperado:

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

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

Convertida a lenguaje de programación C…

#include 
Doble AttackerSuccessProbability ( doble q, int z )
{
    doble p = 1.0 - q;
    lambda doble = z * ( q / p );
    suma doble = 1.0;
    int i, k;
    para ( k = 0; k < = z; k + + )
    {
        doble poisson = exp ( -lambda );
        para ( i = 1; i < = k; i + + )
            poisson * = lambda / i;
        suma - = poisson * ( 1 - pow ( q / p, z - k ) );
    }
    suma de devolución;
}

Al ejecutar algunos resultados, podemos ver la disminución de la probabilidad exponencialmente con z.

q = 0.1
z = 0 P = 1.000000
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.000012

q = 0.3
z = 0 P = 1.000000
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.000024
z = 50 P = 0.000006

Resolviendo para p menos del 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

12). Conclusión

Hemos propuesto un sistema para transacciones electrónicas sin depender de la confianza. Comenzamos con el marco habitual de monedas hechas con firmas digitales, que proporciona un fuerte control de propiedad, pero está incompleto sin una forma de evitar el doble gasto. Para resolver esto, propusimos una red de igual a igual utilizando la prueba de trabajo para registrar un historial público de transacciones que rápidamente se vuelve computacionalmente poco práctico para que un atacante cambie si los nodos honestos controlan la mayoría de Potencia de la CPU. La red es robusta en su simplicidad no estructurada. Los nodos funcionan de una vez con poca coordinación. No necesitan ser identificados, ya que los mensajes no se enrutan a ningún lugar en particular y solo deben entregarse con el mejor esfuerzo. Los nodos pueden salir y volver a unirse a la red a voluntad,aceptar la cadena de prueba de trabajo como prueba de lo que sucedió mientras se fueron. Votan con su poder de CPU, expresando su aceptación de bloques válidos trabajando para extenderlos y rechazando bloques inválidos al negarse a trabajar en ellos. Cualquier regla e incentivo necesarios se puede hacer cumplir con este mecanismo de consenso.

Referencias

1. W. Dai, «b-dinero,» http://www.weidai.com/bmoney.txt, 1998. ↩
2. H. Massias, X.S. Ávila y J.-J. Quisquater, «Diseño de un servicio seguro de marca de tiempo con requisitos mínimos de confianza,» En XX Simposio sobre teoría de la información en el Benelux, Mayo de 1999. ↩ ↩
3. S. Haber, W.S. Stornetta, «Cómo sellar el tiempo de un documento digital,» En Revista de criptología, vol 3, no 2, páginas 99-111, 1991. ↩
4. RE. Bayer, S. Haber, W.S. Stornetta, «Mejora de la eficiencia y la fiabilidad del estampado digital del tiempo,» En Secuencias II: Métodos en Comunicación, Seguridad e Informática, páginas 329-334, 1993. ↩
5. S. Haber, W.S. Stornetta, «Nombres seguros para cadenas de bits,» En Actas de la 4ta Conferencia ACM sobre Seguridad Informática y de Comunicaciones, páginas 28-35, abril de 1997. ↩ ↩
6. UNA. Atrás, «Hashcash: una contramedida de denegación de servicio,» http://www.hashcash.org/papers/hashcash.pdf, 2002. ↩
7. R.C. Merkle, «Protocolos para criptosistemas de clave pública,» En Proc. Simposio de 1980 sobre seguridad y privacidad, IEEE Computer Society, páginas 122-133, abril de 1980. ↩
8. W. Feller, «Una introducción a la teoría de la probabilidad y sus aplicaciones,» 1957. ↩