Implement z_sendfromaccount, z_proposetransaction, and z_finalizetransaction

[dannywillems]

Stacked on #585 (transparent spending in z_sendmany), which is stacked on #586 (Docker fix). Base auto-retargets to main as each merges.

History rebuilt. The previous 13 commits predated the backend split (they edited zallet/src/…, which is now zallet-core/src/…) and predated several of their own pieces landing upstream, so they could not be rebased. This is the same work rebuilt as 6 commits on the current tree.

What this adds

Three account-based transaction methods. Where z_sendmany takes an address as its source of funds, these take an account UUID plus a fund_source naming where within the account the funds may be drawn from: "orchard", "sapling", "any_transparent", or an explicit array of transparent addresses.

Method	Signs?	Privacy policy
z_proposetransaction	no — returns an inspectable PCZT	reported, not required
z_finalizetransaction	yes — signs and broadcasts a PCZT	required; checked against the reported one
z_sendfromaccount	yes — one shot, returns the txid	required up front

The split exists so a caller can see what the transaction would reveal and then decide, instead of having to commit to a privacy policy before knowing, as z_sendmany demands.

The interesting part: fund_source is just a SpendPolicy

This is where landing transparent spending first pays off, and it is most of the review.

zcash_client_backend could not select transparent inputs when these methods were first written. So the original implementation carried its own transparent input selector (propose_transparent_spend) and an InputSource wrapper to filter notes by pool (FundSourceFilter) — around 1097 lines, with each RPC forking on if spends_transparent { … } else { … }.

librustzcash now does both: TransparentSpendPolicy names which transparent addresses may be drawn upon, and SpendPolicy::shielded_pools restricts the shielded pools. So all of it collapses into a match:

pub(super) fn spend_policy(&self) -> SpendPolicy {
    match self {
        Self::Orchard => SpendPolicy::shielded_pools([ShieldedPool::Orchard, ShieldedPool::Ironwood]),
        Self::Sapling => SpendPolicy::shielded_pools([ShieldedPool::Sapling]),
        Self::AnyTransparent => SpendPolicy::shielded_pools([])
            .with_transparent(TransparentSpendPolicy::any_account_addr()),
        Self::Transparent(addrs) => SpendPolicy::shielded_pools([])
            .with_transparent(TransparentSpendPolicy::from_addresses(addrs)),
    }
}

fund_source.rs is now ~120 lines, the hand-rolled selector and the InputSource wrapper are gone, and both forks disappear. There is one proposal path — propose_transfer_with_policy — which z_sendmany also goes through, so the account methods differ from it only in the SpendPolicy they ask for. Two of the six commits exist to make that sharing real rather than incidental.

What fund_source guarantees

It isolates. A source that cannot cover the payment reports insufficient funds; it never quietly reaches into another pool. Naming sapling when the money is in Orchard must fail, or "spend my Sapling" silently spends Orchard — the accounting error the parameter exists to prevent. Same for an address list: sweeping one deposit address must not reach into a sibling address of the same account.

