El recuento de confirmaciones es un estado derivado, no un campo almacenado en la transacción. Si una transacción se encuentra en un bloque de altura h y la punta de la cadena activa es H, su profundidad es H − h + 1. Una transacción en el mempool tiene cero confirmaciones; Bitcoin Core puede mostrar un valor negativo para una transacción de billetera en conflicto, lo que indica la profundidad del conflicto.
El envío no es confirmación. Cada nodo aplica de forma independiente la política de admisión a su mempool, y diferentes nodos pueden ver un conjunto diferente debido al tiempo, tarifas, conflictos, límites de paquetes o configuraciones. RBF puede reemplazar una transacción no confirmada y el pago visto por el comerciante puede desaparecer sin entrar en el bloque. Por lo tanto, la configuración cero cambia la velocidad por el riesgo de doble gasto y una vista de red incompleta; Ni el txid ni la página del explorador son asentamientos. [Guía para desarrolladores de Bitcoin: Transacciones] [Bitcoin Core: coherencia JSON-RPC] [BIP 125: opción de reemplazo completo por tarifa]
Un minero puede seleccionar una transacción en un bloque candidato, pero la primera confirmación ocurre solo cuando el nodo de validación acepta el bloque y el bloque se encuentra en su cadena activa con la cadena más grande. El nodo completo verifica pruebas de trabajo, guiones, existencia y no gasto de insumos, montos y otras reglas de consenso; un minero no puede canjear un gasto no válido simplemente al incluirlo en la lista. La raíz de Merkle confirma la transacción en el bloque y una referencia al bloque anterior la coloca en la prueba del historial de trabajo. [Bitcoin Core - Validación] [Bitcoin Core - validation.cpp]
Si el bloque de transacciones está a la altura h y la punta actual del nodo es H, el recuento es H − h + 1: el bloque en sí se cuenta primero. El valor se genera contra el bloque mejor verificado de ese nodo, por lo que la sugerencia puede variar ligeramente entre nodos. No está escrito en una transacción, no crece con el tiempo y no puede determinarse de manera confiable a partir de una marca de tiempo. Bitcoin Core devuelve blockhash, blockheight y confirmaciones como el estado de la billetera o vista UTXO. [Guía para desarrolladores de Bitcoin: cadena de bloques] [Bitcoin Core RPC: gettransaction] [Bitcoin Core RPC: getbestblockhash]
Si una rama válida competidora obtiene más cadena, el nodo separará los bloques de la punta anterior y unirá la rama ganadora. Una transacción de un bloque separado puede regresar al mempool si sigue siendo válida, confirmarse a una altura diferente o entrar en conflicto porque una nueva rama ha gastado la misma entrada. Las confirmaciones negativas en Bitcoin Core son una convención de billetera para la profundidad del conflicto, no bloques negativos en consenso. [Bitcoin Core RPC - gettransaction] [Bitcoin Core - validation.cpp]
Las confirmaciones adicionales agregan prueba de trabajo para una transacción, lo que generalmente la hace más costosa y es poco probable que se reescriba el historial. No crean una finalidad determinista. Tanto el cálculo de puesta al día del documento técnico como los modelos posteriores dependen de la proporción de hashrate del atacante, el comportamiento de la red honesta y las observaciones del receptor. Las "Seis Confirmaciones" son un recurso histórico, no una constante de consenso ni un límite seguro universal; En principio, todavía es posible una reorganización profunda. [Documento técnico de Bitcoin: prueba de trabajo y cálculos] [Rosenfeld: análisis del doble gasto basado en Hashrate]
El recuento lo requiere el destinatario, el intercambio o el protocolo descendente, no la transacción en sí. El café, la emisión no retornable de bienes caros, el depósito en bolsa y la apertura de canales tienen diferentes ratios de pérdida y espera. La política debe tener en cuenta el valor, la reversibilidad del rendimiento, la motivación y el hashrate del atacante, los conflictos o RBF, la custodia y el backend, el riesgo de eclipse y el estado inusual de la cadena. La confirmación mitiga el riesgo de sobrescribir la cadena; no reparará una clave robada, una dirección incorrecta o un fraude de contraparte. [BIP 125 - Opción de reemplazo completo por tarifa] [Rosenfeld - Análisis del doble gasto basado en Hashrate]
Bitcoin apunta a un promedio de alrededor de diez minutos entre bloques, pero las llegadas de prueba de trabajo son aleatorias: el siguiente bloque puede llegar en segundos u horas. Una tarifa más alta puede mejorar el orden de selección de mineros y la economía del paquete RBF o CPFP, pero ninguna tarifa compra un tiempo fijo y no acelera la creación de bloques. Una transacción barata puede esperar muchos bloques o ser eliminada del mempool; una estimación es una probabilidad, no una fecha límite. [Guía para desarrolladores de Bitcoin: cadena de bloques] [Guía para desarrolladores de Bitcoin: transacciones]
El nodo completo valida la cadena y responde según su propia sugerencia activa. El cliente SPV verifica la prueba de trabajo en los encabezados y la inclusión de pruebas de Merkle, pero no ejecuta todas las reglas de consenso por sí mismo; El servicio de custodia también añade su propia política de crédito y riesgo. Incluso el resultado RPC de un nodo completo es una instantánea que se puede cambiar mediante reorganización. Así que la pregunta no es sólo "cuántas confirmaciones", sino también en qué vista de cadena, validación y custodia confía el usuario. [Documento técnico de Bitcoin: prueba de trabajo y cálculos] [Bitcoin Core: validación] [Bitcoin Core: consistencia JSON-RPC]
Otras clases también comienzan con la confirmación. La salida de Coinbase está sujeta a COINBASE_MATURITY = 100 y solo se puede gastar después de 100 bloques nuevos; esta es una regla diferente a la política de pago regular. Los bloqueos de tiempo relativos BIP68, aplicados por el script BIP112 CHECKSEQUENCEVERIFY (CSV), miden la antigüedad del bloque de confirmación de salida. Un padre no confirmado mantiene a los descendientes dependientes; para que un niño sea afirmado, sus antepasados deben estar en el mismo bloque o en uno anterior. [Bitcoin Core - consenso.h] [BIP 112 - CHECKSEQUENCEVERIFY]
BOLT 2 permite que un receptor de canal Lightning elija transacciones de financiación de profundidad mínima antes de que esté listo el canal; la cifra valora la financiación de riesgo de doble gasto. Un canal de configuración cero establece la profundidad mínima en cero y se basa conscientemente en la confianza del fondo y las restricciones del protocolo en lugar de la finalidad inmediata. La financiación de Coinbase está pendiente de matriculación. El operador debe monitorear el punto de financiación, la profundidad de la cadena activa y las reorganizaciones, no considerar el txid enviado como un canal abierto. [BOLT 2 - Protocolo de pares] [Bitcoin Optech - Canales de configuración cero]
Para obtener la imagen más completa, lee esta entrada junto con Bloque, Transacción, Reorganización de cadena, Doble gasto, Proof of Work, Bitcoin. También enlazan con esta entrada Doble gasto, Transacción coinbase, Reorganización de cadena, Riesgo de liquidación.