Confirmación

Alice envía a un amigo 20 000 sat, las unidades más pequeñas de bitcoin. Su cartera muestra Enviado y el amigo ya ve el pago entrante, pero con cero confirmaciones. No hay contradicción: la noticia del pago se ha propagado entre nodos, los ordenadores que verifican Bitcoin, pero aún no está en un bloque. Mempool es el almacén local de transacciones pendientes de un nodo, no una cola única para toda la red. Cuando el pago entra en un bloque aceptado, obtiene su primera confirmación. El siguiente bloque le da la segunda y el próximo, la tercera. Alice no tiene que enviar nada otra vez. Difundir una transacción no la confirma, y su identificador txid tampoco lo garantiza. Una transacción sin confirmar puede ser sustituida, por ejemplo mediante Replace-by-Fee (RBF) para aumentar la comisión. Aceptar un pago sin confirmación se llama zero-conf y supone asumir que podría confirmarse otro gasto de los mismos fondos. [4] [8] [11]

Un minero elige transacciones para un nuevo bloque y busca un Proof of Work válido, el resultado de cálculos costosos exigido por las reglas de Bitcoin. Después, los demás nodos completos comprueban el bloque: ¿son correctas las firmas, los importes y las condiciones de gasto?, ¿siguen sin gastarse los fondos? No es una votación de mineros ni el sello de una empresa. Un minero no puede hacer válido un pago inválido incluyéndolo en un bloque. El nodo lo cuenta como confirmado solo en la cadena que acepta. Entre ramas válidas elige la de mayor trabajo acumulado, llamado chainwork. Cada bloque apunta al anterior, por lo que cambiar el pasado exige rehacer también su continuación. [2] [7]

Bitcoin busca un promedio de diez minutos entre bloques, no un horario. El siguiente bloque puede llegar en segundos o mucho más tarde. Esperar una hora no equivale por sí mismo a seis confirmaciones. Una tasa de comisión mayor puede aumentar la probabilidad de que el minero elija tu transacción, pero no acelera los bloques. Algunas carteras permiten RBF, sustituir una transacción pendiente por otra con mayor comisión, o CPFP (Child Pays for Parent): una transacción dependiente aporta suficientes comisiones para que resulte rentable incluirla junto con su antecesora. La disponibilidad depende de la cartera y la transacción. Una comisión baja puede causar una espera larga o la retirada de la transacción del Mempool de un nodo. Toma la estimación como una estimación, no como una fecha garantizada. [3] [4]

El destinatario o servicio decide cuántas confirmaciones exige para aceptar el pago. Una compra pequeña permite tolerar un riesgo distinto del de entregar un bien caro de forma irreversible. Si una plataforma espera varias confirmaciones, la transacción puede estar ya en la blockchain aunque el saldo de tu cuenta todavía no se haya abonado. Eso no significa necesariamente que haya un error. Comprueba importe, destino y estado en tu cartera, y los requisitos de ingreso del servicio. También importa la fuente de información. Un atacante puede aislar un nodo y mostrarle una visión limitada de la red: es un Eclipse Attack. La espera adecuada depende del valor, las posibles soluciones, la confianza en la otra parte y la forma de verificar. El número de confirmaciones por sí solo no protege de una clave robada. [11] [13]

Imagina el pago como un registro sobre el que se apilan nuevas páginas del historial. No basta con cambiar una página antigua: un atacante tendría que crear una continuación válida competidora con suficiente trabajo acumulado. Bajo los supuestos habituales, cada confirmación lo dificulta. Pero también influyen la capacidad de cómputo del atacante y el estado de la red. Las seis confirmaciones que suelen citarse son una referencia histórica, no una regla de consenso ni una frontera mágica de seguridad total. No existe una probabilidad fija de reescritura que represente honestamente todas las situaciones. Más confirmaciones tampoco corrigen una dirección equivocada ni un pago a un estafador. [1] [13]

Puede haber una bifurcación breve sin ataque cuando dos mineros encuentran un bloque casi a la vez. El paso del nodo a otra rama ganadora se llama reorganización. Una salida registra una cantidad y sus condiciones de gasto; una entrada de otra transacción hace referencia a ella y la gasta. Una salida no gastada se llama UTXO. Cuando una rama válida competidora acumula más trabajo, es decir, más chainwork, el nodo desconecta los últimos bloques de la cadena anterior y conecta la rama ganadora. Una transacción de un bloque desconectado puede volver al Mempool si sigue siendo válida, o confirmarse a otra altura. También puede entrar en conflicto si la nueva rama ha gastado la misma salida a la que apunta una de sus entradas. Un valor negativo de confirmations en Bitcoin Core es la forma en que la cartera expresa la profundidad del conflicto. No representa un número negativo de bloques en las reglas de consenso. [5] [7]

