¿Qué es el doble gasto?

El doble gasto es un problema potencial en un sistema de efectivo digital donde se envían los mismos fondos a dos destinatarios al mismo tiempo. Sin contramedidas adecuadas, un protocolo que no resuelva el problema queda fundamentalmente debilitado: los usuarios no tienen forma de verificar que los fondos que han recibido no se han gastado ya en otra parte.

Cuando se trata de efectivo digital, garantizar que unidades específicas no se puedan duplicar es de suma importancia. Todo el sistema se vería socavado si Alice pudiera recibir 10 unidades, copiarlas y pegarlas 10 veces y encontrarse en posesión de 100 unidades. De manera similar, tal plan no puede funcionar si puede enviar las mismas 10 unidades a Bob y Carol simultáneamente. Entonces, para que el dinero digital funcione, deben existir mecanismos para prevenir este comportamiento.


¿Cómo se puede prevenir el doble gasto?

El enfoque centralizado

La ruta centralizada es considerablemente más fácil de implementar que las alternativas descentralizadas. Por lo general, esto implica que un supervisor administre el sistema y controle la emisión y distribución de unidades. Un buen ejemplo de una solución centralizada al problema del doble gasto es el eCash de David Chaum.

Para emitir a los usuarios un activo digital que imita el efectivo (capaz de intercambio anónimo y entre pares), un banco puede utilizar firmas ciegas, como detalla el criptógrafo David Chaum en su artículo de 1982 Firmas ciegas para pagos untraceables.

En tal contexto, si un usuario (llamémoslo Dan) desea recibir $100 en efectivo digital, primero debe informar al banco. Siempre que tenga saldo en su cuenta, generará un número aleatorio (o muchos, para denominaciones más pequeñas). Supongamos que produce cinco números, a cada uno de los cuales se le asigna un valor de 20 dólares. Para evitar que el banco rastree unidades específicas, Dan confunde los números aleatorios agregando un factor ciego a cada uno de ellos.

Luego entrega estos datos al banco, que carga en su cuenta 100 dólares y firma mensajes que certifican que cada uno de los cinco datos se puede canjear por 20 dólares. Dan ahora puede gastar los fondos emitidos por el banco. Va al restaurante de Erin y compra una comida que le cuesta $40.

Dan puede eliminar el factor ciego para exponer el número aleatorio asociado con cada "billete" de efectivo digital, que sirve como un identificador único para cada unidad (muy parecido a un número de serie). Le revela dos de estos a Erin, quien ahora debe canjearlos inmediatamente en el banco para evitar que Dan los gaste con otro comerciante. El banco comprobará que las firmas sean válidas y, si todo parece correcto, acreditará 40 dólares en la cuenta de Erin.

Los billetes utilizados ahora están esencialmente quemados y se deben emitir más si Erin desea gastar su nuevo saldo de la misma manera.

La configuración de Chaumian eCash puede resultar valiosa para transferencias privadas. Pero falla en resiliencia porque el banco es un punto central de falla. Un billete emitido no vale nada en sí mismo, ya que su valor se deriva únicamente de la voluntad del banco de cambiarlo por dólares. Los clientes están a merced del banco y deben confiar en su buena voluntad para que el dinero funcione. Este es precisamente el problema que las criptomonedas pretenden remediar.


El enfoque descentralizado

Garantizar que los fondos no se puedan gastar dos veces en un ecosistema sin supervisor es más desafiante. Los participantes igualmente poderosos deben coordinarse en torno a un conjunto de reglas que prevengan el fraude e incentiven a todos los usuarios a actuar con honestidad.

La mayor innovación presentada en el libro blanco de Bitcoin fue una solución al problema del doble gasto. Aunque no se menciona como tal, Satoshi propuso la estructura de datos ahora ampliamente conocida como blockchain.

