Bitcoin: sistema de dinero electrónico en punto a punto.
Satoshi Nakamoto -
satoshin@gmx.com –
http://www.bitcoin.org(Traductores: Benkebab, Grondilu, Mackila)
Resumen. Un sistema de dinero electrónico totalmente igual a igual haría los pagos en línea directamente de una parte a otra sin pasar por una institución financiera. Las firmas digitales ofrecen tal solución, pero pierden su interés cuando se requiere una tercera parte confiable para evitar el doble pago. Proponemos una solución al problema del doble pago mediante el uso de una red de igual a igual. La red marca las transacciones a través del tiempo mediante una función hash que las traduce en una cadena continua de pruebas de trabajo (huellas dactilares), formando un registro que no puede modificarse sin volver a realizar la prueba del trabajo. La cadena más larga (de huellas dactilares) sirve no solo como prueba del progreso de los eventos observados, sino también como prueba de que proviene de la agrupación más grande de potencia informática. Siempre que la mayoría de la potencia de cálculo (CPU) 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í misma solo requiere una estructura reducida. Los mensajes se emiten en el mejor de los casos, y los nodos pueden abandonar la red o unirse a ella a voluntad, aceptando la cadena de prueba de trabajo más larga como evidencia de lo que sucedió durante su ausencia.
1. Introducción
Actualmente, el comercio de Internet depende casi exclusivamente de las instituciones financieras que actúan como terceros confiables para procesar los pagos electrónicos. Aunque este sistema funciona bastante bien para la mayoría de las transacciones, todavía tiene debilidades inherentes en su modelo de confianza. Las transacciones totalmente irreversibles no son realmente posibles, ya que las instituciones financieras deben gestionar la mediación de conflictos. El costo de esta mediación aumenta los costos de transacción, en la práctica limita el tamaño mínimo de una transacción y evita la posibilidad de transacciones pequeñas y económicas. La imposibilidad de tener pagos no reversibles por servicios no reversibles genera un costo aún mayor. Con la capacidad de invertir transacciones, la necesidad de confianza aumenta. Los comerciantes deben desconfiar de sus clientes, acosándolos para obtener más información de la necesaria. Algunos fraudes son aceptados como inevitables. Todos estos costos e incertidumbres de pago se pueden evitar mediante el uso de una moneda física, pero no existe ningún mecanismo para realizar pagos a través de un sistema de comunicación sin recurrir a un tercero de confianza.
Lo que necesitamos es un sistema de pago electrónico basado en la evidencia criptográfica en lugar de un modelo basado en la confianza, que permita a las dos partes que lo deseen comerciar directamente entre sí sin recurso. a un tercero confiable. Las transacciones que son imposibles de cancelar por computadora protegerían a los vendedores de posibles fraudes, y un sistema de cuenta de depósito en garantía podría implementarse fácilmente para proteger a los compradores. En este documento, proponemos una solución al problema del doble gasto mediante el uso de un servidor punto a punto con sello de tiempo para generar evidencia de TI del orden cronológico de las transacciones. El sistema es seguro siempre que los nodos honestos controlen más potencia informática que un grupo de nodos que cooperarían para realizar un ataque.
2.Transactions
Definimos una parte electrónica como una cadena de firmas digitales. Cualquier propietario transfiere esta pieza a otra mediante la firma digital de una huella digital de la transacción anterior, así como la clave pública del nuevo propietario y su adición al final de la pieza. Cualquier destinatario puede revisar las firmas para verificar la cadena de propiedad.
Libro blanco 1
El problema, por supuesto, es que el beneficiario no puede verificar que uno de los propietarios anteriores no haya realizado un "doble gasto" con la habitación. Una solución común es introducir una autoridad de confianza central, o Mint, que verifique cada transacción para evitar el "doble gasto". Después de cada transacción, las monedas deben devolverse a la Casa de la Moneda, lo que crea una nueva, y solo se considera que las monedas directamente de la Casa de la Moneda se gastaron dos veces. El problema con esta solución es que el destino de todo el sistema monetario recae en la empresa que administra la Casa de la Moneda, y que cada transacción debe pasar por ellos, como un banco.
Necesitamos un método para que el destinatario sepa si los propietarios anteriores no han firmado transacciones anteriores. Para esto, la transacción más antigua debe ser la que cuenta, no tenemos que preocuparnos por los intentos posteriores de gastar la moneda duplicada. La única forma de confirmar la ausencia de una transacción previa es conocer todas las transacciones. En el modelo basado en una Casa de la Moneda, este último estaba al tanto de todas las transacciones y decidió cuál era la primera en llegar. Para hacer lo mismo sin un tercero, las transacciones deben anunciarse públicamente [1], y necesitamos un sistema para que todos los participantes acuerden un único historial del orden en que se reciben las transacciones. . El destinatario necesita pruebas de que, en cada momento de una transacción, la mayoría de los nodos coinciden en que fue la primera vez que se recibió.
3. Time Stamp Server
La base de la solución propuesta es un servidor de marca de tiempo. Un servidor de marca de hora toma la impresión de un conjunto de elementos para la marca de hora y publica esta huella, como un anuncio en un periódico o un mensaje en un forum Usenet [2-5]. La marca de tiempo demuestra que los datos existían para que se tuvieran en cuenta en la impresión. Cada marca de tiempo incluye la marca de tiempo anterior en su huella, formando una cadena en la que cada nuevo elemento confirma los anteriores.
Libro blanco 2
4. Prueba de trabajo
Para implementar un servidor de sellado de tiempo distribuido en una red de igual a igual, un sistema basado en el trabajo como el sistema Hashcash de Adam Back [6], en lugar de un periódico o mensaje en una forum Usenet. La prueba de trabajo requiere buscar un valor tal que su huella, calculada por ejemplo con SHA-256, comience con una cantidad de bits en 0. El trabajo requerido depende exponencialmente de la cantidad de bits requeridos en 0, y puede validarse realizando un solo cálculo de huella.
Para nuestra red de marca de tiempo, implementamos pruebas de trabajo al incrementar una variable en el bloque hasta que se encuentra un valor que da una huella digital con suficientes bits en 0. Una vez que se ha realizado el esfuerzo computacional requerido para obtener la prueba del trabajo, ya no es posible modificar el bloque sin rehacer este esfuerzo de cálculo. A medida que se encadenan los bloques nuevos, el esfuerzo computacional necesario para modificar un bloque incluye todo el esfuerzo de cálculo necesario para modificar todos los bloques subsiguientes.
Libro blanco 3
La prueba de trabajo resuelve el problema de elegir la representatividad del voto. Si la mayoría se basa en los votos asignados por la dirección IP, el voto podría ser pervertido por alguien capaz de tomar muchas direcciones. La prueba de trabajo se basa esencialmente en la potencia de cálculo (un procesador, una voz). La decisión de la mayoría está representada por la cadena más larga, la que requirió la mayor cantidad de cálculos de prueba de trabajo. Si la mayoría de la potencia informática de la red está controlada por nodos honestos, la cadena legítima progresa más rápidamente y los canales competidores más distantes. Para modificar un bloque antiguo, un atacante tendría que volver a calcular las pruebas de la obra del bloque modificado y todos los bloques posteriores, para compensar y superar el trabajo realizado por los nodos honestos. Luego demostraremos que la probabilidad de que un atacante con menos poder de cómputo se ponga al día disminuye exponencialmente con cada bloque nuevo agregado.
Con el fin de compensar la potencia informática mejorada del hardware y el interés cambiante en los nodos de la red operativa, la dificultad de la prueba de trabajo está determinada por un promedio del número de bloques que se encuentran por hora. Si estos bloques se generan demasiado rápido, la dificultad aumenta.
5. red
Los pasos implementados para operar la red son los siguientes:
Las nuevas transacciones se transmiten a todos los nodos.
Cada nodo agrupa las nuevas transacciones en un bloque.
Cada nodo está trabajando para resolver la prueba de trabajo en su bloque.
Cuando un nodo encuentra prueba de trabajo, transmite este bloque a todos los nodos.
Los nodos aceptan el bloque solo si todas las transacciones que contiene son válidas y no se han gastado.
Los nodos expresan la aceptación del bloque al trabajar en un nuevo bloque en la cadena, teniendo este bloque nuevo la huella previa del bloque aceptado.
Los nodos siempre consideran la cadena más larga como la cadena legítima y trabajan para extenderla. Si dos nodos transmiten dos versiones diferentes del bloque siguiente al mismo tiempo, algunos de los nodos recibirán uno o el otro primero. En esta situación, todos trabajan en el bloque recibido primero, pero conservan la otra rama en caso de que sea la más larga. Este enlace se romperá cuando se encuentre la siguiente prueba de trabajo y una rama sea más larga que la otra; los nudos que estaban trabajando en la otra rama cambiarán por más tiempo.
Las distribuciones de nuevas transacciones no necesitan llegar a todos los nodos. Desde el momento en que alcanzan suficientes nodos, se encontrarán en un bloque en poco tiempo. Las transmisiones en bloque toleran la pérdida de mensajes. Si un nodo no recibe un bloque, lo solicitará cuando reciba el siguiente bloque, cuando se da cuenta de que le falta uno.
6. incitación
Por convención, la primera transacción de un bloque es una transacción especial que crea una nueva parte que pertenece al creador del bloque. Esto alienta a los nodos a participar en la red, y permite la distribución inicial de la moneda, ya que no existe una autoridad centralizada para hacerlo. Esta constante adición de una cantidad constante de dinero se acerca al esfuerzo que hacen los mineros para agregar oro a la circulación. En nuestro caso, el esfuerzo consiste en calcular la potencia y el tiempo.
El incentivo también puede ser financiado mediante tarifas de transacción. Si el valor de salida de una transacción es menor que su valor de entrada, la diferencia es la tarifa de transacción que se agrega al valor de incentivo del bloque que contiene esa transacción. Una vez que la cantidad predeterminada de dinero ha entrado en circulación, el incentivo puede pasar a un financiamiento basado enteramente en tarifas de transacción y no causar inflación.
La incitación puede alentar a los nodos a permanecer honestos. Si un atacante codicioso tiene los medios para obtener más poder de cómputo que todos los nodos honestos, puede elegir entre defraudar a las personas recuperando pagos o usar su poder para generar nueva moneda. Debe encontrar más interesante jugar el juego, lo que claramente lo favorece porque generará más dinero nuevo que todos los otros nodos, en lugar de socavar el sistema y el valor de su propia riqueza.
7. Ahorra espacio en disco
Una vez que la última transacción de una pieza está enterrada en suficientes bloques, las transacciones pasadas se pueden eliminar para ahorrar espacio en disco. Para permitir esto sin invalidar la huella digital del bloque, las transacciones se resumen en un árbol de Merkle [7] [2] [5], del cual solo la raíz se incluye en la huella digital del bloque. Los bloques viejos se pueden comprimir cortando ramas del árbol. Las huellas dactilares intermedias no necesitan ser almacenadas.
Un encabezado de bloque sin transacción pesa aproximadamente 80 bytes. Si suponemos que se generan bloques cada minuto 10, esto representa 80 bytes * 6 * 24 * 365 = 4.2Mo por año. En 2008, los sistemas informáticos se venden con una capacidad promedio de 2Go RAM y, con la Ley de Moore que predice el crecimiento de 1.2Go por año, el almacenamiento no debería ser un problema, incluso si todos las cabezas de bloque deben mantenerse en RAM.
8. Verificación de pago simplificada
Es posible verificar los pagos sin ejecutar un nodo de red completo. Un usuario solo necesita mantener una copia de la cadena de encabezados de evidencia más larga, que puede obtener a través de consultas en los nodos de la red hasta que esté satisfecho con tener la cadena más larga, luego recuperar la rama del árbol de Merkle que vincula la transacción con el bloque en el que está marcada la hora. El usuario no puede verificar la transacción en sí, pero al vincularla en la cadena, puede ver que un nodo en la red la ha aceptado, y los siguientes bloques confirman aún más la aceptación de la red.
Como tal, la verificación es confiable siempre que los nodos honestos controlen la red, pero es más vulnerable si la red se ve comprometida por un atacante con más poder de cómputo. Aunque los nodos de la red pueden verificar las transacciones por sí mismos, el método simplificado puede ser engañado por transacciones forjadas por el atacante, siempre que tenga los medios para exceder la potencia informática de la red. Una estrategia para protegerse contra un ataque de este tipo podría ser recibir alertas de los nodos de la red cuando detectan un bloqueo no válido, solicitando al software del usuario que descargue el bloque completo y las transacciones sospechosas para verificar la inconsistencia. Las empresas que reciben pagos con frecuencia se beneficiarán de la ejecución de sus propios nodos para una seguridad más independiente y controles más rápidos.
9. Combinación y división de valor
Aunque es posible procesar las partes por separado, no sería práctico generar una transacción diferente para cada centavo en una transferencia. Para permitir la combinación y división de la moneda, las transacciones incluyen entradas y salidas múltiples. Normalmente, hay una sola entrada de una transacción grande anterior, o entradas múltiples que combinan cantidades más bajas, y un máximo de dos salidas: una para el pago y la otra para devolver el intercambio, si existe, a el transmisor.
Cabe señalar que la dispersión, cuando una transacción depende de múltiples transacciones, y que estas transacciones dependen de muchas más transacciones, no es un problema. Nunca es necesario recuperar el historial completo de una transacción.
10. confidencialidad
El sistema bancario tradicional garantiza un cierto nivel de confidencialidad al limitar el acceso a la información a las partes interesadas y al tercero de confianza. La necesidad de publicar todas las transacciones excluye este método, pero se puede lograr la confidencialidad interrumpiendo el flujo de información a otro nivel: manteniendo claves públicas anónimas. Es posible ver que alguien envía una cierta cantidad a otra persona, pero sin ninguna conexión con las personas. Esto es similar al nivel de información disponible en los mercados cambiarios, o la fecha y el monto de cada intercambio, el "curso", es público, pero sin revelar la identidad de las partes.
Como barrera adicional, se puede usar un nuevo par de claves para cada transacción, para evitar estar conectado a un propietario común. Sin embargo, una cierta relación es inevitable con las transacciones de entrada múltiple, que necesariamente revelan que sus entradas fueron propiedad del mismo propietario. El evento temido es que si se revela el propietario de una de las claves, los enlaces permiten la revelación de otras transacciones del mismo propietario.
11. cálculos
Considere el caso de un atacante que intenta generar una cadena alternativa más rápido que la cadena legítima. Incluso si tiene éxito, esto no haría que el sistema sea vulnerable a cambios arbitrarios, como la creación de dinero desde cero, o la apropiación de dinero que nunca ha pertenecido al atacante. Los nodos no aceptan transacciones no válidas como pago, y los nodos honestos nunca aceptarán un bloque que contenga una de estas transacciones. Un atacante solo puede modificar una de sus propias transacciones para recuperar el dinero que acaba de gastar.
La carrera entre la cadena legítima y la cadena del atacante se puede caracterizar como una caminata aleatoria binaria. El evento de éxito es el alargamiento de la cadena legítima, aumentando su ventaja en + 1, y el evento de falla es el alargamiento de la cadena del atacante, lo que reduce el retraso de -1.
La probabilidad de que un atacante se ponga al día es análoga al problema de ruina del jugador. Imagina a un jugador con créditos ilimitados, comenzando en negativo y jugando una cantidad infinita de juegos para intentar igualar. La probabilidad de que llegue allí, o de que un atacante logre atrapar la cadena legítima, se calcula así [8]:
p = probabilidad de que un nudo honesto encuentre el siguiente bloque
q = probabilidad de que el atacante encuentre el siguiente bloque
qz = probabilidad de que el atacante logre atrapar la cadena con z bloques detrás
Dada nuestra hipótesis p> q, la probabilidad disminuye exponencialmente dependiendo del número de bloques que el atacante tiene que atrapar. Con las probabilidades en su contra, si no tiene una racha de suerte desde el principio, sus posibilidades se vuelven escasas cuanto más atrás está.
Ahora estamos interesados en el momento en que el destinatario de una nueva transacción debe esperar antes de estar suficientemente seguro de que el emisor no podrá modificar la transacción. Suponemos que el remitente es un atacante que desea hacer que el destinatario crea que se le ha pagado durante un tiempo, y luego desea cambiar la transacción para recuperar el dinero de la transacción después de un cierto período de tiempo. El destinatario será alertado cuando esto suceda, pero el transmisor espera que sea demasiado tarde.
El destinatario genera un nuevo par de claves y le da la clave pública al remitente poco antes de la firma. Esto evita que el remitente prepare una cadena de bloques por adelantado trabajando en ello hasta que obtenga un avance suficiente, y realiza la transacción en ese momento. Una vez que se emite la transacción, el emisor deshonesto comienza a trabajar en un canal alternativo que contiene una versión modificada de la transacción.
El destinatario espera que la transacción se agregue a un bloque y se han agregado z bloques después de él. No sabe exactamente cuál es el progreso del atacante, pero suponiendo que los bloques legítimos hayan generado el tiempo promedio esperado por bloque, el avance potencial del atacante es una distribución de Poisson. teniendo como valor esperado:
A fin de obtener la probabilidad de que el atacante logre ponerse al día, multiplicamos la densidad de Poisson por cada cantidad de progresión que pudo obtener por la probabilidad de que atrape desde este punto:
Al reordenar para evitar agregar al infinito ...
Convertido a código C ...
#incluir
doble AttackerSuccessProbability (doble q, int z)
{
doble p = 1.0 - q;
doble lambda = z * (q / p);
suma doble = 1.0;
int i, k;
para (k = 0; k <= z; k ++)
{
doble pez = exp (-lambda);
para (i = 1; i <= k; i ++)
pez * = lambda / i;
sum - = fish * (1 - pow (q / p, z - k));
}
devolver la suma;
}
Al realizar algunas pruebas, observamos que la probabilidad disminuye exponencialmente de acuerdo con z:
q = 0.1
z = 0p = 1.0000000
z = 1p = 0.2045873
z = 2p = 0.0509779
z = 3p = 0.0131722
z = 4p = 0.0034552
z = 5p = 0.0009137
z = 6p = 0.0002428
z = 7p = 0.0000647
z = 8p = 0.0000173
z = 9p = 0.0000046
z = 10 p = 0.0000012
q = 0.3
z = 0p = 1.0000000
z = 5p = 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
Soluciones para P menor que 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 de transacciones electrónicas que no se basa en la confianza. Comenzamos con un conjunto habitual de piezas de firma digital, que proporciona un control de propiedad sólido, pero permanece incompleto sin una forma de evitar gastos duplicados. Para resolver este problema, hemos propuesto una red de igual a igual que usa pruebas de trabajo para registrar un registro de transacciones públicas, que rápidamente se vuelve inexpugnable mediante el cálculo si los nodos honestos controlan la mayor parte de la potencia informática. La red es robusta en su simplicidad desestructurada. Los nudos trabajan en concierto con muy poca coordinación. No necesitan ser autenticados, ya que los mensajes no se envían a un destinatario en particular y deben entregarse en el mejor de los casos. Los nodos pueden salir y unirse a la red a voluntad, aceptando la cadena de prueba de trabajo como prueba de lo que sucedió durante su ausencia. Votan usando su poder de cómputo, expresando su acuerdo con bloques válidos trabajando para extenderlos y rechazando bloques inválidos al rehusarse a trabajar en ellos. Todas las reglas e incentivos necesarios se pueden aplicar con este mecanismo de consenso.
referencias
[1] W. Dai, "dinero b"
http://www.weidai.com/bmoney.txt, 1998.
[2] H. Massias, XS Ávila, y JJ Quisquater, "Diseño de un servicio de sellado de tiempo seguras con los requisitos mínimos de confianza," en Simposio 20th sobre Teoría de la Información en los países del Benelux, mayo 1999.
[3] S. Haber, WS Stornetta, "¿Cómo marca de tiempo de un documento digital" En Diario de la criptología, vuelo 3, Nº 2, 99 páginas-111 1991.
[4] D. Bayer, S. Haber, WS Stornetta, "Mejora de la eficiencia y la fiabilidad de sellado de tiempo, digitales" en las secuencias II: Métodos de Comunicación, Seguridad y Ciencias de la Computación, páginas 329 334-1993.
[5] S. Haber, WS Stornetta, "nombres seguros para cadenas de bits", en Actas de la Conferencia ACM sobre 4th Informática y Comunicaciones de Seguridad, páginas 28 35-abril 1997.
[6] A. Atrás, "Hashcash - una contramedida de denegación de servicio"
http://www.hashcash.org/papers/hashcash.pdf, 2002.
[7] RC Merkle, "Protocolos para criptosistemas de clave pública", en Proc. Simposio de 1980 sobre seguridad y privacidad, IEEE Computer Society, páginas 122-133, April 1980.
[8] W. Feller, "Una introducción a la teoría de la probabilidad y sus aplicaciones", 1957.
