13. El Whitepaper de Bitcoin [P. 2] {Satoshi Nakamoto}

bitcoin-freiheit-logo
Lecturas de Bitcoin
13. El Whitepaper de Bitcoin [P. 2] {Satoshi Nakamoto}
Loading
/

Continuamos con la segunda parte del Whitepaper de Bitcoin traducido al español por @breathingdog. Puedes encontrar la primera parte aquí.

7. Recuperación de espacio de disco

Cuando la última transacción de una moneda está enterrada bajo suficientes bloques, las transacciones que se han gastado antes que ella se pueden descartar para ahorrar espacio en disco. Para facilitar esto sin romper el hash del bloque, las transacciones son hasheadas en un Árbol de Merkle [7][2][5], incluyendo solo la raíz en el hash del bloque. Los bloques viejos pueden compactarse podando ramas del árbol. Los hashes interiores no necesitan ser guardados.

Whitepaper de Bitcoin
Transacciones hasheadas en un árbol de Merkle
Whitepaper de Bitcoin
Tras eliminar las Tr. 0-2 del bloque

Una cabecera de bloque sin transacciones pesaría unos 80 bytes. Si suponemos que los bloques se generan cada 10 minutos, 80 bytes × 6 × 24 × 365 = 4.2MB por año. Siendo habitual la venta de ordenadores con 2GB de RAM en 2008, y con la Ley de Moore prediciendo un crecimiento de 1.2GB anual, el almacenamiento no debería suponer un problema incluso si hubiera que conservar en la memoria las cabeceras de bloque.

8. Verificación de pagos simplificada

Es posible verificar pagos sin ejecutar un nodo plenamente en red. El usuario solo necesita tener una copia de las cabeceras de bloque de la cadena más larga de proof-of-work, que puede conseguir solicitándola a los nodos de red hasta estar convencido de que tiene la cadena más larga, y obtener la rama Merkle que enlaza la transacción con el bloque en que está sellado en el tiempo. El usuario no puede comprobar la transacción por sí mismo pero, al enlazarla a un lugar en la cadena, puede ver que un nodo de la red la ha aceptado, y los bloques añadidos posteriormente confirman además que la red la ha aceptado.

Whitepaper de Bitcoin

Como tal, la verificación es fiable en tanto que los nodos honestos controlen la red, pero es más vulnerable si un atacante domina la red. Mientras que los nodos de red pueden verificar las transacciones por sí mismos, el método simplificado puede ser engañado por transacciones fabricadas por un atacante, en tanto el atacante pueda continuar dominando la red. Una estrategia para protegerse contra esto podría ser aceptar alertas de los nodos de red cuando detecten un bloque no válido, sugiriendo al software del usuario que descargue el bloque entero y las transacciones con aviso para confirmar la inconsistencia. Los negocios que reciban pagos con frecuencia seguramente preferirán tener sus propios nodos ejecutándose para tener más seguridad independiente y verificación más rápida.

9. Combinando y dividiendo valor

Aunque sería posible manipular monedas individualmente, no sería manejable hacer una transacción para cada céntimo en una transferencia. Para permitir que el valor se divida y combine, las transacciones contienen múltiples entradas y salidas. Normalmente habrá, o bien una entrada simple de una transacción anterior mayor, o bien múltiples entradas combinando pequeñas cantidades, y como máximo dos salidas: una para el pago y otra devolviendo el cambio, si lo hubiera, al emisor.

Whitepaper de Bitcoin

Cabe señalar que la diseminación de control, donde una transacción depende de varias transacciones, y esas transacciones dependen de muchas más, no supone aquí un problema. No existe la necesidad de extraer una copia completa e independiente del historial de una transacción.

10. Privacidad

El modelo tradicional de banca consigue un nivel de privacidad limitando el acceso a la información a las partes implicadas y el tercero de confianza. La necesidad de anunciar públicamente todas las transacciones excluye este método, pero aún así se puede mantener la privacidad rompiendo el flujo de información en otro punto: manteniendo las claves públicas anónimas. El público puede ver que alguien está enviando una cantidad a otro alguien, pero sin que haya información vinculando la transacción con nadie. Esto es similar al nivel de información que comunican las bolsas de valores, donde el tiempo y tamaño de las operaciones individuales, la “cinta”, son hechos públicos, pero sin decir quiénes fueron las partes.

