Todo comenzó con el whitepaper de Bitcoin, un documento explicativo sobre el término de una tecnología que, actualmente, no cobija dudas. Bitcoin y su tecnología latente, blockchain, se han transformado en una de las mayores revoluciones tecnológicas de los últimos tiempos. Sus conceptos dejan aplicaciones con un increíble potencial. Aún queda mucho por descubrir, aun fuera del ámbito financiero, para el que en un inicio fue creado.

Pero, ¿De qué manera comenzó todo?

Como explicamos en el artículo sobre “¿Quién ha creado Bitcoin?”, Satoshi Nakamoto publicó un documento en un foro de discusión en el año dos mil ocho. En él, definía a modo teorético un medio de pago global sin intercesores entre los usuarios. Un ecosistema formado por piezas combinadas nunca visto hasta la data. El documento, con una presentación de estilo académico, se llama “Bitcoin Paper”, que puedes preguntar aquí.

Preparaos para sumergiros en las palabras originales del autor de Bitcoin. Es la primera mención oficial a la herramienta que ha alterado más que las finanzas. Descubre de qué manera se procuraba dar forma a un cosmos de revoluciones tecnológicas a su alrededor.

A continuación os dejamos la versión traducida al de España del whitepaper de Bitcoin.

Bitcoin: Un Sistema de Efectivo Electrónico Usuario-a-Usuario

Satoshi Nakamoto

[email protected]

www.bitcoin.org

Resumen

Una versión puramente electrónica de efectivo dejaría que los pagos online se manden de forma directa, de un ente a otro. Todo ello sin pasar a través de una corporación financiera. Las firmas digitales dan una parte de la solución al inconveniente, mas las ventajas primordiales se pierden si debe existir un tercero de confianza para prevenir el doble gasto. Planteamos una solución al inconveniente del doble gasto usando una red usuario-a-usuario.

La red pone marcas de tiempo a las transacciones que introduce en una cadena continua de pruebas de trabajo basadas en el cálculo de hashes. Con esto se marcha formando un registro que no puede ser alterado sin regresar a recrear la prueba de trabajo completa. La cadena más larga no solo sirve como testigo y prueba de la secuencia de acontecimientos. Sino asimismo asegura que está vino desde la agrupación con procesamiento de CPU más grande.

Siempre que la mayor parte del poder de procesamiento de CPU esté bajo el control de nodos que no colaboran para agredir la red. Así estos producirán la cadena más larga y van a llevar ventaja a los atacantes. La red en sí requiere una estructura mínima. Los mensajes son mandados bajo la premisa del menor esmero, y los nodos pueden irse y regresar a unirse a la red cuando les parezca. Siempre y en todo momento admitiendo la cadena más larga de prueba de trabajo, como prueba de lo que sucedió a lo largo de su ausencia.

Introducción

El comercio en Internet ha llegado únicamente a depender de las instituciones financieras, las que sirven como terceros de confianza, para el procesamiento de los pagos electrónicos. Al paso que el sistema marcha suficientemente bien para la mayor parte de las transacciones, todavía padece de las debilidades inherentes del modelo basado en confianza. Las transacciones totalmente no reversibles no son verdaderamente posibles, dado a que las instituciones financieras no pueden eludir la mediación en disputas.

El costo de la mediación acrecienta los costos de transacción. Con esto se restringe el tamaño mínimo práctico por transacción y suprimiendo la posibilidad de efectuar pequeñas transacciones casuales, existiendo un costo mayor por esta pérdida y la imposibilidad de hacer pagos no reversibles por servicios no reversibles. Con la posibilidad de revertir, la necesidad de confianza se expande. Los mercaderes deben tener precaución de sus clientes del servicio, molestándoles pidiendo más información de la que se precisaría de otra manera.

