Relax chainfee requirements #6976
Closed
Conversation
This file contains 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
vincenzopalazzo
requested changes
Jan 4, 2024
| @@ -562,7 +562,7 @@ static bool local_opener_has_fee_headroom(const struct channel *channel, | |||
|
|
|||
| /* Now, how much would it cost us if feerate increases 100% and we added | |||
| * another HTLC? */ | |||
| fee = commit_tx_base_fee(2 * feerate, untrimmed + 1, | |||
| fee = commit_tx_base_fee(1.1 * feerate, untrimmed + 1, | |||
There was a problem hiding this comment.
maybe the answer is inside the issue description, but would be good to add a comment on why we are adding this const value?
There was a problem hiding this comment.
Added a comment in the commit description.
JssDWt
force-pushed
the
relax-chainfee-requirements
branch
from
d03df24
to
21df515
Compare
When the node has a small channel and the current chain fees are at an all time high, adding 10% to the chain fee rate for security is sufficient. Especially with anchors/zero-fee-htlc-tx.
JssDWt
force-pushed
the
relax-chainfee-requirements
branch
2 times, most recently
from
d03df24
to
9e1d37e
Compare
|
I pushed the wrong branch accidentally. Currently pushed the right branch again and rebased. |
cdecker
added a commit
to cdecker/lightning
that referenced
this pull request
Feb 11, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes ElementsProject#6974 Closes ElementsProject#6976
Looks good. I'll go ahead and close this PR in favor of #7063 |
cdecker
added a commit
to cdecker/lightning
that referenced
this pull request
Feb 13, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes ElementsProject#6974 Closes ElementsProject#6976
cdecker
added a commit
to cdecker/lightning
that referenced
this pull request
Feb 16, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes ElementsProject#6974 Closes ElementsProject#6976
cdecker
added a commit
to cdecker/lightning
that referenced
this pull request
Feb 21, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes ElementsProject#6974 Closes ElementsProject#6976
cdecker
added a commit
to cdecker/lightning
that referenced
this pull request
Feb 21, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes ElementsProject#6974 Closes ElementsProject#6976
rustyrussell
pushed a commit
to cdecker/lightning
that referenced
this pull request
May 9, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes ElementsProject#6974 Closes ElementsProject#6976
rustyrussell
pushed a commit
to cdecker/lightning
that referenced
this pull request
May 9, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes ElementsProject#6974 Closes ElementsProject#6976 [Fixed up all the other changes required, including spendable calcualtion comments and tests --RR] Header from folded patch 'wip.patch':
endothermicdev
pushed a commit
to cdecker/lightning
that referenced
this pull request
May 9, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes ElementsProject#6974 Closes ElementsProject#6976 [Fixed up all the other changes required, including spendable calcualtion comments and tests --RR] Header from folded patch 'wip.patch':
rustyrussell
pushed a commit
to cdecker/lightning
that referenced
this pull request
May 10, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes ElementsProject#6974 Closes ElementsProject#6976 [Fixed up all the other changes required, including spendable calcualtion comments and unit test and pytest tests --RR]
endothermicdev
pushed a commit
that referenced
this pull request
May 13, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes #6974 Closes #6976 [Fixed up all the other changes required, including spendable calcualtion comments and unit test and pytest tests --RR]
rustyrussell
pushed a commit
to rustyrussell/lightning
that referenced
this pull request
May 14, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes ElementsProject#6974 Closes ElementsProject#6976 [Fixed up all the other changes required, including spendable calcualtion comments and unit test and pytest tests --RR]
endothermicdev
pushed a commit
to rustyrussell/lightning
that referenced
this pull request
May 14, 2024
The feerate security margin is a multiplicative factor applied to the feerate of some transactions in order to guarantee that the transaction remains publishable and has a sufficient chance of being confirmed, that we can base some of our decisions on that. The multiplicative factor is >=1 and was so far a constant 2. This might have been sensible in the low-fee environment, where the fees are expected to oscillate, and almost guaranteeing that we will eventually have rising feerates but in high-fee environments that is no longer the case, and the 100% margin that the multiplicator 2 brings is excessive. We therefore opt to start out with 100%, then linearly interpolate up to a given maxfeerate (which does not have to be a real feerate ever reached, it just indicates the feerate after which we apply the constant 10% margin. Fixes ElementsProject#6974 Closes ElementsProject#6976 [Fixed up all the other changes required, including spendable calcualtion comments and unit test and pytest tests --RR]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is a quickfix for nodes that have small channels in the current high chainfee environment. CLN currently doubles the current fee rate in order to check whether a htlc can be added. @cdecker proposes a more mathematical approach in this issue #6974. This PR changes the security check to 110% the current fee rate, rather than 200%.