Bitcoin: Un Sistema de Efectivo Electrnico Usuario-a-Usuario

Satoshi Nakamoto
satoshin@gmx.com
www.bitcoin.org
Traducido al Espaol de bitcoin.org/bitcoin.pdf
por Angel e!n " www.diariobitcoin.com
Abstracto. #na $ersi!n puramente electr!nica de efecti$o permitir%a &ue los pagos
en l%nea fuesen en$iados directamente de un ente a otro sin tener &ue pasar por
medio de una instituci!n financiera. 'irmas digitales pro$een parte de la soluci!n(
pero los beneficios principales se pierden si existe un tercero confiable para pre$enir
el doble"gasto. )roponemos una soluci!n al problema del doble gasto utili*ando una
red usuario"a"usuario. a red coloca estampas de tiempo a las transacciones al crear
un hash de las mismas en una cadena continua de pruebas de traba+o basadas en
hashes( formando un registro &ue no puede ser cambiado sin $ol$er a recrear la
prueba de traba+o. a cadena m,s larga no solo sir$e como la prueba de la secuencia
de los e$entos testificados( sino como prueba de &ue $ino del gremio de poder de
procesamiento de -)# m,s grande. Siempre &ue la ma.or%a del poder de
procesamiento de -)# est/ ba+o el control de los nodos &ue no cooperan para atacar
la red( estos generar,n la cadena m,s larga . le lle$ar,n la $enta+a a los atacantes.
a red en s% misma re&uiere una estructura m%nima. os mensa+es son en$iados ba+o
la base de me+or esfuer*o( . los nodos pueden irse . $ol$er a unirse a la red como les
pare*ca( aceptando la cadena de prueba de traba+o de lo &ue sucedi! durante su
ausencia.
1. Introduccin
El comercio en el 0nternet ha $enido a depender exclusi$amente de instituciones financieras las
cuales sir$en como terceros confiables para el procesamiento de pagos electr!nicos. 1ientras &ue
el sistema funciona lo suficientemente bien para la ma.or%a de las transacciones( a2n sufre de las
debilidades inherentes del modelo basado en confian*a. Transacciones completamente no"
re$ertibles no son realmente posibles( dado &ue las instituciones financieras no pueden e$itar
mediar disputas. El costo de la mediaci!n incrementa costos de transacci!n( limitando el tamao
m%nimo pr,ctico por transacci!n . eliminando la posibilidad de pe&ueas transacciones casuales(
. ha. un costo m,s amplio en la p/rdida de la habilidad de hacer pagos no"re$ersibles por
ser$icios no"re$ersibles. -on la posibilidad de re$ertir( la necesidad de confian*a se expande. os
comerciantes deben tener cuidado de sus clientes( molest,ndolos pidiendo m,s informaci!n de la
&ue se necesitar%a de otro modo. #n cierto porcenta+e de fraude es aceptable como ine$itable.
Estos costos e incertidumbres de pagos pueden ser e$itadas en persona utili*ando dinero f%sico(
pero no existe un mecanismo para hacer pagos por un canal de comunicaci!n sin un tercero
confiable.
o &ue se necesita es un sistema de pagos electr!nicos basado en pruebas criptogr,ficas en
$e* de confian*a( permiti/ndole a dos partes interesadas en reali*ar transacciones directamente
sin la necesidad de un tercero confiable. as transacciones &ue son computacionalmente poco
factibles de re$ertir proteger%an a los $endedores de fraude( . mecanismos de dep!sitos de
fideicomisos de rutina podr%an ser f,cilmente implementados para proteger a los compradores. En
este traba+o( proponemos una soluci!n al problema del doble"gasto utili*ando un ser$idor de
marcas de tiempo usuario"a"usuario distribuido para generar una prueba computacional del orden
cronol!gico de las transacciones. El sistema es seguro mientras &ue nodos honestos controlen
colecti$amente m,s poder de procesamiento 3-)#4 &ue cual&uier grupo de nodos atacantes en
cooperaci!n.
5
2. Transacciones
6efinimos una moneda electr!nica como una cadena de firmas digitales. -ada dueo transfiere la
moneda al pr!ximo al firmar digitalmente un hash de la transacci!n pre$ia . la cla$e publica del
pr!ximo dueo . agregando estos al final de la moneda. #n beneficiario puede $erificar las
firmas para $erificar la cadena de propiedad.
El problema claro es &ue el beneficiario no puede $erificar si uno de los dueos no se hi*o un
doble"gasto de la moneda. #na soluci!n com2n es introducir una autoridad central confiable( o
casa de moneda( &ue re$isa cada si cada transacci!n tiene doble"gasto. 6espu/s de cada
transacci!n( la moneda debe ser regresada a la casa de moneda para generar una nue$a moneda( .
solo las monedas generadas directamente de la casa de moneda son las &ue se conf%an de no tener
doble"gasto. El problema con esta soluci!n es &ue el destino del sistema monetario entero
depende de la compa%a &ue gestiona la casa de moneda( con cada transacci!n teniendo &ue pasar
por ellos( tal como un banco.
Necesitamos una forma para &ue el beneficiario pueda saber &ue los dueos pre$ios no
firmaron ningunas transacciones m,s tempranas. )ara nuestros prop!sitos( la transacci!n m,s
temprana es la &ue cuenta( as% &ue no nos importan otros intentos de doble"gasto m,s tarde. a
2nica forma de confirmar la ausencia de una transacci!n es estando al tanto de todas las
transacciones. En el modelo de la casa de moneda( la casa de moneda estaba al tanto de todas las
transacciones . esta decidir%a cuales llegaban primero. )ara lograr esto sin un tercero confiable(
las transacciones deben ser anunciadas p2blicamente 758( . necesitamos un sistema de
participantes &ue est/n de acuerdo con una historia 2nica del orden en &ue estas fueron recibidas.
El beneficiario necesita prueba de &ue a la hora de cada transacci!n( la ma.or%a de los nodos
estu$ieron de acuerdo &ue esta fue la primera &ue se recibi!.
3. Servidor de marcas de tiempo.
a soluci!n &ue proponemos comien*a con un ser$idor de marcas de tiempo. #n ser$idor de
marcas de tiempo funciona al tomar un hash de un blo&ue de elementos a ser fechados .
publicando ampliamente el hash( tal como en un peri!dico( o una publicaci!n #senet 79":8. a
marca de tiempo prueba &ue la data debe haber existido en el tiempo( ob$iamente( para meterse
dentro del hash. -ada marca de tiempo inclu.e la marca de tiempo pre$ia en su hash( formando
una cadena( con cada marca de tiempo adicional refor*ando las anteriores a esa.
9
Bloque
Elemento Elemento
...
Hash
Bloque
Elemento Elemento
...
Hash
Transaccin
Clave pblica
del Dueo 1
Firma del
Dueo
Hash
Transaccin
Clave pblica
del Dueo !
Firma del
Dueo 1
Hash

Transaccin
Clave pbica
del Dueo "
Firma del
Dueo !
Hash

#
e
ri$ic
a
r
Clave privada
del Dueo !
Clave privada
del Dueo 1


F
ir
m
a
r


Clave privada
del Dueo "
#
e
ri$ic
a
r
F
ir
m
a
r
4. rue!a-de-tra!a"o
)ara implementar un ser$idor de marcas de tiempo en una base usuario"a"usuario( necesitaremos
utili*ar un sistema de prueba"de"traba+o similar al ;ashcash de Adam <ack 7=8( en $e* de un
peri!dico o una publicaci!n en #senet. a prueba"de"traba+o en$uel$e la exploraci!n de un $alor
&ue al calcular un hash( tal como S;A"9:=( el hash empiece con un n2mero de bits en cero. El
traba+o promedio re&uerido es exponencial en el n2mero de bits puestos en cero re&ueridos .
puede ser $erificado e+ecutando un solo hash.
)ara nuestra red de marcas de tiempo( implementamos la prueba"de"traba+o incrementando un
nonce en el blo&ue hasta &ue un $alor es encontrado &ue de el n2mero re&uerido de bits en cero
para el hash del blo&ue. #na $e* &ue el esfuer*o de -)# se ha gastado para satisfacer la prueba"
de"traba+o( el blo&ue no puede ser cambiado sin rehacer todo el traba+o. A medida &ue m,s
blo&ues son encadenados despu/s de este( el traba+o para cambiar el blo&ue incluir%a rehacer
todos los blo&ues despu/s de este.
a prueba"de"traba+o tambi/n resuel$e el problema de determinar la representaci!n en cuanto a
decisi!n por ma.or%a. Si la ma.or%a fuese basada en un $oto por direcci!n 0)( podr%a ser
sub$ertida por alguien capa* de asignar muchos 0)s. )rueba"de"traba+o es esencialmente un"
-)#"un"$oto. a decisi!n de la ma.or%a es representada por la cadena m,s larga( la cual tiene la
prueba"de"traba+o de ma.or esfuer*o in$ertido en ella. Si la ma.or%a del poder de -)# es
controlada por nodos honestos( la cadena honesta crecer, m,s r,pido . pasar, cual&uier cadena
&ue est/ compitiendo. )ara modificar un blo&ue en el pasado( un atacante tendr%a &ue rehacer la
prueba"de"traba+o del blo&ue . de todos los blo&ues despu/s . luego alcan*ar . pasar el traba+o
de los nodos honestos. uego demostraremos &ue la probabilidad de un atacante m,s lento de
alcan*ar disminu.e exponencialmente a medida &ue blo&ues subsecuentes son aadidos.
)ara compensar por el incremento de $elocidad de hardware . en el inter/s $ariante de corre
nodos en el tiempo( la dificultad de la prueba"de"traba+o es determinada por una media m!$il
dirigida a un n2mero promedio de blo&ues por hora. Si estos se generan mu. r,pido( la dificultad
incrementa.
#. $a %ed
os pasos para gestionar la red son como sigue>
54 Transacciones nue$as son emitidas a todos los nodos.
94 -ada nodo recolecta nue$as transacciones en un blo&ue.
?4 -ada nodo traba+a en encontrar una prueba"de"traba+o dif%cil para su blo&ue.
@4 -uando un nodo encuentra una prueba"de"traba+o( emite el blo&ue a todos los nodos.
:4 os nodos aceptan el blo&ue si todas las transacciones en el blo&ue son $,lidas . no se han
gastado .a.
=4 os nodos expresan su aceptaci!n del blo&ue al traba+ar en crear el pr!ximo blo&ue en la
cadena( utili*ando el hash del blo&ue aceptado como el hash pre$io.
os nodos siempre consideran la cadena m,s larga como la correcta . empie*an a traba+ar en
extenderla. Si dos nodos emiten $ersiones diferentes del pr!ximo blo&ue simult,neamente(
algunos nodos puede &ue reciban uno o el otro primero. En ese caso( traba+an en el primero &ue
reciban pero guardan la otra rama en caso de &ue esta se $uel$a m,s larga. El empate se rompe
cuando la pr!xima prueba"de"traba+o es encontrada . una rama se $uel$e m,s largaA los nodos
&ue estaban traba+ando en la otra rama luego se cambian a la m,s larga.
?
Bloque
Hash %revio &once
T' T' ...
Bloque
Hash %revio &once
T' T' ...
as emisiones de nue$as transacciones no necesariamente necesitan llegar a todos los nodos.
Tanto estas lleguen a muchos nodos( entrar,n a un blo&ue antes de &ue pase mucho tiempo. as
emisiones de blo&ues tambi/n son tolerantes a mensa+es perdidos. Si un nodo no recibe un
blo&ue( lo $a a pedir cuando reciba el pr!ximo blo&ue . se de cuenta &ue se perdi! uno.
&. Incentivo
)or con$enci!n( la primera transacci!n en el blo&ue es una transacci!n especial &ue comien*a
una moneda nue$a cu.o dueo es el creador del blo&ue. Esto agrega un incenti$o para &ue los
nodos apo.en a la red( . pro$ee una forma inicial de distribuir monedas en circulaci!n( dado &ue
no ha. una autoridad para crearlas. Esta adici!n estable de una cantidad constante de monedas
nue$as es an,loga a mineros de oro gastando recursos para agregar oro a la circulaci!n. En
nuestro caso( es el tiempo del -)# . la electricidad &ue se gasta.
El incenti$o tambi/n puede ser fundado con costos de transacci!n. Si el $alor de salida de una
transacci!n es menor &ue la entrada( la diferencia es una tarifa de transacci!n &ue se le aade al
$alor de incenti$o del blo&ue &ue contiene la transacci!n. #na $e* &ue un n2mero
predeterminado de monedas han entrado en circulaci!n( el incenti$o puede transicionar
enteramente a tarifas de transacci!n . ser completamente libre de inflaci!n.
El incenti$o puede a.udar a animar a los nodos a mantenerse honestos. Si un atacante ego%sta
es capa* de reunir m,s potencia de -)# &ue todos los nodos honestos( este tendr%a &ue elegir
entre utili*arla para defraudar a la gente robando sus pagos de $uelta( o en utili*arla para generar
monedas nue$as. 6eber%a encontrar m,s rentable +ugar por las reglas( tales regla lo fa$orecen a el
con m,s monedas &ue a todos los dem,s combinados( &ue soca$ar el sistema . la $alide* de su
propia ri&ue*a.
'. %eclamando Espacio en (isco
#na $e* &ue la 2ltima transacci!n en una moneda es enterrada ba+o suficientes blo&ues( las
transacciones gastadas antes de estas pueden ser descartadas para ahorrar espacio en disco. )ara
facilitar esto sin romper el hash del blo&ue( las transacciones se les comprueba en un ,rbol
1erkle 7B8 798 7:8( con la 2nica ra%* incluida en el hash el blo&ue. os blo&ues $ie+os pueden ser
compactados al sacar ramas del ,rbol. os hashes interiores no necesitan ser guardados.
a cabecera de un blo&ue sin transacciones ser%a de unos CD b.tes. Si suponemos &ue cada
blo&ue es generado cada 5D minutos( CD b.tes E = E 9@ E ?=: F @.91< por ao. -on
computadoras generalmente $endi/ndose con 9G< de HA1 para el 9DDC( . la le. de 1oore
prediciendo el crecimiento actual de 5.9G< por ao( el almacenamiento no debe ser un problema
aun si las cabeceras de los blo&ues deben permanecer en memoria.
@
Bloque Bloque
Cabecera de Bloque (Hash del Bloque)
Hash %revio &once
Hash1
Hash Hash1 Hash! Hash"
Hash!"
Hash *ai+
Hash1
Hash!
T'"
Hash!"
Cabecera de Bloque (Hash del Bloque)
Hash *ai+
Transacciones Hasheadas en un ,rbol -er.le Despu/s de podar T'0! del Bloque
Hash %revio &once
Hash"
T' T'1 T'! T'"
). *erificacin de a+os Simplificada
Es posible $erificar pagos sin correr un nodo de red completo. #n usuario solo necesita mantener
una copia de las cabeceras de los blo&ues de la cadena m,s larga de prueba"de"traba+o( la cual
puede obtener haciendo una b2s&ueda en los nodos de red hasta &ue est/ con$encido &ue tenga la
cadena m,s larga( . obtenga la rama 1erkle &ue enla*a la transacci!n al blo&ue en &ue ha sido
fechado. No puede $erificar la transacci!n por s% mismo( pero al enla*arla a un lugar en la cadena(
ahora puede $er &ue un nodo de la red la ha aceptado . los blo&ues aadidos despu/s confirman
a2n m,s &ue la red lo ha aceptado.
-omo tal( la $erificaci!n es confiable a medida &ue nodos honestos controlen la red( pero es
m,s $ulnerable si la red es dominada por un atacante. 1ientras &ue los nodos de la red puedan
$erificar transacciones por si mismos( el m/todo simplificado puede ser engaado por las
transacciones fabricadas de un atacante hasta &ue el atacante pueda continuar dominando la red.
#na estrategia para protegerse de esto es aceptar alertas de los nodos de la red cuando detecten un
blo&ue in$,lido( pidi/ndole al usuario &ue se ba+e el blo&ue completo . las transacciones
alertadas para confirmar la inconsistencia. os negocios &ue reciban pagos frecuentes $an a
&uerer correr sus propios nodos para seguridad m,s independiente . $erificaci!n m,s r,pida.
,. -om!inando . (ividiendo *alor
Aun&ue ser%a posible manipular monedas indi$idualmente( seria dif%cil de mane+ar el hacer una
transacci!n por cada centa$o en una transferencia. )ara permitir &ue el $alor se di$ida . se
combine( las transacciones contienen m2ltiples entradas . salidas. Normalmente habr,n o una
sola entrada de una transacci!n pre$ia m,s grande o m2ltiples entradas combinando cantidades
m,s pe&ueas( . al menos dos salidas> una para el pago( . una para de$ol$er el cambio( si es &ue
ha. alg2n cambio( de $uelta al emisor.
6ebe ser notado &ue donde una transacci!n depende de $arias transacciones( . esas
transacciones dependen en muchas m,s( no ha. ning2n problema. Nunca existe la necesidad de
extraer una copia completa de la transacci!n por si sola de la historia de transacciones.
:
Hash1
Hash! Hash"
Hash!"
Cabecera del Bloque
*ai+ -er.le
Hash %revio &once
Cabecera del Bloque
*ai+ -er.le
Hash %revio &once
Cabecera del Bloque
*ai+ -er.le
Hash %revio &once
*ama -er.le para T'"
1a Cadena m,s lar2a de %rueba0de0traba3o
T'"
Transaccin
1/. rivacidad
El modelo bancario tradicional logra un ni$el de pri$acidad al limitar el acceso a la informaci!n
de las partes en$ueltas . del tercero confiado. a necesidad de anunciar todas las transacciones
p2blicamente se opone a este m/todo( pero la pri$acidad a2n puede ser mantenida al romper el
flu+o de la informaci!n en otro lugar> al mantener las cla$es p2blicas an!nimas. El p2blico puede
$er &ue alguien est, en$iando una cantidad a otra persona( pero sin informaci!n &ue relacione la
transacci!n a ninguna persona. Esto es similar al ni$el de informaci!n mostrado por las bolsas de
$alores( donde el tiempo . el tamao de las transacciones indi$iduales( la IcintaJ( es p2blico(
pero sin decir &uienes son las partes.
-omo un cortafuegos adicional( un par nue$o de cla$es debe ser utili*ado para cada
transacci!n de modo &ue puedan ser asociadas a un dueo en com2n. Alg2n tipo de asociaci!n es
ine$itable con transacciones de m2ltiples entradas( las cuales pueden re$elar &ue sus entradas
fueron apropiadas por el mismo dueo. El riesgo est, en &ue si el dueo de una cla$e es re$elado(
el enla*ado podr%a re$elar otras transacciones &ue pertenecieron al mismo dueo.
11. -0lculos
-onsideramos el escenario en el &ue un atacante intenta generar una cadena alterna m,s r,pido
&ue la cadena honesta. A2n si esto es logrado( esto no abre el sistema a cambios arbitrarios( tal
como crear $alor del aire o tomar dinero &ue nunca le perteneci! al atacante. os nodos no
aceptar%an una transacci!n in$,lida como pago( . los nodos honestos nunca aceptar, un blo&ue
&ue las contenga. #n atacante puede 2nicamente intentar cambiar solo una de sus propias
transacciones para retomar dinero &ue ha gastado recientemente.
a carrera entre una cadena honesta . la cadena de un atacante puede ser caracteri*ada como
una -aminata Aleatoria <inomial. El e$ento de /xito es la cadena honesta siendo extendida por
un blo&ue( incrementar esta $enta+a por K5( . el e$ento de fracaso es la cadena del atacante
siendo extendida por un blo&ue reduciendo la distancia por "5.
a probabilidad de &ue un atacante pueda alcan*ar desde un d/ficit dado es an,logo al
problema de la Huina del Apostador. Sup!ngase &ue un apostador con cr/dito ilimitado empie*a
en un d/ficit . +uega potencialmente un n2mero infinito de intentos para intentar llegar a un punto
de e&uilibrio. )odemos calcular la probabilidad de &ue llegase al punto de e&uilibrio( o &ue un
atacante llegue a alcan*ar a la cadena honesta( como sigue 7C8>
p F probabilidad de &ue un nodo honesto encuentre el pr!ximo blo&ue
q F probabilidad de &ue el atacante encuentre el pr!ximo blo&ue
qz F probabilidad de &ue el atacante llegue a alcan*ar desde * blo&ues atr,s.
=
4dentidades Transacciones
Tercero
Con$iable
Contraparte %blico
4dentidades Transacciones %blico
&uevo -odelo de %rivacidadl
-odelo de %rivacidad Tradicional
q
z
=
{
5 if p

q
q/ p
z
if p

q
}
6ada nuestra hip!tesis de &ue p L &( la probabilidad cae exponencialmente mientras &ue el
n2mero de blo&ues el cual el atacante debe alcan*ar incrementa. -on las probabilidades en
contra( si no hace una estocada afortunada desde el principio( sus chances se $uel$en
extremadamente pe&ueos a medida &ue se &ueda m,s atr,s.
Ahora consideramos cu,nto necesita esperar el recipiente de una nue$a transacci!n antes de
tener la certe*a suficiente de &ue el emisor no puede cambiar la transacci!n. Asumimos &ue el
emisor es un atacante el cual &uiere hacerle creer al recipiente &ue le pag! durante un rato( luego
cambiar la transacci!n para pagarse de $uelta a s% mismo una $e* &ue ha pasado un tiempo. El
receptor ser, alertado cuando esto suceda( pero el emisor espera &ue sea demasiado tarde.
El receptor genera una nue$o par de cla$es . entrega la cla$e p2blica al emisor poco despu/s
de hacer la firma. Esto pre$iene &ue el emisor prepare una cadena de blo&ues antes de tiempo al
traba+ar continuamente hasta &ue tenga la suerte de adelantarse lo suficiente( . luego e+ecutar la
transacci!n en ese momento. #na $e* &ue la transacci!n es en$iada( el emisor deshonesto
empie*a a traba+ar en secreto en una cadena paralela &ue contiene una $ersi!n alterna de su
transacci!n.
El recipiente espera a &ue la transacci!n sea aadida al blo&ue . * blo&ues han sido enla*ados
despu/s de la transacci!n. El no necesita saber la cantidad exacta de progreso &ue al atacante ha
logrado( pero asumiendo &ue los blo&ues honestos se tardaron el promedio esperado por blo&ue(
el progreso potencial del atacante ser, una distribuci!n de )oisson con un $alor esperado>
)ara obtener la probabilidad de &ue el atacante a2n pueda alcan*ar ahora( multiplicamos la
densidad de )oisson por cada cantidad de progreso &ue pudo haber hecho por la probabilidad de
&ue pudo alcan*ar desde ese punto>
He"organi*amos para e$itar la suma de la cola infinita de la distribuci!n...
-on$ertimos a c!digo en -...
B
=
z
q
p

k=D

k
e

k
!

{
q/ p
zk
if k

z
5
if k

z
}
5

k=D
z

k
e

k
!
5

q
/
p

zk

#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double ! ".# $ q%
double lambda ! z & (q ' )%
double sum ! ".#%
int i, k%
(or (k ! #% k <! z% k)))
{
double oisson ! e*($lambda)%
(or (i ! "% i <! k% i)))
oisson &! lambda ' i%
sum $! oisson & (" $ o+(q ' , z $ k))%
,
return sum%
,
E+ecutamos algunos resultados( podemos $er &ue la probabilidad cae exponencialmente con *.
Hesol$emos para ) menor &ue D.5M...
12. -onclusin
;emos propuesto un sistema para transacciones electr!nicas sin depender en confian*a.
-omen*amos con el marco habitual de monedas hechas de firmas digitales( el cual pro$ee un
control fuerte de propiedad( pero es incompleto sino existe una forma de pre$enir doble"gasto.
)ara solucionar esto( hemos propuesto una red usuario"a"usuario &ue utili*a prueba"de"traba+o
para registrar una historia p2blica de transacciones la cual r,pidamente se con$ierte impr,ctica
computacionalmente para &ue un atacante pueda cambiar si nodos honestos controlan la ma.or%a
del poder de -)#. a red es robusta en su simplicidad no estructurada. os nodos pueden
traba+ar todos al mismo tiempo con poca coordinaci!n. No necesitan ser identificados( dado &ue
los mensa+es no son enrutados a ning2n lugar en particular . solo necesitan ser entregados ba+o la
base de un me+or esfuer*o. os nodos pueden irse . $ol$er a la red a $oluntad( aceptando la
cadena de prueba"de"traba+o como prueba de lo &ue sucedi! mientras estu$ieron ausentes. Notan
con su poder de -)#( expresando su aceptaci!n de los blo&ues $,lidos al traba+ar extendi/ndose
. recha*ando blo&ues in$,lidos al refutar traba+ar en ellos. -ual&uier reglas necesarias e
incenti$os se pueden hacer cumplir con este mecanismo de consenso.
C
q!#."
z!# P!".#######
z!" P!#.-#./012
z!- P!#.#/#3113
z!2 P!#.#"2"1--
z!. P!#.##2.//-
z!/ P!#.###3"21
z!4 P!#.###-.-0
z!1 P!#.####4.1
z!0 P!#.####"12
z!3 P!#.#####.4
z!"# P!#.#####"-
q!#.2
z!# P!".#######
z!/ P!#."112/-2
z!"# P!#.#."44#/
z!"/ P!#.#"#"##0
z!-# P!#.##-.0#.
z!-/ P!#.###4"2-
z!2# P!#.###"/--
z!2/ P!#.####213
z!.# P!#.#####3/
z!./ P!#.#####-.
z!/# P!#.######4
P < #.##"
q!#."# z!/
q!#."/ z!0
q!#.-# z!""
q!#.-/ z!"/
q!#.2# z!-.
q!#.2/ z!."
q!#..# z!03
q!#../ z!2.#
%eferencias
758 O. 6ai( Pb"mone.(P http>//www.weidai.com/bmone..txt( 5QQC.
798 ;. 1assias( R.S. A$ila( and S."S. Tuis&uater( P6esign of a secure timestamping ser$ice with minimal
trust re&uirements(P 0n 20th Symposium on Information Theory in the Benelux( 1a. 5QQQ.
7?8 S. ;aber( O.S. Stornetta( P;ow to time"stamp a digital document(P 0n Journal of Cryptology( $ol ?( no
9( pages QQ"555( 5QQ5.
7@8 6. <a.er( S. ;aber( O.S. Stornetta( P0mpro$ing the efficienc. and reliabilit. of digital time"stamping(P
In Sequences II: etho!s in Communication" Security an! Computer Science( pages ?9Q"??@( 5QQ?.
7:8 S. ;aber( O.S. Stornetta( PSecure names for bit"strings(P 0n #rocee!ings of the $th %C Conference
on Computer an! Communications Security( pages 9C"?:( April 5QQB.
7=8 A. <ack( P;ashcash " a denial of ser$ice counter"measure(P
http>//www.hashcash.org/papers/hashcash.pdf( 9DD9.
7B8 H.-. 1erkle( P)rotocols for public ke. cr.ptos.stems(P 0n )roc. &'(0 Symposium on Security an!
#ri)acy( 0EEE -omputer Societ.( pages 599"5??( April 5QCD.
7C8 O. 'eller( PAn introduction to probabilit. theor. and its applications(P 5Q:B.
Q