_posts: LND'S Deadline-Aware Budget Sweeper #7
Conversation
morehouse
force-pushed
the
lnd_deadline_aware_budget_sweeper
branch
from
eb5e5fb to
0b7fdd7
Compare
yyforyongyu
left a comment
yyforyongyu
left a comment
There was a problem hiding this comment.
Very well put, thanks!
|
|
||
| In this strategy, the fee rate estimator is used to determine the initial fee rate, after which a fixed multiplier is used to increase fee rates for each RBF transaction. | ||
|
|
||
| [eclair](https://github.com/ACINQ/eclair/blob/95bbf063c9283b525c2bf9f37184cfe12c860df1/eclair-core/src/main/scala/fr/acinq/eclair/channel/publish/ReplaceableTxPublisher.scala#L221-L248) uses this strategy when deadlines are within 6 blocks, increasing fee rates by 20% each block. |
There was a problem hiding this comment.
TIL - do you happen to know whether they cap the fees? Given 20%, the fee rate doubles after 4 blocks😂
There was a problem hiding this comment.
eclair caps it by input amount: https://github.com/ACINQ/eclair/blob/e3b3261c2cc19e21f70ec4be56f5a851e98625bb/eclair-core/src/main/scala/fr/acinq/eclair/channel/publish/ReplaceableTxFunder.scala#L98
LDK is more complicated -- when a wallet input is needed, LDK tells the API user what feerate is needed and the user is responsible for constructing the needed transaction and publishing it. For HTLC claims, LDK's documentation suggests that the user should not claim the HTLC if the fee needed is larger than the HTLC value: https://github.com/lightningdevkit/rust-lightning/blob/4c43a5b3df2afc7ffb74df84168aafdf47b965a2/lightning/src/events/bump_transaction.rs#L188-L191.
But I don't see any similar recommendation for commitment transactions, so it's possible that users will overpay for those...
Do you think it's worth mentioning this in the blog post, or is that too much information?
There was a problem hiding this comment.
Given that overshooting fees are not covered here, I'd say leave it. Tho may be one sentence there saying it's capped by the input amount, sth like,
| [eclair](https://github.com/ACINQ/eclair/blob/95bbf063c9283b525c2bf9f37184cfe12c860df1/eclair-core/src/main/scala/fr/acinq/eclair/channel/publish/ReplaceableTxPublisher.scala#L221-L248) uses this strategy when deadlines are within 6 blocks, increasing fee rates by 20% each block. | |
| [eclair](https://github.com/ACINQ/eclair/blob/95bbf063c9283b525c2bf9f37184cfe12c860df1/eclair-core/src/main/scala/fr/acinq/eclair/channel/publish/ReplaceableTxPublisher.scala#L221-L248) uses this strategy when deadlines are within 6 blocks, increasing fee rates by 20% each block, and caps the fees paid by the input amount. |
morehouse
force-pushed
the
lnd_deadline_aware_budget_sweeper
branch
from
7c61de4 to
275a3c4
Compare
|
@Arvin21M: I plan to publish this blog post tomorrow. If you have a chance to review it, I'd really appreciate it. |
Arvin21M
left a comment
Arvin21M
left a comment
There was a problem hiding this comment.
- A few small copy edit suggestions.
- All links work and appear to be pointing to the proper destination.
- Great work!
| When an unreliable (or malicious) Lightning node goes offline while HTLCs are in flight, the other node in the channel can no longer claim the HTLCs *off chain* and will eventually have to force close and claim the HTLCs *on chain*. | ||
| When this happens, it is critical that all HTLCs are claimed before certain deadlines: | ||
|
|
||
| - Incoming HTLCs need to be claimed before their timelocks expire and the channel counterparty can submit a competing timeout claim. |
There was a problem hiding this comment.
| - Incoming HTLCs need to be claimed before their timelocks expire and the channel counterparty can submit a competing timeout claim. | |
| - Incoming HTLCs need to be claimed before their timelocks expire; otherwise, the channel counterparty can submit a competing timeout claim. |
| When this happens, it is critical that all HTLCs are claimed before certain deadlines: | ||
|
|
||
| - Incoming HTLCs need to be claimed before their timelocks expire and the channel counterparty can submit a competing timeout claim. | ||
| - Outgoing HTLCs need to be claimed before their corresponding upstream HTLCs expire and the upstream node can reclaim them on chain. |
There was a problem hiding this comment.
| - Outgoing HTLCs need to be claimed before their corresponding upstream HTLCs expire and the upstream node can reclaim them on chain. | |
| - Outgoing HTLCs need to be claimed before their corresponding upstream HTLCs expire; otherwise, the upstream node can reclaim them on-chain. |
| --- | ||
|
|
||
| Starting with [v0.18.0](https://github.com/lightningnetwork/lnd/releases/tag/v0.18.0-beta), LND has a completely rewritten *sweeper* subsystem for managing transaction batching and fee bumping. | ||
| The new sweeper uses HTLC deadlines and fee budgets to compute a *fee rate curve* over which urgent transactions are fee bumped. |
There was a problem hiding this comment.
| The new sweeper uses HTLC deadlines and fee budgets to compute a *fee rate curve* over which urgent transactions are fee bumped. | |
| The new sweeper uses HTLC deadlines and fee budgets to compute a *fee rate curve*, dynamically adjusting fees (fee bumping) to prioritize urgent transactions. |
Co-authored-by: Yong Yu <yong2452@gmail.com>
morehouse
force-pushed
the
lnd_deadline_aware_budget_sweeper
branch
from
275a3c4 to
fed6043
Compare
@yyforyongyu: here's the initial outline.