Estaba leyendo el Boletín n.° 53 de Coin Metrics , e incluía una sección sobre la reciente congestión de mempool. Después de mencionar las transacciones que fueron desalojadas debido a la cola de transacciones no confirmadas de la red que excedieron el límite predeterminado de mempool, menciona las transacciones que vencen debido al límite de 14 días:
En segundo lugar, expiraron las transacciones que residían en el mempool durante más de dos semanas. De forma predeterminada, los nodos de Bitcoin Core eliminan las transacciones de su mempool si ningún minero encuentra que las tarifas de transacción sean lo suficientemente atractivas como para incluirlas en un bloque durante las últimas 336 horas (dos semanas).
En total, 1.627 transacciones vencieron entre el 25 y el 30 de mayo. Solo el 35% de estos residieron en el mempool durante dos semanas. El 65 % restante probablemente gastó transacciones de padres no confirmadas y dejó de ser válida cuando sus padres expiraron .
En la última oración (resaltado agregado), el boletín describe que las transacciones encadenadas de transacciones vencidas también se eliminarán del mempool. ¿Es esa una descripción precisa del comportamiento del mempool?
En caso afirmativo, digamos que txAestuvo en el mempool durante dos semanas y se eliminó, y txBfue una transacción de CPFP que gastó una salida txAque, por lo tanto, se invalidó y también se eliminó.
¿Qué pasaría si el remitente original retransmitiera txB? Dado que txBlas entradas parecerían no existir sin el contexto de txA, ¿los pares del remitente solicitarían la transacción anterior txAo simplemente la rechazarían txB? ¿Se reproducirían entonces las dos transacciones como una unidad?
Sí, esta es una descripción precisa del comportamiento del mempool. Cuando una transacción expira del mempool, sus descendientes también lo hacen.
Cuando txAse cae, también lo hace txB. Si luego retransmitimos txB(y no es demasiado grande), nuestros compañeros lo agregarán a un (pequeño) caché de transacciones huérfanas que guardan para nosotros. Si transmitimos txAen los próximos 20 minutos (tiempo de espera para el desalojo del caché de transmisión huérfana), y pasa las verificaciones de políticas por sí solo, txA se agregará nuevamente al mempool.
Tenga en cuenta que los pares solo lo solicitarán si les enviamos un invfor txA.
Sin embargo, actualmente no existe tal cosa como "propagación como una unidad" en la red P2P ( aquí se analiza el diseño de retransmisión de paquetes ). Esta es la razón por la que en su ejemplo txAdebe pasar las comprobaciones de política por sí solo.
Esto tiene implicaciones en los protocolos L2 con transacciones prefirmadas, por ejemplo, en Lightning Network, donde la retransmisión de transacciones es crítica. Un pre-firmado txAque esté por debajo de la tarifa mínima de la red mempool en el momento de la transmisión no será aceptado incluso con una tarifa altatxB (1)(2).
(1) Esta es la razón por la que el protocolo Lightning mantuvo el update_feemensaje incluso después de las salidas de anclaje .
(2) Esto también tiene implicaciones en otros protocolos L2. Por ejemplo, en Revault podría evitar que uno anule una bóveda hasta que se procese la acumulación de mempool.
Dichas Transacciones no pueden realizarse sin la salida de sus padres. Por lo tanto, también se eliminan del mempool.