Saltar al contenido
Guia Bitcoins

Whitepaper original de bitcoins

Whitepaper original de bitcoins

El comercio por Internet ha llegado a depender exclusivamente de instituciones financieras que sirven como terceras partes confiables para el procesamiento de pagos electrónicos. Si bien el sistema funciona lo suficientemente bien para la mayoría de las transacciones, todavía adolece de las debilidades inherentes al modelo basado en la confianza. Las transacciones completamente reversibles no son realmente posibles, ya que las instituciones financieras no pueden evitar mediar en las disputas. El costo de la mediación aumenta los costos de transacción al limitar el tamaño mínimo práctico por transacción y eliminar la posibilidad de transacciones casuales pequeñas, y hay un costo más alto al perder la capacidad de hacer pagos no reversibles por servicios no reversibles. Con la capacidad de revertir, la necesidad de confianza se expande. Los comerciantes deben cuidar de sus clientes, irritándolos al pedirles más información de la necesaria. Un cierto porcentaje de fraude es aceptable como inevitable. Estos costos de pago e incertidumbres pueden evitarse personalmente utilizando efectivo físico, pero no existe un mecanismo para realizar pagos a través de un canal de comunicación sin un tercero de confianza. Lo que se necesita es un sistema de pago electrónico basado en pruebas criptográficas en lugar de en la confianza, que permita a dos partes interesadas realizar transacciones directamente sin necesidad de un tercero de confianza. Es poco probable que las transacciones con probabilidad de reversión computacional protejan a los vendedores del fraude, y los mecanismos rutinarios de depósito fiduciario pueden ser fácilmente implementados para proteger a los compradores. En este artículo, proponemos una solución al problema de los gastos duales mediante el uso de un servidor distribuido de marca de tiempo de usuario a usuario para generar una prueba computacional del orden cronológico de las transacciones. El sistema es seguro porque honestamente controlamos colectivamente más potencia de procesamiento.

Transacciones

Definimos una moneda electrónica como una cadena de firmas digitales. Cada propietario transfiere la divisa al siguiente firmando digitalmente un hash de transacción anterior y la clave pública del siguiente propietario y añadiéndolos al final de la divisa. Un beneficiario puede verificar las firmas para verificar la cadena de propiedad. El problema claro es que el beneficiario no puede verificar que uno de los propietarios no haya gastado el doble de la moneda. Una solución común es introducir una autoridad central de confianza, o Casa de la Moneda, para revisar cada una de ellas si cada transacción tiene un doble gasto. Después de cada transacción, la moneda debe ser devuelta a la Fábrica de Moneda para generar una nueva moneda, y sólo las monedas generadas directamente de la Fábrica de Moneda son aquellas en las que se confía que no incurrirán en gastos dobles. El problema con esta solución es que el destino de todo el sistema monetario depende de la empresa que administra la moneda, y cada transacción tiene que pasar por ella, como un banco. Necesitamos un formulario para que el beneficiario pueda saber que los anteriores propietarios no han firmado ninguna transacción previa. Para nuestros propósitos, la transacción más antigua es la que cuenta, así que no nos importan otros intentos de gastar más tarde. La única manera de confirmar la ausencia de una transacción es estar al tanto de todas las transacciones. En el modelo de la Fábrica de la Moneda, la Fábrica de la Moneda estaba al tanto de todas las transacciones y decidió cuáles serían las primeras. Para lograr esto sin un tercero de confianza, las transacciones deben ser anunciadas públicamente, y necesitamos un sistema de participantes que estén de acuerdo con una historia única del orden en que fueron recibidas. El beneficiario debe demostrar que, en el momento de cada transacción, la mayoría de nosotros estaba de acuerdo en que era la primera que se recibía.

Whitepaper original de bitcoins

Servidor de marcas de tiempo

La solución que proponemos comienza con un servidor de marcas de tiempo. Un servidor de marcas de tiempo funciona utilizando un hash de un bloque de elementos a fechar y publicando ampliamente el hash, como en un periódico o en una publicación de Usenet. La marca de tiempo prueba que los datos deben haber existido a tiempo, obviamente, para introducir 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 los registros anteriores.

Prueba de trabajo

Para implementar un servidor de sellos de tiempo de usuario a usuario, necesitaremos utilizar un sistema de pruebas para trabajos similares a Adam Back’s Hashcash, en lugar de un periódico o una publicación de Usenet. Las pruebas de trabajo consisten en explotar un valor que, al calcular un hash, como el SHA-256, comienza con un número de bits a cero. El trabajo promedio requerido es exponencial en el número de bits establecidos a cero requeridos y puede ser verificado ejecutando un solo hash. Para nuestra red de timestamps, implementamos la prueba ejecutada incrementando un nonce en el bloque hasta que se encuentre un valor para el número requerido de bits a cero para el hash del bloque. Una vez que el esfuerzo de la CPU ha sido gastado para satisfacer la prueba de trabajo, el bloque no puede ser cambiado sin rehacer todo el trabajo. Cuantos más bloques se encadenen después de éste, el trabajo para cambiar el bloque incluiría rehacer todos los bloques después de éste. La prueba de trabajo también resuelve el problema de determinar la representación para la decisión de la mayoría. Si la mayoría se basara en un voto por dirección IP, podría ser subvertido por alguien capaz de asignar muchas IPs. La prueba del trabajo es esencialmente un CPU-a-voto. La decisión mayoritaria está representada por la cadena más larga, que tiene la mayor prueba de resistencia al trabajo invertida en ella. Si la mayor parte de la potencia de la CPU es controlada por nosotros honestamente, la cadena honesta crecerá más rápido y pasará a través de cualquier cadena que esté compitiendo.

