Bitcoin: Un sistema de dinero electrónico peer-to-peer

8/13/2019 Bitcoin: Un sistema de dinero electrónico peer-to-peer

http://slidepdf.com/reader/full/bitcoin-un-sistema-de-dinero-electronico-peer-to-peer 1/8

Bitcoin: Un sistema de dinero electrónico peer-to-peer

Satoshi Nakamoto

[email protected]

www.bitcoin.org

Abstract. La adopción del sistema peer-to-peer en el contexto de dinero electrónico

permitiría la transferencia de dinero entre distintas entidades sin intervención de una

institución financiera. Las firmas digitales forman parte de la solución, pero los beneficios

principales se pierden si se requiere de un tercero confiable para prevenir el doble gasto.

Proponemos una solución al problema del doble gasto utilizando una red peer-to-peer. La red

imprime un sello de tiempo en cada transacción aplicando una función hash y crea una

cadena basada en un sistema de prueba de trabao, generando un historial que no puede ser

cambiado sin rehacer la prueba de trabao. 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 mayoría 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!cción

$l comercio en %nternet ha llegado a depender casi exclusivamente en instituciones financieras que

sirvan como terceros confiables para procesar pagos electrónicos. &i bien el sistema funciona

suficientemente bien para la mayoría 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 mediación de disputas. $l costo de esta

mediación incrementa los costos de las transacciones, limitando así el tama'o mínimo pr!ctico de la

transacción 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 información de la que podrían requerir. *n cierto

porcentae de fraude es aceptado como inevitable. $stos costos e incertidumbres de pago pueden ser evitados

al utilizar una divisa física, 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 criptografía en lugar de la confianza,

permitiendo así a dos entidades cualquiera realizar una transacción de forma directa sin la necesidad de un

tercero de confianza. Las transacciones que no son pr!cticas de revertir a nivel computacional protegerían alos vendedores de fraude, mientras que un mecanismo de fideicomiso podría ser f!cilmente implementado

para proteger a los compradores. $n este paper, proponemos una solución al problema de doble gasto

utilizando un servidor peer-to-peer de sellado de tiempo distribuido para generar prueba computacional del

orden cronológico 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 trabaando de forma

cooperativa.

". #ransacciones

)efinimos a una moneda electrónica como una cadena de firmas digitales. ada due'o transfiere unamoneda al siguiente firmando digitalmente un hash de la transacción previa y la llave p+blica del próximo

due'o y a'adiendo estas al final de la moneda. *n beneficiario puede verificar las firmas para verificar la

cadena de propiedad.

mailto:[email protected]

mailto:[email protected]



$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 solución com+n es introducir una autoridad central de confianza, o ceca,

que revise cada transacción en busca de doble gasto. Luego de cada transacción, la moneda debe volver a la

ceca para que se envíe una nueva moneda, y solo las monedas enviadas directamente desde la ceca son

confiables de no haber sido doble gastadas. $l problema con esta solución es que el destino de todo el

sistema monetario depende de la compa'ía que manea la ceca, haciendo que cada transacción 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

transacción. Para nuestros intereses, la transacción 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 transacción 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 solución que proponemos empieza con un servidor de sellado de tiempo. *n servidor de sellado de

tiempo funciona tomando el hash de un bloque de obetos 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 trabao similar a 3ashcash 40. $l sistema de prueba de trabao involucra buscar un valor que, al

aplicarle la función hash 5utilizando, por eemplo, &36-1247, resulte en un hash que empiece con cierto

n+mero de bits cero. $l trabao promedio requerido es depende de forma exponencial del n+mero de bits cero

requeridos y puede ser verificado eecutando una sola función hash.

Para nuestra red de sellado de tiempo, implementamos la prueba de trabao 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 trabao, el bloque

no puede ser cambiado sin volver a realizar el trabao. 6 medida que m!s bloques son encadenados, el

trabao para cambiar el bloque implica rehacer todos los bloques que le siguen.



$sta prueba de trabao tambi"n resuelve el problema de determinar una mayoría en el proceso de

decisión. &i la mayoría se basase en un voto por dirección %P, el sistema podría ser atacado por un grupo

capaz de controlar m+ltiples direcciones %P. La prueba de trabao es esencialmente un voto por P*. Ladecisión de la mayoría es determinada por la cadena m!s larga, que tiene el mayor esfuerzo de prueba de

trabao combinado invertido en la misma. &i la mayoría 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 trabao del bloque y todos los bloques posteriores

y luego alcanzar y sobrepasar el trabao 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 variación de inter"s de los nodos a trav"s

del tiempo, la dificultad de la prueba de trabao es determinada por un obetivo 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 trabaa para encontrar una prueba de trabao difícil para su bloque.

;. uando un nodo encuentra una prueba de trabao, 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 aceptación del bloque trabaando en crear el próximo 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 trabaando enexpandirla. &i dos nodos trasmiten diferentes versiones del próximo bloque simult!neamente, algunos nodos

