Bitcoin: Un sistema de dinero electrnico peer-to-peer

Satoshi Nakamoto satoshin@gmx.com www.bitcoin.org

Abstract. La adopcin del sistema peer-to-peer en el contexto de dinero electrnico permitira la transferencia de dinero entre distintas entidades sin intervencin de una institucin financiera. Las firmas digitales forman parte de la solucin, pero los beneficios principales se pierden si se requiere de un tercero confiable para prevenir el doble gasto. Proponemos una solucin al problema del doble gasto utilizando una red peer-to-peer. La red imprime un sello de tiempo en cada transaccin aplicando una funcin hash y crea una cadena basada en un sistema de prueba de traba o, generando un historial que no puede ser cambiado sin rehacer la prueba de traba o. La cadena m!s larga no solo sirve como prueba de la secuencia de eventos presenciados, sino tambi"n de que proviene de la pool con mayor poder de procesamiento. #ientras la mayora del poder de procesamiento sea controlado por nodos que no est!n cooperando para atacar a la red, generar!n la cadena m!s larga y sobrepasar!n a los atacantes.

1. ntrod!ccin
$l comercio en %nternet ha llegado a depender casi exclusivamente en instituciones financieras que sirvan como terceros confiables para procesar pagos electrnicos. &i bien el sistema funciona suficientemente bien para la mayora de las transacciones, sigue sufriendo de la inherente debilidad que conlleva un modelo basado en la confianza. Las transacciones completamente irreversibles no son realmente posibles, ya que las instituciones financieras no pueden evitar la mediacin de disputas. $l costo de esta mediacin incrementa los costos de las transacciones, limitando as el tama'o mnimo pr!ctico de la transaccin e impidiendo la posibilidad de transacciones m!s casuales y de menor tama'o. (ambi"n existe un costo m!s general que se encuentra en la p"rdida de la habilidad de realizar pagos no reversibles para servicios no reversibles. )ebido a la existencia de la reversibilidad, la necesidad de confianza se esparce. Los comerciantes deben molestar a sus clientes pidi"ndoles m!s informacin de la que podran requerir. *n cierto porcenta e de fraude es aceptado como inevitable. $stos costos e incertidumbres de pago pueden ser evitados al utilizar una divisa fsica, pero no existe ning+n mecanismo para realizar pagos sobre un canal de comunicaciones sin un tercero de confianza. Lo que se necesita es un sistema de pago basado en la criptografa en lugar de la confianza, permitiendo as a dos entidades cualquiera realizar una transaccin de forma directa sin la necesidad de un tercero de confianza. Las transacciones que no son pr!cticas de revertir a nivel computacional protegeran a los vendedores de fraude, mientras que un mecanismo de fideicomiso podra ser f!cilmente implementado para proteger a los compradores. $n este paper, proponemos una solucin al problema de doble gasto utilizando un servidor peer-to-peer de sellado de tiempo distribuido para generar prueba computacional del orden cronolgico de las transacciones. $l sistema es seguro siempre y cuando los nodos honestos controlen de forma colectiva m!s poder de procesamiento que cualquier grupo de nodos atacantes traba ando de forma cooperativa.

". #ransacciones
)efinimos a una moneda electrnica como una cadena de firmas digitales. ,ada due'o transfiere una moneda al siguiente firmando digitalmente un hash de la transaccin previa y la llave p+blica del prximo due'o y a'adiendo estas al final de la moneda. *n beneficiario puede verificar las firmas para verificar la cadena de propiedad.

