La madriguera

El doble gasto: el problema que Bitcoin resolvió

Antes de Bitcoin, el dinero digital tenía un problema fatal. Satoshi lo solucionó sin necesidad de un banco.

Fecha de publicacion: Febrero 2026 · Tiempo de lectura: ~6 minutos

El dinero físico tiene una propiedad obvia que damos por sentada: si le das un billete a alguien, ya no lo tienes. No puedes gastar el mismo billete dos veces porque el billete es un objeto físico que solo puede estar en un lugar a la vez.

El dinero digital es diferente. El dinero digital es información. Y la información se puede copiar.

Si tu "billete digital" es simplemente un archivo, ¿qué impide que lo copies y lo gastes dos veces? ¿O mil veces?

Este es el problema del doble gasto, y fue el obstáculo central que impidió el dinero digital durante décadas. Satoshi lo resolvió, y esa solución es el corazón de Bitcoin.

El problema

Imagina el dinero digital más simple posible: un archivo que representa 10 euros. Alice tiene ese archivo. Quiere pagar a Bob.

Alice envía el archivo a Bob. Pero Alice puede haber guardado una copia. Ahora envía esa copia a Carol. Y otra copia a David.

Todos piensan que tienen 10 euros. Pero solo hay 10 euros reales en el sistema. Cuando intenten gastar su dinero, alguien se llevará una sorpresa desagradable.

Este es el doble gasto: usar el mismo dinero más de una vez.

La solución tradicional: intermediarios

Antes de Bitcoin, todas las soluciones al doble gasto requerían un intermediario de confianza.

En el sistema bancario, el banco lleva el registro de quién tiene qué. Cuando Alice envía dinero a Bob, el banco resta de la cuenta de Alice y suma a la de Bob. Alice no puede gastar el mismo dinero dos veces porque el banco verifica que tiene fondos suficientes antes de procesar cada transacción.

DigiCash, e-gold, PayPal — todos funcionaban igual. Un servidor central que mantiene el registro autoritativo de quién posee qué.

El problema es que el intermediario es un punto de fallo:

  • Puede ser hackeado (Mt. Gox)
  • Puede ser cerrado por el gobierno (Liberty Reserve, e-gold)
  • Puede congelar tu cuenta arbitrariamente (PayPal)
  • Puede quebrar (DigiCash)
  • Puede censurar transacciones (WikiLeaks, Silk Road)

Para tener dinero digital verdaderamente libre, necesitabas resolver el doble gasto sin intermediarios. Durante décadas, nadie supo cómo.

La solución de Satoshi

Satoshi describió el problema directamente en el whitepaper:

"El problema principal con la moneda electrónica es que alguien debe evitar el doble gasto. Tradicionalmente esto se resuelve teniendo una autoridad central de confianza que verifica cada transacción. El problema es que el destino de todo el sistema monetario depende de la empresa que lo gestiona."

Y propuso la solución:

"Proponemos una solución al problema del doble gasto usando una red peer-to-peer. La red marca cada transacción con una timestamp mediante el hash en una cadena continua de proof-of-work, formando un registro que no puede cambiarse sin rehacer el proof-of-work."

La idea clave: en lugar de que un servidor central decida qué transacciones son válidas, toda la red lo decide colectivamente. Y lo hace registrando las transacciones en un orden cronológico público e inmutable.

Si Alice intenta gastar el mismo bitcoin dos veces, las dos transacciones conflictivas llegarán a la red. Pero solo una puede incluirse en la blockchain. La que se incluya primero es la válida; la otra es rechazada automáticamente porque intenta gastar un output que ya no existe.

Cómo funciona en la práctica

Supongamos que Alice tiene 1 BTC y quiere hacer doble gasto. Crea dos transacciones:

  • TX1: envía 1 BTC a Bob
  • TX2: envía 1 BTC a Carol

Ambas transacciones son técnicamente válidas — ambas gastan el mismo UTXO (output no gastado) que Alice controla.

Alice envía TX1 a Bob y TX2 a Carol simultáneamente, esperando que ambos le den algo a cambio antes de que se den cuenta del conflicto.

Pero aquí está el problema de Alice:

Ambas transacciones se propagan por la red. Los nodos ven el conflicto. Cada nodo acepta la primera transacción que recibe y rechaza la segunda como "doble gasto".

Cuando un minero crea un bloque, incluye solo una de las dos transacciones (la que recibió primero o la que paga más fees). Una vez que ese bloque se confirma, la transacción incluida es permanente.

La transacción no incluida se vuelve permanentemente inválida — intenta gastar un UTXO que ya no existe.

Si Bob y Carol esperan al menos una confirmación antes de entregar lo que Alice quería, uno de ellos detectará que su transacción nunca se confirmó. Alice solo puede engañar a uno de los dos, y solo si ese uno acepta la transacción sin confirmaciones.

