feat: recheck on-chain required amount against actual UTXO count#930
Draft
dangershony wants to merge 1 commit into
Draft
feat: recheck on-chain required amount against actual UTXO count#930dangershony wants to merge 1 commit into
dangershony wants to merge 1 commit into
Conversation
…r funds arrive The signing transaction for on-chain invoice payments spends ALL UTXOs on the funding address and pays ~68 vB per input. If the user's payment arrives as multiple UTXOs (two separate sends, exchange withdrawal splits, RBF leftovers), the originally displayed amount no longer covers the miner fee, and BuildInvestmentDraft fails with 'Insufficient funds' after the payment was declared received. Add PaymentFlowConfig.OnChainRequiredForUtxoCount: after MonitorAddressForFunds succeeds, recompute the required amount for the actual detected UTXO count. If the received total is short, tell the user the exact shortfall and keep monitoring for the top-up instead of proceeding to a signing failure. Also add an EstimateOnChainRequired overload that accepts an input count.
Member
Author
|
I am not convinced this commit should go in |
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
1 participant
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.
Problem
Follow-up to #923 and companion to #929 (this one targeted at the next release).
The estimate shown to the user assumes a fixed number of inputs, but the signing path (
AddInputsFromAddressAndSignTransaction) spends all UTXOs on the funding address and pays ~68 vB per input. If the payment arrives as multiple UTXOs (two separate sends, exchange withdrawal splits, RBF leftovers), the paid amount can no longer cover the miner fee —MonitorAddressForFundsdeclares the payment received, thenBuildInvestmentDraftfails with "Insufficient funds".#929 mitigates this with a static 3-input buffer; this PR makes the flow correct for any UTXO count.
Fix
PaymentFlowConfig.OnChainRequiredForUtxoCount— optional delegate that recomputes the required total for the actual number of detected UTXOs.EstimateOnChainRequiredoverload accepting aninputCount(existing signature delegates with count 1, so fix: budget for up to 3 inputs in on-chain required amount estimate #929's padding merges cleanly on top).PaymentFlowViewModel.PayToOnChainAddressAsync— after funds arrive, recheck against the actual UTXO count; if short, show the exact shortfall ("Payment arrived in N parts — please send X sats more") and keep monitoring for the top-up instead of proceeding to a signing failure.InvestPageViewModelwires the delegate (invest flow only; deploy is unaffected as it doesn't restrict signing to the funding address).Lightning/Boltz claims always deliver a single UTXO, so the recheck loop is a no-op on that path.
Known caveat
The top-up monitor reuses
MonitorAddressForFunds, which (via the mempool polling service) tracks unconfirmed UTXOs. If the first payment confirms before the top-up arrives, the aggregate check may need revisiting — worth verifying with a signet UAT run before merging. Marked as draft for the next release accordingly.