Una cadena de bloques es en realidad sólo una base de datos con algunas propiedades únicas. Los participantes de la red (denominados nodos) ejecutan software especializado que les permite sincronizar su copia de la base de datos con sus pares. El resultado es que toda la red puede auditar el historial de transacciones que se remonta al bloque génesis. Al hacer que la cadena de bloques sea visible públicamente, es fácil detectar y prevenir actividades fraudulentas, como transacciones que intentan duplicar el gasto.

Cuando un usuario transmite una transacción, no se agrega inmediatamente a la cadena de bloques; primero debe incluirse en un bloque mediante minería. Como tal, el destinatario sólo debe considerar válida la transacción después de que su bloque se agregue 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 confirmada 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 ello 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 necesario para modificar o reescribir la cadena (lo que puede ocurrir durante un ataque del 51%).

Revisemos el escenario del restaurante. Dan regresa al restaurante y esta vez nota una pegatina de Bitcoin aceptado aquí en la ventana. Disfrutó la comida que comió la última vez, así que la pide nuevamente. 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 posesión de Erin. Sin entrar en demasiados detalles, cualquiera a quien se le presente la transacción firmada por Dan puede verificar que efectivamente estaba en posesión de las monedas y, por lo tanto, tenía la autoridad para enviarlas.

Sin embargo, como se mencionó, la transacción solo es válida si se incluye en un bloque que se confirma. Aceptar transacciones no confirmadas es muy parecido a aceptar los 40 dólares en eCash del ejemplo anterior, sin cobrarlos inmediatamente en el banco: 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.


Doble gasto en Bitcoin

Bitcoin está cuidadosamente diseñado para evitar ataques de doble gasto, al menos cuando el protocolo se utiliza como se espera. Es decir, si las personas esperan que se confirmen las transacciones en un bloque, el remitente no tiene una manera fácil de deshacerlas. Para hacerlo, necesitarían "revertir" la cadena de bloques, lo que requiere una cantidad poco realista de poder de hashing.

Sin embargo, hay un puñado de ataques de doble gasto dirigidos a partes que aceptan transacciones no confirmadas. Para compras de bajo valor, por ejemplo, es posible que un comerciante no quiera esperar a que las transacciones se incluyan en un bloque. Un restaurante de comida rápida concurrido probablemente no pueda darse el lujo de quedarse impasible mientras la red procesa cada compra. Entonces, si una empresa permite pagos “instantáneos”, se expone a gastos dobles. Alguien podría pedir una hamburguesa, pagarla y luego enviar inmediatamente 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.

Existen tres métodos populares para realizar un doble gasto:

  • Ataques del 51%: cuando una sola entidad u organización logra controlar más del 50% del hash rate, lo que le permite excluir o modificar el orden de las transacciones. Un ataque de este tipo es muy poco probable en Bitcoin, pero ha ocurrido en otras redes.

  • Ataques raciales: dos transacciones conflictivas se transmiten sucesivamente, utilizando los mismos fondos, pero solo se confirma una transacción. El objetivo del atacante es invalidar el pago validando únicamente la transacción que lo beneficia (por ejemplo, enviando los mismos fondos a una dirección que él controla). Los ataques raciales requieren que el destinatario acepte una transacción no confirmada como pago.

  • Ataques de Finney: un atacante extrae previamente una transacción en un bloque sin transmitirla a la red inmediatamente. En cambio, gasta las mismas monedas en otra transacción y sólo entonces transmite su bloque previamente minado, lo que puede invalidar el pago. Los ataques de Finney requieren que ocurra una secuencia específica de eventos y también dependen de la aceptación por parte 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 de doble gasto.


Pensamientos finales

Un doble gasto permite a un usuario jugar con un sistema de efectivo electrónico para obtener ganancias financieras, utilizando 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 los esquemas financieros centralizados. Más tarde, la creación de mecanismos de prueba de trabajo y la tecnología blockchain dieron origen a Bitcoin como una poderosa forma de dinero descentralizado, que, a su vez, inspiró miles de otros proyectos de criptomonedas.