Las confirmaciones como defensa

Este es el origen de la recomendación de "esperar confirmaciones":

0 confirmaciones: la transacción está en la mempool pero no en ningún bloque. Un atacante con buena conectividad podría hacer doble gasto enviando una transacción conflictiva que llegue antes a los mineros.

1 confirmación: la transacción está en un bloque. Para revertirla, el atacante necesita que ese bloque se vuelva stale (reorganización de la cadena). Posible pero difícil.

6 confirmaciones: hay 6 bloques encima de la transacción. Para revertirla, el atacante necesita reorganizar 6 bloques. Extremadamente difícil sin una cantidad masiva de hashrate.

En el capítulo 15 del Libro de Satoshi ("Más Sobre Doble Gasto, Prueba de Trabajo y Comisiones de Transacción"), Satoshi discutió estos escenarios en detalle. Su posición era pragmática: para transacciones pequeñas, 0 confirmaciones es aceptable (el riesgo es bajo). Para cantidades significativas, esperar confirmaciones es prudente.

Vectores de ataque reales

El doble gasto no es solo teórico. Hay vectores de ataque específicos:

Race attack: el atacante envía dos transacciones conflictivas casi simultáneamente — una al comerciante, otra a la red general con fee más alta. Si el comerciante acepta sin confirmaciones, puede quedarse sin el pago.

Mitigación: esperar al menos una confirmación, o para pagos pequeños, verificar que la transacción se ha propagado bien por la red.

Finney attack: nombrado por Hal Finney, quien lo describió. El atacante es minero. Pre-mina un bloque con una transacción que se paga a sí mismo. Luego va a un comercio, paga con una transacción conflictiva, recibe el producto, y publica su bloque pre-minado (que invalida el pago al comercio).

Mitigación: esperar confirmaciones. El ataque solo funciona si el atacante publica su bloque antes de que otro minero encuentre uno.

Ataque del 51%: con mayoría del hashrate, un atacante puede minar una cadena secreta y publicarla después de haber hecho doble gasto. Ya cubierto en detalle en el artículo sobre el ataque del 51%.

RBF (Replace-By-Fee): técnicamente no es un "ataque" sino una feature del protocolo. Una transacción marcada como RBF puede ser reemplazada por otra con fee más alta antes de confirmarse. Los comerciantes que aceptan 0-conf deben verificar si la transacción tiene el flag RBF.

El estado actual

En los 16 años de historia de Bitcoin, no hay casos documentados de dobles gastos exitosos en transacciones con confirmaciones.

Los robos masivos de bitcoin (Mt. Gox, Bitfinex, etc.) no fueron dobles gastos — fueron robos de claves privadas. El protocolo de Bitcoin no fue vulnerado; lo que falló fue la seguridad de los custodios.

Esto es notable. Miles de millones de dólares en transacciones procesadas, ningún doble gasto con confirmaciones. El sistema funciona.

Lightning Network y el doble gasto

Lightning Network resuelve el problema de las confirmaciones para pagos pequeños.

En Lightning, los pagos son casi instantáneos porque no requieren confirmación en la blockchain. Pero Lightning tiene sus propios mecanismos anti-fraude: si alguien intenta publicar un estado antiguo de un canal (una forma de doble gasto), la contraparte puede publicar una "penalty transaction" que confisca todos los fondos del atacante.

Esto permite pagos rápidos sin sacrificar seguridad. Para pagos pequeños cotidianos, Lightning elimina la espera de confirmaciones que el doble gasto hacía necesaria.

Por qué importa entenderlo

El doble gasto puede parecer un problema técnico abstracto, pero entenderlo es fundamental para usar Bitcoin de forma segura:

Si eres comerciante, necesitas saber cuántas confirmaciones esperar según el valor de la transacción.

Si eres usuario, necesitas entender por qué tus transacciones tardan en "confirmarse" y por qué los exchanges te hacen esperar múltiples confirmaciones antes de acreditar tu depósito.

Si evalúas otras criptomonedas, necesitas entender que el mecanismo de consenso debe prevenir dobles gastos. Cadenas con menor hashrate o mecanismos de consenso menos probados son más vulnerables.

La solución al doble gasto es lo que hace que Bitcoin sea dinero real en lugar de solo información copiable. Es el breakthrough que permitió el dinero digital sin bancos.

Fuentes y referencias:

  • Whitepaper de Bitcoin, secciones 1, 2 y 11
  • El Libro de Satoshi, capítulos 12 y 15
  • "Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Payments in Bitcoin" (Karame et al., 2012)
  • Documentación de BIP 125 (Replace-By-Fee)

Enlaces internos: