Abstract:
This proposal introduces a policy-level optimization to the Bitcoin Core mempool validation layer to mitigate potential Denial-of-Service (DoS) vectors stemming from high-frequency, low-weight transaction submissions. By enforcing strict minimum transaction weight rules relative to input structures during the initial policy validation phase, nodes can filter out non-standard, economically unviable transaction paths before allocating critical CPU validation time or propagating them further across the peer-to-peer network.
Motivation:
The Bitcoin mempool framework relies on policy checks to prevent resource exhaustion attacks. While minimum relay fees filter out standard spam, specific anomalies involving transactions with abnormally low weights relative to their execution overhead can introduce unnecessary validation strain. Implementing an early-stage weight filter within the standard transaction validation sequence provides an explicit, lightweight layer of defense against low-fee payload flooding.
Specification:
This optimization integrates directly into Bitcoin Core’s native validation pipeline. Instead of running standalone mock structures, the logic applies directly to the standard transaction reference types (CTransactionRef) and populates the validation state machine (TxValidationState) according to standard internal error codes.
C++ Implementation Draft:
#include <consensus/validation.h>
#include <primitives/transaction.h>
#include <policy/policy.h>
bool CheckTransactionWeightPolicy(const CTransactionRef& tx, TxValidationState& state) {
constexpr int64_t MIN_STANDARD_MEMP_WEIGHT = 64;
if (!tx->vin.empty()) {
int64_t current_tx_weight = GetTransactionWeight(*tx);
if (current_tx_weight < MIN_STANDARD_MEMP_WEIGHT) {
return state.Invalid(TxValidationResult::TX_NOT_STANDARD,
"tx-weight-below-mempool-policy",
"Transaction weight is below the minimum required policy threshold.");
}
}
return true;
}
Backward Compatibility:
This proposal is strictly a node-level validation policy configuration (mempool policy rule). It does not introduce changes to the consensus layer or alter core block verification mechanics. Transactions failing this specific rule are rejected from local mempool storage and peer relay, but remain completely valid if mined into an actual block, maintaining full network compatibility and preventing any risk of consensus divergence.