$l problema es, por supuesto, que el beneficiario no puede verificar que uno de los due'os no haya gastado dos veces la moneda. *na solucin com+n es introducir una autoridad central de confianza, o ceca, que revise cada transaccin en busca de doble gasto. Luego de cada transaccin, la moneda debe volver a la ceca para que se enve una nueva moneda, y solo las monedas enviadas directamente desde la ceca son confiables de no haber sido doble gastadas. $l problema con esta solucin es que el destino de todo el sistema monetario depende de la compa'a que mane a la ceca, haciendo que cada transaccin tenga que pasar por ella, similar al funcionamiento de un banco. -ecesitamos una forma para que el beneficiario sepa que el due'o previo no firm ninguna otra transaccin. Para nuestros intereses, la transaccin m!s antigua es la que cuenta, por lo que no nos preocupan intentos subsiguientes de doble gasto. La +nica forma de confirmar la ausencia de una transaccin es el estar informado de todas ellas. $n el modelo basado en cecas, la ceca que conoce todas las transacciones decide cu!l lleg primero. Para lograr esto mismo sin un tercero en el que confiar, las transacciones deben ser p+blicamente anunciadas ./0 y necesitamos un sistema para que los participantes est"n de acuerdo en un mismo orden en el que fueron recibidas.

$. Ser%idor de sellado de tiempo

La solucin que proponemos empieza con un servidor de sellado de tiempo. *n servidor de sellado de tiempo funciona tomando el hash de un bloque de ob etos destinados a ser sellados y publicando el hash de forma masiva .1-20. $l sellado de tiempo prueba que los datos deben haber existido en ese momento, obviamente, para formar parte del hash. ,ada sellado de tiempo incluye el sellado anterior en su hash, formando una cadena en la que cada sellado de tiempo adicional hace referencia a los que se encontraban anteriormente.

&. 'r!eba de traba(o

Para implementar un servidor de sellado de tiempo distribuido, necesitaremos usar un sistema de prueba de traba o similar a 3ashcash .40. $l sistema de prueba de traba o involucra buscar un valor que, al aplicarle la funcin hash 5utilizando, por e emplo, &36-1247, resulte en un hash que empiece con cierto n+mero de bits cero. $l traba o promedio requerido es depende de forma exponencial del n+mero de bits cero requeridos y puede ser verificado e ecutando una sola funcin hash. Para nuestra red de sellado de tiempo, implementamos la prueba de traba o incrementando un nonce en el bloque hasta que un valor es encontrado que da al hash del bloque la cantidad de bits cero requerida. *na vez que suficiente poder de procesamiento ha sido usado para satisfacer la prueba de traba o, el bloque no puede ser cambiado sin volver a realizar el traba o. 6 medida que m!s bloques son encadenados, el traba o para cambiar el bloque implica rehacer todos los bloques que le siguen.

$sta prueba de traba o tambi"n resuelve el problema de determinar una mayora en el proceso de decisin. &i la mayora se basase en un voto por direccin %P, el sistema podra ser atacado por un grupo capaz de controlar m+ltiples direcciones %P. La prueba de traba o es esencialmente un voto por ,P*. La decisin de la mayora es determinada por la cadena m!s larga, que tiene el mayor esfuerzo de prueba de traba o combinado invertido en la misma. &i la mayora del poder de procesamiento es controlado por nodos honestos, la cadena honesta crecer! m!s r!pido y superar! a cualquier cadena competidora. Para modificar un bloque anterior, un atacante deber! rehacer la prueba de traba o del bloque y todos los bloques posteriores y luego alcanzar y sobrepasar el traba o de los nodos honestos. #ostraremos luego que la probabilidad de que esto ocurra disminuye de forma exponencial a medida que nuevos bloques son a'adidos. Para compensar el incremento de velocidad en hard8are y la variacin de inter"s de los nodos a trav"s del tiempo, la dificultad de la prueba de traba o es determinada por un ob etivo de cierta cantidad de nodos por hora. &i son generados demasiado r!pido, la dificultad incrementa.

). *ed
Los pasos para el funcionamiento de la red son los siguientes9 /. Las transacciones nuevas son transmitidas a todos los nodos. 1. ,ada nodo recolecta nuevas transacciones en un bloque. :. ,ada nodo traba a para encontrar una prueba de traba o difcil para su bloque. ;. ,uando un nodo encuentra una prueba de traba o, transmite el bloque a todos los nodos. 2. Los nodos aceptan este bloque si y solo si todas las transacciones en "l son v!lidas y no han sido ya gastadas. 4. Los nodos expresan su aceptacin del bloque traba ando en crear el prximo bloque en la cadena, usando el hash del bloque aceptado como el hash anterior. Los nodos siempre consideran a la cadena m!s larga como la correcta y seguir!n traba ando en expandirla. &i dos nodos trasmiten diferentes versiones del prximo bloque simult!neamente, algunos nodos recibir!n una o la otra versin primero. $n ese caso, traba an en la primer versin recibida, pero guardan la otra en caso de que se vuelva m!s larga. $l empate se decidir! cuando la prxima prueba de traba o sea encontrada< los nodos que hayan estado traba ando en la otra versin pasar!n a la m!s larga. Las transmisiones de nuevas transacciones no deben necesariamente llegar a todos los nodos. #ientras lleguen a varios nodos, entrar!n a un bloque en poco tiempo. Las transmisiones de bloques tambi"n son tolerantes de mensa es cados. &i un nodo no ha recibido un bloque, lo pedir! cuando reciba el prximo bloque y se de cuenta que se ha perdido uno.

