Fee market: el mercado de comisiones

Un bloque, un recurso escaso y una subasta continua

Dos personas envían a la vez una transacción con el mismo importe. Una paga 300 satoshis de comisión y la otra 3.000. Ninguna regla del protocolo explica la diferencia, porque en el consenso no existe una comisión mínima ni una máxima. La comisión es la diferencia entre lo que suman las entradas y lo que suman las salidas, la decide quien firma y no depende del importe que se mueve. Lo que ordena el reparto es un mercado: cada bloque ofrece una cantidad fija de espacio y los usuarios pujan por él.

Esta entrada explica qué se subasta, cómo se mide, cómo se forma el precio, cómo estima una tasa de comisión Bitcoin Core y qué parte de la recompensa de los mineros pagaban las comisiones en el año hasta octubre de 2026. Para la versión de uso cotidiano (pagar más para ir antes) está comisiones de transacción.

Qué se subasta: peso y vbytes

El bien escaso es el espacio de bloque. La regla de consenso dice que el peso de un bloque no puede superar 4.000.000 de unidades (MAX_BLOCK_WEIGHT, en consensus.h de Bitcoin Core v31.1). Con un bloque cada diez minutos de media, ese es el recurso que se reparte. Hay un segundo límite, 80.000 en coste de sigops (MAX_BLOCK_SIGOPS_COST), que casi nunca llega a ser el que manda.

El peso lo define BIP-141 (diciembre de 2015, Lombrozo, Lau y Wuille): «Base transaction size * 3 + Total transaction size». El tamaño base es la transacción sin datos de testigo y el tamaño total la incluye. Dicho de otro modo, cada byte normal pesa 4 unidades y cada byte de testigo (las firmas de SegWit y Taproot) pesa 1. El tamaño virtual, o vbytes, es el peso dividido entre 4 y redondeado hacia arriba. De ahí que 4.000.000 de peso sean 1.000.000 de vbytes.

Un ejemplo inventado, con números redondos. Una transacción tiene 200 bytes sin testigo y 100 bytes de testigo, así que mide 300 bytes en total. Su peso es 200 × 3 + 300 = 900 y su tamaño virtual 900 / 4 = 225 vbytes. Una transacción heredada de 300 bytes sin testigo pesaría 1.200 y ocuparía 300 vbytes. A la misma tasa de comisión, la primera paga un 25 % menos. Por eso una entrada SegWit cuesta menos que una heredada con los mismos bytes: el descuento se aplica a los bytes de testigo, no a la transacción entera.

Dos matices que aparecen en el código de Bitcoin Core v31.1. El primero: para la política y para el minado, GetVirtualTransactionSize toma el mayor entre el peso y el coste en sigops multiplicado por -bytespersigop (20 por defecto). Una transacción con muchas operaciones de firma y poco peso se factura como si fuera más grande. El segundo: la plantilla de bloque reserva por defecto 8.000 unidades de peso (DEFAULT_BLOCK_RESERVED_WEIGHT, configurable con -blockreservedweight) para la cabecera, el recuento de transacciones y la coinbase, así que el espacio útil para transacciones es algo menor que el máximo teórico.

Lo que más pesa en una transacción corriente son las entradas. Gastar muchas UTXO pequeñas cuesta más que gastar una grande, aunque el importe sea el mismo. Para esa consecuencia práctica, véase consolidación de UTXO.

Cómo se forma el precio

La unidad del mercado es la tasa de comisión en sat/vB. Quien construye un bloque quiere maximizar lo que cobra por el espacio que tiene, así que llena el bloque con lo que más paga por unidad de espacio. Bitcoin Core valora grupos, no transacciones sueltas: un padre barato con una hija cara cuenta como un grupo (chunk) con su tasa conjunta. El mecanismo está en cluster mempool.

No hay un precio único. Es una cola con muchas pujas y cada transacción paga lo que ofreció, no un precio de corte. Lo que marca el nivel de las tasas no es el volumen de la cola, sino lo que paga quien tiene prisa. Si todo lo urgente cabe en el siguiente bloque, el resto puede esperar en el suelo aunque haya muchos bloques de cola pendientes. Si lo urgente no cabe, las pujas suben hasta que a quien le queda fuera ya no le compensa pagar más y prefiere esperar.

Ese suelo es política, no consenso. En Bitcoin Core v31.1 el mínimo de retransmisión (-minrelaytxfee) es de 0,1 sat/vB, y era de 1 sat/vB hasta la 29.0 (según las notas de la 29.1 y policy.h). La plantilla de bloque tiene su propio suelo, -blockmintxfee: 0,001 sat/vB desde la 29.1 y 1 sat/vB en la 29.0. Las notas de la 29.1 avisan de que las transacciones por debajo de 1 sat/vB no tienen garantizado que se propaguen ni se confirmen mientras la red no adopte el cambio. Aun así, el 06-10-2026 se minaban bloques con transacciones de unos 0,3 sat/vB (API de mempool.space, bloques 970.206 a 970.220). El mínimo dinámico y el desalojo de la mempool están en mempool.

