net: factor urgency into transaction selection priority #35111

pull takeshikurosawaa wants to merge 1 commits into bitcoin:master from takeshikurosawaa:private-broadcast-urgency changing 3 files +85 −3

takeshikurosawaa commented at 6:35 PM on April 18, 2026: none

Problem

PickTxForSend() prioritizes transactions with fewer send attempts. A transaction that has been waiting 1 hour with 5 attempts loses to a fresh transaction with 1 attempt. This can result in long-waiting transactions being perpetually deprioritized.

Solution

Add an urgency factor to the priority function based on elapsed time since the first send attempt. Urgency is placed last in the comparison tuple so it only breaks ties between transactions with equal send history.

Changes

src/private_broadcast.h: add urgency field to Priority struct
src/private_broadcast.cpp: update DerivePriority() to track oldest pick time and calculate urgency
src/test/private_broadcast_tests.cpp: add urgency_tie_break and urgency_secondary_to_send_count test cases

Behavior

Scenario	Result
TxA: 5 picks, 60min waiting vs TxB: 1 pick, 0min	TxB wins
TxA: 3 picks, 30min waiting vs TxB: 3 picks, 20min	TxA wins (urgency)
TxA: 0 picks, 10min waiting vs TxB: 0 picks, 0min	TxA wins (urgency)

No behavior change for transactions with different send attempt counts.

net: factor urgency into transaction selection priority

Previously, PickTxForSend() would always prioritize transactions with
fewer send attempts, even if those transactions had been waiting much
longer than newer alternatives. This could result in long-waiting
transactions being perpetually deprioritized.

The priority function now includes an urgency factor based on elapsed
time since the first send attempt. Urgency is placed after the
existing fairness metrics (num_picked, num_confirmed) so that it only
breaks ties between transactions with equal send history. This ensures
that transactions which have been waiting significantly longer will
eventually be selected over fresh alternatives.

No behavior change for transactions with different send attempt counts.

eaebd464c6

DrahtBot added the label P2P on Apr 18, 2026
DrahtBot commented at 6:36 PM on April 18, 2026: contributor



The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Reviews

See the guideline for information on the review process. A summary of reviews will appear here.
sedited commented at 7:25 PM on April 18, 2026: contributor

Did you use an LLM to write this? In the message you say "No behavior change for transactions with different send attempt counts.", but in the problem example you distinguish between attempts. How does that make sense? Can you explain the actual change in your own words?
andrewtoth commented at 7:40 PM on April 18, 2026: contributor

How realistic is this starvation scenario?

A transaction goes stale after 1 minute if it has not been received back from the network, and this check runs every 2-3 minutes. To starve a transaction a new transaction must be submitted every 2-3 minutes, and none of the new transactions can be received back from the network.
takeshikurosawaa commented at 8:04 PM on April 18, 2026: none

Fair point. I overstated the motivation here, and I don't think this is the right change.

I'm going to close the PR.
takeshikurosawaa closed this on Apr 18, 2026
takeshikurosawaa deleted the branch on Apr 19, 2026

Contributors

Labels

net: factor urgency into transaction selection priority #35111

Problem

Solution

Changes

Behavior

Reviews