Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add configurable threshold on maximum anchor fee #2816

Merged
merged 2 commits into from Feb 5, 2024

Conversation

t-bast
Copy link
Member

@t-bast t-bast commented Feb 5, 2024

We previously bumped up to 5% of our channel balance when no HTLCs were at risk. For large channels, 5% is an unreasonably high value. In most cases it doesn't matter, because the transaction confirms before we try to bump it to unreasonable levels. But if the commitment transaction was pruned and couldn't be relayed to miners, then eclair would keep trying to bump until it reached that threshold. We now restrict this to a value configurable by the node operator. Note that when HTLCs are at risk, we may still bump up to the HTLC amount, which may be higher than this new configuration parameter.

We also limit the feerate used for fee-bumping based on the fastest feerate returned by our fee estimator. It doesn't make sense
to use much higher values, since this feerate should guarantee that the transaction is included in the next block.

We previously bumped up to 5% of our channel balance when no HTLCs were
at risk. For large channels, 5% is an unreasonably high value. In most
cases it doesn't matter, because the transaction confirms before we try
to bump it to unreasonable levels. But if the commitment transaction
was pruned and couldn't be relayed to miners, then eclair would keep
trying to bump until it reached that threshold. We now restrict this to
a value configurable by the node operator. Note that when HTLCs are at
risk, we still bump up to the HTLC amount, which may be higher than the
new configuration parameter: we want that behavior as a scorched earth
strategy against pinning attacks.
We add a new limit to the feerate used for fee-bumping, based on the
fastest feerate returned by our fee estimator. It doesn't make sense
to use much higher values, since this feerate should guarantee that
the transaction is included in the next block.
@t-bast t-bast requested a review from pm47 February 5, 2024 06:39
@codecov-commenter
Copy link

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (aae16cf) 85.98% compared to head (a8bd6ae) 85.93%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2816      +/-   ##
==========================================
- Coverage   85.98%   85.93%   -0.05%     
==========================================
  Files         217      217              
  Lines       18248    18250       +2     
  Branches      800      759      -41     
==========================================
- Hits        15690    15683       -7     
- Misses       2558     2567       +9     
Files Coverage Δ
...re/src/main/scala/fr/acinq/eclair/NodeParams.scala 93.41% <100.00%> (+0.02%) ⬆️
...r/acinq/eclair/blockchain/fee/OnChainFeeConf.scala 95.00% <ø> (ø)
...q/eclair/channel/publish/ReplaceableTxFunder.scala 85.05% <100.00%> (-0.45%) ⬇️

... and 5 files with indirect coverage changes

@t-bast t-bast merged commit 5b1c69c into master Feb 5, 2024
1 check passed
@t-bast t-bast deleted the max-anchor-fee-without-htlcs branch February 5, 2024 13:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants