Skip to content

staticaddr/withdraw: harden replacement monitoring - #1215

Draft
hieblmi wants to merge 8 commits into
lightninglabs:multi-address-address-hardeningfrom
hieblmi:multi-address-withdrawal-hardening
Draft

staticaddr/withdraw: harden replacement monitoring#1215
hieblmi wants to merge 8 commits into
lightninglabs:multi-address-address-hardeningfrom
hieblmi:multi-address-withdrawal-hardening

Conversation

@hieblmi

@hieblmi hieblmi commented Aug 27, 2026

Copy link
Copy Markdown
Collaborator

Summary

This is PR 3 of 3 in the static-address multi-address stack. It depends on
#1214 and is based on multi-address-address-hardening so this PR only shows
withdrawal replacement and monitor hardening.

This follow-up:

  • validates that a confirmed replacement transaction actually spends the
    selected deposits;
  • identifies static-address change by script instead of assuming a fixed
    output index;
  • reconciles partial conflicting spends without marking untouched deposits as
    withdrawn;
  • follows the output from the transaction that really replaced the original
    withdrawal; and
  • joins withdrawal monitor goroutines during shutdown and adds multi-address
    replacement coverage.

Stack

  1. staticaddr: multi-address #1139 — multi-address core
  2. staticaddr/address: harden multi-address startup #1214 — address startup hardening
  3. This PR — withdrawal replacement hardening

Testing

  • go test -race ./staticaddr/...
  • go vet ./...
  • git diff --check

Pull Request Checklist

  • Added an entry to docs/release-notes/release-notes-next.md.

@hieblmi
hieblmi force-pushed the multi-address-withdrawal-hardening branch from 0a947a5 to 9dd7f66 Compare August 27, 2026 10:28
@hieblmi
hieblmi force-pushed the multi-address-address-hardening branch from 56dcc74 to 7c226da Compare August 27, 2026 10:28
@hieblmi
hieblmi force-pushed the multi-address-withdrawal-hardening branch from 9dd7f66 to 93bbffa Compare August 27, 2026 10:40
@hieblmi
hieblmi force-pushed the multi-address-address-hardening branch from 7c226da to e85c0d3 Compare August 27, 2026 10:40
@hieblmi
hieblmi force-pushed the multi-address-withdrawal-hardening branch from 93bbffa to 942e440 Compare August 27, 2026 11:46
@hieblmi
hieblmi force-pushed the multi-address-address-hardening branch from e85c0d3 to 6f82255 Compare August 27, 2026 11:47
@hieblmi
hieblmi force-pushed the multi-address-withdrawal-hardening branch from 942e440 to 6245c73 Compare August 27, 2026 12:41
@hieblmi
hieblmi force-pushed the multi-address-address-hardening branch from 6f82255 to c458192 Compare August 27, 2026 12:42
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.
@hieblmi
hieblmi force-pushed the multi-address-address-hardening branch from c458192 to f709e0c Compare August 28, 2026 10:34
@hieblmi
hieblmi force-pushed the multi-address-withdrawal-hardening branch from 6245c73 to 82b5b00 Compare August 28, 2026 10:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants