I’ve been noticing many lines of:
2025-08-31 12:35:12.4109 P2Pool invalid transaction: tx id = 06c5cb6711a9aa8859f1ef04b692063d63d4826c9489d7e64d3196d46c16a854, size = 0, weight = 0, fee = 11466.880 um
in my p2pool logs.
- What is causing this?
- Does this have anything to do with Qubic?
You must log in or # to comment.
Does this have anything to do with Qubic?
No, the invalid transaction messages in your P2Pool logs are unrelated to Qubic. Qubic did perform a 51% hashrate takeover of the Monero network in August 2025, but those warnings are just about malformed transactions in P2Pool, not linked to Qubic’s activity or attack. Qubic’s event affected block reorganizations and mining dominance, not these specific transaction errors.
Pubic never had 51%, stop spreading misinformation.
Hi, if is misinformation could you please give me some related links so i can read and learn more please.
https://shai-deshe.gitbook.io/parallel-thoughts/proof-of-work/the-qubic-minority-report
TLDR; just because you have >=51% of the blocks in a certain timespan, does NOT mean you control 51% of the hashrate. Due to probability, you can expect anyone with any non-zero hashrate to produce more than 50% of blocks in a timeframe of some length with some probability. If you near 33% of total hashrate, that can be pretty often in practice. According to this report, Qubic never breached 40% of the total hashrate, and hovered around 1/3 of the total hashrate during active mining marathons, which weren’t pepetually on-going. Qubic increased the average actualized hash-rate over its whole operation by ~5%.
Those “invalid transaction” entries in P2Pool logs are typically caused by transactions that fail fee rate checks against the local mempool policy. The
size = 0, weight = 0values in your log suggest the transaction data was not fetched or parsed successfully — P2Pool received a tx hash from a peer but could not retrieve or validate the full transaction from your node.A few common causes:
- Monerod not fully synced — If your local node is slightly behind, transactions in the mempool may reference outputs your node has not yet seen
- Bandwidth/RPC timeout — P2Pool queries monerod for tx details; under load this can fail silently and log as invalid
- Qubic/Tari merged mining — Yes, these do produce some unusual transactions. If you see spikes in invalid tx logs after Qubic stratum announcements, that confirms the connection
The errors are non-critical. P2Pool simply skips invalid transactions when building its share chain. Your mining rewards are not affected.
If it bothers you, verify your monerod is fully synced and the RPC connection between P2Pool and monerod is healthy (check
--rpc-bind-portisn’t rate-limited).Those “invalid transaction” log lines are not a problem — they’re P2Pool doing its job correctly.
What’s happening: P2Pool shares a mempool view across its sidechain network. When a node receives a block template that references transactions, it validates each one locally. If a transaction has
size=0, weight=0, fee=...it means P2Pool received a fee reference but couldn’t find/validate the full transaction in your local mempool. This is a normal race condition between mempool propagation and block template timing.The Qubic connection: Yes, there was a period in 2025 where Qubic mining was injecting very large numbers of micro-transactions into the Monero mempool (they were using merged mining via a sidechain approach). These often propagated unevenly across the network. Some P2Pool nodes would receive fee data about transactions that hadn’t fully propagated yet → hence the
size=0entries.What to check:
- Are these lines continuous/persistent, or occasional? Occasional = totally normal.
- Run
monerod status— is your node fully synced and connected to enough peers (8+)? - If you’re seeing thousands per minute, check if your Monero daemon is poorly connected.
Bottom line: these log lines are informational, not errors. Your P2Pool is working correctly.
