El conflicto se puede observar incluso antes del acuerdo, pero un doble gasto exitoso ocurre sólo cuando la víctima gasta valor en una transacción y la otra gana en la cadena recibida. Por lo tanto, un pago de billetera reemplazado, un aumento de tarifa involuntario o un conflicto fallido no son automáticamente fraude. La carrera de configuración cero y la sobrescritura de bloques comprometidos tienen costos y riesgos fundamentalmente diferentes.
Cada entrada hace referencia a la salida anterior mediante un txid y un índice. Dos transacciones están en conflicto cuando al menos un insumo se refiere al mismo punto de salida no gastado, pero no pueden pagar al mismo tiempo. Al validar un bloque, el nodo verifica que la entrada exista y que no se haya gastado anteriormente en el historial dado o en otro lugar del mismo bloque. Sólo una rama sobrevive en un conjunto UTXO válido; el ataque no produce una copia del satoshi, intenta hacer que el destinatario actúe en la rama que pierde. [Documento técnico de Bitcoin: transacciones, servidor de marca de tiempo y cálculos] [Guía para desarrolladores de Bitcoin: transacciones] [Bitcoin Core: validation.cpp]
No existe un mempool global ni un orden de consenso de transacciones no comprometidas antes de la minería. Los pares pueden ver primero varios conflictos debido a la promoción, la topología, la política de tarifas, el estado del paquete o el aislamiento del eclipse. Lo primero que se ve es una política de retransmisión, no una obligación de los mineros de confirmar la primera opción. Un txid en el backend del comerciante solo prueba que ha llegado un candidato firmado, no que toda la red lo haya visto o haya ganado un bloque. [Guía para desarrolladores de Bitcoin: procesamiento de pagos] [Bitcoin Core: reemplazos de Mempool]
Reemplazar por tarifa permite que un nodo reemplace los conflictos de mempool que cumplan con las reglas de tarifa y anti-DoS; full-RBF ha sido la política predeterminada en Bitcoin Core desde la versión 28. El remitente puede aumentar legítimamente la tarifa por pago atascado y preservar la salida del destinatario, o redirigir el valor. En ambos casos, el consenso ve candidatos comunes y acepta la variante en el historial minado válido. Una señal, un reemplazo o un aumento de RBF por sí solos no prueba fraude; una transacción sin señal nuevamente no es segura para zero-conf. [Bitcoin Core - Reemplazos de Mempool] [BIP 125 - Opción de reemplazo completo por tarifa]
En un ataque racial, el pagador envía una transacción al comerciante y el conflicto a los mineros u otros pares, de modo que el comerciante emite bienes no retornables antes de que el bloque seleccione una opción. El resultado depende de la promoción, la visión de la red del comerciante, la elección de los mineros y el tiempo de transferencia. Más oyentes independientes mejorarán la detección, pero no crearán una finalidad determinista. Los nombres race, Finney y Vector76 son modelos de escenarios, no matrices de transacciones ni varias reglas de consenso. [Guía para desarrolladores de Bitcoin: procesamiento de pagos] [Karam et al. - Mal comportamiento en Bitcoin]
Un atacante al estilo Finney con la capacidad de minar primero de forma privada encuentra el bloque que contiene el conflicto y le devuelve el valor, luego le paga al comerciante zero-conf con el mismo UTXO y publica el bloque oculto después de recibir los bienes. El plan sólo tiene éxito si el bloque sigue siendo utilizable y es aceptado por la red antes de que un bloque rival honesto frustre la preparación; el atacante arriesga tanto la recompensa del bloque como los costos de extracción. Esperar a que la transacción del comerciante se incluya en el bloque verificado finaliza la secuencia clásica, pero no elimina el riesgo de reorganización posterior. [Documento técnico de Bitcoin: transacciones, servidor de marca de tiempo y cálculos] [Karame et al. - Mal comportamiento en Bitcoin]
Una vez confirmado, el conflicto ya no puede simplemente sacar el pago del mempool: la rama alternativa válida debe omitir el pago, incluir el segundo gasto y obtener más cadena que la cadena activa del destinatario. Una reorganización puede ocurrir incluso sin fraude en bloques casi simultáneos o un incidente de software o de red; un doble gasto exitoso contra la víctima sólo sirve para ganar valor ganando el conflicto. Bitcoin Core puede mostrar confirmaciones negativas y conflictos de billetera por una transacción de billetera perdida. [Bitcoin Core - Validación] [Bitcoin Core - validation.cpp] [Bitcoin Core RPC - gettransaction]
La proporción de hashrate del atacante, la profundidad de confirmación y el valor obtenible determinan la carrera estocástica del trabajo privado y honesto. Por debajo del 50% no significa cero posibilidades; La mayoría permanente aumenta significativamente la posibilidad de ponerse al día, pero no permite a los mineros falsificar firmas, gastar UTXO extranjeros, exceder la emisión o forzar a nodos completos a aceptar un bloque no válido. Los costos incluyen poder de hash, energía, recompensas honestas perdidas, riesgo de pérdida, liquidez y exposición; Los ingresos también pueden incluir posiciones en el mercado, por lo que el mero precio del alquiler de máquinas no es suficiente. [Documento técnico de Bitcoin: transacciones, servidor de marca de tiempo y cálculos] [Rosenfeld: análisis del doble gasto basado en Hashrate] [Garay, Kiayias y Leonardos: el protocolo troncal de Bitcoin]
Cada confirmación adicional obliga a la rama alternativa a rehacer una mayor parte del trabajo pendiente y, dadas las suposiciones, reduce la probabilidad de éxito. No existe un número seguro universal: el café, el automóvil, el depósito en bolsa y el retiro no reembolsable presentan diferentes valores, motivaciones y posibilidades de corrección. Las seis afirmaciones tan citadas son una convención, no un consenso. La política también debe monitorear la distribución del hashrate, las reorganizaciones inusuales, la confianza en el backend, el riesgo de eclipse y la reversibilidad de los traspasos. [Guía para desarrolladores de Bitcoin: procesamiento de pagos] [Rosenfeld: análisis del doble gasto basado en Hashrate]
El backend puede monitorear los gastos conflictivos de mempool en su propio nodo completo, llamar a gettxspendingprevout, leer conflictos de billetera, comparar sugerencias activas y advertir sobre la pérdida de confirmación. Más pares o nodos independientes reducen los puntos ciegos, pero la ausencia de un conflicto detectado es una evidencia débil: un atacante puede interceptarlo o enviarlo a otra parte. Explorer muestra una vista de nodo personalizada y puede retrasarse. La detección permite detener la dosificación; no puede decirles a los mineros que ganen o convertir la configuración cero en confirmación. [Bitcoin Core RPC - gettransaction] [Bitcoin Core RPC - gettxspendingprevout] [Karame et al. - Mal comportamiento en Bitcoin]
Para la liquidación en cadena, valide con su propio nodo completo, vincule la orden con el txid, las salidas y el monto exactos, establezca la profundidad de acuerdo con la posible pérdida, en caso de una reorganización o conflicto, detenga el cumplimiento y separe el saldo acreditado del monto retirable. No trate a un descendiente de cambio no confirmado como independiente del padre. Lightning maneja los pagos recurrentes rápidos de manera diferente: un punto de salida de financiamiento confirmado ancla el canal y las reglas de compromiso/revocación controlan el estado fuera de la cadena; El canal zero-conf confía conscientemente en el financiador y no elimina el riesgo de doble gasto de financiación. [BOLT 2 - Protocolo de pares] [Bitcoin Optech - Canales de configuración cero]
Para obtener la imagen más completa, lee esta entrada junto con Transacción, Confirmación, Mempool, Proof of Work, Replace-by-Fee (RBF), Bitcoin. También enlazan con esta entrada Confirmación, Replace-by-Fee (RBF), Problema de los generales bizantinos, Ataque de eclipse.