Skip to content

Commit 05f4aa7

Browse files
instagibbsfanquake
authored andcommitted
Mempool: Do not enforce TRUC checks on reorg
Not enforcing TRUC topology on reorg was the intended behavior, but the appropriate bypass argument was not checked. This mistake means we could potentially invalidate a long chain of perfectly incentive-compatible transactions that were made historically, including subsequent non-TRUC transactions, all of which may have been very high feerate. Lastly, it wastes CPU cycles doing topology checks since this behavior cannot actually enforce the topology in general for the reorg setting. Github-Pull: bitcoin#33504 Rebased-From: 26e71c2
1 parent ffffdc4 commit 05f4aa7

File tree

1 file changed

+22
-20
lines changed

1 file changed

+22
-20
lines changed

src/validation.cpp

Lines changed: 22 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -1039,26 +1039,28 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, Workspace& ws)
10391039
// Even though just checking direct mempool parents for inheritance would be sufficient, we
10401040
// check using the full ancestor set here because it's more convenient to use what we have
10411041
// already calculated.
1042-
if (const auto err{SingleTRUCChecks(ws.m_ptx, ws.m_ancestors, ws.m_conflicts, ws.m_vsize)}) {
1043-
// Single transaction contexts only.
1044-
if (args.m_allow_sibling_eviction && err->second != nullptr) {
1045-
// We should only be considering where replacement is considered valid as well.
1046-
Assume(args.m_allow_replacement);
1047-
1048-
// Potential sibling eviction. Add the sibling to our list of mempool conflicts to be
1049-
// included in RBF checks.
1050-
ws.m_conflicts.insert(err->second->GetHash());
1051-
// Adding the sibling to m_iters_conflicting here means that it doesn't count towards
1052-
// RBF Carve Out above. This is correct, since removing to-be-replaced transactions from
1053-
// the descendant count is done separately in SingleTRUCChecks for TRUC transactions.
1054-
ws.m_iters_conflicting.insert(m_pool.GetIter(err->second->GetHash()).value());
1055-
ws.m_sibling_eviction = true;
1056-
// The sibling will be treated as part of the to-be-replaced set in ReplacementChecks.
1057-
// Note that we are not checking whether it opts in to replaceability via BIP125 or TRUC
1058-
// (which is normally done in PreChecks). However, the only way a TRUC transaction can
1059-
// have a non-TRUC and non-BIP125 descendant is due to a reorg.
1060-
} else {
1061-
return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, "TRUC-violation", err->first);
1042+
if (!args.m_bypass_limits) {
1043+
if (const auto err{SingleTRUCChecks(ws.m_ptx, ws.m_ancestors, ws.m_conflicts, ws.m_vsize)}) {
1044+
// Single transaction contexts only.
1045+
if (args.m_allow_sibling_eviction && err->second != nullptr) {
1046+
// We should only be considering where replacement is considered valid as well.
1047+
Assume(args.m_allow_replacement);
1048+
1049+
// Potential sibling eviction. Add the sibling to our list of mempool conflicts to be
1050+
// included in RBF checks.
1051+
ws.m_conflicts.insert(err->second->GetHash());
1052+
// Adding the sibling to m_iters_conflicting here means that it doesn't count towards
1053+
// RBF Carve Out above. This is correct, since removing to-be-replaced transactions from
1054+
// the descendant count is done separately in SingleTRUCChecks for TRUC transactions.
1055+
ws.m_iters_conflicting.insert(m_pool.GetIter(err->second->GetHash()).value());
1056+
ws.m_sibling_eviction = true;
1057+
// The sibling will be treated as part of the to-be-replaced set in ReplacementChecks.
1058+
// Note that we are not checking whether it opts in to replaceability via BIP125 or TRUC
1059+
// (which is normally done in PreChecks). However, the only way a TRUC transaction can
1060+
// have a non-TRUC and non-BIP125 descendant is due to a reorg.
1061+
} else {
1062+
return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, "TRUC-violation", err->first);
1063+
}
10621064
}
10631065
}
10641066

0 commit comments

Comments
 (0)