Skip to content

fix(send): harden fee loading and transaction construction - #2703

Open
ben-kaufman wants to merge 3 commits into
SatoshiPortal:developfrom
ben-kaufman:fix/send-fee-tor-fallback
Open

fix(send): harden fee loading and transaction construction#2703
ben-kaufman wants to merge 3 commits into
SatoshiPortal:developfrom
ben-kaufman:fix/send-fee-tor-fallback

Conversation

@ben-kaufman

Copy link
Copy Markdown
Collaborator

Summary

  • retry fee and mempool-server requests through embedded Tor when direct connections fail
  • fall back to conservative minimum fee rates and warn users when live rates are unavailable
  • prevent PSBT display or signing from continuing without a successfully built transaction

On networks that block direct access to the fee API, fee fetching could fail because the app did not retry the request through its embedded Tor connection. This change adds that alternate network path and keeps transaction construction usable with clearly identified fallback rates when neither live request succeeds.

Testing

  • make checks
  • fvm dart run tools/arb.dart validate
  • make translations

Added focused coverage for clearnet-to-Tor retry behavior, fee-rate fallback behavior, send-state warnings, and transaction-construction guards.

A failed transaction build (e.g. fee estimation unreachable on a
restricted network) left the confirm screen showing no fee while the
PSBT route could still be opened: ShowPsbtButton was not disabled, the
router silently converted a null PSBT to '', and UrQrGenerator turned
that into a valid-looking single-frame QR of an empty crypto-psbt.
Users (Passport, testnet) saw a static, unsignable QR instead of an
error.

- disable ShowPsbtButton when unsignedPsbt is null
- show a localized error on ShowPsbtScreen for an empty PSBT instead
  of rendering a QR
- clear the stale unsignedPsbt on every createTransaction failure path
  so a previous build's transaction (wrong amount/recipient) can never
  be signed after a rebuild fails
Fee estimation only honored the external Tor proxy (useTorProxy) and
otherwise always went direct. On networks where clearnet is blocked or
broken — the reason users run Tor in the first place — the fetch failed
while the app's embedded Tor worked fine, leaving the send flow unable
to build a transaction (reported on testnet with Passport: no fee, no
PSBT).

- .onion mempool servers now go straight through an embedded Tor
  session instead of attempting a direct connection
- a failed direct fetch retries once through embedded Tor before
  giving up (Tor startup cost only hits the failure path)
- the session's live endpoint is used, never a persisted port, which
  goes stale when embedded Tor restarts on a new random port
- custom mempool server validation now honors the external proxy for
  clearnet servers too (it previously only used Tor for .onion)
Fee loading now falls back to stale Bitcoin estimates or 1 sat/vB when the live oracle is unavailable, while preserving Liquid's canonical 0.1 sat/vB rates. The policy lives in the send use case and returns typed failures; presentation applies the result and warns when Bitcoin estimates are not live.
@ben-kaufman
ben-kaufman marked this pull request as ready for review August 21, 2026 03:34
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