test framework: cover the zallet#644 mining-pool payout gather scenario#176
Open
pacu wants to merge 1 commit into
Open
test framework: cover the zallet#644 mining-pool payout gather scenario#176pacu wants to merge 1 commit into
pacu wants to merge 1 commit into
Conversation
zcash/zallet#644 reports that a wallet created from scratch fragments its transparent funds onto internal change addresses on every t->t send, after which the account reports a spendable total that no single-address source can pay in one transaction. The z_sendfromaccount `any_transparent` fund source is the capability that closes this gap. Add a scenario that reproduces the miner's pipeline end to end on a fresh account: coinbase -> shield -> de-shield onto the pool's own payout addresses, a t->t send whose change lands on a wallet-chosen internal address (asserted), a payout round that exceeds every single address while the account balance covers it (asserted), the two refusals (a single-address source reports insufficient funds; any_transparent under AllowFullyTransparent is an under-acknowledgement, since gathering links addresses), and finally one any_transparent + NoPrivacy transaction paying all three miners by gathering the change fragment -- with zero shielded inputs while the account still holds Orchard notes, the guarantee exchange-bound payouts need. Adds a transparent_input_addresses helper to util.py that resolves each transparent input's funding address from the node, mirroring transparent_output_addresses. Verified against the Z3 stack (zebrad + zainod + zallet built from zcash/zallet branch dw/sendfromaccount): wallet_z_send_scenarios.py passes in 441s with the new scenario included. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017WB1TU6tyLmMa1n4SQ9XgK
pacu
marked this pull request as ready for review
July 17, 2026 20:46
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #175. (The underlying wallet issue is zcash/zallet#644, resolved by zcash/zallet#531 — this scenario locks the fix in.)
Targets
dw/sendfromaccount(the integration-test side of zcash/zallet#531) — meant to merge into that branch so the scenario ships with the z_sendfromaccount coverage.What this adds
One scenario in
wallet_z_send_scenarios.py,scenario_mining_pool_payout_gathers_fragmented_funds, reproducing zcash/zallet#644 end to end on a fresh account and showing that theany_transparentfund source resolves it:z_shieldcoinbase→ de-shield 2.0 + 2.0 onto the pool's own payout t-addrs.any_transparentunderAllowFullyTransparentis refused (gathering forces ≥2 input addresses, which with transparent recipients requiresNoPrivacy) and moves nothing.z_sendfromaccount(pool, "any_transparent", …, "NoPrivacy")pays all three miners exactly; the transaction is asserted to gather ≥2 inputs from >1 distinct address including the internal change fragment, and to spend zero shielded notes while the account still holds Orchard — the exchange-compatibility guarantee transparent payouts need.Also adds a
transparent_input_addresseshelper toutil.py(resolves each transparent input's funding address from the node, mirroringtransparent_output_addresses) and aqa/CHANGELOG.mdentry.Verification
Ran the full
wallet_z_send_scenarios.pyagainst the Z3 stack — zebrad + zainod test binaries, zallet + zallet-zaino built (release) from zcash/zallet branchdw/sendfromaccount:All pre-existing scenarios still pass with the new one wired in between reserve consolidation and the Sapling payout.
🤖 Generated with Claude Code
https://claude.ai/code/session_017WB1TU6tyLmMa1n4SQ9XgK