La billetera (wallet) de Core tiene suelos propios. Con la v31.1, el -mintxfee de la billetera es 1.000 sat/kvB (1 sat/vB) y su objetivo de confirmación por defecto es de 6 bloques (wallet.h). En la 31.0 desaparecen -paytxfee y settxfee: según las notas de esa versión, hay que apoyarse en la estimación o indicar una tasa por transacción.

Estimar la tasa: qué hace estimatesmartfee

La RPC estimatesmartfee calcula la comisión aproximada por kvB (mil vbytes) para que una transacción empiece a confirmarse dentro de un número de bloques (conf_target). El objetivo admite de 1 a 1008, pero el código lo ajusta a un mínimo de 2. El resultado se devuelve en BTC/kvB y nunca baja del mínimo de la mempool ni del de retransmisión. Cómo ejecutarla con un nodo propio y convertir la unidad se explica en mempool en tu nodo.

Lo importante es que no proyecta la cola que hay ahora: aprende de lo que tardaron en confirmarse las transacciones que vio, y solo cuenta las que siguen esperando para penalizar su cubo. Según el comentario de block_policy_estimator.h (v31.1), el estimador funciona así:

• Agrupa las transacciones en cubos por tasa de comisión, con una separación del 5 % entre cubos (FEE_SPACING = 1.05). El rango va de 100 a 10.000.000 sat/kvB, es decir, de 0,1 a 10.000 sat/vB; ese mínimo de 0,1 sat/vB llegó en la 31.0, que lo bajó desde 1 sat/vB.
• Apunta la altura a la que cada transacción entra en la mempool y cuántos bloques tarda en confirmarse.
• Mantiene tres horizontes con medias exponenciales: corto (12 bloques), medio (48) y largo (1.008). Usa el horizonte que alcance a cubrir cada plazo.
• Para un objetivo de N bloques hace tres cuentas y se queda con la más alta: la tasa más baja con la que más del 60 % se confirmó en N/2 bloques, la que logró el 85 % en N y la que logró el 95 % en 2N.

Dos consecuencias. Una, el estimador reacciona tarde a un pico repentino de demanda, porque aprende de lo que ya se confirmó. Otra, un nodo nuevo, o uno que estuvo más de 60 horas apagado, empieza con pocos datos: el fichero fee_estimates.dat solo se vuelve a usar si es reciente. Al actualizar a la 31.0 se descarta una vez, por el cambio de cubos. Desde la 28.0 el modo por defecto es economical: mira un horizonte más corto, reacciona antes cuando las tasas bajan y puede dar menos que conservative. Según las notas de la 28.0, el cambio debería reducir la sobreestimación, sobre todo cuando se puede usar RBF para subir después una tasa que se quede corta.

Los exploradores usan otro enfoque. mempool.space proyecta los próximos bloques con la mempool actual y calcula sus recomendaciones a partir de las medianas de los primeros bloques proyectados, con algunos ajustes. Para la opción más rápida no baja de 1 sat/vB, porque no todos los mineros aceptan todavía tasas menores (backend/src/api/fee-api.ts). Es una diferencia de diseño: uno aprende del pasado y el otro mira lo que hay en cola.

Equivocarse al estimar no es grave si se puede corregir. Con RBF se reemplaza la transacción por otra con tasa mayor, y con CPFP se paga por el padre desde un hijo. Gracias a eso se puede pujar bajo y subir si hace falta.

Subsidio frente a comisiones

La recompensa de un bloque es el subsidio más las comisiones. El subsidio sale de GetBlockSubsidy (validation.cpp, v31.1): 50 BTC desplazados a la derecha un bit por cada 210.000 bloques. Tras 33 reducciones el resultado ya es 0; el código fuerza además 0 a partir de 64, porque ahí el desplazamiento no estaría definido en C++. Es 3,125 BTC entre las alturas 840.000 y 1.049.999, y 1,5625 BTC entre la 1.050.000 y la 1.259.999. En la altura 6.930.000 el subsidio es de 0 satoshis (cálculo: 50·10⁸ >> 33 = 0, con 32 reducciones aún queda 1 satoshi). La fecha de 2140 que se cita para «el último bitcoin» es aproximada, porque depende del ritmo real de los bloques; lo verificable es la altura. La emisión se explica en emisión monetaria y el mecanismo de reducción en halving.

Las cifras, según la API de mempool.space (/api/v1/mining/reward-stats, consultada el 06-10-2026). El subsidio cuadra exactamente en los tres casos:

