Mempool

Si la red es una, ¿por qué cada nodo ve una cola distinta?

Dos nodos conectados a internet a la vez pueden no coincidir en qué transacciones están pendientes. Uno tiene la tuya y el otro no. No es un fallo. La mempool (abreviatura de memory pool) es la lista de transacciones sin confirmar que un nodo ha aceptado y guarda en memoria mientras espera a que un minero las incluya en un bloque. Cada nodo mantiene la suya, y no forma parte del consenso.

Esa frase corrige un malentendido muy común. Una transacción puede ser perfectamente válida y aun así no entrar en tu mempool. Lo que decide si entra no es solo la validez, sino también la política de tu nodo.

Consenso y política son dos filtros distintos

Cuando una transacción llega a un nodo, por la red peer-to-peer o por RPC, tiene que pasar dos filtros.

Uno es el consenso: las firmas son correctas, las entradas existen y no están gastadas, los scripts se cumplen. Es igual para todos los nodos. Si una transacción falla aquí, no puede entrar en un bloque válido. Casi siempre es para siempre, porque una firma mala no tiene arreglo. Hay dos excepciones comunes: una transacción con un bloqueo de tiempo (timelock) que aún no ha vencido será válida más adelante, y una que gasta una salida que el nodo todavía no conoce puede ser válida cuando llegue su transacción padre (se trata como huérfana).

El otro es la política: estandaridad, tamaño, polvo (dust), datos en OP_RETURN, comisión mínima y límites de encadenado. Aquí cada nodo decide por su cuenta. Si la transacción pasa los dos filtros, entra en la mempool y el nodo la anuncia a sus pares. Si no pasa el de política, la descarta aunque fuera válida para un bloque.

En Bitcoin Core los dos se mezclan: primero van las comprobaciones baratas, muchas de política (la estandaridad va antes que casi nada), luego la finalidad, las entradas y la comisión mínima, y las firmas y scripts se dejan para el final, primero con las reglas de política y después con las de consenso (MemPoolAccept en validation.cpp, v31.1: PreChecks y, después, PolicyScriptChecks y ConsensusScriptChecks). Así no se gasta CPU en verificar firmas de algo que se va a rechazar.

La consecuencia práctica es que un minero con otra política puede incluir en su bloque una transacción que tu mempool rechazó, y tu nodo aceptará ese bloque sin problema. La política solo gobierna lo que se retransmite y se guarda antes de la confirmación. Lo que decide qué bloques son válidos es el consenso.

Algunos ejemplos de política, según el código de Bitcoin Core 31.1 (consultado el 06-10-2026):

• Una transacción estándar no pasa de 400.000 unidades de peso, o sea, 100.000 vB (MAX_STANDARD_TX_WEIGHT). El peso cuenta cada byte normal como 4 unidades y cada byte de testigo (witness), donde van las firmas SegWit, como 1; un vbyte (vB) es la cuarta parte del peso. El detalle está en el mercado de comisiones.
• Polvo: una salida tan pequeña que gastarla costaría más de lo que vale a una tasa de 3 sat/vB, satoshis por vbyte (-dustrelayfee), una cifra que no bajó en la 29.1. El comentario del código da 546 sat como umbral de una salida típica no SegWit y 294 sat para P2WPKH.
• Los datos en OP_RETURN: antes de la 30.0 el límite de retransmisión era de 83 bytes. Desde la 30.0, -datacarriersize vale 100.000 por defecto, lo que según las notas de versión «effectively uncaps the limit», y se admiten varias salidas de este tipo. Con -datacarriersize=83 se vuelve al límite anterior.
• Hay opciones que existen solo para pruebas, como -acceptnonstdtxn, descrita como «Relay and mine "non-standard" transactions (test networks only)».

Las implementaciones distintas también traen políticas distintas. El caso de Bitcoin Knots, más restrictivo con ciertos datos, se explica en su propia entrada. Aquí basta ver que es política local y no una regla del protocolo. La implementación de referencia es Bitcoin Core.

Los límites de la mempool

Una mempool no crece sin fin. Estos son los valores por defecto de Bitcoin Core 31.1 (código consultado el 06-10-2026).

Tamaño máximo: 300 MB de memoria, no de transacciones

-maxmempool vale 300 MB por defecto, y baja a 5 MB en modo -blocksonly si no lo has fijado tú. Ojo con la unidad: es memoria RAM usada, no vbytes de transacciones. Las dos cifras no coinciden, y el RPC getmempoolinfo las separa: bytes es la suma de los tamaños virtuales según el BIP 141, usage es la memoria que ocupa todo y maxmempool es el límite de esa memoria (los dos últimos, en bytes). En vbytes caben menos de 300 millones. La proporción exacta depende de la mezcla de transacciones, y no hay una cifra de fuente primaria que dar.

Desalojo y mínimo dinámico

Cuando la mempool supera su límite, el nodo quita la parte que antes dejaría de minarse, y repite hasta que vuelve a caber. Desde la 31.0 las transacciones se ordenan por la tasa de comisión (feerate), lo que se paga por cada vbyte, en sat/vB, del chunk en que se minarían. Ese mismo orden sirve para las plantillas de bloque, el desalojo y los anuncios a los pares (notas de la 31.0, 19-04-2026). Qué es un chunk y cómo se calcula está en cluster mempool.

Al desalojar, el nodo también sube su mínimo de entrada. Sube a la tasa de lo que acaba de quitar más incrementalrelayfee, para no aceptar enseguida algo igual de barato. Lo que consultas en getmempoolinfo como mempoolminfee es el máximo entre minrelaytxfee y ese mínimo de la mempool. Un ejemplo ilustrativo con las cifras por defecto: si el nodo desaloja un chunk de 0,2 sat/vB, su mínimo pasa a 0,2 + 0,1 = 0,3 sat/vB.

Después baja solo. La semivida es de 12 horas, de 6 horas si la mempool está por debajo de la mitad de su límite y de 3 horas si está por debajo de un cuarto. El reloj no arranca con la subida, sino cuando llega un bloque. Con la semivida de 12 horas, y si la mempool sigue por encima de la mitad de su límite, ese 0,3 sat/vB bajaría a unos 0,15 sat/vB doce horas después del primer bloque (cálculo del redactor, no dato de la red). Mientras sigue activa, la parte dinámica que se aplica nunca baja de incrementalrelayfee, aunque su valor interno siga decayendo. Cuando ese valor interno cae por debajo de la mitad de incrementalrelayfee, se borra, y mempoolminfee vuelve a ser minrelaytxfee, 0,1 sat/vB por defecto. Lo que se ve en getmempoolinfo con los valores por defecto es 0,3, luego un descenso, y después 0,1 de forma estable.

Comisión mínima de retransmisión

-minrelaytxfee define qué comisión se considera cero para retransmitir y minar. Desde Bitcoin Core 29.1 (04-09-2025) es de 100 sat/kvB, o sea, 0,1 sat/vB. Antes era de 1.000 sat/kvB, 1 sat/vB. Lo mismo ocurre con -incrementalrelayfee, que fija el coste de retransmisión para el límite de la mempool y el reemplazo. Las notas de la 29.1 avisan de que, salvo que estos valores más bajos se adopten de forma generalizada, las transacciones con tasas menores «are not guaranteed to propagate or confirm».

La billetera (wallet) de Core no cambió: sigue sin crear transacciones por debajo de 1 sat/vB salvo que cambies -mintxfee. Quien pruebe a enviar a 0,1 sat/vB desde Core verá un error. Las notas de la 29.1 lo dicen así: «The wallet feerates remain unchanged; -mintxfee must be changed before attempting to create transactions with lower feerates using the wallet».

Caducidad: 14 días