Para modificar un bloque en el pasado, un atacante tendría que volver a probar el trabajo del bloque y todos los bloques más tarde y luego alcanzar y pasar el trabajo de los nodos honestos. Entonces, mostraremos que la probabilidad de un intruso de alcance más lento disminuye exponencialmente a medida que se añaden bloques subsiguientes. Para compensar el aumento de la velocidad del hardware y el interés en la ejecución de nodos en el tiempo, la dificultad del trabajo de prueba se determina por una media móvil dirigida a un número medio de bloques por hora. Si se generan demasiado rápido, la dificultad aumenta.

La red

Los pasos para gestionar la red son los siguientes:

  1. Las nuevas transacciones se emiten a todos los nodos.
  2. Cada nodo recoge las 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, envía el bloque a todos los nodos.
  5. Los nodos aceptan el bloque si todas las transacciones del bloque son válidas y aún no se han gastado.
  6. Los nodos expresan su aceptación del bloque cuando se trabaja en la creación del siguiente bloque de la cadena, utilizando el hash del bloque aceptado como el hash anterior.

Los nodos siempre consideran la cadena más larga como la correcta y comienzan a trabajar en su extensión. Si dos nodos envían versiones diferentes del siguiente bloque simultáneamente, algunos nodos pueden recibir uno u otro primero. En este caso, trabajan en la primera que reciben, pero conservan la otra rama si se alarga. El empate se rompe cuando se encuentra la siguiente prueba de trabajo y una rama se hace más larga; los nodos que estaban trabajando en la otra rama cambian al nodo más largo. Los nuevos problemas de transacción no necesariamente tienen que llegar a todos los nodos. Ambos llegan a muchos nodos, entrarán en un bloque antes de que pase mucho tiempo. Las transmisiones en bloque también toleran la pérdida de mensajes. Si un nodo no recibe un bloque, lo solicitará cuando reciba el siguiente bloque y se dará cuenta de que se ha perdido uno de ellos.

Incentivo por convención

La primera operación del bloque es una operación especial que inicia una nueva moneda cuyo propietario es el creador del bloque. Esto añade un incentivo para que los nodos apoyen la red y proporciona una forma inicial de distribuir las monedas en circulación, ya que no hay autoridad para crearlas. Esta adición estable de una cantidad constante de nuevas monedas es análoga a la de los mineros de oro que gastan recursos para añadir oro a la circulación. En nuestro caso, es el tiempo de la CPU y la electricidad que se gasta. El incentivo también puede ser fundado con los costos de transacción. Si el valor de salida de una transacción es menor que el valor de entrada, la diferencia es una tarifa de transacción que se añade 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 ser transferido totalmente a las comisiones de transacción y estar completamente libre de inflación. El incentivo puede ayudar a animar a los nodos a seguir siendo honestos. Si un atacante egoísta consigue reunir más potencia de CPU que todos los nudos honestos, tendrá que elegir entre usarla para defraudar a la gente, robar sus pagos o usarla para generar nuevas divisas. Debe encontrar más rentable jugar con las reglas, esta regla le favorece con más monedas que todas las demás combinadas, lo que daña el sistema y la validez de su propia riqueza.

Reclamar espacio en disco

Después de que la última transacción en una divisa se entierra en bloques suficientes, las transacciones que se han realizado antes pueden ser descartadas para ahorrar espacio en el disco. Para facilitar esto sin romper el hash de bloque, las transacciones se verifican en un árbol de Merkle, con la única raíz incluida en el hash de bloque. Los bloques viejos se pueden comprimir quitando ramas del árbol. No es necesario guardar los hashes internos. La cabecera de un bloque sin transacciones sería de unos 80 bytes. Si suponemos que cada bloque se genera cada 10 minutos, 80 bytes * 6 * 24 * 365 = 4,2 MB por año. Con los ordenadores que se venden generalmente con 2 GB de RAM para 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 las cabeceras de los bloques permanecen en la memoria.

Servidor de marcas de tiempo

Verificación de pago simplificada

