Repository navigation
fix(wallet): record our own sends in the wallet - #40
Merged
Merged
Conversation
Up to 20 payments in one transaction, for payroll, grants and invoices. The send form's "Pay several at once" takes rows (recipient or saved payee, amount, memo) or a pasted list, with one reason for the lot. wallet::prepare_payments builds them with propose_transfer and a ZIP 321 request; prepare_send is now a batch of one through the same path (the one-payment wrapper it used is exactly that). A memo too long to encode is an error instead of being dropped, and memos are trimmed, as they read back. Within a batch, the group's own address is refused: it would read as change to co-signers. Co-signers get every payment in SigningContext.payments (without memos, which they read from the transaction). check_coordinator_claims matches them to the verified payments as an unordered set, since Orchard shuffles outputs: each described payment matches a different one, and there are no others. Signing requests are now sized to fit one frostd message. The context travels hex-encoded inside the signing package, which the old 48 KiB limit on the attached PCZT didn't count, so a large enough transaction failed with "cryptography error from snow: input error". signing::signer_context_budget gives the real room for the chosen signers (tested against a serialized SendSigningPackageArgs for 2 to 40 signers), and the PCZT gets what the rest of the context leaves. One that can't fit is refused at review, saying to make fewer payments. History lists a send's external payments (TxRecord.payments). The wallet learns of its own sends only by scanning, without their fee or outputs, so the sending device shows its sends as it built them; recording them in the wallet is in TODO.md. Tested on an NU7 devnet: 20 payments, three with memos, approved and mined; 20 with full memos refused at review. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A group poll can propose payments (Poll.payments, up to 20), answered "Pay" or "Don't pay". Once Pay is agreed, the member who proposed it sends them with Send payment: wallet_send with poll_id builds the transaction from the poll itself, refusing unless this member asked it, the group agreed to pay, and it hasn't been paid. After broadcast, a PollPaid record (only the poll's author's counts) marks it paid, so it can't be sent twice, and the poll's question becomes the reason. Each approver's app checks a request naming a poll (SigningContext.poll_id) against its own copy of the poll and refuses one sent by a member other than its author, one that doesn't make exactly the proposed payments (an unordered match on address, amount and memo), or one already paid. It shows whether the group agreed, or warns that it hasn't, or that it doesn't have the poll yet. The coordinator's key, which the request's encryption authenticates, now comes with the approval event for this. Members who chose Pay are asked to approve by default. Approving automatically for them is left for the spending-limit rules. Tested on an NU7 devnet: refused before agreement and for Bob, sent by Alice and checked by Bob's app, then shown paid on both and refused a second time. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A group can adopt rules for its payments, which the sender's app and each approver's app apply when deciding whether to sign (core/src/rules.rs): - Pay only trusted payees. A payee is trusted once threshold members trust its current address: its author, and others who said so in a PayeeTrust record. Changing the address leaves only the author's trust. - Larger payments need more approvals: payments of at least an amount, together in one transaction, need more signers than the threshold. An approver counts the signers committed in the signing package (AwaitingApproval.signers), each of whose shares the signature needs. Rules are adopted by poll (Poll.rules, options Adopt / Don't adopt), and the latest set the group agreed to adopt is in effect, so changing them takes as many members as spending. create_poll refuses rules this group can't meet (more approvals than members, or no more than the threshold). commands::rules::check runs the same check on both sides: the sender's wallet_send verifies its own draft as approvers will and refuses before asking anyone; the approval gate refuses a request that breaks the rules, or whose rules it can't read, and tells the approver which rules it met. A transfer within the group makes no payments, so the rules don't apply. Interface: a Rules card on Home (in effect, and Propose rules), Trust on the Payees card, rule polls in Votes, rule errors and approval counts in the send forms, and the rules a request met in Approvals. Tested on an NU7 devnet: with "trusted payees only" adopted by poll, a payment to an untrusted address is refused before anyone is asked, and one to the trusted auditor goes through with Bob's app checking it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A new rule, GroupRules.delay: payments of at least an amount, together in one transaction, are announced in a payment poll and can be sent only once a wait (an hour to 30 days) has passed with no current member choosing Don't pay. Agreement isn't needed; one member's veto stops it for as long as they keep that answer. Each app counts the wait from when it received the announcement: the group log now records when each record arrived (GroupLog.received), and PollView.announced_at is the later of that and the time its author put on it. A backdated announcement gains nothing, and every member has the whole wait to object. commands::rules::poll_permits decides whether a poll's payments can be sent: under the delay, once ready (rules::announcement_ready); otherwise, once agreed. The sender's wallet_send refuses a poll that isn't, and a payment over the amount without one (Broken::NotAnnounced). The approval gate refuses an announcement that isn't ready on its own clock, and an unannounced large payment, including one whose poll it doesn't have. The send forms offer "Announce it" instead of review for such a payment; Votes shows an announcement as waiting, vetoed (and by whom), or ready for its author to send; Approvals shows how long ago it was announced. Message::Record's poll grew past clippy's large-variant limit, so its rules are boxed; serialization is unchanged. Tested on an NU7 devnet: with a one-hour wait adopted by poll, a large payment is refused unannounced, too soon after its announcement, and once Bob vetoes; then rules replacing those take effect. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A new rule, GroupRules.limit: members' apps may approve payments to
trusted payees by themselves while the wallet has sent less than an
amount in a period, the payment and its fee included. Each member turns
it on for their own app ("Approve automatically on this device",
PrivateSettings.auto_approve); the others approve as they choose.
rules::may_approve_automatically decides: every payment to a trusted
payee, none needing more approvals or a wait under the other rules, a
usual fee, and within what's left of the limit. The limit counts
everything the wallet sent in the period, however it was approved, so it
holds however many members turn this on: the wallet's history since the
height that long ago (by block spacing; a chain's block times needn't be
current, and a devnet's aren't), plus what this device approved
automatically in the last 70 minutes that may not be in it yet. Without
a sync in the last 15 minutes it approves nothing by itself.
The approval gate asks only after the transaction verified and every
other rule passed. An automatic approval is remembered by sighash, like
a manual one, so the transaction's later rounds go through and the limit
counts it once. The member is notified, and Approvals shows what it
approved and how much of the limit is used, or why it didn't.
Rules card: the toggle and the wallet's spending against the limit, and
the limit in Propose rules.
Tested on an NU7 devnet: with a limit adopted by poll and automatic
approval on, Bob's app approves a small payment to the trusted auditor
by itself, and leaves the next, over the limit, to Bob, saying why.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Cyze builds sends as PCZTs and broadcasts them itself, so the wallet db learned of them only by scanning: as a balance change, with no fee and no outputs (compact blocks can't be decrypted with the outgoing viewing key). History showed the fee inside the amount and no recipient or memo, for single payments and batches alike. broadcast_signed now takes a RecordSent (the wallet that built it) and, once lightwalletd accepts the transaction, stores the proven PCZT with extract_and_store_transaction_from_pczt, as a wallet that builds its own transactions does: inputs spent, fee, outputs and memos known. After broadcast, not before, so a failed broadcast doesn't leave notes marked spent until the transaction expires; best effort, so a failure is logged and the send still succeeds. A move off the old address was built from the old wallet and is left to scanning. Other members' wallets still see only the balance change (TODO.md). Tested on an NU7 devnet: Alice's history has the first payment's exact amount, fee, recipient and memo, and the batch's exact total and all 20 payments. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3 tasks done
3 tasks done
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.
Stacked on #39 (spending limits), and through it on #34–#38. Merge those first; until then this diff also shows their changes.
Summary
History showed every payment's fee inside its amount, with no recipient or memo. This applied to single payments and batches alike.
Why: Cyze builds sends as PCZTs and broadcasts them itself, so the wallet database learned of them only by scanning, as a change in balance. Compact blocks can't be decrypted with the outgoing viewing key, so the fee and outputs never reached
sent_notes.The fix: once lightwalletd accepts a transaction,
broadcast_signedstores it in the wallet that built it, usingextract_and_store_transaction_from_pczton the proven PCZT. That's what a wallet that builds its own transactions does: the inputs are marked spent, and the fee, outputs and memos are recorded.What this doesn't fix: other members' wallets still see only the balance change. TODO.md lists the options, enhancement or a group record from the sender, each with a privacy trade-off.
Changes
core/src/wallet.rs: newRecordSent;broadcast_signedtakesOption<RecordSent>and keeps the proven PCZT and verifying key to record after sending.src/commands/wallet.rs:wallet_sendrecords payments, not moves;wallet_rebroadcastrecords too.Activity.tsx: comment only.withWhatWasSentstays for sends made before this fix.Testing
cargo clippy --workspace --all-targets -- -D warningscargo test --workspacevitest(47 tests)tests/devnet_send.rs, which passed with new assertions on Alice's history:🤖 Generated with Claude Code