Un cierto porcentaje de fraude se admite como ineludible. Estos costos y también incertidumbres en los pagos se pueden eludir si la persona emplea dinero físico. Mas no hay un mecanismo para hacer pagos por un canal de comunicación sin un tercero fiable. Lo que se precisa es un sistema de pagos electrónicos que esté basado en pruebas criptográficas en lugar de en confianza. Con esto se busca permitir a las 2 partes interesadas efectuar transacciones de manera directa sin la necesidad de un tercero fiable. Las transacciones que son computacionalmente poco viables de revertir resguardarían a los vendedores de fraude. Y de igual manera los mecanismos rutinarios de depósito de garantía podrían ser sencillamente incorporados para resguardar a los compradores.

En este trabajo, planteamos una solución al inconveniente del doble gasto usando un servidor de marcas de tiempo usuario a usuario distribuido para producir una prueba computacional del orden temporal de las transacciones. El sistema es seguro al paso que los nodos francos controlen de forma colectiva más poder de procesamiento (CPU) que cualquier conjunto de nodos atacantes.

Transacciones

Definimos una moneda electrónica como una cadena de firmas digitales. Cada dueño trasfiere la moneda al cercano al firmar digitalmente un hash de la transacción anterior y la clave publica del próximo dueño y añadiendo los dos al final de la moneda. Un adjudicatario puede contrastar las firmas para contrastar la cadena de propiedad.

whitepaper trasacción

El inconveniente está en que el adjudicatario no puede contrastar si ciertos dueños anteriores no hizo un doble gasto de la moneda. La solución común es introducir una autoridad central fiable. Una suerte de casa de la moneda, que examinaría si cada transacción tiene doble gasto o bien no. Tras cada transacción, la moneda ha de ser devuelta a la casa de la moneda para producir una nueva moneda. De esta forma solo las monedas generadas de forma directa por esta casa de la moneda, son en las que se confían de no tener doble-gasto.

El inconveniente con esta solución es que, el destino del sistema monetario entero, depende de la compañía que administra la casa de la moneda. Con todas y cada una de las transacciones debiendo pasar por ellos, tal como actuaría un banco. En consecuencia, precisamos localizar una forma a fin de que el adjudicatario pueda saber que los dueños anteriores no firmaron ninguna transacción precedente.

Para nuestros propósitos, la transacción última o bien más temprana es la que cuenta. Con lo que no nos van a importar otros intentos de doble gasto siguientes. La única forma de confirmar la ausencia de una transacción es estando al tanto de todas y cada una de las transacciones existentes. En el modelo de la casa de la moneda, era esta casa la que estaba al tanto de todas y cada una de las transacciones y decidiría cuales llegaban primero. Para conseguir esto sin un tercero fiable, las transacciones han de ser anunciadas en público [1], y necesitaremos de un sistema de participantes que estén conforme en una historia única, del orden en que estas transacciones fueron recibidas. El adjudicatario precisa saber que en el instante de cada transacción, la mayor parte de los nodos estuvieron conforme en cuál fue la primera que se recibió.

Servidor de marcas de tiempo

La solución que planteamos empieza con un servidor de marcas de tiempo. Un servidor de marcas de tiempo marcha al efectuar el hash de un bloque de datos a ser fechados y publicándolo extensamente, como se haría en un periódico o bien en una publicación de Usenet [2-5]. La marca de tiempo prueba que el dato, evidentemente, debió haber existido en ese instante para poder incluirse en el hash. Cada marca de tiempo incluye en su hash la marca de tiempo anterior, formando una cadena, de tal modo que cada marca de tiempo auxiliar fortalece las precedentes a una dada.

servidor marcas de tiempo

Prueba-de-trabajo

Para incorporar un servidor de marcas de tiempo siguiendo un esquema usuario-a-usuario, necesitaremos emplear un sistema de prueba de trabajo afín al Hashcash de Adam Back [6], en lugar de utilizar una publicación en un periódico o bien en Usenet. La prueba de trabajo implica la exploración de un valor, tal que, al calcular un hash, como SHA-doscientos cincuenta y seis, este comience con un número determinado de bits con valor cero. El trabajo promedio requerido va a ser exponencial al número de bits requeridos con valor cero mas que puede ser verificado ejecutando un solo hash.

Para nuestra red de marcas de tiempo incorporamos la prueba de trabajo acrecentando el valor de un campo nonce, perteneciente al bloque, hasta el momento en que se halle un valor que dé el número requerido de bits con valor cero para el hash del mismo. Cuando el ahínco de CPU se ha gastado para satisfacer la prueba de trabajo, el bloque no puede ser alterado sin rehacer todo el trabajo. Conforme más bloques son encadenados tras uno dado, el trabajo para mudar un bloque incluiría rehacer todos y cada uno de los bloques tras este.

prueba de trabajo

La prueba de trabajo asimismo soluciona el inconveniente de determinar como representar la resolución por mayoría. Si esta mayoría se basara en un voto por dirección IP, podría ser perturbada por alguien capaz de asignar muchas IPs. La prueba de trabajo equivale fundamentalmente a “una-CPU-un-voto”. La resolución de la mayor parte es representada por la cadena más larga, la que tiene la prueba de trabajo con mayor esmero invertido.

Si la mayor parte del poder de CPU está bajo control por nodos francos, la cadena sincera medrará más veloz y va a dejar atrás cualquier otra cadena que esté compitiendo. Para alterar un bloque anteriormente, un atacante debería rehacer la prueba de trabajo del bloque y de todos y cada uno de los bloques siguientes, y después lograr y superar el trabajo de los nodos francos.

Luego demostraremos que la probabilidad de que un atacante más lento pueda lograr a la cadena más larga, reduce exponencialmente conforme más bloques subsecuentes se marchan incorporando.

Para compensar el aumento de la velocidad del hardware y el interés variable de ejecutar nodos en el tiempo, la complejidad de la prueba de trabajo es determinada por una media móvil dirigida por un número promedio de bloques a la hora. Si estos se producen rapidísimo, la complejidad se acrecienta.

La Red

Los pasos que ejecuta la red son los siguientes:

  1. Las transacciones nuevas se emiten a todos y cada uno de los nodos.
  2. Cada nodo recoge nuevas transacciones en un bloque.
  3. Cada nodo trabaja en hallar una prueba de trabajo bastante difícil para su bloque.
  4. Cuando un nodo halla una prueba de trabajo, emite el bloque a todos y cada uno de los nodos.
  5. El bloque se admite por la parte de los nodos si todas y cada una de las transacciones en el bloque se han ratificado y no gastado.
  6. Los nodos expresan su aceptación del bloque al trabajar en crear el próximo bloque en la cadena, usando el hash del bloque admitido como hash anterior.

Siempre se considera la cadena más larga como la adecuada y comienzan a trabajar en extenderla. Si 2 nodos emiten versiones diferentes del próximo bloque simultáneamente, ciertos nodos es posible que reciban uno o bien el otro primero. En un caso así, trabajan en el primero que reciban mas guardan la otra rama caso de que esta se vuelva más larga. El empate se rompe cuando se halla la próxima prueba de trabajo y una rama se vuelve más larga; los nodos que trabajaban en la otra rama más tarde se cambian a la que ahora es más larga.

Las emisiones de nuevas transacciones no necesariamente precisan llegar a todos y cada uno de los nodos. En el instante que estas llegan a muchos nodos, acabasen entrando en un bloque antes que pase un buen tiempo. La emisión de los bloques asimismo es tolerante a la pérdida de mensajes. Si un nodo no recibe un bloque, lo solicitará cuando reciba el próximo bloque y se de cuenta que perdió uno.

Incentivo

Por convención, la primera transacción en el bloque es una transacción singular queproduce una nueva moneda cuyo dueño es el autor del bloque. Esto añade un incentivo a fin de que los nodos apoyen a la red, y provee una forma inicial de repartir y poner en circulación las monedas, puesto que no hay una autoridad para crearlas. Esta adición estable de una cantidad incesante de monedas nuevas, es equivalente a los mineros de oro que gastan recursos para ponerlo en circulación. En nuestro caso, los recursos son el tiempo de CPU y la electricidad que se gastan.