recibir!n una o la otra versión primero. $n ese caso, trabaan en la primer versión recibida, pero guardan la

otra en caso de que se vuelva m!s larga. $l empate se decidir! cuando la próxima prueba de trabao sea

encontrada< los nodos que hayan estado trabaando en la otra versión 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 mensaes caídos. &i un nodo no ha recibido un bloque, lo pedir! cuando reciba el próximo

bloque y se de cuenta que se ha perdido uno.

+. ncenti%o

Por convención, la primer transacción en un bloque es una transacción 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 circulación, ya que no existe una autoridad central para

distribuirlas. La adición constante de una cantidad de monedas nuevas es an!loga a los mineros de oro que

utilizan recursos para poner oro en circulación. $n nuestro caso, lo que se gasta es poder de procesamiento y

electricidad.

$l incentivo tambi"n puede ser fundado con tarifas de transacción. &i el valor de salida de una

transacción es menor que su valor de entrada, la diferencia es una tarifa de transacción que es a'adida al

valor incentivo del bloque que contiene la transacción. *na vez que un n+mero predeterminado de monedas

ha entrado en circulación, el incentivo puede transformarse enteramente en tarifas de transacción y estar

completamente libre de inflación.

$l incentivo motiva a los nodos a permanecer honestos. &i un atacante es capaz de poseer m!s poderde 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 lógica, 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 transacción en una moneda es sucedida por suficientes bloques, las

transacciones anteriores pueden ser descartadas para ahorrar espacio de disco. Para lograr esto sin romper elhash del bloque, se les aplica la función hash a las transacciones en un !rbol #er=le >01020, incluyendo

solo la raíz en el hash del bloque. Los bloques vieos pueden ser compactados al cortar las raíces 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/icación de pago simpli/icada

$s posible verificar pagos sin eecutar 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 transacción

con el bloque en la que ha sido sellada. o puede verificar la transacción 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 verificación 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 sería el aceptar

alertas de nodos de red cuando detecten un bloque inv!lido, motivando al soft8are del usuario para descargarel bloque entero y las transacciones alertadas para confirmar la inconsistencia. 6quellos negocios que reciban

pagos frecuentes probablemente deseen eecutar sus propios nodos para una seguridad m!s independiente y

verificación m!s r!pida.



0. ombinando 2 di%idiendo %alor

6unque sería posible manear monedas individualmente, sería poco pr!ctico realizar una transacción

para cada centavo en una transferencia. Para permitir la combinación y división del valor, las transacciones

contienen m+ltiples entradas y salidas. ormalmente habr! una sola entrada de una transacción 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 información alas 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 fluo de

información en otro aspecto9 manteniendo las claves p+blicas anónimas. $l p+blico puede ver que alguien ha

enviado cierta cantidad a alguien m!s, pero sin ninguna información que conecte a la transacción 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 transacción para evitar que sean enlazadas a un

due'o en com+n. ierto nivel de relación 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, podría revelarse todas las transacciones que pertenecen al mismo due'o.

11. 4lc!los

onsideramos un escenario en el que un atacante trata de generar una cadena alternativa m!s velozque la cadena honesta. %ncluso si lo lograse, esto no dea 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

transacción 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 ventaa

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



6quí puede verse que la probabilidad disminuye exponencialmente con F9

Gesolviendo para P menor a @,/H9

1". oncl!sión

3emos propuesto un sistema para las transacciones electrónicas sin depender de la confianza.

$mpezamos con el marco de trabao usual de un grupo de monedas creadas a partir de firmas digitales, lascuales 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 trabao 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 trabaan simult!neamente con poca coordinación y pueden abandonar y unirse a la red a voluntad,

aceptando la cadena de prueba de trabao como prueba de lo que ocurrió mientras se fueron. Iotan con su

poder de procesamiento, expresando su aceptación de bloques v!lidos al trabaar en expandirlos y

rechazando los inv!lidos al rehusarse a trabaar en ellos. ualquier regla e incentivo necesario puede ser

forzado con este mecanismo de consenso.



*e/erencias

/0 J. )ai, Kb-money,K http9888.8eidai.combmoney.txt, /MM?.

10 3. #assias, N.&. 6vila, and O.-O. uisquater, K)esign of a secure timestamping service 8ith minimal trustrequirements,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,Khttp9888.hashcash.orgpapershashcash.pdf, 1@@1.

>0 G.. #er=le, KProtocols for public =ey cryptosystems,K %n Proc. /M?@ &ymposium on &ecurity andPrivacy, %$$$ omputer &ociety, pages /11-/::, 6pril /M?@.

?0 J. Qeller, K6n introduction to probability theory and its applications,K /M2>.

Bitcoin: Un sistema de dinero electrónico peer-to-peer

Documents

Transcript of Bitcoin: Un sistema de dinero electrónico peer-to-peer