You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a channel has anchors, lnsweep creates a first-stage htlc tx for each htlc, which includes a UTXOs from the wallet. If the commitment tx has several htlcs, we currently reuse the same UTXO in all htlc transactions, because it is still 'unspent' when we loop over htlcs. This can be tested in various regtests by forcing the client to perform a MPP:
Instead of calling wallet methods from lnsweep, we should delegate the creation of the htlc tx to the wallet.
This could be achieved by extending the "batch payment manager" in #9298.
Instead of being payment driven, the payment manager should accept 3 types of requests:
include a given output (for payment requests)
include a given input (sweep to the wallet). (we need that in order to CPFP anchor outputs)
include a given input and a given output (we need that in order to include zero-fee first-stage htlc transactions)
The text was updated successfully, but these errors were encountered:
If a channel has anchors,
lnsweep
creates a first-stage htlc tx for each htlc, which includes a UTXOs from the wallet. If the commitment tx has several htlcs, we currently reuse the same UTXO in all htlc transactions, because it is still 'unspent' when we loop over htlcs. This can be tested in various regtests by forcing the client to perform a MPP:Instead of calling wallet methods from
lnsweep
, we should delegate the creation of the htlc tx to the wallet.This could be achieved by extending the "batch payment manager" in #9298.
Instead of being payment driven, the payment manager should accept 3 types of requests:
The text was updated successfully, but these errors were encountered: