Bitcoin: un sistema de dinero en efectivo electrónico peer ...

1 bitcoin : un sistema de dinero en efectivo electr nico peer-to-peer1 Satoshi al espa ol por forma de dinero en efectivo electr nico puramentepeer-to-peer deber apermitir enviar pagosonline directamente entre las partes y sin pasar a trav s de unainstituci n financiera. Las firmas digitales son parte de la soluci n,pero los beneficiosprincipales desaparecen si un tercero de confianza sigue siendo imprescindible paraprevenir el doble gasto. Proponemos una soluci n para el problema del doble gastousando una redpeer-to-peer. La red sella las transacciones en el tiempo en una cadenacontinua deproof-of-work2 basada en hash3, estableciendo un registro que no se puedemodificar sin rehacer laproof-of-work.

2 La cadena m s larga no solo sirve de pruebaefectiva de la secuencia de eventos, sino que tambi n demuestra que procede del conjuntode CPU m s potente. Mientras la mayor a de la potencia CPU est controlada por nodosque no cooperen para atacar la propia red, se generar la cadena m s larga y se aventajar a los atacantes. La red en s misma precisa de una estructura m nima. Los mensajes setransmiten en base a"mejor esfuerzo"4, y los nodos pueden abandonar la red y regresar aella a voluntad, aceptando la cadenaproof-of-work m s larga como prueba de lo que hasucedido durante su Introducci n El comercio en Internet ha llegado a depender casi exclusivamente de las instituciones financierascomo terceros de confianza en el proceso de los pagos electr nicos.

3 A pesar de que el sistemafunciona suficientemente bien en la mayor parte de las transacciones, sufre la debilidad inherenteal modelo basado en confianza. Las transacciones completamente irreversibles no son posiblesdebido a que las instituciones financieras no pueden evitar mediar en las disputas. El coste de estamediaci n incrementa los costes de transacci n, limitando su tama o m nimo til y eliminando laposibilidad de realizar peque as transacciones ocasionales, y hay un coste mayor al perderse laposibilidad de hacer transacciones irreversibles para servicios irreversibles. Con la posibilidad deser reversible, la necesidad de confianza crece. Los comerciantes deben tener precauci n con susclientes, solicit ndoles m s datos de los que de otra forma ser an necesarios.

4 Se acepta comoinevitable un cierto porcentaje de fraude. Esos costes y la incertidumbre en los pagos se puedenevitar cuando se usa dinero f sico en persona, pero no existe mecanismo que permita realizarpagos a trav s de un canal de comunicaci n sin la participaci n de un tercero de confianza. Es necesario, por tanto, un sistema de pago electr nico basado en prueba criptogr fica en lugarde confianza, permitiendo que dos partes interesadas realicen transacciones directamente entreellas, sin necesidad de un tercero de confianza. Si las transacciones son computacionalmenteimposibles de revertir, proteger n a los vendedores del fraude, y cualquier mecanismo de dep sitode garant a se puede implementar f cilmente para proteger al comprador.

5 En este documentoproponemos una soluci n al problema del doble gasto usando un servidor de sellado de tiempo,distribuido ypeer-to-peer, para generar la prueba computacional del orden cronol gico de lastransacciones. El sistema es seguro mientras los nodos honestos controlen colectivamente m spotencia CPU que cualquier grupo cooperante de nodos TransaccionesDefinimos una moneda electr nica como una cadena de firmas digitales. Cada propietariotransfiere la moneda al siguiente propietario firmando digitalmente unhash de la transacci nprevia y la clave p blica del siguiente propietario, y a adiendo ambos al final de la moneda. Elbeneficiario puede verificar las firmas para verificar la cadena de problema, por supuesto, es que el beneficiario no puede verificar que uno de los propietarios nohaya gastado dos veces la misma moneda.

6 La soluci n habitual es introducir una autoridad centralde confianza, o casa de la moneda, que comprueba cada transacci n para que eso no se cada transacci n, la moneda debe regresar a la casa de la moneda para distribuir una nuevamoneda, y solo las monedas emitidas directamente desde ella est n libres de la sospecha de doblegasto. El problema de esta soluci n es que el destino de todo el sistema de dinero depende de lacompa a que gestiona la casa de la moneda, por la cual pasa cada transacci n, igual que unbanco. Necesitamos una forma de que el beneficiario sepa que los propietarios previos no han firmadotransacciones anteriores. Para nuestros prop sitos, la transacci n m s temprana es la que cuenta,as que no nos preocupamos de los intentos de doble gasto posteriores.

7 La nica manera deconfirmar la ausencia de una transacci n es tener conocimiento de todas las transacciones. En elmodelo de la casa de la moneda, esta tiene conocimiento de todas las transacciones y decide cu lesllegaron primero. Para lograr esto sin la participaci n de una parte de confianza, las transaccioneshan de ser anunciadas p blicamente [1], y necesitamos un sistema para que los participantes est nde acuerdo en un nico historial del orden en que fueron recibidas. El beneficiario necesita pruebade que en el momento de la transacci n la mayor parte de los nodos estaban de acuerdo en que esafue la primera que se recibi .3. Servidor de sellado de tiempoLa soluci n que proponemos comienza con un servidor de sellado de tiempo.

8 Un servidor desellado de tiempo trabaja tomando elhash de un bloque de tems para sellarlos en el tiempo ynotificar p blicamente suhash, como un peri dico o unpost Usenet [2-5]. El sellado de tiempoprueba que los datos han existido en el tiempo, obviamente, para entrar en elhash. Cada selladode tiempo incluye el sellado de tiempo previo en suhash, formando una cadena, con cada selladode tiempo adicional reforzando al que estaba tem tem nClave p blicadel propietario 1 Firma delpropietario 0 HashTransacci nClave p blicadel propietario 2 Firma delpropietario 1 Hash Transacci nClave p blicadel propietario 3 Firma delpropietario 2 Hash VerificarClave privadadel propietario 2 Clave privadadel propietario 1 Firmar Clave privadadel propietario 3 VerificarFirmar4.

9 Proof-of-workPara implementar un servidor de sellado de tiempo distribuido de formapeer-to-peer,necesitaremos emplear un sistema deproof-of-work similar al Hashcash de Adam Back [6], m sque al de los peri dicos o lospost Usenet. Laproof-of-work consiste en escanear en busca de unvalor que cuando fuehasheado, al igual que con SHA-256, elhash comience con un n mero decero bits. El trabajo medio que hace falta es exponencial en el n mero de cero bits requeridos ypuede verificarse ejecutando un nico hash. Para nuestra red de sellado de tiempo, implementamos laproof-of-work incrementando unnonce5 en el bloque hasta que se encuentre un valor que d alhash del bloque los cero bitsrequeridos.

10 Una vez que se ha agotado el esfuerzo de CPU para satisfacer laproof-of-work, elbloque no se puede cambiar sin rehacer el trabajo. A medida que bloques posteriores se encadenentras l, el trabajo para cambiar un bloque incluir a rehacer todos los bloques aproof-of-work tambi n resuelve el problema de determinar la representaci n en la toma dedecisiones mayoritarias. Si la mayor a estuviera basada en un voto por IP, podr a subvertirse porcualquiera capaz de asignar muchas IPs. Laproof-of-work es esencialmente un voto por CPU. Ladecisi n de la mayor a est representada por la cadena m s larga, en la cual se ha invertido elmayor esfuerzo deproof-of-work. Si la mayor a de la potencia CPU est controlada por nodoshonestos, la cadena honesta crecer m s r pido y dejar atr s cualquier cadena que compita.