Pajarito en redes

¿Por qué una recompensa de minería puede estar confirmada y, aun así, no poder gastarse todavía?

La coinbase de un bloque crea las salidas que reciben la recompensa y las comisiones, pero sus UTXO tienen una condición adicional de consenso: deben madurar durante 100 bloques antes de poder gastarse. La altura del bloque que contiene la coinbase determina el punto de referencia; no basta con que la transacción aparezca en una wallet.

Al validar una entrada que gasta una coinbase, el nodo comprueba que hayan pasado suficientes bloques desde su inclusión. Si no se cumple, el bloque que contiene ese gasto es inválido, aunque la firma y el resto de la transacción sean correctos. Es una regla distinta de la política de mempool: un nodo puede rechazar el gasto antes de retransmitirlo, pero la prohibición fundamental pertenece al consenso.

La interacción con las reorganizaciones importa. Si la rama activa pierde el bloque que creó la coinbase, sus salidas dejan de pertenecer al conjunto UTXO activo. Cualquier gasto descendiente debe desaparecer o volver a evaluarse; no basta con que la coinbase haya tenido antes muchas confirmaciones en una rama que ya no es la elegida.

La wallet puede mostrar la recompensa como recibida y llevar su propio seguimiento de madurez, pero esa interfaz no cambia las reglas que aplican los nodos ni permite gastar antes. El minero también debe respetarlas: incluir una transacción que consuma una coinbase inmadura invalidaría todo su bloque.

La consecuencia es precisa: la madurez no es una espera visual ni una recomendación operativa. Es una restricción de consenso ligada a la altura y al estado UTXO de la cadena activa; protege la validez de los gastos derivados de recompensas que todavía podrían quedar afectados por una reorganización.

¿Puede una transacción posterior ayudar a confirmar otra que paga una comisión demasiado baja?

Sí, mediante Child-Pays-for-Parent (CPFP). La transacción hija gasta una salida de la transacción padre que aún está pendiente. Por separado, la padre puede parecer poco atractiva; pero la hija añade una comisión suficientemente alta para que el conjunto tenga una tasa media interesante para un minero.

La relación no es una orden ni una promesa. La hija depende de una salida concreta de la padre, así que no puede confirmarse antes que ella. Si un bloque incluye ambas, el minero obtiene la suma de sus comisiones y evalúa el peso combinado. La política de mempool decide si acepta y retransmite ese paquete; no existe una mempool global.

CPFP no modifica la transacción padre ni la reemplaza. A diferencia de RBF, conserva la operación original y añade otra transacción que gasta su cambio u otra salida disponible. Si la padre no tiene una salida controlable —por ejemplo, porque todas pertenecen a terceros— el receptor puede no tener capacidad para aplicar este mecanismo.

La consecuencia es útil: las transacciones relacionadas pueden evaluarse como un paquete económico, aunque cada una mantenga sus propias reglas de consenso. CPFP puede mejorar la prioridad de confirmación, pero no garantiza que un bloque incluya el conjunto. La inclusión final sigue dependiendo de que ambas transacciones sean válidas y de las decisiones del minero.

¿Cómo puede un nodo recibir un bloque sin que el minero le retransmita todas sus transacciones completas?

Compact Block Relay, definido en BIP152, permite enviar primero el encabezado, la coinbase y una lista compacta de identificadores de transacción. El nodo calcula short IDs para las transacciones que ya tiene en su mempool y reconstruye provisionalmente el bloque sustituyendo esos identificadores por sus transacciones locales.

La conexión depende de que ambos nodos compartan muchas transacciones. La clave usada para los short IDs deriva del hash del encabezado, de modo que no son identificadores globales ni una prueba de validez. Si hay colisiones o falta alguna transacción, el receptor solicita los bloques de datos ausentes mediante una petición de recuperación.

Aquí conviene separar capas. BIP152 es una optimización de relay: no cambia qué bloque es válido. El nodo debe validar después todas las transacciones, sus scripts, el conjunto UTXO, la coinbase, el peso y el resto de reglas de consenso. Un minero puede construir su plantilla con transacciones que otros nodos aún no conocen; en ese caso la reconstrucción será incompleta.

También existe una modalidad de alta prioridad para anunciar un bloque antes de haber propagado todo su contenido, pero no elimina la necesidad de recuperar y verificar los datos. La política de mempool influye en la eficiencia del mecanismo, no en la validez del bloque.

La consecuencia es precisa: compact blocks reducen ancho de banda y latencia cuando las mempools están sincronizadas, pero no convierten el conocimiento local en confianza. El receptor puede reconstruir rápido; la aceptación definitiva sigue dependiendo de validar el bloque completo.

¿Por qué una firma puede ocupar espacio en una transacción y, aun así, pesar menos para el cálculo de comisión?

Desde SegWit, Bitcoin separa los datos de la transacción en dos partes: el contenido base —version, inputs, outputs y locktime— y el witness, que contiene firmas y otros datos de satisfacción. El peso se calcula como 4 × bytes base + bytes witness. Un vbyte es una cuarta parte de ese peso, redondeada hacia arriba para la transacción completa.

La regla conecta tres límites distintos: el bloque no puede superar 4.000.000 de weight units, el tamaño base sigue limitado a 1.000.000 de bytes y los sigops también tienen un presupuesto de consenso. Por tanto, una transacción puede caber por peso y aun así exceder el límite de operaciones de firma.

El descuento no significa que el witness sea opcional ni menos válido. Los nodos deben verificarlo completamente; simplemente cuenta con un factor distinto en el límite de peso. La política de relay suele expresar la comisión en sat/vB, mientras el minero ordena transacciones según sus propios criterios, normalmente relacionados con la tasa efectiva de comisión y las dependencias.

La wallet influye en el resultado al elegir tipos de salida, número de entradas y método de firma: dos pagos con el mismo importe pueden tener pesos muy distintos. La consecuencia es precisa: vbytes no son bytes físicos, y una comisión baja por vbyte no relaja ninguna regla de consenso. Describe cómo se valora el espacio consumido dentro del presupuesto de peso; la validez sigue dependiendo de las reglas completas del protocolo.

¿Qué ocurre si una transacción de Bitcoin se queda pendiente y la comisión elegida ya no resulta atractiva para los mineros?

Existe una opción llamada Replace-by-Fee (RBF): mientras la transacción no esté confirmada, el emisor puede publicar otra que gaste los mismos UTXO, pero con una comisión mayor. La nueva versión puede modificar destinatario, cambio o importe, siempre que siga siendo válida y respete las reglas de reemplazo.

Los nodos no tienen una mempool global. Cada uno decide si acepta el reemplazo según sus políticas; entre otras condiciones, la nueva transacción debe pagar suficiente comisión para cubrir su propio espacio y compensar la retirada de la anterior. Un minero también puede recibir cualquiera de las dos por otra vía.

La frontera importante está en la confirmación. RBF no borra una transacción incluida en un bloque ni reescribe la cadena: solo permite competir por el mismo UTXO antes de que una versión quede confirmada. Por eso una transacción pendiente no debe tratarse como resultado definitivo.

RBF es, en esencia, un mecanismo de sustitución dentro del estado provisional de las mempools. Ayuda a corregir una comisión insuficiente o a actualizar una operación, pero no convierte una transacción confirmada en editable. La confirmación cambia la pregunta: ya no importa qué versión circula, sino cuál quedó incluida en la cadena activa.

¿Cómo detecta Bitcoin que alguien intenta gastar dos veces la misma moneda?

La clave está en los UTXO: cada salida no gastada puede consumirse una sola vez. Un nodo mantiene un conjunto actualizado de esas salidas. Cuando recibe una transacción, comprueba que cada entrada apunta a un UTXO existente y que ninguna entrada de la propia transacción repite el mismo origen.

Si llegan dos transacciones distintas que intentan gastar el mismo UTXO, no pueden confirmarse juntas en un bloque válido. La mempool de cada nodo puede conservar una y rechazar la otra, según sus reglas y el orden en que la reciba. No existe una mempool global que decida por toda la red.

La decisión definitiva llega cuando un bloque incluye una de ellas. Al conectar ese bloque, los nodos eliminan el UTXO gastado y crean las nuevas salidas. La transacción rival ya no puede entrar después usando la misma salida, porque esa entrada dejó de existir como UTXO disponible.

Por eso una transacción pendiente no equivale todavía a un estado final. La red puede observar conflictos antes de la confirmación, pero la cadena activa fija qué gasto quedó registrado. El doble gasto no se evita confiando en una lista central: se rechaza al aplicar las mismas reglas sobre un conjunto de UTXO que cada nodo reconstruye y verifica.

¿Qué ocurre con los UTXO cuando Bitcoin cambia temporalmente de rama? Un nodo no borra la historia anterior sin más: al conectar un bloque, consume entradas, crea salidas nuevas y guarda datos de deshacer asociados a ese bloque.

Esos datos permiten invertir la operación. Si una reorganización hace que otra cadena tenga más trabajo acumulado, el nodo desconecta los bloques de la rama anterior: restaura los UTXO gastados y elimina los creados por cada bloque, en orden inverso. Después conecta la nueva rama aplicando sus transacciones y actualizando el conjunto UTXO.

La coinbase también importa: sus salidas solo pueden gastarse tras la madurez correspondiente. Al desconectar un bloque, el nodo debe revertir esa creación y cualquier cambio derivado sin dejar salidas “huérfanas” en su estado actual.

La consecuencia es que la cadena no se trata como un archivo inmutable que solo crece hacia delante. El historial permanece, pero el estado que usan los nodos puede avanzar y retroceder entre ramas válidas. Los datos de deshacer hacen posible esa transición eficiente; la validación de la nueva rama sigue siendo completa.

Así, una reorganización no significa que Bitcoin edite una transacción confirmada dentro del mismo bloque. Significa que el nodo cambia qué secuencia de bloques considera activa y recalcula el estado UTXO que se deriva de ella.