Finality es el carácter definitivo de la liquidación: hasta qué punto podemos confiar en que una transferencia completada se mantendrá. Bitcoin ofrece una seguridad probabilística que crece con el trabajo válido posterior. Ningún número universal de confirmaciones descarta por sí solo un cambio de rama ni determina el cumplimiento jurídico de un acuerdo completo.
Al principio, Pablo solo ve que su monedero ha conocido la transacción. Eso no equivale a que esté incluida en un bloque. Cuando aparece ese bloque y se añaden otros encima, sustituir ese historial exige superar cada vez más trabajo. Así aumenta la Finality en la práctica. También importan los recursos de un posible atacante y el estado de la red. El protocolo no emite un certificado matemático de irreversibilidad: el receptor debe valorar la solidez de las pruebas antes de aceptar un pago concreto. [1] [2]
Un Full Node comprueba por sí mismo las reglas de Bitcoin. No acepta un historial solo porque sea largo. Primero verifica su validez y, entre las ramas válidas, elige la que acumula más trabajo. Se trata del trabajo demostrado por los bloques, no de una votación por número de personas o de monedas. Más trabajo no convierte una transacción inválida en válida. Pablo necesita comprobar ambas cosas: si el pago respeta las reglas y qué profundidad tiene dentro del historial válido que se está siguiendo. [1]
En nuestro ejemplo, la transacción de Pablo está en el bloque de altura 800000 y el extremo actual de esa misma rama tiene altura 800005. La altura indica la posición del bloque, no una hora. La cuenta es 800005 − 800000 + 1 = 6 confirmaciones: también se incluye el bloque de la propia transacción. No se cuentan únicamente los bloques posteriores. Si el pago solo está en el mempool, la colección de transacciones sin confirmar de ese nodo, tiene 0 confirmaciones. Esperar, por sí solo, no hace subir el contador. [2] [3]
La red puede conocer brevemente bloques rivales y después continuar por otra rama válida con más trabajo. Este cambio del historial activo se llama reorganización. En la documentación de Bitcoin Core 28.0, la consulta de cabecera getblockheader devuelve confirmations = -1 si ese bloque no pertenece a la cadena activa. El dato describe el bloque; no significa que todos sus pagos se hayan perdido. La transacción de Pablo puede figurar también en la nueva rama, quedar sin confirmar o entrar en conflicto con otra. Hay que volver a comprobar su estado concreto. [1] [3]
La guía para desarrolladores menciona 6 confirmaciones como umbral habitual para pagos de valor elevado, pero también explica que hay que evaluar el riesgo. Es una regla de aceptación del receptor, no un cambio en el consenso de Bitcoin. Pablo debe considerar el valor de la bicicleta, la posible pérdida y la fiabilidad de su verificación; una cifra no decide por él. Tampoco una media aproximada de una hora significa que siempre lleguen seis bloques en una hora. La minería no tiene un horario fijo, y una recomendación general antigua no garantiza todos los casos. [2]
Pablo puede tener BTC confirmados y seguir discutiendo la entrega o el estado de la bicicleta. Los PFMI, principios internacionales para las infraestructuras del mercado financiero, exigen definir claramente el momento de liquidación definitiva y el límite tras el cual un participante no puede revocar una instrucción. Es un marco distinto del recuento de bloques de Bitcoin. Las confirmaciones no determinan por sí solas los efectos jurídicos del contrato, la liquidación definitiva de un pago bancario ni la transmisión de la propiedad. Verificar el pago no sustituye las demás condiciones de la operación. [4]
Si Pablo y el comprador acuerdan devolver el dinero, el reembolso habitual consiste en una nueva transacción enviada por quien recibió el pago original. La transferencia anterior no desaparece del historial. Bitcoin no tiene una central de atención con un botón para anular pagos confirmados a petición del cliente. Una reorganización cambia el historial activo de la red; no es un servicio para corregir equivocaciones. Por eso conviene revisar destinatario e importe antes de enviar. Más confirmaciones no arreglan un pago introducido incorrectamente. [5]
Para quien opera una aplicación de pagos, el trabajo no termina al aceptar el dinero. Debe registrar la transacción, su bloque y la fuente de verificación, y detectar si el nodo se ha quedado atrás respecto a la red. El valor confirmations describe el estado al consultar, no un certificado permanente. Si disminuye o aparece un conflicto, la aplicación necesita reglas de actuación definidas de antemano y una nueva comprobación de la rama activa. Una captura antigua no es una prueba nueva. Pablo debe decidir según el estado actual de su pago, no solo por lo que mostró una vez el monedero. [2] [3]
Para obtener la imagen más completa, lee esta entrada junto con Confirmación, Proof of Work, Settlement risk, Delivery versus payment. También enlazan con esta entrada Byzantine Generals Problem, Delivery versus payment.