The Architecture of Priority: Tracking Attempts and Confirmations

[!NOTE] Technical Context: private_broadcast.h | Lines 141-147

In lines 141 through 147 of private_broadcast.h, we encounter the Priority structure. This is the "Intelligence Core" of the private broadcast module. It is the repository of cumulative statistics that allows the node to make rational decisions about which transactions deserve the network's bandwidth and which have already achieved their mission.

1. num_picked: Measuring Intent

Line 143 defines num_picked, initialized to zero. This variable tracks every time the PickTxForSend() method (discussed in Part 012) selects this transaction.

The Anti-Spam Signal

In a P2P network, "Picking" a transaction is an expensive operation. It involves encryption, packet construction, and bandwidth consumption. By tracking num_picked, the node can detect if a transaction is "Stuck." If a transaction has been picked 50 times but still has 0 confirmations, the node can conclude that the transaction is likely invalid or that the chosen peers are malicious. This "Attempt Counter" is the first line of defense against wasting system resources.

2. last_picked: The Temporal Anchor of Action

Line 144 stores last_picked, a NodeClock::time_point.

While num_picked tells us How Many, last_picked tells us When. This is the anchor for the STALE_DURATION logic. If 1 minute has passed since the last_picked time, the transaction is eligible to be picked again. This ensures a steady, rhythmic retry cadence. Without this timestamp, the node would have no way of knowing if a transaction's current broadcast attempt is "Fresh" or "Expired."

3. num_confirmed: The Metric of Success

Line 145 introduces num_confirmed. This is the ultimate "Scoreboard" for the private broadcast effort. Every time a PONG arrives and the NodeConfirmedReception() method is called (Part 014), this counter increments.

Determining Finality

In a private broadcast, the goal is often to reach a "Quorum" of peers (e.g., send the transaction to 3 different nodes to ensure it enters the global mempool). By tracking num_confirmed, the PrivateBroadcast class can decide when its job is done. Once num_confirmed reaches the target threshold, the transaction can be safely "Removed" or "Forgotten," freeing up space in the queue for the next user's data.

4. last_confirmed: The Pulse of Propagation

Finally, line 146 records last_confirmed. This is the timestamp of the most recent success.

This metric is vital for Latency Analysis. By comparing last_picked and last_confirmed, the node can calculate how long it takes for the network to respond. If the average "Pick-to-Confirm" time is 2 seconds, the node is healthy. If it jumps to 45 seconds, the node might be under a DoS (Denial of Service) attack or suffering from a severe network partition. This timestamp is the "Diagnostic Probe" that allows the developers to monitor the health of the P2P layer.

5. Architectural Synthesis: The Decision-Making Matrix

The Priority struct is a "Decision-Making Matrix." When the PickTxForSend() method is looking for the "Most Urgent" transaction, it consults these four variables for every item in the queue.

It looks for the transaction where:

• num_picked is low (Fairness).

• num_confirmed is zero (Necessity).

• last_picked is old (Persistence).

By combining these simple counters and timestamps, the architect has created a sophisticated "Prioritization Engine" that ensures maximum reliability with minimum footprint. It is a masterpiece of "Information-Light" engineering—capturing only the most essential data points to drive a complex, global behavior.

Conclusion: The Record of Performance

Lines 141-147 represent the "Performance Log" of the transaction. We now have a way to measure the history of each private broadcast attempt. With this data, the node moves from a "Static Queue" to a "Dynamic Scheduler," capable of adapting to the chaotic and adversarial reality of the Bitcoin network.

In the next batch (0022-0030), we will examine the constructor of this Priority struct and the master m_transactions map that organizes these records.