Skip to content

btc: connect-authoritative won-block submit (always-fire submitblock RPC) — G3b leg-(b) connect fix - #530

Merged
frstrtr merged 1 commit into
masterfrom
btc/g3b-connect-authoritative-submitblock
Jun 26, 2026
Merged

btc: connect-authoritative won-block submit (always-fire submitblock RPC) — G3b leg-(b) connect fix#530
frstrtr merged 1 commit into
masterfrom
btc/g3b-connect-authoritative-submitblock

Conversation

@frstrtr

@frstrtr frstrtr commented Jun 26, 2026

Copy link
Copy Markdown
Owner

What

Fixes the G3b leg-(b) connect blocker: a won block was relayed but never connected the tip, silently losing the subsidy.

The stratum won-block path called submit_block_with_fallback, whose P2P-primary policy treats a P2P relay success as "reached the network" and short-circuits the submitblock RPC. But a P2P relay success only means the block was announced (a cmpctblock header). Under compact-block relay the daemon then requests the body via getblocktxn, which the c2pool broadcaster does not serve, so the daemon never ConnectBlock()s and the block is silently lost despite relay_p2p() returning true.

Change (BTC-lane-fenced)

  • Add btc::coin::broadcast_block_for_connect + Node::submit_block_for_connect: fires the submitblock RPC unconditionally (connect-authoritative -- submitblock delivers the full block, so it always connects), keeping the P2P relay for best-effort fast propagation.
  • Wire the stratum won-block path (main_btc.cpp) to the connect-authoritative call.
  • New block_broadcast_connect_test.cpp (rides the allowlisted btc_share_test, no NOT_BUILT risk) -- 5 KATs pin always-fire, P2P-fail-still-connects, both-fail-reaches-neither, null-P2P, plus a side-by-side contrast lock that the fallback policy still short-circuits.

What is NOT changed

The cross-coin SSOT core::broadcast_block_with_fallback contract is untouched. The "give submitblock primacy / always-fire" convergence is the v37 broadcaster-convergence shape held on HOLD (#500 / #498); only the BTC won-block connect path opts into it locally here. The existing block_broadcast_guard_test (6 KATs) still passes unchanged, proving the fallback policy is intact.

Verify

btc_share_test builds clean; BtcBlockBroadcastConnect.* (5) + BtcBlockBroadcastGuard.* (6) = 11/11 PASS.

Held for operator tap -- I do not self-merge.

…RPC)

The won-block path called submit_block_with_fallback, whose P2P-primary
policy treats a cmpctblock announce-success as reaching the network and so
short-circuits the submitblock RPC. But an announce does NOT connect the
tip: under compact-block relay the daemon requests the body via getblocktxn,
which the c2pool broadcaster does not serve, so the block never
ConnectBlock()s and the subsidy is silently lost (G3b leg-(b) blocker).

Add a BTC-lane-fenced broadcast_block_for_connect / submit_block_for_connect
that fires the submitblock RPC UNCONDITIONALLY (connect-authoritative),
keeping the P2P relay for best-effort fast propagation, and wire the stratum
won-block path to it. The cross-coin core::broadcast_block_with_fallback
contract is untouched (the always-fire convergence stays HOLD per #500/#498);
only the BTC connect path opts in. New block_broadcast_connect_test.cpp rides
the allowlisted btc_share_test (no NOT_BUILT risk) and pins the always-fire
invariant plus a side-by-side contrast lock that the fallback policy still
short-circuits.
@frstrtr
frstrtr merged commit 015dc02 into master Jun 26, 2026
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant