Second-layers with time-sensitive transactions might see their propagation tampered by their counterparties in opportunistic or adversarial environments. Additionally, non-cooperatively fee-bumped chain of transactions might produce suboptimal miners block templates.
Motivation
Currently, replaced or evicted transactions out of the mempool are not kept in archive. Later transaction reception might invalidate again the replacement candidate letting a spend utxo free to be spent by the original replaced transaction.
It is possible to keep in bounded memory a list of all seen transactions, which have entered our mempool at least once at current mempool min fee (or weight-based mempool min fee on the last X period of time).
-
A transaction issuer on the network might broadcast a batch payout transaction paying many users outputs to user-selected wallets scriptpubkeys. Fee bumping responbility might be shared between the initial broadcaster RBF or payouts users CPFP. Current in-mempool chain package limits might prevent a higher-fee RBF than the sum of CPFP of replacing the chain of transactions or at th contrary the sum of CPFP entering the mempool after the RBF might be higher due to lack of coordination between the set of multi-party transactions participants.
-
Recently, p2p replacement attacks have come to awareness affecting second-layers with time-sensitive transactions where a counterparty can delay the confirmation of time-sensitive states until a more favorable ones become consensus final at the advantage of the attacker. In such situations the initial spend candidate of the channel funding output might be the best fee proposal after a full sequence of replacement have played out.
Design Questions
What Denial-of-Service vectors to consider ?
A cache of replacement transaction will have to be DoS-resistant. Traversal of the cache should be efficient to avoid being a source of new DoS vectors, both memory and CPU validation. Transactions signatuters in the replacement cache could stay in a new cache we have already (like built from CuckooCache primitives) or existent one. New cluster-based algorithms can be leveraged to make traversal of replacement cache more efficient.
Reconciliation between replacement caches due to asymmetric transaction-relay network topology of block templates builders shouldn’t hamper on compact block validation.
What replacement cache expiration delay to consider ?
After an epoch-based or height-based delay, transactions in the replacement cache might be definitively pruned out of node memory, until a subsequent automatic or manual re-broadcast by the transaction issuer. Currently, core’s mempool expiration delay (DEFAULT_MEMPOOL_EXPIRY_HOURS=336) so 14 days time at max during which a transaction might stay in network mempools.
Expiration delay value of the replacement cache might let opportunistic behavior happen in function of mempool cycles, where transaction issuers might delay a fee-bumping (RBF or CPFP) to trigger a “resurrection” of the cached transactions back in miners block templates, saving on the RBF penalty.
How to handle reorgs consistently ?
If we have one or two blocks of reorgs, which happen sometimes on mainnet, some transactions laying in the replacement cache might become stale, i.e a spent output does not exist anymore. In that situation, the replacement cache should be pruned in consequence to remove the staled transactions. Pruning parameters should be selected carefully to avoid low-hashrate miners provoking shallow reorgs to optimize their block templates, in a variant of a “selffish” miner attack.