News

La plantilla de bloque que descartaba transacciones que cabían

Bitcoin Core medía un grupo candidato de transacciones con una regla y el espacio libre del bloque con otra. Los grupos densos en firmas que sí cabían quedaban descartados, y la corrección se integró el 24 de agosto de 2026.

4 min de lecturaMinería
La plantilla de bloque que descartaba transacciones que cabían

Qué pasó

El 24 de agosto de 2026 Bitcoin Core integró la pull request 35580, "bugfix: compare non-adjusted chunk weight against block weight limit". El ensamblador de bloques, el código que elige qué transacciones entran en la plantilla que un minero hashea, medía un grupo candidato de transacciones con una regla y el espacio restante del bloque con otra. Grupos que sí habrían cabido quedaban descartados y, como dice la descripción, "esos chunks pagan comisiones más altas, así que esto podría hacer que los mineros renuncien innecesariamente a algunos ingresos por comisiones". La corrección está en master y todavía no ha llegado a ninguna versión publicada.

Qué cambia

Bitcoin Core mantiene dos tamaños distintos para una transacción, y existen por motivos distintos.

El primero es el peso real, y es un límite de consenso: un bloque no puede superar 4.000.000 de unidades de peso, con un techo aparte de 80.000 para el coste de sus operaciones de firma. El segundo es un mecanismo de política. Las verificaciones de firma son caras de validar para cada nodo y baratas de meter en una transacción, así que Core ordena una transacción en la mempool por su peso ajustado por sigops, que GetSigOpsAdjustedWeight calcula como max(weight, sigop_cost * bytes_per_sigop), con -bytespersigop en 20 por defecto. Una transacción densa en verificaciones de firma queda así valorada como si fuera más grande de lo que es, que es el efecto buscado.

El fallo consistía en usar el segundo número para responder a una pregunta que solo el primero puede responder. TestChunkBlockLimits sumaba el peso ajustado del grupo al peso que ya había en el bloque y comparaba eso con el límite. Un grupo que físicamente cabía quedaba rechazado porque su tamaño inflado no cabía. El ensamblador lo descartaba y tomaba el siguiente mejor grupo, que por construcción paga menos. Con el bloque casi lleno, una racha de descartes así podía además activar la salida que termina el ensamblado tras mil fallos consecutivos.

El parche pasa en su lugar la suma del peso real de cada transacción y deja la comprobación de operaciones de firma donde estaba, contrastando el coste real de sigops con el techo real de sigops. Dos límites, dos reglas, que es aquello en lo que la norma de ordenación nunca tuvo que intervenir.

Qué no cambia

Ninguna regla de consenso se movió, y ningún bloque fue nunca inválido. Toda plantilla que producía el código antiguo era un bloque legal. Solo dejaba dinero sobre la mesa, y únicamente en el caso estrecho en que la densidad de firmas de un grupo empujaba su peso ajustado por encima del espacio libre.

No es un fallo que pueda perjudicar a un usuario corriente. Una transacción descartada de una plantilla sigue en la mempool y la recoge el bloque siguiente u otro minero con software distinto. La estimación de comisiones no se ve afectada: nada de esto cambia lo que una wallet debería ofertar.

Y todavía no está corregido para quien use una versión publicada. Bitcoin Core 31.0, del 18 de marzo de 2026, y la 31.1, del 8 de julio de 2026, llevan ambas la comparación original; la serie 30.x no, porque es anterior al ensamblador por chunks. Un minero que quiera la corrección hoy compila desde master o espera.

Contexto

Core ha dedicado este agosto a la aritmética alrededor de los bloques más que a las reglas de su interior. El estimador de comisiones por mempool integrado una semana antes toma el menor de dos cálculos precisamente para que una señal nueva no pueda subir una recomendación por sí sola. Ambos cambios tratan de no confiar en un número para hacer el trabajo de otro.

La lección transferible es más estrecha que "revisa las unidades". Ordenar y medir capacidad son trabajos distintos. Un número de ordenación puede permitirse ser una ficción, porque su único fin es ordenar cosas entre sí, y cobrar a una transacción densa en firmas como si fuera mayor es una ficción deliberada que funciona. Un número de capacidad tiene que ser verdadero, porque se está llenando algo físico. El código que deja al primero sustituir al segundo produce bloques correctos que valen menos de lo que deberían, y nada en ningún sitio lo informa.

Boletín

Bitcoin, sin ruido

Qué ha pasado en Bitcoin, qué cambia de verdad, y las fuentes para que puedas comprobarnos. Un número cada vez, directo a tu correo.

  • Un correo por número, nunca una secuencia automática
  • Sin píxeles de seguimiento y sin compartir direcciones
  • Baja desde cualquier número con un clic

Recibe el próximo número

Un correo por número, sin píxeles de seguimiento, y te puedes dar de baja desde cualquiera de ellos. No compartimos tu dirección. Política de privacidad