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.

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.
Transaccin
Clave pblica

Transaccin
Clave pblica

Transaccin
Clave pbica

del Dueo 1

del Dueo !

del Dueo "

Hash

#er i$ica

Hash
r

#er i$ica

Hash
r

Firma del Dueo

ar m Fir

Firma del Dueo 1

ar m Fir

Firma del Dueo !

Clave privada

Clave privada

Clave privada

del Dueo 1

del Dueo !

del Dueo "

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.
Hash Hash

Bloque
Elemento Elemento

Bloque ...
Elemento Elemento

...

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.
Bloque
Hash %revio

Bloque &once ...

Hash %revio

&once ...

T'

T'

T'

T'

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.

#.
54 94 ?4 @4 :4

$a %ed
Transacciones nue$as son emitidas a todos los nodos. -ada nodo recolecta nue$as transacciones en un blo&ue. -ada nodo traba+a en encontrar una prueba"de"traba+o dif%cil para su blo&ue. -uando un nodo encuentra una prueba"de"traba+o( emite el blo&ue a todos los nodos. 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 pasos para gestionar la red son como sigue>

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.

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.
Bloque
Cabecera de Bloque (Hash del Bloque)

Bloque

Cabecera de Bloque (Hash del Bloque)

Hash %revio Hash *ai+

&once

Hash %revio Hash *ai+

&once

Hash 1

Hash!"

Hash 1

Hash!"

Hash

Hash1

Hash!

Hash"

Hash!

Hash"

T'

T'1

T'!

T'"

T'" Despu/s de podar T' 0! del Bloque

Transacciones Hasheadas en un ,rbol -er.le

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.

).

*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.
1a Cadena m,s lar2a de %rueba0de0traba3o Cabecera del Bloque
Hash %revio

Cabecera del Bloque

Hash %revio

Cabecera del Bloque

Hash %revio

&once

&once

&once

*ai+ -er.le

*ai+ -er.le

*ai+ -er.le

Hash 1

Hash!" *ama -er.le para T'" Hash! Hash"

T'"

-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.
Transaccin

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.

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.
-odelo de %rivacidad Tradicional 4dentidades Transacciones Tercero Con$iable Contraparte %blico

&uevo -odelo de %rivacidadl 4dentidades Transacciones %blico

-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.

q z=

if p q 5 z q / p 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>

= z

q p

)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>

k e q / p z k if k z k! 5 if k z k =D

He"organi*amos para e$itar la suma de la cola infinita de la distribuci!n...

z k z k 5 e 5 q / p k! k =D

-on$ertimos a c!digo en -...

#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 *.
q!#." z!# z!" z!z!2 z!. z!/ z!4 z!1 z!0 z!3 z!"# q!#.2 z!# z!/ z!"# z!"/ z!-# z!-/ z!2# z!2/ z!.# z!./ z!/# P!".####### P!#.-#./012 P!#.#/#3113 P!#.#"2"1-P!#.##2.//P!#.###3"21 P!#.###-.-0 P!#.####4.1 P!#.####"12 P!#.#####.4 P!#.#####"P!".####### P!#."112/-2 P!#.#."44#/ P!#.#"#"##0 P!#.##-.0#. P!#.###4"2P!#.###"/-P!#.####213 P!#.#####3/ P!#.#####-. P!#.######4

Hesol$emos para ) menor &ue D.5M...

P < #.##" q!#."# z!/ q!#."/ z!0 q!#.-# z!"" q!#.-/ z!"/ q!#.2# z!-. q!#.2/ z!." q!#..# z!03 q!#../ z!2.#

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.

%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 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. Conference