Es decir, en el año hasta octubre de 2026 las comisiones fueron menos del 1 % de lo que cobraron los mineros. El resto fue subsidio. La excepción más visible es el día del halving, el 20-04-2024. El bloque 840.000 pagó 37,63 BTC en comisiones frente a 3,125 BTC de subsidio, el 92,3 % de la recompensa, con una mediana de 200 sat/vB. Y no fue el único: los 104 bloques del 840.000 al 840.103, minados ese día entre las 00:09 y las 19:48 UTC, cobraron todos más en comisiones que en subsidio, con medianas que en algunos pasaron de 2.000 sat/vB (API de mempool.space, consultada el 06-10-2026). Ese mismo bloque 840.000 se eligió como el primero en el que valían los Runes, un protocolo de tokens (repositorio ord, rune.rs). Las fuentes consultadas no miden qué parte de esas comisiones vino de ahí.

En los 15 bloques del 970.206 al 970.220 (06-10-2026), la mediana de tasa por bloque iba de 0,32 a 3,29 sat/vB y las comisiones por bloque, de 797.822 a 4.584.540 satoshis (API de mempool.space). Son tasas bajas, muy lejos de las del día del halving.

Seguridad a largo plazo: una pregunta abierta

Lo que sale del código y del whitepaper es el diseño. Nakamoto, en la sección 6 del whitepaper (2008), escribe: «once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free». Es decir, una vez en circulación un número predeterminado de monedas, el incentivo puede pasar por completo a las comisiones. El subsidio llega a cero y, a partir de ahí, solo las comisiones pagan a los mineros.

Que esas comisiones basten para pagar una seguridad suficiente no es un hecho comprobado. Es una pregunta abierta, y cada postura se apoya en algo distinto.

La postura optimista se puede argumentar con el diseño y con datos. El whitepaper prevé la transición. El día del halving de 2024 muestra que las comisiones pueden superar al subsidio durante horas seguidas. Los propios autores del trabajo de Carlsten, citado abajo, creen, aunque no lo demuestran, que el problema que describen se suaviza cuando los bloques van llenos. La billetera de Bitcoin Core, además, casi siempre pone a sus transacciones un timelock igual a la altura actual. Así, un minero que remine el último bloque no puede meter en él las transacciones creadas después. No le impide quedarse con las del bloque que remina, pero le deja menos que ganar (DiscourageFeeSniping, wallet/spend.cpp, v31.1). Y hay una cuenta sencilla: con las comisiones medias del último año (0,0201 BTC por bloque) y el subsidio de 1,5625 BTC que llega en la altura 1.050.000, las comisiones serían un 1,3 % de la recompensa. El cálculo no predice nada, solo muestra que el porcentaje sube cuando el subsidio baja, aunque las comisiones se queden igual.

La postura escéptica parte de los mismos datos: en el año hasta octubre de 2026 las comisiones fueron el 0,64 % de la recompensa y el pico del halving duró un día. Pregunta si un mercado donde las medianas de los bloques 970.206 a 970.220 iban de 0,32 a 3,29 sat/vB puede pagar por sí solo la seguridad. Hay trabajos académicos en esa línea. Carlsten, Kalodner, Weinberg y Narayanan, en «On the Instability of Bitcoin Without the Block Reward» (ACM CCS 2016), muestran que, cuando solo hay comisiones y en cada bloque cabe todo lo pendiente, a un minero puede salirle a cuenta reminar el bloque anterior y dejar parte de sus comisiones sin cobrar para atraer a los demás (lo llaman undercutting). Con bloques llenos, según los autores, el efecto se mantendría, pero más débil. Budish, en «The Economic Limits of Bitcoin and the Blockchain» (NBER, 2018), estudia la relación entre lo que se paga a los mineros y lo que costaría un ataque.

El punto común es el vínculo entre lo que cobran los mineros y la seguridad. Como explica hashrate y seguridad, la seguridad se mide por lo que costaría atacar la red. Ese coste sigue al hashrate, y el hashrate sigue a lo que cobran los mineros. Sin subsidio, lo cobran todo de las comisiones.

Ninguna de las dos lecturas es un dato. Predecir qué volumen de demanda habrá dentro de décadas excede lo que los datos permiten. El siguiente halving llegará en la altura 1.050.000; a diez minutos por bloque caería hacia 2028, pero es una estimación y la fecha real depende del ritmo de los bloques.

Qué significa esto para ti

Para elegir tasa, importan el tamaño en vbytes y la urgencia, no el importe. Usar entradas SegWit o Taproot abarata, y consolidar UTXO cuando las tasas están bajas evita pagar mucho más tarde. Si la billetera ofrece un control de tasa, mirar la estimación y compararla con un explorador es mejor que fiarse de un único valor, sobre todo en un pico. Y si se queda corta, RBF o CPFP lo corrigen. Del lado del protocolo, lo sensato es leer con cuidado a quien afirme que las comisiones «garantizan» la seguridad futura o que su falta la «condena»: ninguno de los dos tiene la respuesta todavía.