El incentivo asimismo puede establecerse con los costos de transacción. Si el valor de salida de una transacción es menor que la entrada, la diferencia va a ser una tarifa de transacción que se agregará al valor del incentivo del bloque que la contiene. En el momento en que un número predeterminado de monedas han entrado en circulación, el incentivo puede evolucionar por entero a tarifas de transacción y estar absolutamente libres de inflación.

El incentivo asimismo puede asistir a animar a los nodos a sostenerse francos. Si un atacante ególatra es capaz de reunir más potencia de CPU que todos y cada uno de los nodos sinceros, este debería escoger entre emplearlo para defraudar a la gente robando sus pagos, o bien emplearlo para producir monedas nuevas. Debería hallar más rentable jugar siguiendo las reglas, puesto que estas lo favorecerán con más monedas que combinando a todos los otros nodos, que minar el sistema y la valía de su riqueza.

Reclamando Espacio en Disco

Una vez que la última transacción está sepultada bajo suficientes bloques, las transacciones gastadas precedentes a esta pueden ser descartadas para ahorrar espacio en disco. Para facilitar esto sin romper el hash del bloque, las transacciones se verifican en un árbol de Merkle [7] [2] [5], con solo la raíz incluida en el hash del bloque. Los bloques viejos pueden compactarse al sacar ramas del árbol. Los hashes interiores no precisan guardarse.

árbol de Merkle

La cabecera de un bloque sin transacciones va a ser de unos ochenta bytes. Si suponemos que cada bloque se produce cada uno minutos, ochenta bytes * seis * veinticuatro * trescientos sesenta y cinco = cuatro.2MB al año. Con ordenadores vendiéndose en general con 2GB de RAM en dos mil ocho, y la ley de Moore pronosticando un desarrollo actual de 1.2GB al año, el almacenaje no ha de ser un inconveniente incluso si las cabeceras de los bloques deben continuar en memoria.

Verificación de Pagos Simplificada

Es posible contrastar pagos sin ejecutar un nodo de red completo. Un usuario solo precisa sostener una imitación de las cabeceras de los bloques de la cadena más larga de la prueba de trabajo, la que puede conseguirse haciendo una busca en los nodos de la red hasta el momento en que esté persuadido de tener la cadena más larga, y conseguir la rama del árbol de Merkle, que enlaza la transacción con el bloque en que ha sido fechado. Si bien no puede contrastar la transacción por sí solo, al enlazarla a algún sitio de la cadena, puede ver que algún nodo de la red la ha admitido, de tal modo que los bloques añadidos después confirmarían todavía más esta aceptación por la parte de la red.

verificación de pagos

Como tal, la verificación es fiable conforme los nodos sinceros controlen la red, mas se vuelve más frágil si la red es dominada por un atacante. Al paso que los nodos de la red puedan contrastar las transacciones por si acaso mismos, el procedimiento simplificado puede ser engañado por transacciones elaboradas por un atacante mientras que este pueda dominar la red. Una estrategia para resguardarse es admitir alarmas de los nodos de la red cuando adviertan un bloque inválido, pidiéndole al usuario que se baje el bloque completo y las transacciones alertadas para confirmar la falta de consistencia. Los negocios que a menudo reciban pagos, desearán ejecutar sus nodos para tener una seguridad más independiente y una verificación más veloz.

Combinando y Dividiendo Valor

Aunque sería posible manipular monedas individualmente, seria bastante difícil de manejar el hacer transacciones separadas por cada céntimo de una trasferencia. Para dejar que el valor se divida y se combine, las transacciones poseen múltiples entradas y salidas. Por norma general va a haber o bien una sola entrada, de una transacción anterior más grande, o bien múltiples entradas combinando cantidades más pequeñas, y por lo menos 2 salidas: una para el pago, y una para devolver el cambio, si hay alguno, de vuelta al transmisor.