+. ncenti%o
Por convencin, la primer transaccin en un bloque es una transaccin especial que empieza una nueva moneda que pertenece al creador del bloque. $sto a'ade un incentivo para que los nodos soporten a la red, y provee una forma inicial de poner monedas en circulacin, ya que no existe una autoridad central para distribuirlas. La adicin constante de una cantidad de monedas nuevas es an!loga a los mineros de oro que utilizan recursos para poner oro en circulacin. $n nuestro caso, lo que se gasta es poder de procesamiento y electricidad. $l incentivo tambi"n puede ser fundado con tarifas de transaccin. &i el valor de salida de una transaccin es menor que su valor de entrada, la diferencia es una tarifa de transaccin que es a'adida al valor incentivo del bloque que contiene la transaccin. *na vez que un n+mero predeterminado de monedas ha entrado en circulacin, el incentivo puede transformarse enteramente en tarifas de transaccin y estar completamente libre de inflacin. $l incentivo motiva a los nodos a permanecer honestos. &i un atacante es capaz de poseer m!s poder de procesamiento que todos los nodos honestos, deber! elegir entre usarlo para cometer fraude y robar sus propios pagos, o usarlo para generar nuevas monedas. Por lgica, encontrar! m!s lucrativo el seguir las reglas, las cuales lo favorecen con m!s monedas que todos los dem!s combinados, que el intentar colapsar el

sistema y su propio dinero en el proceso.

,. Ahorrando espacio de disco

*na vez que la +ltima transaccin en una moneda es sucedida por suficientes bloques, las transacciones anteriores pueden ser descartadas para ahorrar espacio de disco. Para lograr esto sin romper el hash del bloque, se les aplica la funcin hash a las transacciones en un !rbol #er=le .>0.10.20, incluyendo solo la raz en el hash del bloque. Los bloques vie os pueden ser compactados al cortar las races del !rbol. Los hash interiores no necesitan ser guardados.

$l hash de un bloque sin transacciones pesa aproximadamente ?@ bytes. &i suponemos que los bloques son generados cada /@ minutos, ?@ bytes A 4 A 1; A :42 B ;,1 #C por a'o.

-. .eri/icacin de pago simpli/icada

$s posible verificar pagos sin e ecutar un nodo de red completo. *n usuario solo debe guardar una copia del hash del bloque de la cadena m!s larga, el cual puede obtener consultando a los nodos de la red hasta estar convencido que tiene la cadena m!s larga, y obtener la rama #er=le que conecta a la transaccin con el bloque en la que ha sido sellada. -o puede verificar la transaccin por s solo, pero al ubicarla en un lugar en la cadena, puede ver que un nodo la ha aceptado, y bloques a'adidos luego de la misma verifican que la red la ha aceptado.

)e esta forma, la verificacin es confiable siempre que los nodos honestos controlen la red, pero es m!s vulnerable si la red es dominada por un atacante. &i bien los nodos de la red pueden verificar transacciones por s solos, el m"todo simplificado puede ser enga'ado por las transacciones fabricadas de un atacante siempre que pueda seguir dominando la red. *na estrategia para proteger contra esto sera el aceptar alertas de nodos de red cuando detecten un bloque inv!lido, motivando al soft8are del usuario para descargar el bloque entero y las transacciones alertadas para confirmar la inconsistencia. 6quellos negocios que reciban pagos frecuentes probablemente deseen e ecutar sus propios nodos para una seguridad m!s independiente y verificacin m!s r!pida.