Puede verificar los pagos sin necesidad de realizar un nodo de red completo. Un usuario sólo necesita conservar una copia de las cabeceras de los bloques de la cadena de prueba de mayor longitud, que se puede obtener buscando en los nodos de la red hasta que se convenza de que tiene la cadena más larga y obtenga la rama de Merkle que enlaza la transacción con el bloque en el que fue fechada. No puede verificar la transacción por sí mismo, pero al enlazarla a un lugar de la cadena, ahora puede ver que un nodo de la red la ha aceptado y los bloques que se añadan posteriormente confirman que la red la ha aceptado. Como tal, la verificación es fiable porque los nodos honestos controlan la red, pero es más vulnerable si la red está dominada por un atacante. Mientras que los nodos de la red pueden verificar las transacciones por sí mismos, el método simplificado puede ser engañado por las transacciones fabricadas por el atacante hasta que el atacante pueda continuar dominando la red. Una estrategia para protegerse contra esto es aceptar alertas de los nodos de la red cuando detectan un bloque inválido, pidiendo al usuario que descargue el bloque completo y las transacciones alertadas para confirmar la inconsistencia. Las empresas que reciben pagos frecuentes querrán ejecutar sus propios nodos para una seguridad más independiente y una verificación más rápida.

Combinación y partición de valores

Aunque es posible manipular las monedas individualmente, sería difícil manejar una transacción por cada centavo de una transferencia. Para permitir que el valor se divida y combine, las transacciones contienen entradas y salidas múltiples. Típicamente, habrá una sola entrada de una transacción previa mayor o múltiples entradas que combinen cantidades menores y al menos dos salidas: una para el pago y otra para devolver el cambio, si hay algún cambio, de vuelta al emisor. Cabe señalar que cuando una transacción depende de varias transacciones, y estas transacciones dependen de mucho más, no hay problema. Nunca es necesario extraer una copia completa de la transacción, por sí sola, del historial de transacciones.

Privacidad

El modelo bancario tradicional logra un nivel de privacidad al limitar el acceso a la información de las partes involucradas y del tercero de confianza. La necesidad de anunciar públicamente todas las transacciones se opone a este método, pero la privacidad puede mantenerse rompiendo el flujo de información en otros lugares: manteniendo el anonimato de las claves públicas. El público puede ver que alguien está enviando una cantidad a otra persona, pero sin información que relacione la transacción con alguien. Esto es similar al nivel de información que muestran las bolsas de valores, donde el tiempo y el tamaño de las transacciones individuales, la “cinta”, es pública, pero sin decir quiénes son las partes. Como cortafuegos adicionales, se debe utilizar un nuevo par de claves para cada transacción, de modo que se puedan asociar con un propietario común. Algún tipo de asociación es inevitable con múltiples transacciones entrantes, lo que puede revelar que sus entradas han sido apropiadas por el mismo propietario. El riesgo es que si se revela el propietario de una clave, el enlace puede revelar otras transacciones pertenecientes al mismo propietario.

Cálculos

Consideramos el escenario en el que un atacante intenta generar una cadena alternativa más rápido que una cadena honesta. Incluso si esto se logra, no abre el sistema a cambios arbitrarios, como la creación de valor aéreo o la obtención de dinero que nunca perteneció al atacante. Los nodos no aceptarían una transacción no válida como pago y los nodos honestos nunca aceptarían un bloque que los contenga. Un atacante sólo puede intentar cambiar una de sus transacciones para recibir el dinero que ha gastado recientemente. La carrera entre una cadena honesta y la cadena de un atacante puede ser caracterizada como un Binomial Random Walk.

El evento de éxito es la cadena honesta siendo extendida por un bloque, aumentando esa ventaja en +1, y el evento de fallo es la cadena del atacante siendo extendida por un bloque, reduciendo la distancia en -1. La probabilidad de que un atacante pueda llegar de un déficit dado es análoga al problema de la Parada de Apuestas.

Supongamos que un jugador con crédito ilimitado comienza con un déficit y potencialmente juega un número infinito de intentos para tratar de alcanzar un punto de equilibrio. Podemos calcular la probabilidad de alcanzar el punto de equilibrio, o de que un atacante llegue a la cadena honesta, como sigue:

  1. p = probabilidad de que un nodo honesto encuentre el siguiente bloque
  2. q = probabilidad de que el atacante encuentre el siguiente bloque
  3. qz = probabilidad de que el atacante alcance z bloques hacia atrás.

Dada nuestra hipótesis de que p> q, la probabilidad disminuye exponencialmente a medida que aumenta el número de bloques que el atacante debe golpear. Con probabilidades opuestas, si usted no hace un movimiento exitoso desde el principio, sus probabilidades se vuelven extremadamente pequeñas a medida que se queda atrás. Ahora, consideramos cuánto 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. Suponemos que el remitente es un intruso que quiere hacer creer al destinatario que le pagó durante un tiempo y luego cambiar la transacción para que lo devuelva una vez que haya pasado el tiempo. El receptor recibirá un aviso cuando esto suceda, pero el remitente espera que sea demasiado tarde. El receptor genera un nuevo par de claves y entrega la clave pública al remitente poco después de firmar.

Esto evita que el remitente prepare una cadena de bloques por adelantado, trabajando continuamente hasta que tenga la suerte de llegar temprano y ejecutar la operación en ese momento. Después de 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 a que la operación se añada al bloque y los bloques z se han enlazado después de la operación.