Combinando y Dividiendo Valor

Hay que tener en consideración que este sistema se abre en abanico, de tal modo que una transacción puede depender de múltiples transacciones, y esas por su parte depender de considerablemente más, lo que no es ningún inconveniente. Jamás hay la necesidad de extraer una copia completa única de la historia de  las transacciones.

Privacidad

El modelo bancario tradicional, consigue su nivel de privacidad, al limitar el acceso a la información a las partes implicadas y al tercero de confianza. La necesidad de anunciar todas y cada una de las transacciones en público se opone a este procedimiento, mas la privacidad todavía puede sostenerse rompiendo el flujo de información en otro lugar: sosteniendo las claves públicas anónimas. En público puede verse que alguien está mandando una cierta cantidad a otra persona, mas sin información que relacione la transacción con absolutamente nadie particularmente. Esto es afín al nivel de información que se muestra en las bolsas de valores, donde el tiempo y el tamaño de las transacciones individuales, la “cinta”, son públicos, mas sin decir quienes son las partes.

modelo privacidad tradicional

Como un cortafuegos auxiliar, un nuevo par de claves debe usarse para cada transacción de forma que puedan asociarse a un dueño en común. Son ineludibles ciertos géneros de asociación con transacciones de múltiples entradas, las que pueden descubrir que sus entradas pertenecen al mismo dueño. El peligro estaría en que si el dueño de una clave se revela, entonces el enlazado podría descubrir otras transacciones que pertenecieron al mismo dueño.

Cálculos

Consideramos el escenario en el que un atacante procura producir una cadena alterna más veloz que la cadena franca. Todavía si esto se consiguiese, no abriría el sistema a cambios arbitrarios, como crear valor del aire o bien tomar dinero que jamás perteneció al atacante. Los nodos no admitirían una transacción inválida como pago, y los nodos sinceros jamás admitieran un bloque que las contenga. Un atacante puede solamente procurar mudar solo sus transacciones para reanudar dinero que ha gastado últimamente.

La carrera entre una cadena sincera y la cadena de un atacante se caracteriza como un Camino Binomial Azaroso. El acontecimiento de éxito es la cadena franca extendiéndose en un bloque auxiliar y también acrecentando su ventaja en +1, y siendo el acontecimiento de descalabro que la cadena del atacante se extienda en un bloque reduciendo la distancia en -1.

La probabilidad de que un atacante pueda alcanzarnos, desde un déficit dado, es equivalente al inconveniente de la Ruina del Jugador. Supóngase que un jugador con crédito ilimitado comienza en déficit y juega potencialmente un número infinito de intentos para procurar llegar a un punto de equilibrio. Podemos calcular la probabilidad de que llegara al punto de equilibrio, o bien que llegue a lograr a la cadena sincera, como prosigue [8]:

p = probabilidad de que un nodo franco halle el próximo bloque

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

qz = probabilidad de que el atacante llegue a lograr desde z bloques atrás.

Dada nuestra hipótesis de que p > q, la probabilidad cae exponencialmente al tiempo que el número de bloques que el atacante debe lograr acrecienta. Con las probabilidades en contra, si no hace una jugada agraciada desde el comienzo, sus ocasiones se vuelven exageradamente pequeñas conforme se queda más atrás.

Ahora consideremos cuánto precisa aguardar el adjudicatario de una nueva transacción ya antes de tener la certidumbre suficiente de que el transmisor no puede mudarla. Aceptamos que el transmisor es un atacante el que desea hacer opinar al adjudicatario que se le pagó a lo largo de un rato, entonces mudar la transacción para pagarse a sí  mismo de vuelta en el momento en que ha pasado un tiempo.El adjudicatario va a ser alertado cuando esto ocurra, mas el transmisor espera que sea demasiado tarde.

