staticaddr: multi-address - #1139
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces multi-address support for static-address deposits, significantly increasing the flexibility of loop-in and withdrawal operations. By persisting per-deposit address parameters and implementing a generation-based recovery flow, the system ensures that funds remain accessible even after local data loss. Additionally, the PR includes robust CLI updates for address funding and improved deposit reconciliation logic to handle mempool-level changes and chain reorgs. Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request implements a robust recovery system for Loop's static addresses and L402 tokens, utilizing encrypted immutable backups. Key additions include a new recover CLI command, a dedicated recovery package for backup orchestration, and significant updates to the address and deposit managers to support multi-address derivation and mempool-aware reconciliation. The loop-in FSM is also enhanced to handle fractional swaps with static change outputs and server-side risk notifications. Feedback focuses on improving the clarity of change amount logic, optimizing the performance of multiset matching during change verification, and making the retry limit for stable block height lookups configurable.
There was a problem hiding this comment.
Code Review
This pull request introduces static address recovery for Loop, enabling the restoration of L402 and static-address state from encrypted backups. It also adds support for fractional loop-ins by implementing change address derivation and handling, along with improved deposit reconciliation and validation logic. My review identified several critical issues regarding notification replay logic, performance concerns with wallet transaction scanning, and potential address leakage during retries.
bc06754 to
242a3e1
Compare
5a5c613 to
c1c691e
Compare
82ce8fa to
e481301
Compare
Register timeout-sweep confirmations by destination script instead of the originally published txid. This lets recovery detect an RBF replacement after restart with a stale txid.
Construct each cooperative MuSig2 session from the address parameters stored on its deposit. This prepares loop-ins and withdrawals to sign inputs belonging to different derived static addresses. Clean up sessions created before a later setup failure. Reject duplicate deposit outpoints to avoid leaking signer state. Validate transaction inputs, session handles, and nonce counts before signing so malformed responses fail before any signer operation.
Map every selected outpoint to the static address descriptor that derived its deposit and include those descriptors in loop-in requests. This lets the server validate mixed-address inputs independently of request order.
Include the derivation key for every withdrawal input in the server request. This lets the server validate and sign withdrawals that combine deposits from multiple derived addresses.
Join restored deposits with their persisted static-address rows and hydrate pre-migration deposits from the legacy root address. Return complete ownership metadata from deposit reads and use each deposit's own expiry during loop-in selection.
Associate fractional loop-ins with their operation-specific static change address so recovery restores the descriptor needed to reconstruct signed transactions. Backfill legacy fractional swaps to the original address.
Create a fresh static address for fractional loop-in change and send its descriptor to the server. Reconstruct signed HTLCs with the persisted parameters and verify cooperative batch change by output script.
Multi-address loop-ins sign and construct transactions from the parameters attached to each deposit and their dedicated change address. The legacy root address fields therefore became write-only, but populating them could still abort signing, sweep handling, or recovery when the root lookup failed. Remove those fields and lookups, select the FSM from the protocol version persisted with the swap, and set that version before constructing new state machines. Keep the root-parameter lookup used by autoloop expiry calculation and add regression coverage for recovery and unsupported persisted versions.
Create a fresh static address for partial-withdrawal change and persist that output from the confirmed transaction. Keep all withdrawal outputs in the PSBT without separate signing metadata while preserving full-withdrawal behavior.
Let loop static deposit create and fund a fresh receive address through lnd SendCoins. Validate funding arguments before address creation and require explicit confirmation unless --force is set, including for non-interactive and first-use deposits. Resolve requested existing addresses through the active script index rather than reconstructing every persisted address. Expose the nested request through the client RPC, require swap:execute permission, and cover the CLI and daemon funding paths. Regenerate RPC and CLI documentation.
Include the owning static address in every deposit RPC response and CLI listing. Users can distinguish deposits created by different receive and change addresses without reconstructing scripts externally. Calculate blocks until expiry from each deposit owner instead of the legacy root address, and reject deposits whose owning parameters are missing. Centralize deposit response conversion and update generated RPC artifacts, regression coverage, and command replay fixtures.
The CLI previously recognized an uninitialized static-address seed by searching arbitrary gRPC error text. Any wrapping or wording change could suppress the L402 backup warning before a user funded a newly derived address. Map ErrNoStaticAddress to codes.NotFound at the RPC boundary and classify that status in the CLI. Retain compatibility with older daemons only for an exact Unknown-status message, avoiding the broad substring match, and cover both sides with regression tests.
A static-address account can now receive deposits across multiple derived addresses, so the singular summary field can no longer describe the current receive address. Removing or repurposing field 1 would break existing clients. Keep the wire value as the legacy/root derivation address, formally deprecate it, document the expiry as the shared CSV delay, and direct CLI users to derive a fresh receive address. Rename the server locals to make the compatibility behavior explicit and regenerate protobuf and Swagger artifacts.
Cover per-deposit address ownership and operation-specific change outputs across the shared SQL persistence boundary. Reconstruct the deposit, loop-in, and withdrawal stores to verify ownership and change metadata survive restart.
Document fresh receive-address derivation, lazy seed initialization, funding-address lookup hardening, and the swap:execute permission required by address creation. Regenerate the CLI, gRPC, Swagger, and man-page documentation and add feature, breaking-change, and recovery release notes.
Follow the transaction that actually spends the watched deposit, require its confirmed form to spend every selected withdrawal input, persist that transaction, and stop republishing both the original and replacement.
Identify withdrawal change through its active change-family script instead of a fixed output index. Record amounts correctly when confirmed replacements reorder or add outputs.
Stop republishing an obsolete withdrawal when its confirmed spender consumes only part of the deposit group. Finalize spent deposits, release untouched deposits, and clear stale transaction references.
handleWithdrawal starts a long-lived spend and confirmation monitor, but the manager did not own its lifecycle. Manager.Run could return while a monitor was still transitioning deposits, updating withdrawal rows, or reading package-level logging state. Track every monitor with a WaitGroup and give the run loop a child context that is canceled on every exit path. Close request delivery, cancel the monitors, and join them before returning. Configure the test logger once and make monitor tests cancel and wait so consecutive race tests cannot overlap through the global logger.
Withdrawal spend monitoring followed an RBF replacement's txid while retaining the original destination script. Confirmation requests match both values, so a replacement paying a newly derived destination could remain invisible and leave deposits stuck in Withdrawing. Build the confirmation request from the actual spending transaction, use a positive spending height as its historical hint with the startup height as the mempool fallback, and identify change from the confirmed transaction's own destination. Persist the confirmation's block height and remove both original and replacement republish entries after resolution. Widen the manager store dependency to an interface so the complete transition and persistence path can be covered without a database, and add replacement, map-cleanup, and mempool-height regression tests.
Record the exact confirmed HTLC transaction, output index, and value so recovery sweeps the server-published output instead of reconstructing it from legacy assumptions.
4 participants
Summary
This is PR 1 of 3 in the static-address multi-address stack. It adds the core
multi-address feature; the two dependent PRs isolate address startup and
withdrawal replacement hardening.
Static-address deposits now retain the concrete address parameters they were
sent to instead of assuming every deposit belongs to one reusable output
script. Loop-ins and withdrawals can therefore spend deposits received across
multiple derived static addresses.
Key Changes
with
SendCoins.Recovery
Recovery derives receive and change candidates from the immutable static
address seed, scans wallet-visible UTXOs, and reconciles matching deposits back
into loopd with their owning address parameters.
Stack
Testing
go test -count=1 ./...make unit-racego vet ./...golangci-lint runmake mod-check docs-check fsm-check rpc-js-compilegit diff --checkPull Request Checklist
docs/release-notes/release-notes-next.md.