Criptomonedas
Análisis Técnicos e Información De Mercados y Economías de Capitales Digitales Emergentes
El Libro Blanco de Bitcoin; By Satoshi Nacamoto
Combinación y partición del valor
A pesar de que sería posible manejar las monedas de forma individual, resultaría poco práctico realizar una transacción independiente por cada céntimo que se quiera transferir. Para que sea posible dividir y combinar valores, las transacciones contienen diversas entradas y salidas. Por lo general, habrá una sola entrada que proviene de una transacción anterior de mayor tamaño, o bien, múltiples entradas que combinan cantidades más pequeñas. En cuanto a las salidas, habrá como máximo dos: una para el pago y otra para la devolución del cambio al remitente en caso de que sea necesario.
Cabe señalar que, cuando una transacción depende de múltiples transacciones y esas transacciones dependen a su vez de muchas otras, la difusión de estos datos no supone ningún problema. No existe la necesidad de extraer una copia independiente completa que refleje el historial de una transacción.
Privacidad
El modelo bancario tradicional consigue cierto nivel de privacidad al limitar el acceso a la información, que sólo está disponible para las partes involucradas y para el tercero de confianza. La necesidad de hacer públicas todas las transacciones va en contra de este método. No obstante, se puede conservar este nivel de privacidad si se detiene el flujo de la información en otro punto: al conservar la función anónima de las claves públicas. El público puede comprobar que alguien está mandando dinero a otra persona, pero no dispondrá de información que vincule la transacción a una persona determinada. Este sistema es similar al que se emplea en las bolsas de valores, donde la hora, la fecha y el importe de cada operación se hacen públicos, pero no se indica quiénes son las partes involucradas.
Con el fin de establecer un sistema de seguridad adicional, cada transacción debe ir asociada a un par de claves nuevo. De esta forma, se evita que alguien pueda vincular distintas transacciones a un mismo propietario. Resulta inevitable asumir cierto grado de vinculación cuando se trata de transacciones que contienen varias entradas, ya que en estos casos es posible constatar que todas las entradas pertenecían al mismo dueño. El riesgo está en que, si se descubre quién es el propietario de una clave, los vínculos podrían mostrar otras transacciones pertenecientes a la misma persona.
Cálculos
Se considera la posibilidad de que un transgresor intente generar una cadena alternativa más rápida que la cadena honrada. Aunque esto se consiga, el sistema no se ve sometido a cambios arbitrarios, tales como la creación de valor a partir de la nada o la adjudicación de fondos que no pertenecen al transgresor. Los nodos no aceptan transacciones inválidas a modo de pago, así que los nodos honrados rechazarán todo bloque que las contenga. Lo único que podría intentar el transgresor es cambiar una de sus propias transacciones para recuperar los fondos de una transferencia reciente.
La carrera entre la cadena honrada y la cadena transgresora se podría describir como un camino aleatorio17 binomial. El caso de éxito ocurre cuando la cadena honrada consigue extenderse con un bloque de ventaja y sube una posición (+1), mientras que el caso fallido tendría lugar si el transgresor adquiere la ventaja de un bloque y acorta la distancia, restando así una posición (-1).
La probabilidad de que un transgresor en desventaja consiga ponerse al día es análoga al problema de la ruina del jugador18. Supongamos que un jugador con crédito ilimitado comienza a apostar con un déficit y tiene un sinfín de intentos para alcanzar el punto de equilibrio en el que ni gana ni pierde. De la siguiente manera se puede calcular la probabilidad de que el jugador llegue a este punto, o de que un transgresor alcance a la cadena honrada [8]:
p = probabilidad de que un nodo honrado encuentre el siguiente bloque.
q = probabilidad de que un transgresor encuentre el siguiente bloque.
qz = probabilidad de que el transgresor alcance a la cadena partiendo de una desventaja de z bloques.
Dada la hipótesis de que p > q, la probabilidad cae de forma exponencial a medida que aumenta el número de bloques que el transgresor tiene por delante. Con las probabilidades en su contra, el transgresor va perdiendo opciones conforme se va quedando atrás, a menos que consiga hacer una embestida afortunada que lo posicione por delante desde un principio.
Por otro lado, se considera el tiempo que debe esperar el receptor de una nueva transacción hasta estar lo bastante seguro de que el remitente no puede modificar la operación. Asumimos que el remitente es un transgresor que quiere convencer al receptor de que ha pagado, pero luego pretende cambiar la operación para recuperar los fondos. El remitente tendrá la esperanza de que, para cuando el receptor se dé cuenta de lo ocurrido, sea ya demasiado tarde.
Ante esta situación, el beneficiario genera un nuevo par de claves y proporciona la clave pública al pagador poco antes de que se firme la operación. Esto evita que el pagador pueda preparar con antelación una cadena de bloques y trabajar en ésta de forma continua hasta tener la suerte de adquirir suficiente ventaja con respecto a la cadena principal, para así ejecutar la transacción en ese momento. Una vez que se envía la transferencia, el pagador deshonesto comienza a trabajar en secreto sobre una cadena paralela que contiene una versión alternativa de su transacción.
El receptor espera hasta que la transacción se introduzca en un bloque, que tiene enlazado un número de z bloques posteriores. Desconoce el progreso exacto que el agresor ha conseguido; pero, si suponemos que los bloques auténticos se han construido en un espacio de tiempo esperado, el progreso potencial del transgresor será una distribución de Poisson19 con valor esperado:
Para calcular la probabilidad de que el transgresor alcance su objetivo, multiplicamos la densidad de la distribución de Poisson de cada cantidad de progreso posible por la probabilidad de que el agresor alcance a la cadena a partir de ese punto:
Reorganización para evitar la suma infinita de la distribución:
Convertido a código C:
#include
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
En vista de algunos resultados, se observa que la probabilidad disminuye de forma exponencial con z:
q=0.1
z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137
z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012
q=0.3
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006
Cálculo de P cuando es menor que 0.1%:
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340
Conclusión
El presente documento propone un sistema de transacciones electrónicas que no depende de la confianza. Comenzamos con la descripción de la infraestructura habitual en la que funcionan las monedas compuestas por firmas digitales. Este sistema brinda un fuerte control sobre la propiedad, pero queda incompleto si no existe un método para evitar el gasto doble. Para resolver esta cuestión, hemos propuesto una red P2P que emplea un sistema de comprobantes de trabajo mediante el que se registran las transacciones en un historial público. De esta forma, en poco tiempo resulta inviable a nivel computacional modificar las transacciones, siempre que los nodos honrados controlen la mayor parte de los recursos de la CPU. La red es robusta dentro de una simplicidad no estructurada. Los nodos funcionan de forma simultánea sin requerir gran coordinación. No necesitan identificarse, ya que los mensajes no se dirigen a un lugar concreto, sino que se difunden mediante el esfuerzo colectivo. Los nodos pueden entrar y salir de la red cuando lo deseen, rigiéndose siempre por la cadena de comprobantes de trabajo que refleja lo que ha ocurrido mientras no estaban. Se vota con la potencia de la CPU. De esta forma, se puede expresar la aprobación de los bloques válidos en el momento en que se continúa trabajando para extender la cadena o, por el contrario, se pueden rechazar los bloques inválidos cuando se decide no trabajar sobre ellos. Toda regla o incentivo que se requiera puede acordarse a través de este sistema de consenso.
.....................................................................................................................................................................................................................................
Fuentes
[1] W. Dai, “b-money”, http://www.weidai.com/bmoney.txt, 1998.
[2] H. Massias, X.S. Avila, y J.-J. Quisquater, “Design of a secure timestamping service with minimal trust requirements”, en 20th Symposium on Information Theory in the Benelux, mayo1999.
[3] S. Haber, W.S. Stornetta, “How to time-stamp a digital document”, en Journal of Cryptology, vol. 3, no. 2, págs. 99-111, 1991.
[4] D. Bayer, S. Haber, W.S. Stornetta, “Improving the efficiency and reliability of digital time-stamping”, en Sequences II: Methods in Communication, Security and Computer Science, págs. 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, págs. 28-35, abril 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, págs. 122-133, abril 1980.
[8] W. Feller, “An introduction to probability theory and its applications”, 1957.
Documento original para descargar en inglés: