Bitcoin: Un Sistema de Efectivo Electrnico Peer-to-Peer

SatoshiNakamoto satoshin@gmx.com www.bitcoin.org TraducidoalEspaolporIng.AngelLeon. www.diariobitcoin.com Abstracto. Una versin puramente electrnica de efectivo permitira que los pagos en lnea fuesen enviados directamente de un ente a otro sin tener que pasar por medio de una institucin financiera. Firmasdigitalesproveenpartedelasolucin,perolosbeneficiosprincipalessepierdensi existeuntercero confiable para prevenir el doblegasto. Proponemos una solucin al problema del doble gasto utilizando una red peertopeer. La red coloca estampas de tiempo a las transacciones al crear un hash de las mismas enuna cadena continua de pruebas de trabajo basadas enhashes,formando unregistroqueno puede ser cambiado sin volver a recrear la prueba de trabajo. La cadena ms largano solo sirvecomola prueba de la secuencia de los eventos testificados, sino como prueba de que vino de lapiscinadepoder de procesamiento de CPU ms grande. Siemprequelamayora del poderde procesamientode CPUest bajoel control de los nodos que no cooperan paraatacarla red,estosgenerarn lacadenamslargayle llevarn la ventaja alosatacantes. Laredensmismarequiereunaestructura mnima.Los mensajesson enviados bajo la base de mejor esfuerzo, y los nodos pueden irse y volver a unirse a la red como les parezca,aceptandolacadenadepruebadetrabajodeloquesucedidurantesuausencia.

1. Introduccin
El comercio en el Internet ha venido a depender exclusivamente de instituciones financieras las cuales sirven como terceros confiables para el procesamiento de pagos electrnicos. Mientrasqueelsistema losuficientementebienpara la mayora de las transacciones, an sufre de las debilidades inherentes del modelo basado en confianza. Transacciones completamente norevertibles no son realmente posibles, dado que las instituciones financieras no pueden evitar mediar disputas. El costodelamediacinincrementacostosdetransaccin,limitandoeltamaomnimo prctico portransaccinyeliminandolaposibilidaddepequeastransaccionescasuales, y hayuncostomsamplioen la prdida de la habilidad de hacer pagos noreversibles por servicios noreversibles. Con la posibilidad derevertir, la necesidad de confianza se expande. Los comerciantes deben tener cuidado de sus clientes, molestandolos pidiendo ms informacin de la que se necesitara de otro modo. Un cierto porcentaje de fraude es aceptable como inevitable. Estos costos e incertidumbres de pagos pueden ser evitadas en persona utilizando dinero fsico, pero no existe un mecanismoparahacerpagosporuncanaldecomunicacinsinunterceroconfiable. Lo que senecesitaesunsistemadepagoselectronicosbasado enpruebascriptogrficas envezdeconfianza, permitindole a dos partes interesadasenrealizartransaccionesdirectamente sinlanecesidaddeun terceroconfiable. Las transacciones que son computacionalmente impracticas de revertir protegeran a los vendedores de fraude, y mecanismos de depsitos de fideicomisos de rutina podran ser fcilmente implementados para proteger a los compradores. En este trabajo, proponemos una solucin al problema deldoblegasto utilizandounservidordemarcas de tiempo peertopeer distribuido para generar una prueba computacionaldelordencronolgicodelastransacciones. Elsistema esseguro mientras que nodos honestos controlen colectivamentemspoder deprocesamiento (CPU)que cualquiergrupodenodosatacantesencooperacin.

2. Transacciones
Definimos una moneda electrnica como una cadena de firmas digitales. Cada dueotransfierelamonedaalproximo al firmar digitalmente un hash delatransaccinpreviaylaclavepublicadelproximodueoyagregandoestosalfinalde lamoneda.Unbeneficiariopuedeverificarlasfirmasparaverificarlacadenadepropiedad.

El problema claro es que el beneficiario no puede verificar si uno de los dueos no se hizo un doblegasto de la moneda. Una solucin comn es introducir una autoridad centralconfiable,ocasade moneda,querevisacadasicada transaccin tiene doblegasto. Despus decadatransaccin,lamoneda debeserregresadaalacasademonedapara generar una nueva moneda, ysololasmonedasgeneradasdirectamente delacasa demonedasonlasqueseconfan de no tener doblegasto. El problema con esta solucin es que el destino del sistemamonetarioenterodependedela compaaquegestionalacasademoneda,concadatransaccinteniendoquepasarporellos,talcomounbanco. Necesitamos una forma para que el beneficiario pueda saber que los dueos previos no firmaron ningunas transacciones ms tempranas. Para nuestros propsitos, la transaccin ms temprana es la que cuenta, asi queno nos importan otros intentos de doblegasto ms tarde. La nica forma de confirmar la ausencia deunatransaccines estando al tanto de todaslastransacciones.Enelmodelo delacasa demoneda, lacasademonedaestabaaltantode todas las transacciones y esta decidiria cuales llegaban primero. Para lograr esto sin un tercero confiable, las transacciones deben ser anunciadas pblicamente [1], y necesitamos un sistema de participantes que estn de acuerdo con una historianicadelordenenqueestasfueronrecibidas.Elbeneficiarionecesitapruebadequealahora decadatransaccin,lamayoradelosnodosestuvierondeacuerdoqueestafuelaprimeraqueserecibi.

3. Servidor de marcas de tiempo.

La solucin que proponemos comienza con un servidor de marcas de tiempo. Un servidor de marcas de tiempo funciona altomarunhashdeunbloquedeelementosaser fechadosypublicandoampliamenteelhash,talcomoenun peridico, o una publicacin Usenet [25]. La marca de tiempo prueba que la data debe haberexistido enel tiempo, obviamente, para meterse dentro del hash. Cada marca de tiempo incluye la marca de tiempo previa en su hash, formandounacadena,concadamarcadetiempoadicionalreforzandolasanterioresaesa.

4. Prueba-de-Trabajo
Para implementar un servidor de marcas de tiempo en una base peertopeer, necesitaremos utilizar un sistema de pruebadetrabajosimilaralHashcashdeAdamBack[6],envezdeunperidicoounapublicacinenUsenet. La pruebadetrabajo envuelve la exploracin de un valor que al calcular un hash, tal como SHA256,el hash empiece con un nmero de bits en cero. El trabajo promedio requerido es exponencial en el nmero de bits puestosen cero requeridosypuedeserverificadoejecutandounsolohash. Para nuestra red de marcas de tiempo, implementamos la pruebadetrabajo incrementando un nonce en el bloque hasta que un valor es encontrado que de el nmero requerido de bits en cero paraelhashdelbloque.Unavez que el esfuerzo de CPU se ha gastado para satisfacer la pruebadetrabajo, el bloque no puede ser cambiado sin rehacer todo el trabajo. A medida que ms bloques son encadenados despus de este, el trabajo para cambiar el bloqueincluirarehacertodoslosbloquesdespusdeeste.

La pruebadetrabajo tambin resuelve el problema de determinar la representacin en cuanto a decisinpor mayora. Si la mayora fuese basada en un voto por direccin IP, podra ser subvertida por alguien capaz deasignar muchos IPs. Pruebadetrabajo es esencialmente unCPUunvoto. La decisin de la mayora es representada porla cadena ms larga, la cualtienelapruebadetrabajode mayoresfuerzoinvertidoen ella. Sila mayoradelpoderdeCPU es controlada por nodos honestos, la cadena honesta crecer ms rpido y pasar cualquier cadena que est compitiendo. Para modificar un bloque en el pasado, un atacante tendra que rehacerla pruebadetrabajodelbloquey de todos los bloques despus y luegoalcanzarypasarel trabajode losnodos honestos. Luegodemostraremosquela probabilidad de un atacante ms lento de alcanzar disminuye exponencialmente a medida quebloquessubsecuentes sonaadidos. Para compensar por el incremento de velocidad de hardware y en el inters variante de corre nodos en el tiempo, la dificultad de la pruebadetrabajo es determinada por una media mvil dirigida a un nmero promedio de bloquesporhora.Siestossegeneranmuyrpido,ladificultadincrementa.

5. La Red.
Lospasosparagestionarlaredsoncomosigue: 1. Transaccionesnuevassonemitidasatodoslosnodos. 2. Cadanodorecolectanuevastransaccionesenunbloque. 3. Cadanodotrabajaenencontrarunapruebadetrabajodifcilparasubloque. 4. Cuandounnodoencuentraunapruebadetrabajo,emiteelbloqueatodoslosnodos. 5. Losnodosaceptanelbloquesitodaslastransaccionesenelbloquesonvlidasynosehangastadoya. 6. Los nodos expresan su aceptacin del bloque al trabajaren crearelprximobloqueenla cadena,utilizandoel hashdelbloqueaceptadocomoelhashprevio. Los nodos siempre consideran la cadena ms larga como la correcta y empiezan a trabajar en extenderla. Si dos nodos emiten versiones diferentes del prximo bloque simultneamente, algunos nodospuedequerecibanunoo el otro primero. En ese caso, trabajan en el primero que reciban pero guardan la otra rama en caso de que esta se vuelvams larga. El empate se rompe cuando la prxima pruebadetrabajo es encontrada y una rama se vuelvems largalosnodosqueestabantrabajandoenlaotraramaluegosecambianalamslarga.

Las emisiones de nuevas transacciones no necesariamente necesitan llegar a todos los nodos. Tanto estas lleguen a muchos nodos, entrarn a un bloque antes de que pase mucho tiempo. Las emisionesdebloquestambin son tolerantes a mensajes perdidos. Si unnodono recibeun bloque,lovaa pedircuandorecibaelprximobloqueyse decuentaqueseperdiuno.

6. Incentivo
Porconvencin, la primeratransaccinenelbloqueesuna transaccinespecialquecomienzaunamonedanuevacuyo dueo es el creador del bloque. Esto agrega unincentivo para que losnodos apoyenalared,yproveeunaformainicial de distribuirmonedasencirculacin,dadoquenohayunaautoridadparacrearlas.Estaadicinestabledeunacantidad constante de monedas nuevas es anloga a mineros de oro gastando recursos para agregaroro ala circulacin. En nuestrocaso,eseltiempodelCPUylaelectricidadquesegasta. Elincentivo tambin puede ser fundado con costos de transaccin. Si el valorde salidadeunatransaccines menor que la entrada, la diferencia es una tarifa de transaccin que se le aade al valor de incentivo del bloque que contiene la transaccin. Una vez que un nmero predeterminado de monedas han entrado en circulacin, el incentivo puedetransicionarenteramenteatarifasdetransaccinysercompletamentelibredeinflacin. El incentivo puede ayudar a animar a los nodos a mantenerse honestos. Si un atacante egostaes capaz de reunir ms potencia de CPU que todos los nodos honestos, este tendra que elegir entre utilizarla paradefraudar ala gente robando sus pagos de vuelta,oenutilizarlaparagenerar monedasnuevas.Deberaencontrarmsrentablejugar por las reglas, tales regla lo favorecen a el con ms monedas que a todos los dems combinados, que socavarel sistemaylavalidezdesupropiariqueza.

7. Reclamando Espacio en Disco

Una vez que la ltima transaccin en una moneda es enterrada bajo suficientes bloques, las transacciones gastadas antes de estaspuedenserdescartadasparaahorrarespacio endisco.Para facilitar estosin romper elhashdelbloque, las transacciones se les comprueba en un rbol Merkle [7] [2] [5], con la nica raz incluida en el hash el bloque.Los bloquesviejospuedensercompactadosalsacarramasdelrbol.Loshashesinterioresnonecesitanserguardados.

La cabecera de un bloque sin transacciones sera de unos 80 bytes. Si suponemos que cada bloque es generado cada 10 minutos, 80 bytes *6*24*365 = 4.2MBpor ao.Concomputadorasgeneralmentevendiendosecon 2GB de RAM para el 2008, y la ley de MOore prediciendoelcrecimientoactualde1.2GBpor ao,elalmacenamientono debeserunproblemaaunsilascabecerasdelosbloquesdebenpermanecerenmemoria.

8. Verificacin de Pagos Simplificada.

Es posible verificar pagos sin correr un nodo de red completo. Un usuario solo necesita mantener una copia de las cabeceras de los bloques de lacadenamslargadepruebadetrabajo, lacualpuedeobtenerhaciendounabsqueda en losnodos de red hasta que est convencido quetengalacadena mslarga,yobtengalaramaMerklequeenlazala transaccin al bloque en que ha sido fechado. No puede verificar la transaccion por s mismo, pero al enlazarla a un lugaren la cadena, ahora puede ver que un nodo de la red la ha aceptado y losbloquesaadidosdespusconfirman anmsquelaredlohaaceptado.

Como tal, la verificacin es confiableamedidaquenodoshonestos controlenlared,peroes msvulnerablesi la redes dominada por un atacante. Mientras que los nodos de laredpuedanverificartransaccionesporsimismos,el mtodo simplificado puede ser engaado por lastransaccionesfabricadasde unatacantehastaqueelatacantepueda continuar dominando la red. Una estrategia para protegerse de esto es aceptar alertas de los nodos de laredcuando detecten un bloque invlido, pidindole al usuario que se baje el bloque completo y lastransaccionesalertadas para confirmarlainconsistencia.Losnegociosquerecibanpagos frequentessun vana querercorrer suspropiosnodospara seguridadmsindependienteyverificacinmsrpida.

9. Combinando y Dividiendo Valor.

Aunque sera posible manipular monedas individualmente, seria dificil de manejar el hacer una transaccin por cada centavo en una transferencia. Para permitir que el valor se divida y se combine, las transacciones contienen mltiples entradas ysalidas.Normalmentehabrnounasolaentradade una transaccinprevia msgrande omltiplesentradas combinando cantidades ms pequeas, y al menos dos salidas: una para elpago,yunaparadevolverelcambio,sies quehayalgncambio,devueltaalemisor.

Debe ser notado que donde una transaccin depende de varias transacciones, y esas transacciones dependen en muchas ms, no hay ningun problema. Nunca existe la necesidad de extraer unacopia completa de la transaccinporsisoladelahistoriadetransacciones.

10. Privacidad.
Elmodelo bancario tradicional logra un nivel deprivacidad allimitarelaccesoalainformacinde laspartesenvueltasy del tercero confiado. La necesidad de anunciar todas las transacciones pblicamente seoponeaestemtodo,perola privacidad an puede ser mantenida al romper el flujo de la informacin en otro lugar: al mantenerlas clavespblicas annimas. El pblico puede ver que alguien est enviando una cantidad a otra persona, pero sin informacin que relacione la transaccin a ninguna persona. Esto es similaralniveldeinformacinmostradopor lasbolsas devalores, donde el tiempo y el tamao de las transacciones individuales, la cinta, es pblico, pero sin decir quienes sonlas partes.

Como un cortafuegos adicional, un par nuevo de claves debeserutilizadoparacadatransaccindemodoque puedan ser asociadas a un dueo en comn. Algn tipo de asociacin es inevitable contransaccionesde mltiples entradas, las cuales pueden revelar que sus entradas fueron apropiadas por elmismo dueo.Elriesgoestenquesi eldueodeunaclaveesrevelado,elenlazadopodrarevelarotrastransaccionesquepertenecieronalmismodueo.

11. Clculos.
Consideramos el escenario en el que un atacante intenta generar una cadena alterna ms rpido que la cadena honesta. An si esto es logrado, esto no abre el sistema a cambios arbitrarios, tal como crear valor del aire o tomar dinero que nunca le perteneci al atacante. Los nodos no aceptarian una transaccin invlidacomo pago, ylosnodos honestos nunca aceptar un bloqueque lascontenga. Unatacantepuedenicamenteintentarcambiarsolounadesus propiastransaccionespararetomardineroquehagastadorecientemente. La carrera entre una cadena honesta y la cadena de un atacante puede sercaracterizadacomounaCaminata Aleatoria Binomial.Eleventodexitoeslacadenahonestasiendo extendida porunbloque,incrementarestaventajapor +1,yeleventodefracasoeslacadenadelatacantesiendoextendidaporunbloquereduciendoladistanciapor1. La probabilidad de que un atacante alcance dese un dficit dado es anlogo al problema de la Ruina del Apostador. Supngase que un apostador con crdito ilimitado empieza en un dficityjuegapotencialmenteunnmero infinito de intentos para intentar llegar a un punto de equilibrio. Podemos calcular la probabilidad de que llegase al puntodeequilibrio,oqueunatacantellegueaalcanzaralacadenahonesta,comosigue[8]: p=probabilidaddequeunnodohonestoencuentreelprximobloque q=probabilidaddequeelatacanteencuentreelprximobloque qz=probabilidaddequeelatacantellegueaalcanzardesdezbloquesatrs.

Dadanuestra hiptesis de que p > q, laprobabilidadcaeexponencialmente mientras queelnmerodebloqueselcual el atacante debe alcanzar incrementa. Con las probabilidades en contra, si no hace una estocadaafortunadadesdeel principio,suschancessevuelvenextremadamentepequeosamedidaquesequedamsatrs. Ahora consideramos cunto necesita esperar el recipiente de una nueva transaccin antes de tenerlacerteza suficiente de que el emisor no puede cambiar la transaccin. Asumimos que el emisor es un atacante el cual quiere hacerle creer al recipiente que le pag duranteunrato,luego cambiarla transaccinparapagarsedevueltaasmismo una vez que ha pasado un tiempo. El receptor ser alertado cuando esto suceda, pero el emisor espera que sea demasiadotarde. Elreceptorgeneraunanuevopardeclavesyentregala clave pblica alemisorpocodespusdehacerlafirma. Esto previene queelemisorprepareunacadenade bloques antesdetiempoal trabajarcontinuamentehastaquetenga la suertede adelantarse lo suficiente, y luego ejecutar la transaccin en ese momento. Una vez que la transaccin es enviada, el emisor deshonesto empieza a trabajar en secreto en una cadenaparalela quecontieneunaversinalterna desutransaccin. Elrecipiente espera a que latransaccinseaaadidaalbloqueyzbloqueshansidoenlazadosdespusdela transaccin. El no necesita saber la cantidad exacta de progreso que al atacante ha logrado, pero asumiendo que los bloques honestos se tardaron el promedio esperado por bloque, el progreso potencial del atacante ser una distribuciondePoissonconunvaloresperado: Para obtener la probabilidad de que el atacante an pueda alcanzar ahora, multiplicamos la densidad de Poisson por cadacantidaddeprogresoquepudohaberhechoporlaprobabilidaddequepudoalcanzardesdeesepunto:

Reorganizamosparaevitarlasumadelacolainfinitadeladistribucin...

ConvertimosacdigoenC...
# i n c l u d e < m a t h . h > d o u b l e A t t a c k e r S u c c e s s P r o b a b i l i t y ( d o u b l e q , i n t z ) { d o u b l e p = 1 . 0 q d o u b l e l a m b d a = z * ( q / p ) d o u b l e s u m = 1 . 0 i n t i , k f o r ( k = 0 k < = z k + + ) { d o u b l e p o i s s o n = e x p ( l a m b d a ) f o r ( i = 1 i < = k i + + ) p o i s s o n * = l a m b d a / i s u m = p o i s s o n * ( 1 p o w ( q / p , z k ) ) } r e t u r n s u m }

Ejecutamosalgunosresultados,podemosverquelaprobabilidadcaeexponencialmenteconz.
q = 0 . 1 z = 0 P = 1 . 0 0 0 0 0 0 0 z = 1 P = 0 . 2 0 4 5 8 7 3 z = 2 P = 0 . 0 5 0 9 7 7 9 z = 3 P = 0 . 0 1 3 1 7 2 2 z = 4 P = 0 . 0 0 3 4 5 5 2 z = 5 P = 0 . 0 0 0 9 1 3 7 z = 6 P = 0 . 0 0 0 2 4 2 8 z = 7 P = 0 . 0 0 0 0 6 4 7 z = 8 P = 0 . 0 0 0 0 1 7 3 z = 9 P = 0 . 0 0 0 0 0 4 6 z = 1 0 P = 0 . 0 0 0 0 0 1 2 q = 0 . 3 z = 0 P = 1 . 0 0 0 0 0 0 0 z = 5 P = 0 . 1 7 7 3 5 2 3 z = 1 0 P = 0 . 0 4 1 6 6 0 5 z = 1 5 P = 0 . 0 1 0 1 0 0 8 z = 2 0 P = 0 . 0 0 2 4 8 0 4 z = 2 5 P = 0 . 0 0 0 6 1 3 2 z = 3 0 P = 0 . 0 0 0 1 5 2 2 z = 3 5 P = 0 . 0 0 0 0 3 7 9 z = 4 0 P = 0 . 0 0 0 0 0 9 5 z = 4 5 P = 0 . 0 0 0 0 0 2 4 z = 5 0 P = 0 . 0 0 0 0 0 0 6

ResolvemosparaPmenorque0.1%...
P < 0 . 0 0 1 q = 0 . 1 0 z = 5 q = 0 . 1 5 z = 8 q = 0 . 2 0 z = 1 1 q = 0 . 2 5 z = 1 5 q = 0 . 3 0 z = 2 4 q = 0 . 3 5 z = 4 1 q = 0 . 4 0 z = 8 9 q = 0 . 4 5 z = 3 4 0

12. Conclusion
Hemos propuesto un sistema para transacciones electrnicas sin depender en confianza. Comenzamos conelmarco habitual de monedas hechas de firmas digitales, el cualproveeuncontrolfuertedepropiedad,peroesincompletosino existe una forma de prevenir doblegasto. Para solucionar esto, hemos propuesto una red peertopeer que utiliza pruebadetrabajo para registrar una historia pblica de transacciones la cual rpidamente se convierte impractica computacionalmenteparaqueunatacantepueda cambiarsinodos honestoscontrolan lamayoradelpoderdeCPU.La red es robusta en su simplicidad no estructurada. Los nodos pueden trabajar todos al mismo tiempo con poca coordinacin. No necesitan ser identificados, dado que los mensajes no son enrutados a ningn lugaren particular y solo necesitan ser entregados bajo la base de un mejor esfuerzo. Los nodos pueden irse y volvera lared avoluntad, aceptando la cadena de pruebadetrabajo como prueba de loquesucedimientrasestuvieronausentes.Votanconsu poder de CPU, expresando su aceptacin de los bloques vlidos al trabajar extendindose y rechazando bloques invlidos al refutar trabajar en ellos. Cualquier reglas necesarias e incentivos se pueden hacer cumplir con este mecanismodeconsenso.