Similar reasoning to #33504
During a deeper reorg it’s possible that a long sequence of dust-having transactions that are connected in a linear fashion. On reorg, this could cause each subsequent “generation” to be rejected. These rejected transactions may contain a large amount of competitive fees via normal means.
PreCheck based PreCheckEphemeralSpends is left in place because we wouldn’t have relayed them prior to the reorg.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33616.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | darosior, ismaelsadeeq, sedited |
If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Possible typos and grammar issues:
2026-02-25 14:24:30
112@@ -113,6 +113,26 @@ def create_block(hashprev=None, coinbase=None, ntime=None, *, version=None, tmpl
113 block.hashMerkleRoot = block.calc_merkle_root()
114 return block
115
116+def create_empty_fork(node, fork_length):
create_empty_fork() can be deleted from mempool_updatefromblock.py.
1607@@ -1608,7 +1608,7 @@ PackageMempoolAcceptResult MemPoolAccept::AcceptMultipleTransactions(const std::
1608 }
1609
1610 // Now that we've bounded the resulting possible ancestry count, check package for dust spends
1611- if (m_pool.m_opts.require_standard) {
1612+ if (!args.m_bypass_limits && m_pool.m_opts.require_standard) {
m_bypass_limits to be true in this function, so undoing this diff doesn’t make a difference. Could we omit it or Assume(!args.m_bypass_limits)?
Took feedback in other PR ahead of time #33504 (review)
I can definitely put an Assume() on it.
Mild preference for consistency between the two checks that are disabled upon reorgs: either we gate both TRUC and ephemeral dust on !bypass_limits in both code paths, or we gate both only on the AcceptSingleTx code path. Since the TRUC bypass is not enabled in AccecptMultiTx, the easier seems to be dropping it in this PR. Assume sounds good.
Not a blocker for me. Happy to re-ACK if you drop it and/or add an Assume.
ACK a5299c3509a126916ce3b87cb1fcf1e9a3631b1b
The comment for CheckEphemeralSpends seems incorrect. It currently states, “Must be called for each package/transaction with dust.” That is no longer the case. It wasn’t the case before either, because on the test chain, you can override and accept non-standard transactions, and then it won’t be called.
reACK 2854de7b0baa29f294b4dc64cc4d2c4233ce1f24
9a3631b1b..2854de7b fixed a comment as mentioned in #33616 (comment)
Labels
TX fees and policy
Milestone
31.0