¿Qué es el Doble Gasto?
El doble gasto es un problema potencial de los sistemas de efectivo digital, consistente en el envío simultáneo (y por lo tanto gasto) de los mismos fondos a dos destinatarios distintos. Sin contramedidas adecuadas, un protocolo que no resuelva el problema se verá desvirtuado; los usuarios no tendrán forma de verificar que los fondos que reciban no han sido gastados ya en algún otro sitio.
En lo que respecta al efectivo digital, garantizar que unidades específicas no pueden ser duplicadas resulta de suma importancia. Todo el sistema se vería comprometido si Alice pudiera recibir 10 unidades, «copiar y pegarlas» 10 veces, y como resultado de ello, encontrarse en posesión de 100 unidades. De manera similar, un esquema de este tipo tampoco podrá funcionar en el caso de que Alice sea capaz de enviar las mismas 10 unidades a Bob y Carol de forma simultánea. Por ello, para que el dinero digital funcione, es necesario contar con mecanismos que prevengan este tipo de acciones.
¿Cómo Puede Evitarse el Doble Gasto?
El enfoque centralizado
La vía centralizada es considerablemente más fácil de implementar que las alternativas descentralizadas. La misma, habitualmente, implica contar con un supervisor que gestione el sistema y controle la emisión y distribución de unidades. Un buen ejemplo de solución centralizada al problema de doble gasto sería eCash, de David Chaum.
Para la expedición de activos digitales que imiten el efectivo (y permitan un intercambio anónimo y peer-to-peer) entre usuarios, un banco podrá utilizar firmas ciegas; tal como detallaría en 1982 el criptógrafo David Chaum en su artículo Blind Signatures for Untraceable Payments (Firmas Ciegas para Pagos No Rastreables).
Ejemplo Práctico
En tal contexto, si un usuario (llamémosle Dan) desea recibir 100$ en efectivo digital, primero deberá informar al banco. Siempre y cuando disponga del balance necesario en su cuenta, a continuación generará un número aleatorio. Supongamos que produce cinco números, a cada uno de los cuales se le asignará un valor de 20$. Para evitar que el banco rastree unidades específicas, Dan ofuscará los números aleatorios añadiendo un factor de ocultación a cada uno de ellos.
A continuación entrega estos datos al banco, que admite cargos a su cuenta por 100$, y firma mensajes certificando que cada uno de los fragmentos de información anteriormente mencionados es redimible por 20$. Dan ya puede ahora gastar los fondos emitidos por el banco. Por ello se dirige al restaurante de Erin y compra una comida que le cuesta 40$.
Dan puede eliminar el factor de ocultación para así exponer el número aleatorio asociado a cada billete de efectivo digital, el cual sirve como identificador único de cada unidad. Dan le revela dos de estos números a Erin, y éste deberá proceder a redimirlos de forma inmediata a través del banco, para evitar que el primero vuelva a gastarlos en otro comercio. El banco comprobará que las firmas sean válidas, y si todo está en orden, abonará 40$ a Erin en su cuenta. Los billetes ya utilizados son esencialmente quemados, por lo que otros nuevos deberán ser emitidos si Erin desea gastar su nuevo balance de la misma forma.
La configuración chaumiana de eCash puede resultar valiosa para las transacciones privadas. Pero fracasa en términos de resiliencia porque el banco es un punto central de fallo. Los billetes emitidos no valen nada en sí mismos; su valor deriva solamente de la disposición del banco a intercambiarlos por dólares. Los clientes se encuentran a merced del banco, por lo que dependerán de su buena voluntad para que el dinero funcione. Este es precisamente el problema que las criptomonedas se proponen remediar.
El enfoque descentralizado
Garantizar que los fondos no pueden verse sujetos a doble gasto en un ecosistema sin supervisor es un desafío mucho mayor. Los participantes, que presentan un poder similar, deben coordinarse en torno a un conjunto de reglas que previenen el fraude e incentivan que todos los usuarios actúen de forma honesta.
La principal innovación presentada en el white paper de Bitcoin era una solución al problema de doble gasto. Aunque no se la menciona como tal, Satoshi proponía la estructura de datos que hoy conocemos popularmente como blockchain.
Una blockchain es, en realidad, solamente una base de datos con una serie de propiedades únicas. Los participantes de la red ejecutan un software especializado, que les permite sincronizar con sus pares la copia que poseen de la base de datos. Como resultado, la red en su conjunto es capaz de auditar el historial de transacciones, remontándose hasta el bloque génesis. El hecho de que la blockchain sea visible de una forma pública, hace que resulte sencillo detectar y prevenir actividades fraudulentas; tales como transacciones que intentan incurrir en un doble gasto.
Cuando un usuario difunde una transacción, no se agrega inmediatamente a la blockchain; primero debe incluirse en un bloque a través de la minería. Como tal, el destinatario solo debe considerar la transacción válida después de agregar su bloque a la cadena. De lo contrario, corren el riesgo de perder los fondos, ya que el remitente podría gastar las mismas monedas en otro lugar.
Una vez que se confirma la transacción, las monedas no se pueden gastar dos veces, ya que la propiedad se asigna a un nuevo usuario, y toda la red puede verificar esto. Es por esta razón que muchos recomiendan esperar múltiples confirmaciones antes de aceptar un pago como válido. Cada bloque posterior aumenta drásticamente la cantidad de esfuerzo requerido para modificar o reescribir la cadena; que puede ocurrir durante un ataque del 51%.
Ejemplo Práctico
Volvamos al escenario del restaurante. Dan regresa al restaurante, y esta vez nota una pegatina de Se acepta Bitcoin en la ventana. Disfrutó de la comida que tuvo la última vez, así que la vuelve a ordenar. Le cuesta 0.005 BTC. Erin le presenta una dirección pública a la que debe enviar los fondos. Dan transmite la transacción, que es esencialmente un mensaje firmado que indica que los 0.005 BTC que estaban en posesión de Dan ahora están en manos de Erin. Sin entrar en demasiados detalles, cualquier persona que se presente con la transacción firmada de Dan puede verificar que realmente poseía las monedas y, por lo tanto, tenía la autoridad para enviarlas.
Sin embargo, como se mencionó, la transacción sólo es válida si se incluye en un bloque que se confirma. Aceptar transacciones no confirmadas es muy similar a aceptar los $40 en eCash del ejemplo anterior, sin cobrarlos de inmediato con el banco: le permite al remitente gastarlos en otro lugar. Por lo tanto, se recomienda que Erin espere al menos 6 confirmaciones de bloque (aproximadamente una hora) antes de aceptar el pago de Dan.
El Doble Gasto en Bitcoin
Bitcoin está cuidadosamente diseñado para evitar ataques de doble gasto, al menos cuando el protocolo se usa como se espera. Es decir, si las personas esperan que las transacciones se confirmen en un bloque, no hay forma fácil de que el remitente las deshaga. Para hacerlo, tendrían que «revertir» la blockchain, lo que requiere una cantidad poco realista de poder de hashing.
Sin embargo, hay un montón de ataques de doble gasto que apuntan a partes que aceptan transacciones no confirmadas. Para compras de bajo valor, por ejemplo, un trader puede no querer esperar a que las transacciones se incluyan en un bloque. Un restaurante de comida rápida concurrido probablemente no puede permitirse el lujo de esperar mientras la red procesa cada compra. Por lo tanto, si una empresa permite pagos «instantáneos», se abren al doble gasto. Alguien puede pedir una hamburguesa, pagarla e inmediatamente enviar los mismos fondos a su propia dirección. Con una tarifa más alta, es probable que esta nueva transacción se confirme primero y, por lo tanto, invalidará la anterior.
Métodos Populares Para Realizar un Doble Gasto
- Ataque del 51%: cuando una sola entidad u organización logra controlar más del 50% de la tasa de hash, lo que les permite excluir o modificar el orden de las transacciones. Tal ataque es altamente improbable en Bitcoin, pero ha sucedido en otras redes.
- Ataques de carrera: dos transacciones en conflicto se transmiten sucesivamente, utilizando los mismos fondos, pero solo se confirma una transacción. El objetivo del atacante es invalidar el pago validando sólo la transacción que lo beneficia; por ejemplo, enviando los mismos fondos a una dirección que él controla. Los ataques de carrera requieren que el destinatario acepte una transacción no confirmada como pago.
- Ataques Finney: un atacante mina una transacción en un bloque sin transmitirla a la red de inmediato. En cambio, gasta las mismas monedas en otra transacción y solo luego transmite su bloque previamente minado, lo que puede invalidar el pago. Los ataques Finney requieren una secuencia específica de eventos y también dependen de la aceptación del destinatario de transacciones no confirmadas.
Como podemos ver, un comerciante que espera confirmaciones de bloque reducirá enormemente los riesgos de convertirse en víctima del doble gasto.
Conclusión
Un doble gasto le permite al usuario jugar un sistema de efectivo electrónico para obtener ganancias financieras, haciendo uso de los mismos fondos más de una vez. Tradicionalmente, la falta de soluciones adecuadas al problema ha obstaculizado el progreso en el área.
Afortunadamente, sin embargo, el uso de firmas ciegas propuso una solución interesante para esquemas financieros centralizados. Más tarde, la creación de mecanismos de Proof of Work y tecnología blockchain dio a luz a Bitcoin como una forma poderosa de dinero descentralizado, que, a su vez, inspiró a miles de otros proyectos de criptomonedas.