Both are pinned by tests (zcash/integration-tests#145, FS1/FA2 and two dedicated scenarios) precisely because a fallback bug would pass every happy path and only surface as an accounting error.

fund_source: "orchard" permits Ironwood too. Ironwood notes are Orchard-shaped, and once NU6.3 activates an account's Orchard-receiver funds are held there rather than in the legacy Orchard pool. Restricting to ShieldedPool::Orchard alone would report insufficient funds for an account whose Orchard money is all in Ironwood. The original branch predates Ironwood and never faced this; flagging it as a deliberate choice.

Already upstream, dropped

7 of the original 13 commits: the AmountParameter / build_request extraction, its proptests, required_privacy_policy, the NU6.3 regtest activation height, and the librustzcash/zebra pin bumps — main is now newer than what the branch pinned.

Dependencies

• The pczt crate, at the librustzcash rev the workspace already pins, added to all three manifests so check-lockstep.sh still sees one rev.
• The pczt feature on zcash_client_backend, and serde on zcash_client_sqlite (create_pczt_from_proposal serializes the account id).
• bip32 at the 0.6 line in zallet-core: the workspace entry is the 0.2 line used by the zcashd-import path, and extract_bip_44_fields speaks the newer one.

Known weakness, ported as-is

z_finalizetransaction checks the caller's policy against the one recorded for that PCZT at proposal time. On a cache miss (eviction, restart, or a PCZT proposed elsewhere) the requirement cannot be re-derived faithfully from the PCZT, so the supplied policy is accepted as acknowledgement only — see #217. This is the existing design; I ported it faithfully rather than silently changing the security posture, but it is a real gap: a caller who proposes elsewhere can under-acknowledge.

Testing

Clippy clean, 205 zallet-core unit tests pass (8 new for fund_source, incl. proptests over arbitrary seeds), all three workspaces build, librustzcash rev in lockstep across the three lockfiles.

Covered end to end by zcash/integration-tests#145, all passing against a zallet built from this branch: parameter validation, every fund source, propose/review/finalize, and 11 real-world scenarios.

ZIT-Revision: dw/sendfromaccount

[dannywillems]

Trying out the new RPC methods

zallet rpc <method> <params...>, where each param is a JSON value (so strings are quoted inside the shell quotes). zallet rpc auto-authenticates via the datadir cookie.

Prerequisites

cargo build --release --features rpc-cli      # binary at target/release/zallet
zallet start                                  # synced zebrad; wallet unlocked + funded

Discover an account and a destination address

zallet rpc z_listaccounts                                  # copy a "uuid"
zallet rpc z_getaddressforaccount '"<ACCOUNT_UUID>"'

1. Propose → inspect → finalize (the PCZT flow)

z_proposetransaction account fund_source recipients [minconf]

# fund_source: "orchard" | "sapling" | "any_transparent" | ["t-addr", ...]
zallet rpc z_proposetransaction \
  '"<ACCOUNT_UUID>"' \
  '"orchard"' \
  '[{"address":"<DEST_ADDRESS>","amount":"0.002"}]' \
  '1'

Returns { "pczt": "<hex>", "privacy_policy": "<Policy>" }. Then:

z_finalizetransaction account pczt privacy_policy

zallet rpc z_finalizetransaction \
  '"<ACCOUNT_UUID>"' \
  '"<PCZT_HEX>"' \
  '"<PRIVACY_POLICY>"'

The privacy_policy passed to finalize must be at least as permissive as the one the proposal returned (it is enforced via a proposal-policy cache).

2. One-shot send

z_sendfromaccount account fund_source recipients [minconf] privacy_policy

zallet rpc z_sendfromaccount \
  '"<ACCOUNT_UUID>"' \
  '"orchard"' \
  '[{"address":"<DEST_ADDRESS>","amount":"0.002"}]' \
  '1' \
  '"AllowRevealedAmounts"'

Notes

• Multiple recipients (exchange-style batch): add objects to the array, e.g. '[{"address":"addr1","amount":"0.002"},{"address":"addr2","amount":"0.005"}]'.
• Memo (shielded recipients only): add "memo":"<hex>" to a recipient object.
• minconf is optional; pass null for the configured default.
• Privacy policy values (strictest → loosest): FullPrivacy, AllowRevealedAmounts, AllowRevealedRecipients, AllowRevealedSenders, AllowFullyTransparent, AllowLinkingAccountAddresses, NoPrivacy. The proposal reports the minimum required.

Raw JSON-RPC alternative

curl -s --user "<rpcuser>:<rpcpass>" -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"z_sendfromaccount","params":["<ACCOUNT_UUID>","orchard",[{"address":"<DEST_ADDRESS>","amount":"0.002"}],1,"AllowRevealedAmounts"]}' \
  http://127.0.0.1:<rpc-port>/

---

This usage guide was generated by Claude (Claude Code).

[dannywillems]

Integration testing: transparent fund_source selects no inputs

While writing integration tests for this PR (regtest Z3 stack: zebrad + zaino + zallet), I found that the transparent fund sources select zero inputs in propose_transfer, so a transparent-sourced send always fails with Insufficient balance (have 0, ...). The shielded fund sources ("orchard", "sapling") work correctly.

This affects z_sendfromaccount and z_proposetransaction with fund_source = "any_transparent" and the ["<taddr>"] array form.

Repro / evidence

• An account holds a spendable, non-coinbase transparent UTXO (created by de-shielding orchard → its own taddr). It is confirmed spendable by both z_getbalances (transparent spendable ≥ the amount) and z_listunspent (stable across the scan settle).
• z_proposetransaction(account, "any_transparent", [{address: <shielded>, amount: "1.0"}], 1) →
  Failed to propose transaction: Insufficient balance (have 0, need 100010000 including fee).
• The "orchard" fund source on the identical flow proposes and finalizes correctly (exact balances), so FundSourceFilter's shielded path works; only its transparent path yields nothing.
• This is not the coinbase-maturity rule: the UTXO above is a regular non-coinbase output and still isn't selected. (Coinbase remaining only-spendable-via-z_shieldcoinbase is a separate, expected property.)