El adjudicatario produce un nuevo par de claves y entrega la clave pública al transmisor poco tras hacer la firma. Esto previene que el transmisor prepare una cadena de bloques ya antes de tiempo, y pueda estar trabajando en ella de forma continua hasta el momento en que tenga la fortuna de anticiparse lo bastante, y después ejecutar la transacción en ese instante. Cuando la transacción es mandada, el transmisor inmoral comienza a trabajar en secreto en una cadena paralela que contiene una versión alterna de su transacción.

El adjudicatario espera a que la transacción se agregue a un bloque y que z bloques se hayan enlazado tras la transacción. No precisará saber la cantidad precisa de progreso que ha conseguido el atacante, mas asumiendo que los bloques sinceros tardaron el promedio aguardado por bloque, el progreso potencial del atacante va a ser una distribución de Poisson con un valor aguardado de:

Para conseguir la probabilidad de que el atacante todavía pueda alcanzarnos ahora, multiplicamos la densidad de Poisson por la cantidad de progreso que pudo haber hecho por la probabilidad de que pudiese lograr ese punto:

Re-organizamos para eludir la suma de la cola infinita de la distribución…

Convertimos a código en C…

#include double
AttackerSuccessProbability(double q, int z)
undefined

Ejecutamos ciertos 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

Resolvemos para P menor que 0.1 por ciento …

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

Conclusiones

Hemos propuesto un sistema de transacciones electrónicas que no dependen de la confianza. Empezamos con el marco frecuente de monedas hechas en base al empleo de firmas digitales, el que provee un fuerte control de la propiedad, mas que está incompleto sino más bien hay una forma de prevenir el doble gasto. Para solventarlo, planteamos una red usuario a usuario que usa la prueba de trabajo para registrar una historia pública de transacciones y que de forma rápida se transforma en computacionalmente irremediable para un atacante que desee mudarla, si los nodos francos controlan la mayor parte del poder deCPU.

Una red robusta por su simplicidad no estructurada. Los nodos pueden trabajar todos al tiempo con poca coordinación. No precisan que los identifiquen, puesto que los mensajes no se enrutan a ningún sitio particularmente y solo precisan entregados bajo la base del mejor esmero. Los nodos pueden ir y regresar de la red a voluntad, admitiendo la cadena de prueba de trabajo como prueba de lo que sucedió mientras que estuvieron ausentes. Votan con su poder de CPU, expresando su aceptación de los bloques válidos al trabajar propagando y rechazando bloques inválidos al reutilizar trabajar en ellos. Cualquier regla precisa o bien incentivos pueden hacerse cumplir con este mecanismo de acuerdo.

Referencias

  • [1] W. Dai, “b-money,” https://www.weidai.com/bmoney.txt, mil novecientos noventa y ocho.
  • [2] H. Massias, X.S. Avila, and J.-J. Quisquater, “Design of a secure timestamping service with minimal trust requirements,” In 20th Symposium on Information Theory in the Benelux, May mil novecientos noventa y nueve.
  • [3] S. Haber, W.S. Stornetta, “How to time-stamp a digital document,” In Journal of Cryptology, vol tres, no dos, pages noventa y nueve-ciento once, mil novecientos noventa y uno.
  • [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, pages trescientos veintinueve-trescientos treinta y cuatro, mil novecientos noventa y tres.
  • [5] S. Haber, W.S. Stornetta, “Secure names for bit-strings,” In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages veintiocho-treinta y cinco, April mil novecientos noventa y siete.
  • [6] A. Back, “Hashcash – a denial of service counter-measure,” https://www.hashcash.org/papers/hashcash.pdf, dos mil dos.
  • [7] R.C. Merkle, “Protocols for public key cryptosystems,” In Proc. mil novecientos ochenta Symposium on Security and Privacy, IEEE Computer Society, pages ciento veintidos-ciento treinta y tres, April mil novecientos ochenta.
  • [8] W. Feller, “An introduction to probability theory and its applications,” mil novecientos cincuenta y siete.