0. 1ombinando 2 di%idiendo %alor

6unque sera posible mane ar monedas individualmente, sera poco pr!ctico realizar una transaccin para cada centavo en una transferencia. Para permitir la combinacin y divisin del valor, las transacciones contienen m+ltiples entradas y salidas. -ormalmente habr! una sola entrada de una transaccin m!s grande o m+ltiples entradas que combinen peque'as transacciones, y como m!ximo dos salidas9 una para el pago, y una para devolver el cambio, si existiese, al transmisor.

13. 'ri%acidad
$l modelo bancario tradicional logra cierto nivel de privacidad limitando el acceso de informacin a las entidades involucradas y al tercero de confianza. La necesidad de anunciar todas las transacciones p+blicamente excluye este m"todo, pero la privacidad puede ser mantenida rompiendo el flu o de informacin en otro aspecto9 manteniendo las claves p+blicas annimas. $l p+blico puede ver que alguien ha enviado cierta cantidad a alguien m!s, pero sin ninguna informacin que conecte a la transaccin con una persona. $sto es similar a lo que ocurre en el mercado burs!til, donde se sabe el tiempo y tama'o de las transacciones individuales, pero no las entidades involucradas.

*n nuevo par de claves pueden ser usadas para cada transaccin para evitar que sean enlazadas a un due'o en com+n. ,ierto nivel de relacin es inevitable con transacciones de m+ltiples entradas, las cuales necesariamente revelan que las entradas provienen del mismo due'o. $l riesgo es que si el due'o de una clave es revelado, podra revelarse todas las transacciones que pertenecen al mismo due'o.

11. 14lc!los
,onsideramos un escenario en el que un atacante trata de generar una cadena alternativa m!s veloz que la cadena honesta. %ncluso si lo lograse, esto no de a al sistema abierto a cambios arbitrarios, como crear valor a partir de la nada o tomar dinero que nunca le perteneci al atacante. Los nodos no aceptar!n una transaccin inv!lida como paga, y los nodos honestos nunca aceptar!n un bloque que las contenga. *n atacante solo puede cambiar una de sus propias transacciones para recuperar dinero que gast recientemente. La carrera entre la cadena honesta y la cadena del atacante puede caracterizarse como un camino aleatorio binomio. $l evento exitoso es la cadena siendo extendida por un bloque, incrementando su venta a por D/, mientras que el evento fallido es la cadena del atacante siendo extendida por un bloque, reduciendo la distancia por -/. La probabilidad de que un atacante alcance la cadena honesta es an!loga a un problema de ruina del ugador. &upongamos que un ugador con cr"dito ilimitado empieza con un d"ficit y uega un n+mero potencialmente infinito de veces tratando de recuperar su dinero. Podemos calcular la probabilidad de que lo recupere, o de que un atacante alcance a la cadena honesta, de la siguiente manera .?09

