Context
protocol-core/convergence.md, lines 140-161:
effective_commit_depth =
raw_commit_depth
+ (witness_quorum_met ? max_witness_override_depth : 0)
Eligible branches are compared in this order:
1. Higher effective_commit_depth.
2. Witness quorum beats no quorum.
3. Higher raw_commit_depth.
4. Higher app_witness_score.
5. Lower tip_priority (privileged before ordinary).
6. Lower tip_committer.
7. Lower tip_digest.
Defect
Criterion 3 can never be the deciding factor. Two branches only reach criterion 3 if criterion 1 tied (effective_commit_depth equal) and criterion 2 tied (witness_quorum_met equal for both — i.e. both true or both false). Since effective_commit_depth = raw_commit_depth + (witness_quorum_met ? B : 0) and the boost term B is identical for both branches whenever witness_quorum_met is equal, effective_commit_depth equality between two branches forces raw_commit_depth equality between them as a matter of arithmetic. By the time criterion 3 is reached, raw_commit_depth is already guaranteed tied — the comparison is vacuous.
Failure scenario
Not a wrong-outcome bug (the chain still terminates deterministically via criterion 4+), but the spec text asserts a comparison step that can never fire, which is exactly the kind of formula defect that undermines confidence in the rest of the tie-break chain. An implementer or conformance-fixture author trying to construct a test vector where criterion 3 is the deciding rule will find it impossible, and will reasonably wonder whether the depth-boost formula, or the criteria ordering itself, has a bug elsewhere.
Suggested fix
Either remove criterion 3 as redundant (documenting why), or clarify that it exists only as a defensive/documentation-only step and can never actually decide a comparison, so implementers and test-vector authors aren't left second-guessing the algorithm.
Why not a duplicate
Distinct from open issue #250, which is about "Same-epoch races"'s ordering contradicting "Branch selection"'s overall precedence (a relationship between two different sections) — that issue does not identify or address criterion 3's internal vacuity within "Branch selection" itself.
Context
protocol-core/convergence.md, lines 140-161:Defect
Criterion 3 can never be the deciding factor. Two branches only reach criterion 3 if criterion 1 tied (
effective_commit_depthequal) and criterion 2 tied (witness_quorum_metequal for both — i.e. both true or both false). Sinceeffective_commit_depth = raw_commit_depth + (witness_quorum_met ? B : 0)and the boost termBis identical for both branches wheneverwitness_quorum_metis equal,effective_commit_depthequality between two branches forcesraw_commit_depthequality between them as a matter of arithmetic. By the time criterion 3 is reached,raw_commit_depthis already guaranteed tied — the comparison is vacuous.Failure scenario
Not a wrong-outcome bug (the chain still terminates deterministically via criterion 4+), but the spec text asserts a comparison step that can never fire, which is exactly the kind of formula defect that undermines confidence in the rest of the tie-break chain. An implementer or conformance-fixture author trying to construct a test vector where criterion 3 is the deciding rule will find it impossible, and will reasonably wonder whether the depth-boost formula, or the criteria ordering itself, has a bug elsewhere.
Suggested fix
Either remove criterion 3 as redundant (documenting why), or clarify that it exists only as a defensive/documentation-only step and can never actually decide a comparison, so implementers and test-vector authors aren't left second-guessing the algorithm.
Why not a duplicate
Distinct from open issue #250, which is about "Same-epoch races"'s ordering contradicting "Branch selection"'s overall precedence (a relationship between two different sections) — that issue does not identify or address criterion 3's internal vacuity within "Branch selection" itself.