AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 51 Cryptographic libraries

zmq: apply restricted-mode privacy filtering to get_transaction_pool

Public commit record

What the developer wrote

Authored by greatjourney589

81/100 · Strong
zmq: apply restricted-mode privacy filtering to get_transaction_pool

Add an include_sensitive parameter to tx_memory_pool::get_pool_for_rpc
(and its core passthrough), mirroring the include_sensitive_data
parameter on the HTTP analog get_transactions_and_spent_keys_info.
When false, receive_time and last_relayed_time are zeroed using the
same masking already applied on the HTTP path.

The ZMQ handler in daemon_handler.cpp passes !m_restricted, so
--restricted-zmq-rpc callers now receive the same privacy-filtered view
as restricted HTTP callers instead of the unfiltered timing metadata
they previously got. Stem-phase txs continue to be excluded regardless
(relay_category::broadcasted filter unchanged).

Refs #10529.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a privacy gap in Monero's restricted ZeroMQ RPC mode. Before the patch, someone using the --restricted-zmq-rpc option could still see exact times when transactions arrived and were last relayed through the get_transaction_pool ZMQ call. The HTTP restricted mode already hid those timing details, but the ZMQ path did not. The patch adds the same on/off privacy filter to the ZMQ path so restricted callers now get zeroed-out timestamps, matching restricted HTTP behavior. Timing metadata can help an observer deanonymize or trace transactions, so this is a privacy hardening fix.

Recommended action

Apply the patch and ensure nodes running --restricted-zmq-rpc are restarted. Operators exposing ZMQ RPC publicly should verify restricted mode is enabled. No immediate incident response is indicated beyond normal patching.

Security signals we found

01

Privacy filter inconsistency between HTTP and ZMQ restricted RPC paths

02

Exposure of transaction receive_time and last_relayed_time to restricted ZMQ callers

03

Timing metadata can aid transaction-source deanonymization / network-level traffic analysis

04

Patch closes the gap by reusing existing HTTP masking logic in ZMQ path

Risk score

Why this scored 51/100

Our methodology →
Potential impact 12/30
Exploitability 10/25
Stealth signal 8/15
Affected reach 9/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.