Doble gasto

Imaginemos que Tomás tiene una salida recibida anteriormente de 100 000 sat, las unidades más pequeñas de bitcoin. Una salida todavía sin gastar se llama UTXO. Prepara un pago de 99 000 sat a Alicia y deja 1 000 sat de comisión. Sin embargo, también podría firmar otra transacción que gastara ese mismo UTXO y enviara el dinero a otro destino. Las dos usan la misma fuente de fondos y, por eso, entran en conflicto. No es como copiar un archivo: un nodo de Bitcoin, el ordenador que verifica las reglas, no permite gastar dos veces la misma salida en una cadena válida. El fraude tendría éxito si Alicia entregara el producto por el primer pago, pero el historial aceptado acabara incluyendo el segundo. No se han creado monedas; Alicia confió en la versión perdedora. Técnicamente, cada entrada identifica una salida anterior mediante el identificador de su transacción, txid, y el número de salida. Esa pareja se llama outpoint. [1] [3] [7]

Alicia puede ver el pago entrante en pocos segundos. Eso no significa que ya esté registrado en un bloque. El Mempool es el conjunto local de transacciones sin confirmar de un nodo; no existe un Mempool global ni un orden de llegada común a toda la red. Otro nodo podría haber recibido primero la versión incompatible o no haber visto todavía la de Alicia. La política first-seen da preferencia a la primera versión recibida al retransmitir transacciones. No promete que un minero vaya a incluirla en un bloque. Una captura de pantalla de la cartera o un txid, por sí solos, no demuestran que el pago esté liquidado. Importa el estado de ese pago concreto en una cadena verificada de forma fiable. [2] [5]

También puede ser Alicia quien envíe un pago legítimo que lleva mucho tiempo esperando. Replace-by-Fee (RBF) permite sustituir una transacción sin confirmar, normalmente por otra con una comisión mayor. El destinatario puede recibir el mismo importe aunque cambie el txid. La sustituta utiliza parte de los mismos fondos, por lo que técnicamente entra en conflicto con la original, sin que nadie intente engañar al destinatario. Importan el contenido del nuevo pago y las circunstancias, no la etiqueta RBF. Ese mismo mecanismo también permite redirigir los fondos. Full-RBF es la política predeterminada de Bitcoin Core desde la versión 28 y no exige que la transacción original señale que admite sustituciones. La sustituta debe seguir cumpliendo las reglas del nodo sobre comisiones y protección frente a abusos. Por tanto, la ausencia de esa señal tampoco vuelve irreversible un pago sin confirmar. [5] [6] [15]

Un pago obtiene una confirmación cuando entra en un bloque válido aceptado por el nodo. Los bloques posteriores suelen dificultar la sustitución de ese historial y reducir el riesgo de fraude. No hay, sin embargo, un número seguro para todas las situaciones. Perder el precio de un café no es lo mismo que entregar un coche o autorizar una gran retirada de un exchange. Las seis confirmaciones que se citan a menudo son una costumbre, no una regla de Bitcoin. Conviene valorar el importe, las posibilidades de reclamar, las anomalías de la cadena y la calidad de la información. Aislar un nodo, mediante un Eclipse Attack, puede distorsionar su visión de la red. Esperar debe acompañar a la verificación, no sustituirla. [2] [10]

El cambio de un nodo a otra rama válida se llama reorganización. Proof of Work acredita el trabajo necesario para producir bloques; el trabajo acumulado de una rama se llama chainwork. Una vez confirmado el pago, la transacción incompatible ya no puede limitarse a expulsarlo del Mempool. Una rama alternativa válida debe omitir el pago original, incluir el otro gasto y acumular más trabajo, o chainwork, que la cadena activa del receptor. Una reorganización también puede ocurrir sin fraude, por ejemplo cuando se minan bloques casi al mismo tiempo o se produce un fallo de software o de red. Solo existe un doble gasto exitoso contra la víctima cuando el atacante obtiene valor gracias a que prevalece la transacción incompatible. Para la transacción perdedora de la cartera, Bitcoin Core puede mostrar un número negativo de confirmaciones en el campo confirmations y los conflictos relacionados en walletconflicts. [4] [7] [8]

Hashrate es la velocidad de cálculo de la minería. Una mayor proporción ayuda en la competición por el historial, pero no exime de las demás reglas. La probabilidad de que una rama minada en privado alcance a la cadena honesta depende, entre otras cosas, de la proporción de potencia de cálculo que controla el atacante y del número de confirmaciones. El valor que podría obtener influye sobre todo en si le compensa realizar el ataque. Estar por debajo del 50 % no significa que la probabilidad sea nula; mantener una mayoría aumenta considerablemente las posibilidades de alcanzar a la otra rama. Ni siquiera esa mayoría permite a los mineros falsificar firmas, gastar UTXO ajenos, infringir las reglas de emisión u obligar a los nodos completos a aceptar un bloque inválido. Al evaluar un ataque hay que considerar la potencia de cálculo, la energía y las recompensas que se dejan de ganar por no minar honestamente. También importan el capital disponible, el riesgo de fracaso y la posibilidad de ser descubierto. El beneficio también puede incluir ganancias de posiciones en los mercados financieros, por lo que el precio de alquilar equipos de minería no basta para estimarlo. [1] [10] [12]

Race se refiere aquí a una carrera de tiempos: el destinatario y los mineros pueden ver primero transacciones diferentes. En un race attack, el pagador envía una transacción al comercio y otra incompatible a los mineros o a otros nodos. Intenta que el comercio entregue la mercancía de forma irreversible antes de que un bloque seleccione una de las variantes. El resultado depende de la propagación, de la perspectiva que tenga el comercio sobre la red, de la selección de los mineros y del momento de la entrega. Disponer de varios nodos independientes que observen la red mejora la detección de conflictos, pero no garantiza una liquidación irreversible. Los nombres race, Finney y Vector76 describen escenarios de ataque, no campos de datos de una transacción ni reglas de consenso diferentes. [2] [11]

Finney attack designa un escenario en el que el atacante controla también capacidad de minería. No es la subida normal de comisión de una cartera. En un Finney attack, un atacante capaz de minar obtiene primero, en privado, un bloque con una transacción incompatible que le devuelve los fondos. Después utiliza el mismo UTXO para pagar a un comercio que acepta pagos sin confirmar y publica el bloque oculto tras recibir la mercancía. El plan solo tiene éxito si el bloque sigue siendo utilizable y la red lo acepta antes de que un bloque competidor honesto frustre la preparación. El atacante arriesga tanto la recompensa del bloque como los costes de minado. Esperar a que la transacción del comercio entre en un bloque validado interrumpe esta secuencia clásica, aunque no elimina el riesgo de una reorganización posterior de la cadena. [1] [11]

RPC es la interfaz de programación del nodo. Los nombres siguientes son órdenes y campos para desarrollar un sistema de pagos, no otro tipo de confirmación. El sistema del comercio puede vigilar los gastos incompatibles en el Mempool de su propio nodo completo, llamar a gettxspendingprevout, leer el campo walletconflicts, comparar el último bloque de la cadena activa y avisar de la pérdida de confirmaciones. Tener más nodos conectados o independientes reduce los puntos ciegos, pero no detectar un conflicto aporta poca garantía de seguridad: el atacante puede retener la transacción incompatible o enviarla por otra vía. Un explorador de bloques muestra la perspectiva de su propio nodo y puede llevar retraso. Detectar el conflicto permite detener la entrega de mercancía. No permite ordenar a los mineros qué transacción deben elegir ni convertir un pago sin confirmar en el equivalente de uno confirmado. [8] [9] [11]

Compruebe el pago realmente recibido, su destino, importe y confirmaciones. El justificante del remitente no sustituye esa comprobación. Un nodo completo propio permite verificar las reglas directamente; si utiliza un servicio ajeno, entienda de quién dependen la información y la custodia. El sistema de un comercio debe vincular cada pedido a salidas concretas y seguir también las sustituciones. Ante un conflicto o la pérdida de confirmaciones, debe detener una entrega irreversible. Un pago posterior que gasta cambio sin confirmar depende de la primera transacción: no demuestra de forma independiente que esta sea segura. Lightning Network permite pagos rápidos mediante canales financiados con una transacción de Bitcoin. Los participantes intercambian transacciones commitment firmadas que reflejan el reparto de los fondos. Al actualizar el canal, entregan a la otra parte datos secretos que permiten penalizarlos si publican después un estado obsoleto; esta invalidación del estado anterior se llama revocation. La protección exige detectar el intento y reaccionar a tiempo. Es un mecanismo distinto de entregar mercancía por un pago sin confirmar en la cadena. Un canal abierto sin confirmación, o zero-conf channel, confía deliberadamente en quien lo financia y conserva el riesgo de doble gasto de esa financiación. [13] [14]