Whitepaper de Bitcoin

Como cortafuegos adicional, debería usarse un nuevo par de claves en cada transacción para evitar que se relacionen con un propietario común. Con las transacciones multientrada será inevitable algún tipo de vinculación, pues revelan necesariamente que sus entradas pertenecieron al mismo propietario. El riesgo es que si se revela la identidad del propietario de una clave, la vinculación podría revelar otras transacciones que pertenecieron al mismo propietario.

11. Cálculos

Consideramos el escenario de un atacante intentando generar una cadena alternativa más rápido que la cadena honesta. Incluso si se consigue, el sistema no queda abierto a cambios arbitrarios como crear valor de la nada o tomar dinero que nunca perteneció al atacante. Los nodos no van a aceptar una transacción inválida como pago y los nodos honestos nunca aceptarán un bloque que las contenga. Un atacante solo puede tratar de cambiar una de sus propias transacciones para recuperar dinero que ha gastado recientemente.

La carrera entre la cadena honesta y la cadena de un atacante puede verse como un paseo aleatorio binomial. El suceso que prospera es la cadena honesta creciendo un bloque, aumentando su liderato por +1, y el suceso que fracasa es la cadena del atacante creciendo un bloque, reduciendo la brecha en -1.

La probabilidad de que un ataque alcance [la cadena honesta] desde un déficit dado es análoga al problema de la ruina del jugador. Supongamos que un jugador con crédito ilimitado comienza con un déficit y juega en potencia un número infinito de intentos para alcanzar un punto de equilibrio. Podemos calcular la probabilidad de que alcance ese punto, o de que un ataque alcance alguna vez a la cadena honesta, como sigue [8]:

p = probabilidad de que un nodo honesto encuentre el siguiente bloque
q = probabilidad de que el atacante encuentre el siguiente bloque
qz = probabilidad de que el atacante alcance [la cadena honesta] desde z bloques atrás

Calculos

Asumiendo que p > q, la probabilidad cae de forma exponencial a medida que aumenta el número de bloques que el atacante tiene que alcanzar. Con las probabilidades en su contra, si no tiene un golpe de suerte que lo haga avanzar desde el principio, sus oportunidades se irán desvaneciendo a medida que se va quedando atrás.

Consideremos ahora cuánto tiempo necesita esperar el receptor de una transacción para tener la suficiente seguridad de que el emisor no puede cambiarla. Asumimos que el emisor es un atacante que quiere que el receptor crea durante un tiempo que le ha pagado; entonces cambiará el pago para devolvérselo a sí mismo un tiempo después. El receptor recibirá un aviso cuando esto suceda, pero el emisor espera que ya sea demasiado tarde.

El receptor genera un nuevo par de claves y da la clave pública al emisor poco antes de firmar. Esto impide que el emisor pueda preparar una cadena de bloques previa trabajando de continuo en ella hasta tener la suerte suficiente como para ponerse a la cabeza y, entonces, ejecutar la transacción. Una vez que la transacción se ha emitido, el emisor deshonesto comienza a trabajar en secreto en una cadena paralela que contiene una versión alternativa de su transacción.

El receptor espera hasta que la transacción se ha añadido al bloque y z bloques se han enlazado tras él. No sabe la cantidad de progreso que ha realizado el atacante, pero asumiendo que los bloques honestos han tomado la media de tiempo esperada por bloque, el potencial de progreso del atacante será una distribución de Poisson9 con un valor esperado:

Calculos

Para obtener la probabilidad de que el atacante pueda ponerse al día incluso ahora, multiplicamos la densidad de Poisson para cada aumento en el progreso que podría haber realizado, por la probabilidad que podría haber alcanzado desde ese punto:

Calculos

Reordenándola para evitar sumar la cola infinita de la distribución…

Calculos

Convertida a lenguaje de programación C…

Codigo

Ejecutando algunos resultados, podemos ver que la probabilidad disminuye exponencialmente con z.

Codigo

Resolviendo para P menor que 0.1%…

Codigo

12. Conclusión

Hemos propuesto un sistema para realizar transacciones electrónicas sin depender de confianza. Comenzamos con el marco habitual de monedas creadas a partir de firmas digitales, lo cual permite un firme control de la propiedad, pero que está incompleto sin una forma de prevenir el doble gasto. Para resolver esto, hemos propuesto una red peer-to-peer usando proof-of-work para realizar un registro público de las transacciones que rápidamente se hace computacionalmente inviable de cambiar para un atacante si la mayoría de la potencia CPU está controlada por nodos honestos. La red es robusta dada su simplicidad no estructurada. Los nodos trabajan todos a la vez, precisando poca coordinación. No necesitan ser identificados dado que los mensajes no se envían a ningún lugar en particular, y solo necesitan ser emitidos en base a “mejor esfuerzo”. Los nodos pueden abandonar y reincorporarse a la red a voluntad, aceptando la cadena proof-of-work como prueba de lo que ha sucedido mientras estaban ausentes. Votan con su potencia CPU, expresando su aceptación de los bloques válidos trabajando en extenderlos y descartando los bloques no válidos al rechazar trabajar en ellos. Cualesquiera reglas e incentivos necesarios pueden ser aplicados con este mecanismo de consenso.

Referencias

[1] W. Dai, “b-money”, http://www.weidai.com/bmoney.txt, 1998.

[2] H. Massias, X. S. Avila, and J.-J. Quisquater, “Design of a secure timestamping service with minimal
trust requirements”, en el 20th Symposium on Information Theory in the Benelux, mayo de 1999.

[3] S. Haber, W. S. Stornetta, “How to time-stamp a digital document”, en Journal of Cryptology, vol. 3,
n.° 2, pp. 99-111, 1991.

[4] D. Bayer, S. Haber, W. S. Stornetta, “Improving the efficiency and reliability of digital timestamping”, en Sequences II: Methods in Communication, Security and Computer Science, pp. 329-
334, 1993.

[5] S. Haber, W. S. Stornetta, “Secure names for bit-strings”, en Proceedings of the 4th ACM Conference
on Computer and Communications Security, pp. 28-35, abril de 1997.

[6] A. Back, “Hashcash – a denial of service counter-measure”,
http://www.hashcash.org/papers/hashcash.pdf, 2002.

[7] R. C. Merkle, “Protocols for public key cryptosystems”, en Proc. 1980 Symposium on Security and
Privacy, IEEE Computer Society, pp. 122-133, abril de 1980.

[8] W. Feller, “An introduction to probability theory and its applications”, 1957.

N. del T. Para esta traducción se ha respetado la estética del documento original y sus esquemas, así como la tipografía empleada por Satoshi Nakamoto; se ha tratado también de conservar el estilo lingüístico. Algunas expresiones se han mantenido en la lengua original por ser de uso común en lengua española, y se han señalado en cursiva. Las notas en superíndice a enlaces externos no pertenecen al documento original y se han añadido para facilitar su comprensión. La traducción ha sido realizada en Apache OpenOffice, donde se supone que fue escrito el texto original.

@breathingdog

  1. https://es.wikipedia.org/wiki/Peer-to-peer
  2. https://es.wikipedia.org/wiki/Prueba_de_trabajo
  3. https://es.wikipedia.org/wiki/Funci%C3%B3n_hash
  4. https://es.wikipedia.org/wiki/Entrega_de_mejor_esfuerzo
  5. https://en.wikipedia.org/wiki/Cryptographic_nonce (en inglés)
  6. https://es.wikipedia.org/wiki/Dise%C3%B1o_estructurado#Fan-In_y_Fan-Out
  7. https://es.wikipedia.org/wiki/Camino_aleatorio
  8. https://en.wikipedia.org/wiki/Gambler%27s_ruin (en inglés)
  9. https://es.wikipedia.org/wiki/Distribuci%C3%B3n_de_Poisson

Leave a Reply

Your email address will not be published. Required fields are marked *

Comparte este Articulo!!!

Si encuentras valor en el articulo, compartelo con tus amigos.

Scroll to Top