p B probabilidad de que un nodo honesto encuentre el siguiente bloque q B probabilidad de que el atacante encuentre el siguiente bloque qz B probabilidad de que el atacante alcance la cadena honesta con una desventa a inicial de z bloques qz B 1 si p q (q / p)z si p>q

)ada nuestra suposicin de que p E q, la probabilidad disminuye exponencialmente a medida que el n+mero de bloques que el atacante debe alcanzar aumenta. ,on las probabilidades en su contra, si no consigue una venta a significativa al comienzo, sus chances se vuelven m!s peque'as mientras queda cada vez m!s atr!s. 6hora consideramos qu" tanto tiempo el destinatario de una transaccin debe esperar antes de estar lo suficientemente seguro de que el transmisor no puede cambiar la transaccin. 6sumimos que el transmisor es un atacante que quiere hacer creer al destinatario que le pag, para luego volver a tener el dinero en su posesin. $l destinatario ser! alertado cuando eso ocurra, pero el transmisor espera que sea ya demasiado tarde. $l receptor genera un nuevo par de claves y da la clave p+blica al transmisor poco antes de firmarla. $sto evita que el receptor pueda preparar una cadena de bloques antes de tiempo traba ando en ellos continuamente hasta lograr una venta a significativa y luego e ecutar la transaccin. *na vez que la transaccin es enviada, el transmisor deshonesto empieza a traba ar en secreto en una cadena paralela que contiene una versin alternativa de su transaccin. $l destinatario espera hasta que la transaccin ha sido a'adida al bloque y z cantidad de bloques han sido enlazados al mismo. -o sabe el progreso exacto del atacante, pero asumiendo que los bloques honestos hayan tomado la cantidad de tiempo promedio por bloque, el potencial progreso del atacante ser! una distribucin de Poisson con valor esperado9

Para obtener la probabilidad de que un atacante pueda alcanzar la cadena en este momento, multiplicamos la densidad de Poisson por cada cantidad de progreso que pueda haber hecho por la probabilidad de que pueda alcanzar la cadena desde ese punto9

,onvertido a cdigo ,9

6qu puede verse que la probabilidad disminuye exponencialmente con F9

Gesolviendo para P menor a @,/H9

1". 1oncl!sin
3emos propuesto un sistema para las transacciones electrnicas sin depender de la confianza. $mpezamos con el marco de traba o usual de un grupo de monedas creadas a partir de firmas digitales, las cuales proveen un fuerte control de propiedad, pero sin manera de evitar el doble gasto. Para solucionar esto, propusimos una red peer-to-peer que use un sistema de prueba de traba o para mantener un historial p+blico de las transacciones que r!pidamente se vuelve poco pr!ctico de atacar siempre que los nodos honestos controlen la mayor parte del poder de procesamiento. La red es robusta en su simplicidad no estructurada. Los nodos traba an simult!neamente con poca coordinacin y pueden abandonar y unirse a la red a voluntad, aceptando la cadena de prueba de traba o como prueba de lo que ocurri mientras se fueron. Iotan con su poder de procesamiento, expresando su aceptacin de bloques v!lidos al traba ar en expandirlos y rechazando los inv!lidos al rehusarse a traba ar en ellos. ,ualquier regla e incentivo necesario puede ser forzado con este mecanismo de consenso.

*e/erencias
./0 J. )ai, Kb-money,K http9LL888.8eidai.comLbmoney.txt, /MM?. .10 3. #assias, N.&. 6vila, and O.-O. Puisquater, K)esign of a secure timestamping service 8ith minimal trust requirements,K %n 1@th &ymposium on %nformation (heory in the Cenelux, #ay /MMM. .:0 &. 3aber, J.&. &tornetta, K3o8 to time-stamp a digital document,K %n Oournal of ,ryptology, vol :, no 1, pages MM-///, /MM/. .;0 ). Cayer, &. 3aber, J.&. &tornetta, K%mproving the efficiency and reliability of digital time-stamping,K %n &equences %%9 #ethods in ,ommunication, &ecurity and ,omputer &cience, pages :1M-::;, /MM:. .20 &. 3aber, J.&. &tornetta, K&ecure names for bit-strings,K %n Proceedings of the ;th 6,# ,onference on ,omputer and ,ommunications &ecurity, pages 1?-:2, 6pril /MM>. .40 6. Cac=, K3ashcash - a denial of service counter-measure,K http9LL888.hashcash.orgLpapersLhashcash.pdf, 1@@1. .>0 G.,. #er=le, KProtocols for public =ey cryptosystems,K %n Proc. /M?@ &ymposium on &ecurity and Privacy, %$$$ ,omputer &ociety, pages /11-/::, 6pril /M?@. .?0 J. Qeller, K6n introduction to probability theory and its applications,K /M2>.