-mempoolexpiry vale 336 horas, 14 días. Al caducar una transacción, el nodo también olvida sus descendientes.

Olvidar no es cancelar. La transacción sigue siendo válida mientras no se confirme otra que gaste alguna de sus entradas. Cualquiera que guarde una copia (quien la creó, el receptor, un explorador) puede volver a difundirla. Y la billetera de Bitcoin Core que la creó la reenvía sola: reintenta con las transacciones sin confirmar cada 12 a 36 horas (ResubmitWalletTransactions en wallet.cpp, v31.1). Tampoco se devuelve ni se pierde nada a los 14 días: los fondos nunca se movieron mientras no hubo confirmación.

De ahí viene un peligro real. Si ves que la transacción desapareció y rehaces el pago con otras monedas, la primera puede reaparecer y confirmarse también, y habrás pagado dos veces. Por eso no rehagas un pago con otras monedas mientras el primero no esté confirmado ni invalidado. Si quieres rehacerlo, hazlo como reemplazo, gastando al menos una de las mismas entradas: así no pueden confirmarse las dos, y en cuanto el reemplazo se confirme la primera quedará invalidada de verdad. La técnica está en reemplazo por comisión (RBF).

Persistencia

Con -persistmempool, activado por defecto, el nodo guarda la mempool en disco al apagarse y la recarga al arrancar.

Por qué no hay una mempool de la red

Las mempools de dos nodos difieren por varias razones, todas normales:

• La propagación no es instantánea.
• Cada nodo tiene su política: la versión, la implementación, opciones como -datacarriersize o -minrelaytxfee.
• Cada uno tiene su tamaño máximo y su propio historial de desalojos y caducidades.
• Algunos nodos acaban de arrancar por primera vez, han estado mucho tiempo apagados o funcionan en modo -blocksonly.

Por eso lo que muestra un explorador como mempool.space es la mempool de sus propios nodos, no «la» mempool. Es una buena estimación del estado general, pero no una verdad única.

Cómo se lee a grandes rasgos

En mempool.space, los primeros «bloques proyectados» son trozos de 1 MvB ordenados por tasa, y el último agrupa todo el resto. Lo que cuenta es la tasa de comisión, no el importe total que paga la transacción. Una transacción grande que paga mucho en total puede tener una tasa baja, y esperar más que otra pequeña.

Un ejemplo con la API de mempool.space el 06-10-2026, hacia las 19:15 UTC: unas 75.000 transacciones pendientes y unos 40 MvB, lo que son unos 40 bloques de cola. Aun así, su tasa recomendada más rápida era de 1 sat/vB y la mínima de 0,1 sat/vB. Mucho volumen y poca puja. Qué hace que ese precio suba o baje se explica en mercado de comisiones.

En un nodo propio, getmempoolinfo devuelve, entre otros, size, bytes, usage, maxmempool, mempoolminfee, minrelaytxfee e incrementalrelayfee. Las tasas salen en BTC/kvB: 0,00001 BTC/kvB equivale a 1 sat/vB. Cómo consultarla con nodo propio y mempool.space autoalojado está en la mempool en tu nodo.

Qué significa esto para ti

Si tu transacción no se confirma, lo primero es entender qué pasó. Quizá solo espera a un bloque. Quizá su tasa quedó por debajo del mínimo de muchos nodos. Quizá se desalojó. En cualquiera de esos casos, tus fondos siguen donde estaban hasta que haya una confirmación, y justo por eso no conviene volver a pagar con otras monedas: la primera transacción puede reaparecer. Si hay prisa, se acelera con RBF, que reemplaza la transacción gastando las mismas entradas, o con CPFP, si controlas alguna de sus salidas.

Y al revés: que una transacción aparezca en una mempool no la hace definitiva. Solo las confirmaciones la hacen firme. Y como cada minero tiene su propia mempool y su propia política, la que importa para que se confirme es la de quien produce el bloque.