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

1 bitcoin : Un Sistema de Efectivo Electr nico Usuario-a-UsuarioSatoshi al Espa ol de Angel Le n - Una versi n puramente electr nica de Efectivo permitir a que los pagosen l nea fuesen enviados directamente de un ente a otro sin tener que pasar pormedio de una instituci n financiera. Firmas digitales proveen parte de la soluci n,pero los beneficios principales se pierden si existe un tercero confiable para prevenirel doble-gasto. Proponemos una soluci n al problema del doble gasto utilizando unared Usuario-a-Usuario . La red coloca estampas de tiempo a las transacciones al crearun hash de las mismas en una cadena continua de pruebas de trabajo basadas enhashes, formando un registro que no puede ser cambiado sin volver a recrear laprueba de trabajo.

2 La cadena m s larga no solo sirve como la prueba de la secuenciade los eventos testificados, sino como prueba de que vino del gremio de poder deprocesamiento de CPU m s grande. Siempre que la mayor a del poder deprocesamiento de CPU est bajo el control de los nodos que no cooperan para atacarla red, estos generar n la cadena m s larga y le llevar n la ventaja a los red en s misma requiere una estructura m nima. Los mensajes son enviados bajola base de mejor esfuerzo, y los nodos pueden irse y volver a unirse a la red como lesparezca, aceptando la cadena de prueba de trabajo de lo que sucedi durante Introducci n El comercio en el Internet ha venido a depender exclusivamente de instituciones financieras lascuales sirven como terceros confiables para el procesamiento de pagos electr nicos.

3 Mientras queel Sistema funciona lo suficientemente bien para la mayor a de las transacciones, a n sufre de lasdebilidades inherentes del modelo basado en confianza. Transacciones completamente no-revertibles no son realmente posibles, dado que las instituciones financieras no pueden evitarmediar disputas. El costo de la mediaci n incrementa costos de transacci n, limitando el tama om nimo pr ctico por transacci n y eliminando la posibilidad de peque as transacciones casuales,y hay un costo m s amplio en la p rdida de la habilidad de hacer pagos no-reversibles porservicios no-reversibles. Con la posibilidad de revertir, la necesidad de confianza se expande.

4 Loscomerciantes deben tener cuidado de sus clientes, molest ndolos pidiendo m s informaci n de laque se necesitar a de otro modo. Un cierto porcentaje de fraude es aceptable como costos e incertidumbres de pagos pueden ser evitadas en persona utilizando dinero f sico,pero no existe un mecanismo para hacer pagos por un canal de comunicaci n sin un que se necesita es un Sistema de pagos electr nicos basado en pruebas criptogr ficas envez de confianza, permiti ndole a dos partes interesadas en realizar transacciones directamentesin la necesidad de un tercero confiable. Las transacciones que son computacionalmente pocofactibles de revertir proteger an a los vendedores de fraude, y mecanismos de dep sitos defideicomisos de rutina podr an ser f cilmente implementados para proteger a los compradores.

5 Eneste trabajo, proponemos una soluci n al problema del doble-gasto utilizando un servidor demarcas de tiempo Usuario-a-Usuario distribuido para generar una prueba computacional del ordencronol gico de las transacciones. El Sistema es seguro mientras que nodos honestos controlencolectivamente m s poder de procesamiento (CPU) que cualquier grupo de nodos atacantes encooperaci TransaccionesDefinimos una moneda electr nica como una cadena de firmas digitales. Cada due o transfiere lamoneda al pr ximo al firmar digitalmente un hash de la transacci n previa y la clave publica delpr ximo due o y agregando estos al final de la moneda.

6 Un beneficiario puede verificar lasfirmas para verificar la cadena de problema claro es que el beneficiario no puede verificar si uno de los due os no se hizo undoble-gasto de la moneda. Una soluci n com n es introducir una autoridad central confiable, ocasa de moneda, que revisa cada si cada transacci n tiene doble-gasto. Despu s de cadatransacci n, la moneda debe ser regresada a la casa de moneda para generar una nueva moneda, ysolo las monedas generadas directamente de la casa de moneda son las que se conf an de no tenerdoble-gasto. El problema con esta soluci n es que el destino del Sistema monetario enterodepende de la compa a que gestiona la casa de moneda, con cada transacci n teniendo que pasarpor ellos, tal como un una forma para que el beneficiario pueda saber que los due os previos nofirmaron ningunas transacciones m s tempranas.

7 Para nuestros prop sitos, la transacci n m stemprana es la que cuenta, as que no nos importan otros intentos de doble-gasto m s tarde. La nica forma de confirmar la ausencia de una transacci n es estando al tanto de todas lastransacciones. En el modelo de la casa de moneda, la casa de moneda estaba al tanto de todas lastransacciones y esta decidir a cuales llegaban primero. Para lograr esto sin un tercero confiable,las transacciones deben ser anunciadas p blicamente [1], y necesitamos un Sistema departicipantes que est n de acuerdo con una historia nica del orden en que estas fueron beneficiario necesita prueba de que a la hora de cada transacci n, la mayor a de los nodosestuvieron de acuerdo que esta fue la primera que se recibi.

8 3. Servidor de marcas de soluci n que proponemos comienza con un servidor de marcas de tiempo. Un servidor demarcas de tiempo funciona al tomar un hash de un bloque de elementos a ser fechados ypublicando ampliamente el hash, tal como en un peri dico, o una publicaci n Usenet [2-5]. Lamarca de tiempo prueba que la data debe haber existido en el tiempo, obviamente, para metersedentro del hash. Cada marca de tiempo incluye la marca de tiempo previa en su hash, formandouna cadena, con cada marca de tiempo adicional reforzando las anteriores a nClave p blicadel Due o 1 Firma delDue o 0 HashTransacci nClave p blicadel Due o 2 Firma delDue o 1 Hash Transacci nClave p bicadel Due o 3 Firma delDue o 2 Hash VerificarClave privadadel Due o 2 Clave privadadel Due o 1 Firmar Clave privadadel Due o 3 VerificarFirmar4.

9 Prueba-de-trabajoPara implementar un servidor de marcas de tiempo en una base Usuario-a-Usuario , necesitaremosutilizar un Sistema de prueba-de-trabajo similar al Hashcash de Adam Back [6], en vez de unperi dico o una publicaci n en Usenet. La prueba-de-trabajo envuelve la exploraci n de un valorque al calcular un hash, tal como SHA-256, el hash empiece con un n mero de bits en cero. Eltrabajo promedio requerido es exponencial en el n mero de bits puestos en cero requeridos ypuede ser verificado ejecutando un solo nuestra red de marcas de tiempo, implementamos la prueba-de-trabajo incrementando unnonce en el bloque hasta que un valor es encontrado que de el n mero requerido de bits en ceropara el hash del bloque.

10 Una vez que el esfuerzo de CPU se ha gastado para satisfacer la prueba-de-trabajo, el bloque no puede ser cambiado sin rehacer todo el trabajo. A medida que m sbloques son encadenados despu s de este, el trabajo para cambiar el bloque incluir a rehacertodos los bloques despu s de prueba-de-trabajo tambi n resuelve el problema de determinar la representaci n en cuanto adecisi n por mayor a. Si la mayor a fuese basada en un voto por direcci n IP, podr a sersubvertida por alguien capaz de asignar muchos IPs. Prueba-de-trabajo es esencialmente un-CPU-un-voto. La decisi n de la mayor a es representada por la cadena m s larga, la cual tiene laprueba-de-trabajo de mayor esfuerzo invertido en ella.