Likely area

FundSourceFilter's InputSource impl for the transparent path (get_spendable_transparent_outputs / get_unspent_transparent_output / get_transparent_receivers) in zallet/src/components/json_rpc/fund_source.rs, and how propose_transfer drives transparent input selection when FundSource::allowed_pools() is empty (the AnyTransparent / Transparent cases). Worth checking whether propose_transfer ever consults transparent outputs for a transfer whose recipients are shielded, and that the account's transparent receiver for the funded address is enumerated.

A Rust e2e mirroring the existing transparent_shielding_round_trip_signs_transparent_inputs test (which injects a WalletTransparentOutput) but proposing with FundSource::AnyTransparent should reproduce have 0.

Test status

The integration tests for the orchard/sapling fund sources, the PCZT propose → finalize round trip, and all validation paths pass. The transparent-source positive tests are skipped with a TODO referencing this issue and can be re-enabled once transparent selection works. Reference: wallet_z_proposetransaction.py (R2) and wallet_z_sendfromaccount.py on the dw/sendfromaccount branch of zcash/integration-tests.

(Found while testing with Claude Code.)

[dannywillems]

Verified fixed by 2f696f1 (Spend transparent UTXOs for transparent fund sources). Re-ran the integration tests against a fresh build (--no-default-features --features zaino --features zcashd-import):

• wallet_z_sendfromaccount.py is green, with the transparent fund-source tests re-enabled:
  • any_transparent under FullPrivacy → refused.
  • [<taddr>] array → transparent recipient credited the exact amount.
  • any_transparent → transparent recipient credited the exact amount.
  • [<unfunded taddr>] → insufficient (array restriction holds).
• wallet_z_proposetransaction.py still green (no regression).

One behavioural note the tests now encode: a transparent fund source pays transparent recipients only — sending to a shielded address is rejected with "a transparent fund source supports only transparent recipients; use a shielded fund source to send to shielded addresses" (single-step proposals can't carry an ephemeral shielded change output). The tests create non-coinbase transparent UTXOs by de-shielding (coinbase remains spendable only via z_shieldcoinbase).

The transparent positive tests are no longer skipped; the dw/sendfromaccount branch of zcash/integration-tests is updated.

[dannywillems]

Bug found while adding adversarial tests: a rejected/double-spend transaction crashes the whole wallet

While writing edge-case tests for the propose/finalize split, I hit a reproducible crash that takes down the entire zallet daemon.

Repro (regtest, Z3 stack):

1. z_proposetransaction twice with the same account, fund source, and recipient, building two proposals p1, p2 over the same notes (the greedy selector picks the same inputs from identical account state). Re-finalizing a single already-spent PCZT triggers the same path.
2. z_finalizetransaction(account, p1, policy) → confirms normally.
3. z_finalizetransaction(account, p2, policy) → builds, signs, and broadcasts a double-spending transaction.

Observed: the second finalize does not detect that the inputs are already spent. The network rejects the broadcast, and then the wallet's sync task dies:

Wallet data-requests sync task exited wallet_sync_result=Err(... source: Some(Chain(Backend(ChainIndexError {
  kind: InternalServerError,
  message: "critical error in backing block source: could not fetch transaction data:
            unexpected error response from server: RPC Error (code: -5):
            No such mempool or main chain transaction",
  source: Some(BlockchainSourceError(Unrecoverable(...))) }))) ...)
Exiting Zallet because an ongoing task exited; asking other tasks to stop
Shutting down Zallet

All subsequent RPCs get connection-refused — the daemon is gone.

Impact: any transaction the wallet broadcasts but the network then rejects (a double-spend here, but plausibly any conflict/eviction) is treated as Unrecoverable by the data-requests sync task, which exits the whole process. That is a wallet-wide DoS triggerable by a stale/duplicate PCZT.

Suggested fixes (either/both):

• z_finalizetransaction should reject a PCZT whose inputs are already spent (before signing/broadcasting), rather than emit a guaranteed-invalid transaction.
• The data-requests sync task should treat "no such mempool or main chain transaction" for a locally-broadcast tx as recoverable (drop/mark the tx) rather than exiting the daemon.

Test status: I added R4 (finalizing under a more-permissive policy succeeds), R5 (wrong-account finalize rejected), and R6 (tampered PCZT rejected) to wallet_z_proposetransaction.py, all green. The double-spend case (R3) is skipped with a comment pointing here, since it crashes the wallet; happy to re-enable it (asserting the second finalize is rejected and the recipient is not paid twice) once this is addressed.