La altura de un bloque es su posición en la secuencia, contando desde el bloque inicial número cero. Si el bloque que contiene la transacción tiene altura h y el último bloque de la cadena activa del nodo tiene altura H, el número de confirmaciones es H − h + 1. El propio bloque de la transacción cuenta como el primero. El resultado depende del mejor bloque validado por ese nodo y puede diferir brevemente entre nodos cuando llegan nuevos bloques. No forma parte de la transacción, no aumenta por el mero paso del tiempo y no se puede deducir de manera fiable de una marca temporal. Bitcoin Core devuelve datos como blockhash, blockheight y confirmations según el estado que conoce la cartera correspondiente o su vista de los UTXO. [3] [5] [6]

SPV significa verificación simplificada de pagos, mientras que RPC es una interfaz de programación para consultar un nodo. La diferencia entre métodos importa aunque dos aplicaciones muestren el mismo número. Un nodo completo valida la cadena y responde según el extremo actual de su propia cadena validada. Un cliente SPV comprueba el Proof of Work de las cabeceras y la prueba de inclusión de Merkle de la transacción, pero no verifica por sí mismo todas las reglas de consenso. Una prueba de Merkle usa un pequeño conjunto de huellas criptográficas para demostrar que una transacción está incluida en un bloque, sin descargar todas sus transacciones. Un servicio que custodia los fondos del usuario aplica además sus propias reglas para abonar los pagos y gestionar el riesgo. Incluso una respuesta RPC de un nodo completo refleja el estado en un instante concreto, que una reorganización puede cambiar. Por eso, además del número de confirmaciones, importa en quién confía el usuario para conocer la cadena, verificarla y custodiar sus fondos. [1] [2] [8]

Coinbase Transaction es la primera transacción especial de un bloque y paga la recompensa al minero; no está relacionada con la plataforma Coinbase. Un bloqueo temporal limita cuándo se pueden gastar los fondos. BIP identifica una propuesta técnica o un estándar. La confirmación también pone en marcha ciertos plazos del protocolo. Una salida de una transacción coinbase está sujeta a COINBASE_MATURITY = 100: no se puede gastar antes de un bloque cuya altura sea 100 superior a la del bloque de esa transacción coinbase. Es un periodo de espera obligatorio antes de gastar la recompensa del bloque, no una elección del destinatario de un pago corriente. Los bloqueos temporales relativos de BIP68 se calculan a partir de la confirmación de la salida que se quiere gastar y evalúan su antigüedad según reglas basadas en bloques o en tiempo. Un script es un pequeño programa que define las condiciones para gastar una salida. La instrucción CHECKSEQUENCEVERIFY (CSV), definida en BIP112, permite exigir esa condición relativa en un script. Una transacción que gasta una salida sin confirmar sigue dependiendo de la transacción que la creó. Para que la transacción dependiente se confirme, sus antecesoras deben estar incluidas en el mismo bloque o en uno anterior. [9] [10]

Lightning Network permite pagos por canales financiados mediante transacciones de Bitcoin. BOLT denomina sus especificaciones técnicas; aquí hablamos de abrir un canal, no de esperar un bloque en cada pago dentro de él. BOLT 2 permite a la parte que acepta un canal Lightning especificar en el campo minimum_depth el número de confirmaciones que exige a la transacción de financiación antes de enviar el mensaje channel_ready. Este requisito tiene en cuenta el riesgo de un doble gasto de la financiación. Un canal abierto sin confirmaciones, o zero-conf channel, fija minimum_depth en cero y se apoya deliberadamente en la confianza en quien aporta los fondos y en las restricciones del protocolo. Eso no le da una liquidación instantánea e irreversible. Si la propia transacción de financiación es una transacción coinbase, BOLT 2 obliga a la parte que no abre el canal a esperar al menos 100 bloques. El operador debe vigilar la salida concreta que financia el canal —el funding outpoint—, su profundidad en la cadena activa y las reorganizaciones. Haber difundido un txid no significa todavía que el canal esté abierto. [12] [14]