Contenidos mostrar
Bitcoin: un sistema de efectivo electrónico de igual a igual
Satoshi Nakamoto
satoshin@gmx.com
Resumen. Una versión puramente de igual a igual del efectivo electrónico permitiría en línea
pagos que se enviarán directamente de una parte a otra sin pasar por un
institución financiera. Las firmas digitales proporcionan parte de la solución, pero las principales
los beneficios se pierden si aún se requiere un tercero de confianza para evitar el doble gasto.
Proponemos una solución al problema de doble gasto utilizando una red de igual a igual.
La red marca las transacciones al agruparlas en una cadena continua de
prueba de trabajo basada en hash, formando un registro que no se puede cambiar sin rehacer
La prueba de trabajo. La cadena más larga no solo sirve como prueba de la secuencia de
eventos presenciados, pero prueba de que provino del grupo más grande de potencia de CPU. Como
siempre que la mayoría de la potencia de la CPU esté controlada por nodos que no cooperan para
atacan la red, generarán la cadena más larga y atacarán a los atacantes. los
La propia red requiere una estructura mínima. Los mensajes se transmiten en un mejor esfuerzo
base, y los nodos pueden salir y volver a unirse a la red a voluntad, aceptando el más largo
cadena de prueba de trabajo como prueba de lo que sucedió mientras estaban fuera.
1. Introducción a Bitcoin
El comercio en Internet ha llegado a depender casi exclusivamente de instituciones financieras que actúan como
terceros de confianza para procesar pagos electrónicos. Si bien el sistema funciona lo suficientemente bien como para
En la mayoría de las transacciones, todavía sufre las debilidades inherentes del modelo basado en la confianza.
Las transacciones completamente no reversibles no son realmente posibles, ya que las instituciones financieras no pueden
evitar mediaciones en disputas. El costo de la mediación aumenta los costos de transacción, limitando la
tamaño mínimo de transacción práctica y cortar la posibilidad de pequeñas transacciones casuales,
y hay un costo más amplio en la pérdida de la capacidad de hacer pagos no reversibles para
Servicios reversibles. Con la posibilidad de reversión, se extiende la necesidad de confianza. Los comerciantes deben
tenga cuidado con sus clientes, solicitándoles más información de la que de otra manera necesitarían.
Un cierto porcentaje de fraude se acepta como inevitable. Estos costos e incertidumbres de pago
puede evitarse en persona utilizando moneda física, pero no existe ningún mecanismo para realizar pagos
a través de un canal de comunicaciones sin una parte confiable.
Lo que se necesita es un sistema de pago electrónico basado en pruebas criptográficas en lugar de confianza,
Permitir a cualquiera de las dos partes dispuestas a realizar transacciones directamente entre sí sin la necesidad de un confiable
tercero. Las transacciones que son computacionalmente poco prácticas para revertir protegerían a los vendedores
del fraude, y mecanismos de custodia de rutina podrían implementarse fácilmente para proteger a los compradores. En
En este documento, proponemos una solución al problema de doble gasto utilizando un sistema distribuido de igual a igual
servidor de marca de tiempo para generar pruebas computacionales del orden cronológico de las transacciones. los
el sistema es seguro siempre que los nodos honestos controlen colectivamente más potencia de CPU que cualquier otro
grupo cooperante de nodos atacantes.
2. Transacciones de bitcoin
Definimos una moneda electrónica como una cadena de firmas digitales. Cada propietario transfiere la moneda al
luego, firmando digitalmente un hash de la transacción anterior y la clave pública del próximo propietario
y agregando estos al final de la moneda. Un beneficiario puede verificar las firmas para verificar la cadena de
propiedad.
El problema, por supuesto, es que el beneficiario no puede verificar que uno de los propietarios no haya gastado el doble
la moneda. Una solución común es introducir una autoridad central confiable, o mint, que verifique cada
transacción por doble gasto. Después de cada transacción, la moneda debe devolverse a la casa de moneda para
emitir una nueva moneda, y solo las monedas emitidas directamente desde la casa de moneda se confía en que no se gasten dos veces.
El problema con esta solución es que el destino de todo el sistema monetario depende de
compañía que maneja la casa de la moneda, con cada transacción que tiene que pasar por ellos, como un banco.
Necesitamos una manera para que el beneficiario sepa que los propietarios anteriores no firmaron antes
actas. Para nuestros propósitos, la transacción más temprana es la que cuenta, por lo que no nos importa
sobre intentos posteriores de doble gasto. La única forma de confirmar la ausencia de una transacción es
Esté al tanto de todas las transacciones. En el modelo basado en mint, la mint estaba al tanto de todas las transacciones y
Decidió cuál llegó primero. Para lograr esto sin una parte confiable, las transacciones deben ser
anunciado públicamente [1], y necesitamos un sistema para que los participantes acuerden un solo historial de la
orden en que fueron recibidos. El beneficiario necesita una prueba de que en el momento de cada transacción, el
La mayoría de los nodos estuvieron de acuerdo en que fue el primero recibido.
3. Servidor de marca de tiempo de Bitcoin
La solución que proponemos comienza con un servidor de marca de tiempo. Un servidor de marca de tiempo funciona tomando un
hash de un bloque de elementos que se debe marcar con la hora y publicar ampliamente el hash, como en un
periódico o post de Usenet [2-5]. La marca de tiempo demuestra que los datos deben haber existido en el
tiempo, obviamente, para entrar en el hash. Cada marca de tiempo incluye la marca de tiempo anterior en
su hash, formando una cadena, con cada marca de tiempo adicional que refuerza las anteriores.
2
Bloquear
ít
ít
…
Picadillo
Bloquear
ít
ít
…
Picadillo
Transacción
Propietario 1
Llave pública
Propietario 0’s
Firma
Picadillo
Transacción
Propietario 2
Llave pública
Propietario 1
Firma
Picadillo
Verificar
Transacción
Propietario 3
Llave pública
Propietario 2
Firma
Picadillo
Verificar
Propietario 2
Llave privada
Propietario 1
Llave privada
Firmar
Firmar
Propietario 3
Llave privada
4. Prueba de trabajo de Bitcoin ( Proff of Work)
Para implementar un servidor de marca de tiempo distribuido de igual a igual, necesitaremos usar una prueba
sistema de trabajo similar al Hashcash de Adam Back [6], en lugar de publicaciones en periódicos o Usenet.
La prueba de trabajo implica la exploración de un valor que, cuando se utiliza hash, como con SHA-256, el
hash comienza con una cantidad de cero bits. El trabajo promedio requerido es exponencial en el número
de cero bits requeridos y pueden verificarse ejecutando un solo hash.
Para nuestra red de marca de tiempo, implementamos la prueba de trabajo incrementando un nonce en el
bloquee hasta que se encuentre un valor que le dé al hash del bloque los bits cero requeridos. Una vez que la CPU
Se ha realizado un esfuerzo para satisfacer la prueba de trabajo, el bloque no se puede cambiar
sin rehacer el trabajo. A medida que los bloques posteriores se encadenan después, el trabajo para cambiar el bloque
incluiría rehacer todos los bloques después de esto.
La prueba de trabajo también resuelve el problema de determinar la representación en la decisión mayoritaria.
fabricación. Si la mayoría se basara en una dirección IP, un voto, cualquiera podría subvertirla
capaz de asignar muchas IP. La prueba de trabajo es esencialmente una CPU-un-voto. La mayoría
la decisión está representada por la cadena más larga, que tiene el mayor esfuerzo de prueba de trabajo invertido
en eso. Si la mayoría de la potencia de la CPU está controlada por nodos honestos, la cadena honesta crecerá
más rápido y supera a cualquier cadena de la competencia. Para modificar un bloque pasado, un atacante tendría que
rehaga la prueba de trabajo del bloque y todos los bloques que se encuentran a continuación y luego se ponga al día y supere
trabajo de los nodos honestos. Más adelante mostraremos que la probabilidad de que un atacante más lento se ponga al día
disminuye exponencialmente a medida que se agregan bloques posteriores.
Para compensar el aumento de la velocidad del hardware y el interés variable en ejecutar nodos a lo largo del tiempo,
la dificultad de la prueba de trabajo está determinada por un promedio móvil dirigido a un número promedio de
bloques por hora. Si se generan demasiado rápido, la dificultad aumenta.
5. Red de Bitcoin
Los pasos para ejecutar la red son los siguientes:
1) Las nuevas transacciones se transmiten a todos los nodos.
2) Cada nodo recopila nuevas transacciones en un bloque.
3) Cada nodo trabaja para encontrar una prueba de trabajo difícil para su bloque.
4) Cuando un nodo encuentra una prueba de trabajo, transmite el bloque a todos los nodos.
5) Los nodos aceptan el bloque solo si todas las transacciones en él son válidas y no se han gastado.
6) Los nodos expresan su aceptación del bloque trabajando en la creación del siguiente bloque en el
cadena, utilizando el hash del bloque aceptado como el hash anterior.
Los nodos siempre consideran que la cadena más larga es la correcta y seguirá trabajando en
extendiéndolo Si dos nodos transmiten versiones diferentes del siguiente bloque simultáneamente, algunos
los nodos pueden recibir uno u otro primero. En ese caso, trabajan en el primero que recibieron,
pero guarde la otra rama en caso de que se alargue. El empate se romperá cuando la próxima prueba
se encuentra el trabajo y una rama se alarga; los nodos que estaban trabajando en el otro
la rama cambiará a la más larga.
3
Bloquear
Hash Previo
Mientras tanto
Tx
Tx
…
Bloquear
Hash Previo
Mientras tanto
Tx
Tx
…
Las nuevas transmisiones de transacciones no necesariamente tienen que llegar a todos los nodos. Mientras alcancen
muchos nodos, entrarán en un bloque en poco tiempo. Las transmisiones en bloque también toleran la caída.
mensajes Si un nodo no recibe un bloque, lo solicitará cuando reciba el siguiente bloque y
se da cuenta de que se perdió uno.
6. Incentivo en bitcoin
Por convención, la primera transacción en un bloque es una transacción especial que inicia una nueva moneda
por el creador del bloque. Esto agrega un incentivo para que los nodos admitan la red y proporciona
una forma de distribuir inicialmente las monedas en circulación, ya que no existe una autoridad central para emitirlas.
La adición constante de una cantidad constante de nuevas monedas es análoga al gasto de los mineros de oro.
recursos para agregar oro a la circulación. En nuestro caso, es el tiempo de CPU y la electricidad lo que se gasta.
El incentivo también se puede financiar con tarifas de transacción. Si el valor de salida de una transacción es
menor que su valor de entrada, la diferencia es una tarifa de transacción que se agrega al valor de incentivo de
El bloque que contiene la transacción. Una vez que ha ingresado un número predeterminado de monedas
circulación, el incentivo puede pasar completamente a tarifas de transacción y ser completamente inflación
gratis.
El incentivo puede ayudar a alentar a los nodos a ser honestos. Si un atacante codicioso es capaz de
reunir más potencia de CPU que todos los nodos honestos, tendría que elegir entre usarlo
defraudar a la gente robando sus pagos o usándolos para generar nuevas monedas. El debe
les resulta más rentable seguir las reglas, reglas que lo favorecen con más monedas nuevas que
todos los demás combinados, que socavan el sistema y la validez de su propia riqueza.
7. Recuperando espacio en disco de bitcoin
Una vez que la última transacción en una moneda está enterrada bajo suficientes bloques, las transacciones gastadas antes
Se puede descartar para ahorrar espacio en disco. Para facilitar esto sin romper el hash del bloque,
las transacciones se procesan en un Merkle Tree [7] [2] [5], con solo la raíz incluida en el hash del bloque.
Los bloques viejos se pueden compactar cortando ramas del árbol. Los hashes interiores hacen
No necesita ser almacenado.
Un encabezado de bloque sin transacciones tendría aproximadamente 80 bytes. Si suponemos que los bloques son
generado cada 10 minutos, 80 bytes * 6 * 24 * 365 = 4.2MB por año. Con sistemas informáticos
típicamente vendiendo con 2GB de RAM a partir de 2008, y la Ley de Moore que predice el crecimiento actual de
1,2 GB por año, el almacenamiento no debería ser un problema, incluso si los encabezados de bloque deben mantenerse en
memoria.
4 4
Bloquear
Bloquear
Encabezado de bloque (Hash de bloque)
Hash Previo
Mientras tanto
Hash01
Hash0
Hash1
Hash2
Hash3
Hash23
Root Hash
Hash01
Hash2
Tx3
Hash23
Encabezado de bloque (Hash de bloque)
Root Hash
Transacciones Hashed en un Merkle Tree
Después de podar Tx0-2 del bloque
Hash Previo
Mientras tanto
Hash3
Tx0
Tx1
Tx2
Tx3
8. Verificación de pago simplificada de bitcoin
Es posible verificar pagos sin ejecutar un nodo de red completo. Un usuario solo necesita mantener
una copia de los encabezados de bloque de la cadena de prueba de trabajo más larga, que puede obtener consultando
nodos de red hasta que esté convencido de que tiene la cadena más larga y obtenga la rama Merkle
vincular la transacción al bloque en el que está estampado. No puede verificar la transacción para
él mismo, pero al vincularlo a un lugar en la cadena, puede ver que un nodo de red lo ha aceptado,
y bloques agregados después de que confirme que la red lo ha aceptado.
Como tal, 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. Mientras que los nodos de la red pueden verificar
transacciones por sí mismos, el método simplificado puede ser engañado por un atacante fabricado
transacciones durante el tiempo que el atacante pueda continuar dominando la red. Una estrategia para
protegerse contra esto sería aceptar alertas de nodos de red cuando detectan un error
bloquear, solicitando al software del usuario que descargue el bloque completo y las transacciones alertadas a
confirmar la inconsistencia Las empresas que reciben pagos frecuentes probablemente aún quieran
ejecutar sus propios nodos para una seguridad más independiente y una verificación más rápida.
9. Combinando y dividiendo valor
Aunque sería posible manejar monedas individualmente, sería difícil de manejar
transacción separada por cada centavo en una transferencia. Para permitir que el valor se divida y combine,
Las transacciones contienen múltiples entradas y salidas. Normalmente habrá una sola entrada
de una transacción anterior más grande o múltiples entradas que combinan cantidades más pequeñas, y como máximo dos
salidas: una para el pago y otra para devolver el cambio, si corresponde, al remitente.
Cabe señalar que se despliegan, donde una transacción depende de varias transacciones, y esas
Las transacciones dependen de muchos más, no es un problema aquí. Nunca es necesario extraer un
copia completa e independiente del historial de una transacción.
5 5
Transacción
En
…
En
Fuera
…
Hash01
Hash2
Hash3
Hash23
Encabezado de bloque
Raíz Merkle
Hash Previo
Mientras tanto
Encabezado de bloque
Raíz Merkle
Hash Previo
Mientras tanto
Encabezado de bloque
Raíz Merkle
Hash Previo
Mientras tanto
Rama Merkle para Tx3
Cadena de prueba de trabajo más larga
Tx3
10. Privacidad de Bitcoin
El modelo bancario tradicional alcanza un nivel de privacidad al limitar el acceso a la información a
partes involucradas y el tercero de confianza. La necesidad de anunciar todas las transacciones públicamente
excluye este método, pero aún se puede mantener la privacidad rompiendo el flujo de información en
otro lugar: manteniendo las claves públicas anónimas. El público puede ver que alguien está enviando
una cantidad para otra persona, pero sin información que vincule la transacción con nadie. Esto es
similar al nivel de información publicado por las bolsas de valores, donde el tiempo y el tamaño de
los oficios individuales, la «cinta», se hacen públicos, pero sin decir quiénes fueron las partes.
Como firewall adicional, se debe utilizar un nuevo par de claves para cada transacción para mantenerlos
de estar vinculado a un propietario común. Algunos enlaces aún son inevitables con entradas múltiples
transacciones, que necesariamente revelan que sus entradas fueron propiedad del mismo propietario. El riesgo
es que si se revela el propietario de una clave, la vinculación podría revelar otras transacciones que pertenecían a
El mismo dueño.
11. Cálculos de Bitcoin
Consideramos el escenario de un atacante que intenta generar una cadena alternativa más rápido que el honesto
cadena. Incluso si esto se logra, no abre el sistema a cambios arbitrarios, como
como crear valor de la nada o tomar dinero que nunca perteneció al atacante. Los nodos son
no aceptará una transacción no válida como pago, y los nodos honestos nunca aceptarán un bloqueo
que los contiene Un atacante solo puede intentar cambiar una de sus propias transacciones para recuperar
dinero que gastó recientemente.
La carrera entre la cadena honesta y una cadena de atacantes puede caracterizarse como un binomio
Caminata aleatoria. El evento de éxito es la cadena honesta que se extiende por un bloque, aumentando su
liderado por +1, y el evento de falla es que la cadena del atacante se extiende en un bloque, reduciendo el
brecha por -1.
La probabilidad de que un atacante se recupere de un déficit dado es análoga a la de un jugador
Problema de ruina. Supongamos que un jugador con crédito ilimitado comienza con un déficit y juega potencialmente un
Número infinito de intentos para intentar alcanzar el equilibrio. Podemos calcular la probabilidad de que alguna vez
llega a punto de equilibrio, o que un atacante se pone al día con la cadena honesta, de la siguiente manera [8]:
p = probabilidad de que un nodo honesto encuentre el siguiente bloque
q = probabilidad de que el atacante encuentre el siguiente bloque
q z = probabilidad de que el atacante se recupere de z bloques detrás
q z = { 1
si p ≤ q
q / p
z
si p q }
6 6
Identidades
Actas
Trusted
Tercero
Contraparte
Público
Identidades
Actas
Público
Nuevo modelo de privacidad
Modelo de privacidad tradicional
Dado nuestro supuesto de que p> q , la probabilidad cae exponencialmente a medida que el número de bloques
el atacante tiene que ponerse al día con los aumentos. Con las probabilidades en su contra, si no tiene suerte
se lanza hacia adelante desde el principio, sus posibilidades se vuelven muy pequeñas a medida que se queda atrás.
Ahora consideramos cuánto tiempo debe esperar el destinatario de una nueva transacción antes de ser
suficientemente seguro de que el remitente no puede cambiar la transacción. Asumimos que el remitente es un atacante
quien quiere hacer que el destinatario crea que le pagó por un tiempo, luego cambiarlo para pagar
él mismo después de un tiempo ha pasado. El receptor recibirá una alerta cuando eso suceda, pero el
El remitente espera que sea demasiado tarde.
El receptor genera un nuevo par de claves y le entrega la clave pública al remitente poco antes
firma. Esto evita que el remitente prepare una cadena de bloques antes de tiempo trabajando en
continuamente hasta que tenga la suerte de adelantarse lo suficiente, luego ejecute la transacción en
ese momento. Una vez que se envía la transacción, el remitente deshonesto comienza a trabajar en secreto en un
cadena paralela que contiene una versión alternativa de su transacción.
El destinatario espera hasta que la transacción se haya agregado a un bloque y se hayan bloqueado z
vinculado después de eso. No sabe la cantidad exacta de progreso que ha realizado el atacante, pero
asumiendo que los bloques honestos tomaron el tiempo promedio esperado por bloque, el potencial del atacante
El progreso será una distribución de Poisson con el valor esperado:
= z
q
pag
Para obtener la probabilidad de que el atacante aún pueda ponerse al día ahora, multiplicamos la densidad de Poisson para
cada cantidad de progreso que pudo haber hecho por la probabilidad de que pudiera ponerse al día desde ese punto:
∑
k = 0
∞
k e −
k !
⋅ { q / p z – k
si k ≤ z
1
si k z }
Reorganizando para evitar sumar la cola infinita de la distribución …
1− ∑
k = 0
z
k e −
k !
1 − q / p z – k
Conversión a código C …
#include <math.h>
double AttackerSuccessProbability (double q, int z)
{
doble p = 1.0 – q;
doble lambda = z * (q / p);
suma doble = 1.0;
int i, k;
para (k = 0; k <= z; k ++)
{
doble poisson = exp (-lambda);
para (i = 1; i <= k; i ++)
poisson * = lambda / i;
suma – = poisson * (1 – pow (q / p, z – k));
}
suma de retorno;
}
7 7
Al ejecutar algunos resultados, podemos ver que la probabilidad disminuye exponencialmente 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
Resolver para P menos del 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
12. Conclusión
Hemos propuesto un sistema para transacciones electrónicas sin depender de la confianza. Empezamos con
El marco habitual de monedas hechas de firmas digitales, que proporciona un fuerte control de
propiedad, pero está incompleta sin una forma de evitar el doble gasto. Para resolver esto, nosotros
propuso una red de igual a igual utilizando prueba de trabajo para registrar un historial público de transacciones
que rápidamente se vuelve computacionalmente poco práctico para que un atacante cambie si nodos honestos
controlar la mayoría de la potencia de la CPU. La red es robusta en su simplicidad no estructurada. Nodos
trabaje todo a la vez con poca coordinación. No es necesario identificarlos, ya que los mensajes son
no se enruta a ningún lugar en particular y solo debe entregarse con el mejor esfuerzo. Los nodos pueden
abandonar y unirse a la red a voluntad, aceptando la cadena de prueba de trabajo como prueba de lo que
sucedió mientras se fueron. Votan con la potencia de su CPU, expresando su aceptación de
bloques válidos trabajando en extenderlos y rechazando bloques inválidos negándose a trabajar en
ellos. Las reglas e incentivos necesarios se pueden hacer cumplir con este mecanismo de consenso.
8
Referencias
[1] W. Dai, «b-money», http://www.weidai.com/bmoney.txt, 1998.
[2] H. Massias, XS Ávila y J.-J. Quisquater, «Diseño de un servicio seguro de marca de tiempo con un mínimo
requisitos de confianza «, en el XX Simposio sobre teoría de la información en el Benelux , mayo de 1999.
[3] S. Haber, WS Stornetta, «Cómo sellar el tiempo de un documento digital», en Journal of Cryptology , vol 3, no
2, páginas 99-111, 1991.
[4] D. Bayer, S. Haber, WS Stornetta, «Mejora de la eficiencia y la fiabilidad del sellado de tiempo digital»
En Secuencias II: Métodos en comunicación, seguridad y ciencias de la computación , páginas 329-334, 1993.
[5] S. Haber, WS Stornetta, «Nombres seguros para cadenas de bits», en Actas de la 4ª Conferencia ACM
on Computer and Communications Security , páginas 28-35, abril de 1997.
[6] A. Volver, «Hashcash – una contramedida de denegación de servicio»
http://www.hashcash.org/papers/hashcash.pdf, 2002.
[7] RC Merkle, «Protocolos para criptosistemas de clave pública», en Proc. Simposio de 1980 sobre seguridad y
Privacidad , IEEE Computer Society, páginas 122-133, abril de 1980.
[8] W. Feller, «Una introducción a la teoría de la probabilidad y sus aplicaciones», 1957
Paper en Ingles Original